VPC-ruter

En rute sender trafik til en destination via et næste hop inde i din VPC. Hver VPC har sin egen rutetabel; at tilføje en rute er måden, hvorpå du sender trafik gennem noget, du selv kører — en VPN-enhed, en firewall, en proxy — i stedet for den vej, platformen giver dig som standard.

Ruter administreres på VPC'en, under Netværk → VPC'er → din VPC → Ruter, med fm network vpc route eller med Terraform-ressourcen frostmoln_vpc_route.

Vis ruter

fm network vpc route list <vpc-id>

Dette viser de ruter, du ejer. Ruter, som platformen stiller til rådighed, vises ikke — se Ruter du ikke kan se eller ændre nedenfor.

Tilføj en rute

En rute har to dele:

• Destination — en CIDR-blok, f.eks. 203.0.113.0/24. En standardrute for IPv4 (0.0.0.0/0) er tilladt; en for IPv6 (::/0) tilbydes endnu ikke og afvises — skriv de IPv6-intervaller, du har brug for, som mere specifikke destinationer. Skriv destinationen på kanonisk form: 203.0.113.0/24, ikke 203.0.113.5/24, som afvises.
• Næste hop — en adresse på et subnet, der er tilknyttet denne VPC, af samme adressefamilie som destinationen, eller det reserverede ord internet.

fm network vpc route add <vpc-id> --destination 203.0.113.0/24 --next-hop 10.0.1.10

resource "frostmoln_subnet" "app" {
  name   = "app"
  cidr   = "10.0.1.0/24"
  vpc_id = frostmoln_vpc.main.id
  zone   = "falkenberg"
}

resource "frostmoln_vpc_route" "partner" {
  vpc_id      = frostmoln_vpc.main.id
  destination = "203.0.113.0/24"
  next_hop    = "10.0.1.10"

  # Næste hop skal ligge på et subnet, VPC'en allerede har tilknyttet. Uden dette kan
  # én og samme apply oprette ruten først, og skrivningen afvises.
  depends_on = [frostmoln_subnet.app]
}

Næste hop skal være nåbart inde i VPC'en — en adresse på et subnet, som VPC'en har tilknyttet, som regel en af dine instanser. Det er ikke et sted på internettet, og det er ikke en adresse i en anden VPC.

En rute gælder hele VPC'en

En rute matches kun på sin destination. Der findes ingen routing per afsender i en VPC, så en rute, du tilføjer for én instans, tager hver instans i VPC'en samme vej for den destination. Planlæg ruter for VPC'en som helhed; har to grupper af instanser brug for forskellige veje, hører de hjemme i hver sin VPC.

Ændr en rute

En destination kan kun have ét næste hop, så der findes ingen redigering. At tilføje endnu en rute for en destination, du allerede ruter, afvises. For at pege en rute et andet sted hen fjerner du den og tilføjer den igen:

fm network vpc route remove <vpc-id> 203.0.113.0/24
fm network vpc route add <vpc-id> --destination 203.0.113.0/24 --next-hop 10.0.1.20

Terraform gør det samme for dig: hvert argument i frostmoln_vpc_route fremtvinger en erstatning, så at ændre next_hop sletter ruten og opretter den på ny.

Uanset metoden er der et hul mellem de to trin, hvor den destination ikke har nogen rute fra dig, og trafikken følger den mindre specifikke rute, der er tilbage.

Næste hop internet

internet er et reserveret ord, ikke en adresse. Det betyder "ud via VPC'ens egen Gateway", og det findes, fordi platformens egen standardrute ikke har nogen adresse, du kunne angive. Det matches præcist og skelner mellem store og små bogstaver — Internet afvises.

fm network vpc route add <vpc-id> --destination 198.51.100.7/32 --next-hop internet

resource "frostmoln_gateway" "main" {
  vpc_id = frostmoln_vpc.main.id
  mode   = "public_ip"
}

