Skip to content

VPC-ruter ​

En rute sender trafikk til et mål via et neste hopp inne i VPC-en din. Hver VPC har sin egen rutetabell; å legge til en rute er måten du sender trafikk gjennom noe du selv kjører — en VPN-enhet, en brannmur, en proxy — i stedet for veien plattformen gir deg som standard.

Ruter håndteres på VPC-en, under Nettverk → VPC-er → din VPC → Ruter, med fm network vpc route, eller med Terraform-ressursen frostmoln_vpc_route.

List ruter ​

bash
fm network vpc route list <vpc-id>

Dette lister rutene du eier. Ruter plattformen tilbyr, vises ikke — se Ruter du ikke kan se eller endre nedenfor.

Legg til en rute ​

En rute har to deler:

  • Mål — en CIDR-blokk, f.eks. 203.0.113.0/24. En standardrute for IPv4 (0.0.0.0/0) er tillatt; for IPv6 (::/0) tilbys den ikke ennå og blir avvist — skriv IPv6-områdene du trenger som mer spesifikke mål. Skriv målet på kanonisk form: 203.0.113.0/24, ikke 203.0.113.5/24, som blir avvist.
  • Neste hopp — en adresse på et subnett som er koblet til denne VPC-en, av samme adressefamilie som målet, eller det reserverte ordet internet.
bash
fm network vpc route add <vpc-id> --destination 203.0.113.0/24 --next-hop 10.0.1.10
hcl
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"

  # Neste hopp må ligge på et subnett VPC-en allerede har koblet til. Uten dette
  # kan én og samme apply opprette ruten først, og skrivingen blir avvist.
  depends_on = [frostmoln_subnet.app]
}

Neste hopp må være nåbart inne i VPC-en — en adresse på et subnett VPC-en har koblet til, som regel en av instansene dine. Det er ikke et sted på internett, og ikke en adresse i en annen VPC.

En rute gjelder hele VPC-en

En rute treffes bare på målet sitt. Det finnes ingen ruting per avsender i en VPC, så en rute du legger til for én instans tar hver instans i VPC-en samme vei for det målet. Planlegg ruter for VPC-en som helhet; trenger to grupper instanser ulike veier, hører de hjemme i hver sin VPC.

Endre en rute ​

Et mål kan bare ha ett neste hopp, så det finnes ingen redigering. Å legge til en rute nummer to for et mål du allerede ruter, blir avvist. Fjern den og legg den til på nytt for å peke den et annet sted:

bash
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 gjør det samme for deg: hvert argument i frostmoln_vpc_route tvinger fram en erstatning, så å endre next_hop sletter ruten og oppretter den på nytt.

Uansett metode finnes det et opphold mellom de to trinnene der målet ikke har noen rute fra deg, og trafikken følger den mindre spesifikke ruten som er igjen.

Neste hopp internet ​

internet er et reservert ord, ikke en adresse. Det betyr "ut via VPC-ens egen Gateway", og det finnes fordi plattformens egen standardrute ikke har noen adresse du kunne oppgi. Det treffes eksakt og skiller mellom store og små bokstaver — Internet blir avvist.

