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

Du åbner indstillingerne for Site-to-Site VPN, ser to CIDR-felter mærket lokalt og eksternt og griber efter den adresse, du opfatter som lokal: VPC'en. Det er det modsatte af, hvad API'et mener. I forbindelsesindstillingerne navngiver LocalIpv4NetworkCidr kundegateway-siden, og RemoteIpv4NetworkCidr navngiver AWS-siden, fordi kundegatewayen er det sted, forbindelsen bygges fra. Konsollen siger det aldrig højt, og intet afviser en plausibel ombytning.

Begynd ved API-kaldet, ikke ved konsol-etiketten

Læs referencen for forbindelsesindstillinger igennem én gang og læg mærke til, at hver indstilling er skrevet fra kundegatewayens synspunkt. Det er ikke en tilfældighed i navngivningen. Tunnelen beskrives, som den ser ud for den enhed, der terminerer den på din side, så lokalt betyder netværket bag din gateway, og eksternt betyder netværket bag AWS-gatewayen. Både IPv4- og IPv6-felterne følger samme regel.

Skriv de to etiketter på et selvklæbende notat, før du taster noget: kundesiden, AWS-siden. Knyt derefter dine adresser til dem.

Et gennemregnet eksempel med rollerne sat på

Antag, at det lokale præfiks er 10.20.0.0/16, og VPC-præfikset er 10.60.0.0/16. Indstillingerne læses præcis, som rollerne antyder, med det lokale område i det lokale felt:

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

Giv nu det samme par til den, der konfigurerer peer-enheden, og se fælden klappe. På mange firewalls betyder lokalt den grænseflade, tunnelen terminerer på, og eksternt den fjerne ende, hvilket er den omvendte mapning for AWS-siden. Begge kan have ret og alligevel frembringe en tunnel, der aldrig bliver færdig, fordi de to ordforråd beskriver forskellige endepunkter.

Gentag øvelsen på papir i peerens terminologi, med begge CIDR'er og begge etiketter, før nogen enhed røres.

Standardværdier er ikke et design

Samme reference angiver 0.0.0.0/0 som standard for begge IPv4-felter, med tilsvarende værdier for IPv6. At se de værdier i en eksisterende forbindelse fortæller dig, at feltet aldrig blev indsnævret, ikke at der er konfigureret en internetudgang. Rutedistribution, subnettets rutetabel og sikkerhedskontrollerne afgør stadig, hvilken trafik der reelt kan passere; CIDR-værdierne beskriver kun, hvilke områder tunnelen er villig til at vælge.

At erstatte en snævrere værdi med standarden er derfor ikke et kompatibilitetstrick, man kan anvende, når en tunnel opfører sig forkert. Det udvider selektoren og lader alle andre lag være præcis som før.

Peer-enheden bruger det andet synspunkt

Når AWS-siden er klar, ligger det meste af den resterende forvirring i peer-konfigurationen. En enhed, der spørger efter et lokalt netværk og et eksternt netværk, beskriver sin egen grænseflade som lokal, så dit VPC-område hører i dens eksterne felt, og dit lokale område hører i dens lokale felt. Spørger den i stedet efter trafikselektorer i par, skriver du begge retninger eksplicit, og etiketterne betyder mindre end parringen.

Læs enhedens felt-hjælp frem for dens feltnavne. Producenter genbruger de samme to ord til tre forskellige begreber.

Kontrollér derefter tunnelstatus for begge faser, da en uoverensstemmende selektor normalt viser sig som en fejl i anden fase, mens første fase står lunt etableret.

Ændr indstillingerne som en ændring, ikke som dokumentation

Redigering af forbindelsesindstillinger på en aktiv VPN kan afbryde tjenesten, så behandl det som en vedligeholdelseshandling med et vindue, en rollback-værdi og en note om, hvem der berøres. Optag først de nuværende indstillinger, inklusive begge CIDR-felter og tunnelindstillingerne, så en tilbagerulning er en indsættelse og ikke en genopbygning.

Efter ændringen skal du verificere fra AWS-siden og fra peer'en: en kilde i hvert område, der når en destination i det andet, i begge retninger. Et enkelt ping fra én side beviser én selektor.

Opdater derefter forbindelsesdokumentationen med rollerne skrevet ud, så den næste person ikke behøver at genopdage, at lokalt betyder din side.