AWS VPN: lokalt og eksternt CIDR - kva side er kva?

Du opnar innstillingane for Site-to-Site VPN, ser to CIDR-felt merkte lokalt og eksternt, og grip etter adressa du oppfattar som lokal: VPC-en. Det er det motsette av kva API-et meiner. I tilkoplingsinnstillingane namngir LocalIpv4NetworkCidr kundegateway-sida, og RemoteIpv4NetworkCidr namngir AWS-sida, fordi tilkoplinga vert bygd frå kundegatewayen. Konsollen seier det aldri høgt, og ingenting avviser ein plausibel ombytting.

Start ved API-kallet, ikkje ved konsoll-etiketten

Les referansen for tilkoplingsinnstillingar ein gong heilt gjennom og legg merke til at kvar innstilling er skriven frå kundegatewayen sitt synspunkt. Det er ikkje ein tilfeldigheit i namngjevinga. Tunnelen vert skildra slik han ser ut for eininga som terminerer han på di side, så lokalt tyder nettet bak gatewayen din og eksternt nettet bak AWS-gatewayen. Både IPv4- og IPv6-felta følgjer same regel.

Skriv dei to etikettene på ein lapp før du tastar noko: kundesida, AWS-sida. Knytt deretter adressene dine til dei.

Eit gjennomrekna døme med rollene

Anta at det lokale prefikset er 10.20.0.0/16 og VPC-prefikset er 10.60.0.0/16. Innstillingane vert lesne nøyaktig slik rollene antydar, med det lokale området i det lokale feltet:

{
  "LocalIpv4NetworkCidr": "10.20.0.0/16",
  "RemoteIpv4NetworkCidr": "10.60.0.0/16"
}

Gi no det same paret til den som konfigurerer peer-eininga, og sjå fella slå til. På mange brannmurar tyder lokalt grensesnittet tunnelen terminerer på, og eksternt den fjerne enden, som er den omvende tilordninga for AWS-sida. Begge kan ha rett og likevel produsere ein tunnel som aldri kjem opp, fordi dei to vokabulari skildrar ulike endepunkt.

Gjenta øvinga på papir i peer-en si terminologi, med begge CIDR-ane og begge etikettene, før nokon eining vert rørd.

Standardverdiar er ikkje eit design

Same referanse listar 0.0.0.0/0 som standard for begge IPv4-felta, med tilsvarande verdiar for IPv6. Å sjå desse verdiane i ei eksisterande tilkopling fortel deg at feltet aldri vart innsnevra, ikkje at det er konfigurert ein internettutgang. Rutedistribusjon, rutetabellen til subnettet og tryggleikskontrollane avgjer framleis kva trafikk som faktisk kan passere; CIDR-verdiane skildrar berre kva område tunnelen er viljug til å velje.

Å erstatte ein snevrare verdi med standarden er derfor ikkje eit kompatibilitetstriks ein kan bruke når ein tunnel oppfører seg feil. Det utvidar veljaren og lèt alle andre lag vere nøyaktig som dei var.

Peer-eininga brukar det andre synspunktet

Når AWS-sida er klar, ligg det meste av den gjenverande forvirringa i peer-konfigurasjonen. Ei eining som spør etter eit lokalt nett og eit eksternt nett, skildrar grensesnittet sitt eige som lokalt, så VPC-området ditt går i det eksterne feltet hennar og det lokale området ditt går i det lokale feltet hennar. Spør ho i staden etter trafikkveljarar i par, skriv du begge retningane eksplisitt, og etikettene tyder mindre enn paringa.

Les felt-hjelpa til eininga i staden for feltnamna. Produsentar brukar dei same to orda for tre ulike omgrep.

Kontroller deretter tunnelstatus for begge fasane, sidan ein veljar som ikkje stemmer vanlegvis viser seg som ein feil i andre fase medan første fase står roleg etablert.

Endre innstillingane som ei endring, ikkje som dokumentasjon

Redigering av tilkoplingsinnstillingar på ein aktiv VPN kan bryte tenesta, så handsam det som ei vedlikehaldshandling med eit vindauge, ein tilbakerullingsverdi og eit notat om kven det gjeld. Ta først opp dei gjeldande innstillingane, inkludert begge CIDR-felta og tunnelinnstillingane, slik at ei tilbakerulling er ei innliming og ikkje ein gjenoppbygging.

Etter endringa, verifiser frå AWS-sida og frå peer-en: ei kjelde i kvart område som når ein destinasjon i det andre, i begge retningar. Ein einaste ping frå éi side beviser éin veljar.

Oppdater deretter tilkoplingsdokumentasjonen med rollene skrivne ut, slik at neste person ikkje må gjenoppdage at lokalt tyder di side.