VPC-rutter

En rutt skickar trafik till en destination via ett nästa hopp inuti din VPC. Varje VPC har en egen rutttabell; att lägga till en rutt är hur du skickar trafik genom något du själv kör — en VPN-apparat, en brandvägg, en proxy — i stället för den väg plattformen ger dig som standard.

Rutter hanteras på VPC:n, under Nätverk → VPC:er → din VPC → Rutter, med fm network vpc route, eller med Terraform-resursen frostmoln_vpc_route.

Lista rutter

fm network vpc route list <vpc-id>

Detta listar de rutter du äger. Rutter som plattformen tillhandahåller visas inte — se Rutter du inte kan se eller ändra nedan.

Lägg till en rutt

En rutt har två delar:

• Destination — ett CIDR-block, t.ex. 203.0.113.0/24. En standardrutt för IPv4 (0.0.0.0/0) är tillåten; för IPv6 (::/0) erbjuds den inte ännu och avvisas — skriv de IPv6-intervall du behöver som mer specifika destinationer. Skriv destinationen i kanonisk form: 203.0.113.0/24, inte 203.0.113.5/24, som avvisas.
• Nästa hopp — en adress på ett subnät som är anslutet till denna VPC, av samma adressfamilj som destinationen, eller det reserverade ordet 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ästa hopp måste ligga på ett subnät som VPC:n redan anslutit. Utan detta kan
  # en och samma apply skapa rutten först, och skrivningen avvisas.
  depends_on = [frostmoln_subnet.app]
}

Nästa hopp måste vara nåbart inuti VPC:n — en adress på ett subnät som VPC:n har anslutit, oftast en av dina instanser. Det är inte någonstans på internet, och inte en adress i en annan VPC.

En rutt gäller hela VPC:n

En rutt matchas enbart på sin destination. Det finns ingen routing per avsändare i en VPC, så en rutt du lägger till för en instans tar varje instans i VPC:n samma väg för den destinationen. Planera rutter för VPC:n som helhet; om två grupper av instanser behöver olika vägar hör de hemma i olika VPC:er.

Ändra en rutt

En destination kan bara ha ett nästa hopp, så det går inte att redigera. Att lägga till en andra rutt för en destination du redan dirigerar avvisas. Ta bort den och lägg till den igen för att peka om den:

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 samma sak åt dig: varje argument i frostmoln_vpc_route tvingar fram en ersättning, så att ändra next_hop tar bort rutten och skapar den på nytt.

Hur du än gör finns det en lucka mellan de två stegen där destinationen inte har någon rutt av dig, och trafiken följer den mindre specifika rutt som återstår.

Nästa hopp internet

internet är ett reserverat ord, inte en adress. Det betyder "ut via VPC:ns egen Gateway", och det finns eftersom plattformens egen standardrutt inte har någon adress du skulle kunna ange. Det matchas exakt och är skiftlägeskänsligt — Internet avvisas.

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 att VPC:n har en Gateway, så rutten måste skapas efter den.
  depends_on = [frostmoln_gateway.main]
}

Det kräver att VPC:n har en internetvänd Gateway. Har VPC:n ingen Gateway lägger du till en och skapar sedan rutten. Har den redan en, men den är en väg för intern anslutning snarare än mot internet, hjälper det inte att lägga till ännu en — använd i stället en adress inuti VPC:n som nästa hopp.

På en plats vars Gateway är IPv4 löser internet upp till en IPv4-adress, så en IPv6-destination kan inte använda det där — ge en sådan rutt en adress inuti VPC:n i stället.

Trafik som skickas den här vägen lämnar via plattformens egen gateway-adress, som inte är en du kan se eller behålla. Om motparten låser eller vitlistar din avsändaradress — eller själv initierar anslutningen till dig — ska instansen i stället ha en egen publik IP, se Gateway.

Skicka en VPC genom din egen apparat

Det vanligaste skälet att skriva rutter är att lägga en VPN- eller brandväggsapparat i vägen. Det kräver två rutter, och den andra är den som oftast glöms:

# Skicka trafiken genom apparaten...
fm network vpc route add <vpc-id> --destination 0.0.0.0/0 --next-hop 10.0.1.10

# ...utom apparatens egen tunnel till sin motpart.
fm network vpc route add <vpc-id> --destination 198.51.100.7/32 --next-hop internet

Utan den andra rutten sätter apparaten stopp för sig själv: dess egna krypterade paket till motparten matchar standardrutten och skickas tillbaka till apparaten, som går i loop. Det undantaget är en /32 och vinner därför tillförlitligt över varje mindre specifik rutt.

Detsamma gäller allt annat apparaten själv behöver nå. Rutter matchas bara på destinationen, och apparaten är en instans i VPC:n som vilken annan som helst, så dess egen trafik ut mot internet följer standardrutten rakt tillbaka till den. Den behåller det den når genom sin egen tunnel och förlorar resten — paketspeglar, NTP, ett API den anropar. Ge varje sådan destination en egen rutt via internet, eller skicka den trafiken genom tunneln också.

