Varför GRE och ESP misslyckas genom en AWS NAT-gateway

Tunneln misslyckas, säkerhetsgruppen tillåter redan all trafik, och slutsatsen är att AWS blockerar VPN:en. Den blockerar ingenting. En hanterad NAT-gateway vidarebefordrar en dokumenterad uppsättning yttre protokoll, och inbyggt GRE eller inbyggt ESP finns inte i den, så ingen regel du lägger till får gatewayen att bära dem. Tillåtelseregeln och transportförmågan är två olika saker, och bara en av dem kan du ändra.

Regeluppsättningen är inte protokolluppsättningen

En säkerhetsgrupp avgör vilken trafik som får lämna instansen. NAT-gatewayen avgör vad den kan översätta och vidarebefordra. När den andra gränsen gäller ger en tillåtande regel exakt det symptom som folk feltolkar som ett brandväggsproblem: paketen lämnar instansen, kontrollutbytet kan till och med slutföras, och inget når fram till motparten.

AWS protokollspecifikation för NAT-gatewayen listar TCP, UDP och ICMP för den hanterade tjänsten. Det är hela den stödda uppsättningen. En tillåtelseregel för ett annat IP-protokoll kan inte utöka den, eftersom regeln utvärderas långt innan gatewayens vidarebefordringsväg nås.

Skillnaden är viktig eftersom de två felen ser identiska ut från klienten och har helt olika åtgärder.

PPTP visar varför ett porttest ljuger

PPTP är det tydligaste gamla exemplet på en portkontroll som inte bevisar något. Den öppnar en TCP-kontrollanslutning på port 1723 och bär sedan tunneldata över GRE, som är IP-protokoll 47. Protokoll 47 är inte TCP-port 47, och de två talen har inget med varandra att göra annat än att de delar siffror.

En operatör som testar anslutning till 1723 och ser ett slutfört handskakning drar slutsatsen att vägen fungerar. Sedan passerar datakanalen aldrig ett enda paket, eftersom gatewayen inte har något GRE-stöd att erbjuda. Det är en tolkning av kraven i ett gammalt protokoll, inte ett råd att införa PPTP, som har varit föråldrat i flera år.

Samma resonemang gäller för alla protokoll vars kontrollkanal är TCP eller UDP medan dess dataväg inte är det.

IPsec överlever bara som UDP

IPsec är fallet där svaret är villkorat i stället för ett klart nej. AWS dokumenterar NAT-traversering som det stödda arrangemanget för IPsec genom en NAT-gateway. Med NAT-T förhandlat inkapslas ESP i UDP, och gatewayen ser vanlig UDP i stället för protokoll 50.

Att tillåta UDP 4500 får inte ändpunkterna att använda NAT-traversering. Det tillåter bara paketen om de redan är formade så. Bekräfta från klientens egen förhandlingsutdata vilken inkapsling som valdes, och bekräfta på mottagarsidan att motparten accepterade den. Två ändpunkter konfigurerade för inbyggt ESP fortsätter att skicka inbyggt ESP, vad regeluppsättningen än säger.

Ett TCP- eller UDP-baserat VPN passar i den dokumenterade transportuppsättningen och kan ändå misslyckas av skäl som rör routing, filtrering eller autentisering. Att passa i uppsättningen är nödvändigt, inte tillräckligt.

Kontrollera vägen innan du utökar policyn

Verifiera arbetsbelastningens subnäts faktiska rutt och identiteten hos dess nästa hopp först. En direkt offentlig väg, en NAT-instans, en hanterad NAT-gateway och en privat väg genom en transit-gateway är fyra olika designer, och bara en av dem är den hanterade tjänst som beskrivs här.

Registrera sedan den försökta ändpunkten, adressfamiljen, det yttre protokollet och porten där protokollet har en. Använd klientens diagnostik och nätverkägarens flödesobservationer i stället för en lyckad webbläsarförfrågan, som bara bevisar att TCP och UDP fungerar. Granska därefter säkerhetsgruppen, subnätets ACL, gästens brandvägg och tjänstepolicyn för båda riktningarna av flödet.

Öppna inte all trafik för att kompensera för en transport som tjänsten inte kan bära. Regeländringen löser det inte, och den överlever incidenten.

När transporten inte passar

Om det yttre protokollet ligger utanför den stödda uppsättningen är åtgärden arkitektonisk: välj en transport som vägen kan bära, eller flytta egress till något som bär den du behöver. OpenVPN över UDP, WireGuard över UDP och TLS-baserade tunnlar passar alla i den dokumenterade uppsättningen. En kundhanterad NAT-instans är alternativet när ett visst protokoll måste igenom och driftskostnaden för att köra den är acceptabel.

Att vara värd för en inkommande VPN-server är ett separat problem med ett separat svar. En NAT-gateway ger utgående översättning och ingen allmän inkommande portvidarebefordran, så en server bakom den behöver sin godkända offentliga ingång utformad på egna villkor.

Arbetsordning: namnge det yttre protokollet, bekräfta nästa hopp, jämför det med den dokumenterade uppsättningen och ändra sedan arkitektur eller transport. Ett annat portnummer kan inte göra GRE till TCP, och en mer tillåtande regel kan inte göra ett slutfört kontrollutbyte till en fungerande datakanal.