AWS VPN: lokalt och externt CIDR - vilken sida är vilken?

Du öppnar alternativen för Site-to-Site VPN, ser två CIDR-fält märkta lokalt och externt och sträcker dig efter adressen du uppfattar som lokal: VPC:n. Det är motsatsen till vad API:t menar. I anslutningsalternativen namnger LocalIpv4NetworkCidr kundgateway-sidan och RemoteIpv4NetworkCidr AWS-sidan, eftersom anslutningen byggs från kundgatewayen. Konsolen säger aldrig detta högt, och ingenting avvisar en rimlig omkastning.

Börja vid API-anropet, inte vid konsolens etikett

Läs referensen för anslutningsalternativ en gång hela vägen och notera att varje alternativ är skrivet ur kundgatewayens perspektiv. Det är ingen slump i namngivningen. Tunneln beskrivs som den ser ut för enheten som avslutar den på din sida, så lokalt betyder nätet bakom din gateway och externt nätet bakom AWS-gatewayen. Både IPv4- och IPv6-fälten följer samma regel.

Skriv de två etiketterna på en lapp innan du skriver något: kundsidan, AWS-sidan. Koppla sedan dina adresser till dem.

Ett genomräknat exempel med rollerna

Anta att det lokala prefixet är 10.20.0.0/16 och VPC-prefixet är 10.60.0.0/16. Alternativen läses exakt som rollerna antyder, med det lokala intervallet i det lokala fältet:

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

Ge nu samma par till den som konfigurerar peer-enheten och se fällan slå till. På många brandväggar betyder lokalt gränssnittet där tunneln avslutas och externt den bortre änden, vilket är den omvända mappningen för AWS-sidan. Båda kan ha rätt och ändå skapa en tunnel som aldrig kommer upp, eftersom de två vokabulären beskriver olika ändpunkter.

Upprepa övningen på papper i peerns terminologi, med båda CIDR:erna och båda etiketterna, innan någon enhet rörs.

Standardvärden är inte en design

Samma referens listar 0.0.0.0/0 som standard för båda IPv4-fälten, med motsvarande värden för IPv6. Att se dessa värden i en befintlig anslutning säger att fältet aldrig snävades in, inte att en internetutgång konfigurerats. Ruttdistribution, subnätets rutttabell och säkerhetskontrollerna avgör fortfarande vilken trafik som faktiskt kan passera; CIDR-värdena beskriver bara vilka intervall tunneln är beredd att välja.

Att ersätta ett snävare värde med standarden är därför inget kompatibilitetstrick man kan använda när en tunnel beter sig fel. Det vidgar väljaren och lämnar alla andra lager exakt som de var.

Peer-enheten använder det andra synsättet

När AWS-sidan är klar, ligger det mesta av den återstående förvirringen i peer-konfigurationen. En enhet som frågar efter ett lokalt nät och ett externt nät beskriver sitt eget gränssnitt som lokalt, så ditt VPC-intervall hamnar i dess externa fält och ditt lokala intervall i dess lokala fält. Frågar den i stället efter trafikväljare i par skriver du båda riktningarna uttryckligen, och etiketterna spelar mindre roll än parkopplingen.

Läs enhetens fälthjälp i stället för fältnamnen. Tillverkare återanvänder samma två ord för tre olika begrepp.

Kontrollera sedan tunnelstatus för båda faserna, eftersom en väljare som inte stämmer vanligen visar sig som ett fel i andra fasen medan första fasen står lugnt etablerad.

Ändra alternativen som en ändring, inte som dokumentation

Redigering av anslutningsalternativ på en aktiv VPN kan avbryta tjänsten, så behandla det som en underhållsåtgärd med ett fönster, ett återställningsvärde och en notering om vem det berör. Fånga först de nuvarande alternativen, inklusive båda CIDR-fälten och tunnelalternativen, så att en återställning är en inklistring och inte en återuppbyggnad.

Efter ändringen, verifiera från AWS-sidan och från peern: en källa i varje intervall som når en destination i det andra, i båda riktningarna. En enda ping från en sida bevisar en enda väljare.

Uppdatera sedan anslutningsdokumentationen med rollerna utskrivna, så att nästa person inte behöver upptäcka på nytt att lokalt betyder din sida.