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

Du åpner innstillingene for Site-to-Site VPN, ser to CIDR-felter merket lokalt og eksternt, og griper etter adressen du oppfatter som lokal: VPC-en. Det er det motsatte av hva API-et mener. I tilkoblingsinnstillingene navngir LocalIpv4NetworkCidr kundegateway-siden, og RemoteIpv4NetworkCidr navngir AWS-siden, fordi tilkoblingen bygges fra kundegatewayen. Konsollen sier det aldri høyt, og ingenting avviser en plausibel ombytting.

Start ved API-kallet, ikke ved konsoll-etiketten

Les referansen for tilkoblingsinnstillinger én gang helt gjennom og legg merke til at hver innstilling er skrevet fra kundegatewayens synspunkt. Det er ikke en tilfeldighet i navngivningen. Tunnelen beskrives slik den ser ut for enheten som terminerer den på din side, så lokalt betyr nettet bak gatewayen din og eksternt nettet bak AWS-gatewayen. Både IPv4- og IPv6-feltene følger samme regel.

Skriv de to etikettene på en lapp før du taster noe: kundesiden, AWS-siden. Knytt deretter adressene dine til dem.

Et gjennomregnet eksempel med rollene

Anta at det lokale prefikset er 10.20.0.0/16 og VPC-prefikset er 10.60.0.0/16. Innstillingene leses nøyaktig slik rollene antyder, med det lokale området i det lokale feltet:

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

Gi nå det samme paret til den som konfigurerer peer-enheten, og se fellen slå til. På mange brannmurer betyr lokalt grensesnittet tunnelen terminerer på, og eksternt den fjerne enden, som er den omvendte tilordningen for AWS-siden. Begge kan ha rett og likevel produsere en tunnel som aldri kommer opp, fordi de to vokabularene beskriver forskjellige endepunkter.

Gjenta øvelsen på papir i peerens terminologi, med begge CIDR-ene og begge etikettene, før noen enhet røres.

Standardverdier er ikke et design

Samme referanse lister 0.0.0.0/0 som standard for begge IPv4-feltene, med tilsvarende verdier for IPv6. Å se disse verdiene i en eksisterende tilkobling forteller deg at feltet aldri ble innsnevret, ikke at det er konfigurert en internettutgang. Rutedistribusjon, subnettets rutetabell og sikkerhetskontrollene avgjør fortsatt hvilken trafikk som faktisk kan passere; CIDR-verdiene beskriver bare hvilke områder tunnelen er villig til å velge.

Å erstatte en snevrere verdi med standarden er derfor ikke et kompatibilitetstriks man kan bruke når en tunnel oppfører seg feil. Det utvider velgeren og lar alle andre lag være nøyaktig som de var.

Peer-enheten bruker det andre synspunktet

Når AWS-siden er klar, ligger det meste av den gjenværende forvirringen i peer-konfigurasjonen. En enhet som spør etter et lokalt nett og et eksternt nett, beskriver sitt eget grensesnitt som lokalt, så VPC-området ditt går i dens eksterne felt og det lokale området ditt går i dens lokale felt. Spør den i stedet etter trafikkvelgere i par, skriver du begge retningene eksplisitt, og etikettene betyr mindre enn paringen.

Les enhetens felt-hjelp i stedet for feltnavnene. Produsenter gjenbruker de samme to ordene for tre forskjellige begreper.

Kontroller deretter tunnelstatus for begge faser, siden en velger som ikke stemmer vanligvis vises som en feil i andre fase mens første fase står rolig etablert.

Endre innstillingene som en endring, ikke som dokumentasjon

Redigering av tilkoblingsinnstillinger på en aktiv VPN kan avbryte tjenesten, så behandle det som en vedlikeholdshandling med et vindu, en tilbakerullingsverdi og et notat om hvem det gjelder. Ta først opp de gjeldende innstillingene, inkludert begge CIDR-feltene og tunnelinnstillingene, slik at en tilbakerulling er en innliming og ikke en gjenoppbygging.

Etter endringen, verifiser fra AWS-siden og fra peer-en: en kilde i hvert område som når en destinasjon i det andre, i begge retninger. En enkelt ping fra én side beviser én velger.

Oppdater deretter tilkoblingsdokumentasjonen med rollene skrevet ut, slik at neste person ikke må gjenoppdage at lokalt betyr din side.