Hvorfor GRE og ESP feiler gjennom en AWS NAT-gateway

Tunnelen feiler, sikkerhetsgruppen tillater allerede all trafikk, og konklusjonen er at AWS blokkerer VPN-et. Den blokkerer ingenting. En administrert NAT-gateway videresender et dokumentert sett med ytre protokoller, og native GRE eller native ESP er ikke i det, så ingen regel du legger til får gatewayen til å bære dem. Tillatelsesregelen og transportevnen er to forskjellige ting, og bare én av dem kan du endre.

Regelsettet er ikke protokollsettet

En sikkerhetsgruppe avgjør hvilken trafikk som får forlate instansen. NAT-gatewayen avgjør hva den kan oversette og videresende. Når den andre grensen gjelder, gir en tillatende regel nøyaktig det symptomet folk feiltolker som et brannmurproblem: pakker forlater instansen, kontrollutvekslingen kan til og med fullføres, og ingenting når frem til motparten.

AWS' protokollspesifikasjon for NAT-gatewayen lister opp TCP, UDP og ICMP for den administrerte tjenesten. Det er hele det støttede settet. En tillatelsesregel for en annen IP-protokoll kan ikke utvide det, fordi regelen vurderes lenge før gatewayens videresendingsvei nås.

Forskjellen er viktig fordi de to feilene ser identiske ut fra klienten og har helt forskjellige rettelser.

PPTP viser hvorfor en porttest lyver

PPTP er det tydeligste gamle eksempelet på en portkontroll som ikke beviser noe. Den åpner en TCP-kontrollforbindelse på port 1723 og bærer deretter tunneldata over GRE, som er IP-protokoll 47. Protokoll 47 er ikke TCP-port 47, og de to tallene har ingenting med hverandre å gjøre utover å dele sifre.

En operatør som tester forbindelse til 1723 og ser et fullført håndtrykk, konkluderer med at veien virker. Deretter passerer datakanalen aldri en eneste pakke, fordi gatewayen ikke har noen GRE-støtte å tilby. Det er en tolkning av kravene til en gammel protokoll, ikke et råd om å innføre PPTP, som har vært utdatert i årevis.

Samme resonnement gjelder for enhver protokoll der kontrollkanalen er TCP eller UDP, mens dataveien ikke er det.

IPsec overlever bare som UDP

IPsec er tilfellet der svaret er betinget i stedet for et klart nei. AWS dokumenterer NAT-traversering som den støttede ordningen for IPsec gjennom en NAT-gateway. Med NAT-T forhandlet innkapsles ESP i UDP, og gatewayen ser vanlig UDP i stedet for protokoll 50.

Å tillate UDP 4500 får ikke endepunktene til å bruke NAT-traversering. Det tillater bare pakkene hvis de allerede er formet slik. Bekreft fra klientens egen forhandlingsutdata hvilken innkapsling som ble valgt, og bekreft på mottakersiden at motparten godtok den. To endepunkter konfigurert for native ESP vil fortsette å sende native ESP, uansett hva regelsettet sier.

Et TCP- eller UDP-basert VPN passer i det dokumenterte transportsettet og kan likevel feile av hensyn til ruting, filtrering eller autentisering. Å passe i settet er nødvendig, ikke tilstrekkelig.

Kontroller veien før du utvider policyen

Bekreft arbeidsbelastningens undernetts faktiske rute og identiteten til dens neste hopp først. En direkte offentlig vei, en NAT-instans, en administrert NAT-gateway og en privat vei gjennom en transit-gateway er fire forskjellige design, og bare ett av dem er den administrerte tjenesten som beskrives her.

Registrer deretter endepunktet som ble forsøkt, adressefamilien, den ytre protokollen og porten der protokollen har en. Bruk klientens diagnostikk og nettverkseierens strømningsobservasjoner i stedet for en vellykket nettleserforespørsel, som bare beviser at TCP og UDP virker. Deretter går du gjennom sikkerhetsgruppen, undernetts-ACL-en, gjestebrannmuren og tjenestepolicyen for begge retninger av strømmen.

Ikke åpne all trafikk for å kompensere for en transport tjenesten ikke kan bære. Regelendringen retter det ikke, og den vil overleve hendelsen.

Når transporten ikke passer

Hvis den ytre protokollen er utenfor det støttede settet, er rettelsen arkitektonisk: velg en transport veien kan bære, eller flytt egress til noe som bærer den du trenger. OpenVPN over UDP, WireGuard over UDP og TLS-baserte tunneler passer alle i det dokumenterte settet. En kundestyrt NAT-instans er alternativet når en bestemt protokoll må gjennom, og driftskostnaden ved å kjøre den er akseptabel.

Å hoste en inngående VPN-server er et separat problem med et separat svar. En NAT-gateway gir utgående oversettelse og ingen generell inngående portvideresending, så en server bak den trenger sin godkjente offentlige inngang utformet på egne vilkår.

Arbeidsrekkefølge: navngi den ytre protokollen, bekreft neste hopp, sammenlign det med det dokumenterte settet, og endre deretter arkitektur eller transport. Et annet portnummer kan ikke gjøre GRE til TCP, og en mer tillatende regel kan ikke gjøre en fullført kontrollutveksling til en fungerende datakanal.