Undantaget kan inte peka på en Frostmoln-adress

En rutts destination får inte ligga inom Frostmolns eget publika adressintervall, oavsett vilket nästa hopp du anger — internet inräknat. Är tunnelns motpart själv en publik Frostmoln-adress, en annan egen VPC inräknad, avvisas alltså undantagsrutten, och en standardrutt genom apparaten loopar tillbaka dess tunneltrafik till den. Rutta i stället just de destinationer du behöver genom apparaten och skriv ingen standardrutt: apparatens egen trafik matchar då aldrig, och inget undantag behövs.

Apparaten kan använda vilken adress som helst — med en standardrutt vilken adress som helst i världen

En instans kan bara vidarebefordra åt andra om plattformen slutar förkasta de paket den skickar med någon annans avsändaradress. Plattformen gör det själv för varje adress som en rutt anger som nästa hopp: du konfigurerar ingenting, det finns inget att begära, och tillståndet skrivs före rutten — en rutt vars tillstånd inte kan skrivas skrivs inte heller.

Vad det omfattar. Varje subnät som är anslutet till denna VPC, plus destinationen för varje rutt som pekar på instansen. En standardrutts destination är hela adressrymden, så en apparat som håller VPC:ns standardrutt kan använda vilken adress som helst, inte bara adresser i din VPC.

Vad det kostar. Säkerhetsgruppsregler som matchar på en avsändaradress eller på en avsändande grupp begränsar inte längre den instansen — inte heller regler som släpper in en publik adress, till exempel ert kontor eller en partners intervall. Den kan dessutom göra anspråk på en annan instans adress på subnätet, så trafik avsedd för den instansen kan dras till apparaten i stället. Det handlar alltså inte bara om vad apparaten kan skicka.

Vad du bör göra i stället. Använd inte avsändarbaserade regler som gräns mellan den här instansen och något som betyder något. Låt den vara en dedikerad apparat och inte en delad arbetslastvärd, lägg det som måste skyddas från den i en annan VPC, och där den måste dela VPC, kräv autentisering den inte kan förfalska. Det finns ingen separat lista över de instanser som har det här tillståndet: det är exakt mängden nästa hopp i fm network vpc route list, så granska den listan som du skulle granska en behörighet.

När det försvinner. När du tar bort den sista rutten som anger den adressen — det är det enda som drar tillbaka det. Det är inte begränsat av instansens livslängd. Det härleds till den port som håller adressen, så om du ersätter instansen och samma adress kommer tillbaka slutar vidarebefordran bara tills plattformen härlett det på nytt, normalt inom tio minuter och utan att du behöver göra något. Kommer ersättaren upp på en annan adress ser rutten fortfarande riktig ut och vidarebefordrar aldrig; peka om den. Och ger du en apparats adress till någon annan instans medan rutten står kvar ärver den instansen tillståndet.

En rutt vars nästa hopp är internet ger inget tillstånd — detta gäller bara en rutt som anger en adress inne i VPC:n.

Publika IP-adresser i denna VPC slutar svara

En standardrutt fångar all trafik som lämnar VPC:n, svarstrafiken inräknad. En instans med en publik IP-adress tar fortfarande emot inkommande trafik, men svaret ruttas av samma tabell — destinationen är internetklienten, så det matchar din standardrutt och går till din apparat i stället för ut via gatewayen. Publika IP-adresser i denna VPC slutar svara så länge standardrutten finns, och fungerar igen när du tar bort den.

Plattformens DNS och hanterade tjänster fortsätter att fungera: de använder rutter som är mer specifika än en standardrutt och vinner därför.

En standardrutt räknas också som två mot VPC:ns ruttgräns.

Kom ihåg att den andra rutten matchas på sin destination, så den tar varje instans i VPC:n förbi apparaten för just den adressen — inte bara apparaten.

Om rutterna ser rätt ut och ingenting vidarebefordras

Tillståndet ovan härleds ur dina rutter, och det finns några sätt att hamna med en rutt som accepteras och ändå inte vidarebefordrar något. Säkerhetsgrupper har inte med saken att göra: avsändarfiltreringen på gränssnittet är en annan mekanism, och en grupp som tillåter allt mjukar inte upp den.