resource "frostmoln_vpc_route" "peer_exception" {
  vpc_id      = frostmoln_vpc.main.id
  destination = "198.51.100.7/32"
  next_hop    = "internet"

  # `internet` kræver, at VPC'en har en Gateway, så ruten skal oprettes efter den.
  depends_on = [frostmoln_gateway.main]
}

Det kræver, at VPC'en har en internetvendt Gateway. Har VPC'en ingen Gateway, tilføjer du en og opretter derefter ruten. Har den allerede en, men den er en vej til intern forbindelse snarere end mod internettet, hjælper det ikke at tilføje endnu en — brug i stedet en adresse inde i VPC'en som næste hop.

På et sted, hvis Gateway er IPv4, oversættes internet til en IPv4-adresse, så en IPv6-destination kan ikke bruge det der — giv en sådan rute en adresse inde i VPC'en i stedet.

Trafik, der sendes denne vej, forlader netværket via platformens egen gateway-adresse, som ikke er en, du kan se eller beholde. Hvis modparten låser sig fast på eller kun tillader din kildeadresse — eller selv opretter forbindelsen til dig — så giv i stedet instansen sin egen offentlige IP-adresse, og se Gateway.

Send en VPC gennem din egen enhed

Den mest almindelige grund til at skrive ruter er at lægge en VPN- eller firewallenhed i vejen. Det kræver to ruter, og den anden er den, folk glemmer:

# Send trafikken gennem enheden...
fm network vpc route add <vpc-id> --destination 0.0.0.0/0 --next-hop 10.0.1.10

# ...bortset fra enhedens egen tunnel til dens fjerne modpart.
fm network vpc route add <vpc-id> --destination 198.51.100.7/32 --next-hop internet

Uden den anden rute ødelægger enheden det for sig selv: dens egne krypterede pakker til modparten matcher standardruten og sendes tilbage til enheden, som går i løkke. Den undtagelse er en /32 og vinder derfor pålideligt over enhver mindre specifik rute.

Det samme gælder alt andet, enheden selv har brug for at nå. Ruter matches kun på destinationen, og enheden er en instans i VPC'en som alle andre, så dens egen trafik ud mod internettet følger standardruten direkte tilbage til den. Den beholder det, den når gennem sin egen tunnel, og mister resten — pakkespejle, NTP, et API den kalder. Giv hver sådan destination sin egen rute via internet, eller send også den trafik gennem tunnelen.

Undtagelsen må ikke pege på en Frostmoln-adresse

En rutes destination må ikke ligge inden for Frostmolns eget offentlige adresseinterval, uanset hvilket næste hop du angiver — internet inklusive. Er tunnelens fjerne modpart selv en offentlig Frostmoln-IP-adresse, en anden af dine egne VPC'er inklusive, afvises undtagelsesruten altså, og en standardrute gennem enheden sender dens tunneltrafik i løkke tilbage til den. Rut i stedet netop de destinationer, du har brug for, gennem enheden frem for at skrive en standardrute: enhedens egen trafik matcher så aldrig, og der er ikke brug for nogen undtagelse.

Enheden må bruge enhver kildeadresse — med en standardrute enhver adresse overhovedet

En instans kan kun videresende for andre, hvis platformen holder op med at kassere de pakker, den sender med en andens kildeadresse. Platformen gør det af sig selv for hver adresse, en rute angiver som næste hop: du konfigurerer intet, der er intet at anmode om, og tilladelsen skrives før ruten — en rute, hvis tilladelse ikke kan skrives, skrives heller ikke selv.

Hvad den omfatter. Hvert subnet, der er tilknyttet denne VPC, plus destinationen for hver rute, der peger på den instans. En standardrutes destination er hele adresserummet, så en enhed, der holder denne VPC's standardrute, må bruge enhver adresse overhovedet, ikke kun adresser i din VPC.

Hvad det koster. Sikkerhedsgrupperegler, der matcher på en kildeadresse eller på en kildegruppe, begrænser ikke længere den instans — heller ikke regler, der giver en offentlig adresse adgang, såsom jeres kontor eller en partners interval. Den kan desuden gøre krav på en anden instans' adresse på subnettet, så trafik, der er tiltænkt den instans, kan trækkes til enheden i stedet. Det handler altså ikke kun om, hvad enheden kan sende.