bash
fm network vpc route add <vpc-id> --destination 198.51.100.7/32 --next-hop internet
hcl
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` krever at VPC-en har en Gateway, så ruten må opprettes etter den.
  depends_on = [frostmoln_gateway.main]
}

Det krever at VPC-en har en internettvendt Gateway. Har VPC-en ingen Gateway, legger du til en og oppretter så ruten. Har den allerede en, men den er en vei for intern tilkobling og ikke mot internett, hjelper det ikke å legge til enda en — bruk i stedet en adresse inne i VPC-en som neste hopp.

På et sted der Gateway-en er IPv4, løses internet til en IPv4-adresse, så et IPv6-mål kan ikke bruke det der — gi en slik rute en adresse inne i VPC-en i stedet.

Trafikk som sendes denne veien går ut via plattformens egen gateway-adresse, som ikke er en du kan se eller beholde. Hvis motparten låser eller hvitelister avsenderadressen din — eller selv oppretter forbindelsen til deg — gi instansen sin egen offentlige IP, og se Gateway.

Sende en VPC gjennom din egen enhet ​

Den vanligste grunnen til å skrive ruter er å legge en VPN- eller brannmurenhet i veien. Det krever to ruter, og den andre er den folk glemmer:

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

# ...bortsett fra enhetens egen tunnel til motparten.
fm network vpc route add <vpc-id> --destination 198.51.100.7/32 --next-hop internet

Uten den andre ruten ødelegger enheten for seg selv: dens egne krypterte pakker til motparten treffer standardruten og sendes tilbake til enheten, som går i løkke. Det unntaket er en /32 og vinner derfor pålitelig over enhver mindre spesifikk rute.

Det samme gjelder alt annet enheten selv trenger å nå. Ruter treffes bare på målet, og enheten er en instans i VPC-en som alle andre, så dens egen trafikk ut mot internett følger standardruten rett tilbake til den. Den beholder det den når gjennom sin egen tunnel og mister resten — pakkespeil, NTP, et API den kaller. Gi hvert slikt mål sin egen rute via internet, eller send den trafikken gjennom tunnelen også.

Unntaket kan ikke peke på en Frostmoln-adresse

Målet til en rute kan ikke ligge innenfor Frostmolns eget offentlige adresseområde, uansett hvilket neste hopp du oppgir — internet inkludert. Er tunnelens motpart selv en offentlig Frostmoln-adresse, en annen VPC av dine egne inkludert, blir unntaksruten altså avvist, og en standardrute gjennom enheten løkker tunneltrafikken dens tilbake til den. Rut heller nettopp de målene du trenger gjennom enheten, og skriv ingen standardrute: enhetens egen trafikk treffer da aldri, og det trengs ikke noe unntak.

Enheten kan bruke hvilken som helst adresse — med en standardrute hvilken som helst adresse i det hele tatt

En instans kan bare videresende for andre hvis plattformen slutter å forkaste pakkene den sender med noen andres avsenderadresse. Plattformen gjør det selv for hver adresse en rute oppgir som neste hopp: du konfigurerer ingenting, det finnes ingenting å be om, og tillatelsen skrives før ruten — en rute hvis tillatelse ikke kan skrives, blir heller ikke skrevet.

Hva den omfatter. Hvert subnett som er tilknyttet denne VPC-en, pluss målet til hver rute som peker på instansen. Målet til en standardrute er hele adresserommet, så en enhet som holder VPC-ens standardrute kan bruke hvilken som helst adresse, ikke bare adresser i VPC-en din.

Hva det koster. Sikkerhetsgruppregler som matcher på en avsenderadresse eller på en avsendende gruppe begrenser ikke lenger den instansen — heller ikke regler som slipper inn en offentlig adresse, som kontoret deres eller en partners område. Den kan i tillegg gjøre krav på en annen instans' adresse på subnettet, slik at trafikk ment for den instansen kan trekkes til enheten i stedet. Dette handler altså ikke bare om hva enheten kan sende.

Hva du bør gjøre i stedet. Ikke bruk avsenderbaserte regler som grense mellom denne instansen og noe som betyr noe. La den være en dedikert enhet og ikke en delt arbeidslastvert, legg det som må beskyttes mot den i en annen VPC, og der den må dele VPC, krev autentisering den ikke kan forfalske. Det finnes ingen egen liste over instansene som har denne tillatelsen: det er nøyaktig mengden neste hopp i fm network vpc route list, så gjennomgå den listen slik du ville gjennomgått en tilgang.

Når den forsvinner. Når du fjerner den siste ruten som oppgir den adressen — det er det eneste som trekker den tilbake. Den er ikke begrenset av instansens levetid. Den utledes til den porten som holder adressen, så erstatter du instansen og den samme adressen kommer tilbake, stopper videresendingen bare til plattformen har utledet den på nytt, normalt innen ti minutter og uten at du trenger å gjøre noe. Kommer erstatningen opp på en annen adresse, ser ruten fortsatt riktig ut og videresender aldri; pek den om. Og gir du en enhets adresse til en annen instans mens ruten står, arver den instansen tillatelsen.

En rute med internet som neste hopp gir ingen tillatelse — dette gjelder bare en rute som oppgir en adresse inne i VPC-en.

Offentlige IP-adresser i denne VPC-en slutter å svare

En standardrute fanger all trafikk som forlater VPC-en, svartrafikken inkludert. En instans med offentlig IP mottar fortsatt innkommende trafikk, men svaret rutes av den samme tabellen — målet er internettklienten, så det treffer standardruten din og går til enheten din i stedet for ut via gatewayen. Offentlige IP-adresser i denne VPC-en slutter å svare så lenge standardruten finnes, og virker igjen når du fjerner den.

Plattformens DNS og forvaltede tjenester fortsetter å virke: de bruker ruter som er mer spesifikke enn en standardrute, og vinner derfor.

En standardrute teller også som to mot VPC-ens rutegrense.

Husk at den andre ruten treffes på målet sitt, så den tar hver instans i VPC-en utenom enheten for akkurat den adressen — ikke bare enheten.

Hvis rutene ser riktige ut og ingenting videresendes ​

Tillatelsen over utledes fra rutene dine, og det finnes noen måter å ende opp med en rute som godtas og likevel ikke videresender noe. Sikkerhetsgrupper har ikke noe med det å gjøre: avsenderfiltreringen på grensesnittet er en annen mekanisme, og en gruppe som tillater alt løsner ikke på den.

  • Neste hopp må være en adresse en instans faktisk har. Det holder at det er en gyldig vertsadresse på et tilknyttet subnett, så en rute som oppgir en adresse ingen har, godtas og videresender stille ingenting. Kontroller den mot adressen på enhetens grensesnitt.
  • Tillatelsen lander på det grensesnittet ruten oppgir, ikke på hele instansen. En enhet med et annet grensesnitt på et annet subnett har den ikke der — går trafikken ut via det grensesnittet, pek en rute på det grensesnittets adresse også.
  • En delt virtuell adresse støttes ikke. To enheter som veksler en VIP mellom seg med keepalived eller VRRP kan ikke fungere: ingen grensesnitt holder VIP-en, så en rute som oppgir den videresender ingenting, og en rute som oppgir en av enhetenes egen adresse følger ikke med ved en overtakelse. Plattformen eier denne tillatelsesmengden og skriver den om i sin helhet fra rutene dine, så å sette den for hånd på grensesnittet er ingen vei rundt det.
  • Høyst ti områder per enhetsadresse. VPC-ens tilknyttede subnett av samme adressefamilie telles først, og en standardrute teller som to, så en VPC med mange subnett kan nå taket med én enkelt rute — åtte tilknyttede subnett ved siden av en standardrute, ni ved siden av en vanlig. Over det avvises ruteskrivingen. Pek noen ruter mot en annen enhet, eller fjern noen. Å slå sammen målene til færre og større områder hjelper bare når det er målene som fyller mengden, og et bredere mål er et bredere område enheten kan bruke som avsenderadresse.

Skriv 0.0.0.0/0, ikke halvdelene

Internt lagrer plattformen en standardrute som to likeverdige halvdeler som til sammen dekker de samme adressene, slik at den vinner helt over plattformens egen standardrute i stedet for å dele trafikken med den. Du trenger aldri å tenke på dette: du skriver 0.0.0.0/0, du leser tilbake 0.0.0.0/0, og å skrive eller fjerne én av halvdelene direkte blir avvist. Det er med vilje — at en rute du skrev kommer tilbake som en annen, er nettopp det som ødelegger et verktøy som konvergerer mot rutene du har erklært.

Ruter du ikke kan se eller endre ​

Noen ruter tilhører plattformen. De er måten en VPC når plattformens DNS og administrerte tjenester på, og måten en VPC med Gateway når internett på.

De listes ikke blant rutene dine, de kan ikke fjernes, og et mål eller neste hopp som kolliderer med en av dem blir avvist. Det er med vilje: å vise en rute du uansett ikke kunne slette ville vært verre enn ikke å vise den.

To følger verdt å kjenne til:

  • Et mål innenfor et område plattformen ruter, avvises permanent, og det gjør også ethvert mål innenfor Frostmolns eget offentlige adresseområde — en annen kundes offentlige adresse så vel som din egen, uansett hvilket neste hopp du oppgir. Å prøve igjen hjelper ikke. Velg et mål i ditt eget adresserom, eller nå den adressen via VPC-ens vanlige vei i stedet for en rute av dine egne.
  • Har VPC-en din en internettvendt Gateway, sender den allerede all annen trafikk til internett. En 0.0.0.0/0-rute via internet blir derfor avvist — det er ingenting å legge til. Vil du lede VPC-en gjennom din egen enhet, peker du standardruten mot en adresse inne i VPC-en, som over — les merknaden i den seksjonen først.

Et mål som er, eller ligger inne i, et subnett koblet til denne VPC-en blir også avvist: det subnettet leverer det allerede direkte, uten rute.

Fjern en rute ​

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

Å fjerne en rute tar bort veien instansene brukte for det målet. Trafikken følger deretter den mindre spesifikke ruten som er igjen — plattformens egen standardrute, hvis VPC-en har en Gateway, eller ingen i det hele tatt hvis den ikke har det.

Fordi en fjerning utføres ved å skrive hele VPC-ens gjenværende rutesett på nytt, kontrolleres hver rute i det på nytt — så en fjerning kan bli avvist på grunn av en rute du allerede hadde framfor den du fjerner, og løsningen er å liste rutene og rette eller fjerne den.

En standardrute fjernes i sin helhet. 0.0.0.0/0 tar bort begge radene plattformen lagrer den som, i én skriving, eller ingen av dem — så en fjerning kan ikke etterlate en halv standardrute. Når den fjernes, går utgående trafikk tilbake til VPC-ens egen Gateway, og offentlige IP-adresser på instanser her begynner å svare igjen.

Grenser ​

Det er en grense for hvor mange ruter en VPC kan ha. Den teller dine ruter; plattformens egne bruker ingenting av den. Den samme grensen gjelder hver VPC på plattformen framfor å settes per kunde, så er den virkelig for lav for det du bygger, kontakt support.

Av samme grunn blir en fjerning avvist hvis VPC-ens lagrede ruter allerede er over grensen: settet er fortsatt over den når én rute er fjernet. Å fjerne dem én om gangen kan ikke komme under grensen igjen, så kontakt support for å få settet erstattet i én enkelt skriving.

En standardrute teller som to, fordi plattformen lagrer den som to halvdeler — så én 0.0.0.0/0 i listen din bruker to av kvoten.

Relatert ​