• Nästa hopp måste vara en adress som en instans faktiskt har. Det räcker att det är en giltig värdadress på ett anslutet subnät, så en rutt som anger en adress ingen har accepteras och vidarebefordrar tyst ingenting. Stäm av den mot adressen på apparatens gränssnitt.
• Tillståndet landar på det gränssnitt rutten anger, inte på hela instansen. En apparat med ett andra gränssnitt på ett annat subnät har det inte där — lämnar trafiken via det gränssnittet, peka en rutt på det gränssnittets adress också.
• En delad virtuell adress stöds inte. Två apparater som växlar en VIP mellan sig med keepalived eller VRRP kan inte fungera: inget gränssnitt har VIP:en, så en rutt som anger den vidarebefordrar ingenting, och en rutt som anger en av apparaternas egen adress följer inte med vid en växling. Plattformen äger den här tillståndsmängden och skriver om den i sin helhet ur dina rutter, så att sätta den för hand på gränssnittet är ingen väg runt det.
• Högst tio intervall per apparatadress. VPC:ns anslutna subnät av samma adressfamilj räknas först, och en standardrutt räknas som två, så en VPC med många subnät kan nå taket med en enda rutt — åtta anslutna subnät vid sidan av en standardrutt, nio vid sidan av en vanlig. Över det avvisas ruttskrivningen. Peka några rutter på en andra apparat, eller ta bort några. Att slå ihop destinationerna till färre och större intervall hjälper bara när det är destinationerna som fyller mängden, och en bredare destination är ett bredare intervall apparaten får använda som avsändaradress.

Skriv 0.0.0.0/0, inte halvorna

Internt lagrar plattformen en standardrutt som två likvärdiga halvor som tillsammans täcker samma adresser, så att den vinner helt över plattformens egen standardrutt i stället för att dela trafiken med den. Du behöver aldrig tänka på det: du skriver 0.0.0.0/0, du läser tillbaka 0.0.0.0/0, och att skriva eller ta bort en av halvorna direkt avvisas. Det är avsiktligt — att en rutt du skrev kommer tillbaka som en annan är precis det som bryter ett verktyg som konvergerar mot de rutter du deklarerat.

Rutter du inte kan se eller ändra

Vissa rutter tillhör plattformen. De är hur en VPC når plattformens DNS och hanterade tjänster, och hur en VPC med Gateway når internet.

De listas inte bland dina rutter, de kan inte tas bort, och en destination eller ett nästa hopp som krockar med en av dem avvisas. Det är avsiktligt: att visa en rutt du ändå inte kunde ta bort vore sämre än att inte visa den alls.

Två följder värda att känna till:

• En destination inom ett intervall som plattformen dirigerar avvisas permanent, och det gör också varje destination inom Frostmolns eget publika adressintervall — en annan kunds publika adress såväl som din egen, oavsett vilket nästa hopp du anger. Att försöka igen hjälper inte. Välj en destination i ditt eget adressutrymme, eller nå den adressen via VPC:ns vanliga väg i stället för en egen rutt.
• Om din VPC har en internetvänd Gateway skickar den redan all övrig trafik till internet. En 0.0.0.0/0-rutt via internet avvisas därför — det finns inget att lägga till. Vill du leda VPC:n genom din egen apparat pekar du standardrutten mot en adress inuti VPC:n, som ovan — läs notisen i det avsnittet först.

En destination som är, eller ligger inom, ett subnät anslutet till denna VPC avvisas också: det subnätet levererar den redan direkt, utan rutt.

Ta bort en rutt

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

Att ta bort en rutt tar bort vägen instanserna använde för den destinationen. Trafiken följer sedan den mindre specifika rutt som återstår — plattformens egen standardrutt, om VPC:n har en Gateway, eller ingen alls om den inte har det.

Eftersom en borttagning utförs genom att hela VPC:ns återstående ruttuppsättning skrivs om kontrolleras varje rutt i den på nytt — så en borttagning kan avvisas på grund av en rutt du redan hade snarare än den du tar bort, och lösningen är att lista rutterna och rätta eller ta bort den.

En standardrutt tas bort i sin helhet. 0.0.0.0/0 tar bort båda de rader plattformen lagrar den som, i en enda skrivning, eller ingen av dem — så en borttagning kan inte lämna en halv standardrutt kvar. När den tas bort går utgående trafik tillbaka till VPC:ns egen Gateway, och publika IP-adresser på instanser här börjar svara igen.

Gränser

Det finns en gräns för hur många rutter en VPC kan ha. Den räknar dina rutter; plattformens egna förbrukar inget av den. Samma gräns gäller varje VPC på plattformen snarare än att sättas per kund, så om den verkligen är för låg för det du bygger, kontakta supporten.

Av samma skäl avvisas en borttagning om VPC:ns lagrade rutter redan ligger över gränsen: uppsättningen ligger fortfarande över den när en rutt tagits bort. Att ta bort dem en i taget kan inte komma under gränsen igen, så kontakta supporten för att få uppsättningen ersatt i en enda skrivning.

En standardrutt räknas som två, eftersom plattformen lagrar den som två halvor — så en 0.0.0.0/0 i din lista använder två av utrymmet.

Relaterat

• VPC:er · Gateway · Publika IP-adresser · Säkerhetsgrupper