Hvad du bør gøre i stedet. Brug ikke kildebaserede regler som grænse mellem denne instans og noget, der betyder noget. Lad den være en dedikeret enhed frem for en delt vært for arbejdslaster, læg det, der skal beskyttes mod den, i en anden VPC, og kræv autentificering, den ikke kan forfalske, der hvor den er nødt til at dele VPC. Der findes ingen separat liste over de instanser, der har denne tilladelse: det er præcis mængden af næste hop i fm network vpc route list, så gennemgå den liste, som du ville gennemgå en tildelt adgang.

Hvornår den forsvinder. Når du fjerner den sidste rute, der angiver den adresse — det er det eneste, der trækker den tilbage. Den er ikke begrænset af instansens levetid. Den udledes til den port, der holder adressen, så erstatter du instansen, og den samme adresse kommer tilbage, stopper videresendelsen kun, indtil platformen har udledt den igen, normalt inden for ti minutter og uden at du skal gøre noget. Kommer erstatningen op på en anden adresse, ser ruten stadig rigtig ud og videresender aldrig; peg den om. Og giver du en enheds adresse til en anden instans, mens ruten står, arver den instans tilladelsen.

En rute, hvis næste hop er internet, giver ingen tilladelse — dette gælder kun en rute, der angiver en adresse inde i VPC'en.

Offentlige IP-adresser i denne VPC holder op med at svare

En standardrute fanger al trafik, der forlader VPC'en, svartrafikken inklusive. En instans med en offentlig IP-adresse modtager stadig indgående trafik, men svaret rutes af den samme tabel — destinationen er internetklienten, så det matcher din standardrute og går til din enhed i stedet for ud via gatewayen. Offentlige IP-adresser i denne VPC holder op med at svare, så længe standardruten findes, og virker igen, når du fjerner den.

Platformens DNS og administrerede tjenester bliver ved med at virke: de bruger ruter, der er mere specifikke end en standardrute, og vinder derfor.

En standardrute tæller også som to mod denne VPC's rutegrænse.

Husk, at den anden rute matches på sin destination, så den tager hver instans i VPC'en uden om enheden for netop den adresse — ikke kun enheden.

Hvis ruterne ser rigtige ud, og intet videresendes

Tilladelsen ovenfor udledes af dine ruter, og der er nogle få måder at ende med en rute, der accepteres og ikke videresender noget. Sikkerhedsgrupper har intet med sagen at gøre: kildefiltreringen på interfacet er en anden mekanisme, og en gruppe, der tillader alt, løsner ikke på den.

• Næste hop skal være en adresse, en instans faktisk har. Det er nok, at det er en gyldig værtsadresse på et tilknyttet subnet, så en rute, der angiver en adresse, ingen har, accepteres og videresender stille og roligt ingenting. Kontroller den mod adressen på enhedens interface.
• Tilladelsen lander på det interface, ruten angiver, ikke på hele instansen. En enhed med et andet interface på et andet subnet har den ikke der — forlader trafikken netværket via det interface, så peg også en rute på det interfaces adresse.
• En delt virtuel adresse understøttes ikke. To enheder, der lader en VIP skifte mellem sig med keepalived eller VRRP, kan ikke fungere: intet interface holder VIP'en, så en rute, der angiver den, videresender ingenting, og en rute, der angiver den ene enheds egen adresse, følger ikke med ved et skifte. Platformen ejer denne tilladelsesmængde og skriver den om i sin helhed ud fra dine ruter, så at sætte den i hånden på interfacet er ingen vej uden om det.
• Højst ti intervaller per enhedsadresse. VPC'ens tilknyttede subnets af samme adressefamilie tælles først, og en standardrute tæller som to, så en VPC med mange subnets kan nå loftet med en enkelt rute — otte tilknyttede subnets ved siden af en standardrute, ni ved siden af en almindelig. Derover afvises ruteskrivningen. Peg nogle ruter mod en anden enhed, eller fjern nogle. At slå destinationer sammen til færre og større intervaller hjælper kun, når det er destinationerne, der fylder mængden, og en bredere destination er et bredere interval, enheden må bruge som kildeadresse.

Skriv 0.0.0.0/0, ikke halvdelene

Internt lagrer platformen en standardrute som to ligeværdige halvdele, der tilsammen dækker de samme adresser, så den vinder helt over platformens egen standardrute frem for at dele trafikken med den. Du behøver aldrig at tænke på dette: du skriver 0.0.0.0/0, du læser 0.0.0.0/0 tilbage, og at skrive eller slette en af halvdelene direkte afvises. Det er med vilje — at en rute, du skrev, kommer tilbage som en anden, er præcis det, der ødelægger et værktøj, som konvergerer mod de ruter, du har erklæret.

Ruter du ikke kan se eller ændre

Nogle ruter tilhører platformen. De er måden, hvorpå en VPC når platformens DNS og administrerede tjenester, og måden, hvorpå en VPC med en Gateway når internettet.

De vises ikke blandt dine ruter, de kan ikke fjernes, og en destination eller et næste hop, der kolliderer med en af dem, afvises. Det er med vilje: at vise dig en rute, du alligevel ikke kunne slette, ville være værre end ikke at vise den.

To følger er værd at kende:

• En destination inden for et interval, platformen ruter, afvises permanent, og det samme gør enhver destination inden for Frostmolns eget offentlige adresseinterval — en anden kundes offentlige IP-adresse såvel som din egen, uanset hvilket næste hop du angiver. At prøve igen hjælper ikke. Vælg en destination i dit eget adresserum, eller nå den adresse via VPC'ens normale vej frem for en rute af dine egne.
• Har din VPC en internetvendt Gateway, sender den allerede alt andet til internettet. En 0.0.0.0/0-rute via internet afvises derfor — der er intet at tilføje. Vil du lede VPC'en gennem din egen enhed, peger du standardruten mod en adresse inde i VPC'en, som ovenfor — og læs noten i det afsnit først.

En destination, der er, eller ligger inden for, et subnet tilknyttet denne VPC, afvises også: det subnet leverer den allerede direkte, uden en rute.

Fjern en rute

fm network vpc route remove <vpc-id> 203.0.113.0/24

At fjerne en rute tager den vej væk, som instanserne brugte til den destination. Trafikken følger derefter den mindre specifikke rute, der er tilbage — platformens egen standardrute, hvis VPC'en har en Gateway, eller slet ingen, hvis den ikke har.

Fordi en fjernelse udføres ved at skrive hele VPC'ens resterende rutesæt, kontrolleres hver rute i det igen — så en fjernelse kan blive afvist på grund af en rute, du allerede havde, frem for den, du er ved at fjerne, og løsningen er at vise ruterne og rette eller fjerne den.

En standardrute fjernes i sin helhed. 0.0.0.0/0 fjerner begge de rækker, platformen lagrer den som, i én skrivning, eller ingen af dem — så en fjernelse kan ikke efterlade en halv standardrute. Når den fjernes, gives udgående trafik tilbage til denne VPC's egen Gateway, og offentlige IP-adresser på instanser her begynder at svare igen.

Grænser

Der er en grænse for, hvor mange ruter en VPC kan have. Den tæller dine ruter; platformens egne bruger intet af den. Den samme grænse gælder hver VPC på platformen frem for at blive sat per kunde, så er den virkelig for lav til det, du bygger, så kontakt support.

Af samme grund afvises en fjernelse, hvis VPC'ens lagrede ruter allerede er over grænsen: sættet er stadig over den, når én rute er væk. At fjerne dem én ad gangen kan ikke komme under grænsen igen, så kontakt support for at få sættet erstattet i én enkelt skrivning.

En standardrute tæller som to, fordi platformen lagrer den som to halvdele — så én 0.0.0.0/0 i din liste bruger to af kvoten.

Relateret

• VPC'er · Gateway · Offentlige IP-adresser · Sikkerhedsgrupper