Hvorfor GRE og ESP fejler gennem en AWS NAT-gateway

Tunnelen fejler, sikkerhedsgruppen tillader allerede al trafik, og konklusionen er, at AWS blokerer VPN'et. Den blokerer ikke noget. En administreret NAT-gateway videresender et dokumenteret sæt ydre protokoller, og native GRE eller native ESP er ikke i det, så ingen regel du tilføjer får gatewayen til at bære dem. Tilladelsesreglen og transportevnen er to forskellige ting, og kun den ene af dem kan du ændre.

Regelsættet er ikke protokolsættet

En sikkerhedsgruppe afgør, hvilken trafik der må forlade instansen. NAT-gatewayen afgør, hvad den kan oversætte og videresende. Når den anden grænse gælder, giver en tilladende regel præcis det symptom, som folk fejltolker som et firewallproblem: pakker forlader instansen, kontroludvekslingen kan endda fuldføres, og intet når frem til modparten.

AWS' protokolspecifikation for NAT-gatewayen angiver TCP, UDP og ICMP til den administrerede tjeneste. Det er hele det understøttede sæt. En tilladelsesregel for en anden IP-protokol kan ikke udvide det, fordi reglen vurderes længe før gatewayens videresendelsesvej nås.

Forskellen er vigtig, fordi de to fejl ser identiske ud fra klienten og har helt forskellige rettelser.

PPTP viser, hvorfor en porttest lyver

PPTP er det tydeligste gamle eksempel på en portkontrol, der ikke beviser noget. Den åbner en TCP-kontrolforbindelse på port 1723 og bærer derefter tunneldata over GRE, som er IP-protokol 47. Protokol 47 er ikke TCP-port 47, og de to tal har intet med hinanden at gøre ud over at dele cifre.

En operatør, der tester forbindelse til 1723 og ser et fuldført håndtryk, konkluderer, at vejen virker. Derefter passerer datakanalen aldrig en enkelt pakke, fordi gatewayen ikke har nogen GRE-support at tilbyde. Det er en fortolkning af en gammel protokols krav, ikke en anbefaling om at implementere PPTP, som har været forældet i årevis.

Samme ræsonnement gælder for enhver protokol, hvis kontrolkanal er TCP eller UDP, mens dens datavej ikke er.

IPsec overlever kun som UDP

IPsec er tilfældet, hvor svaret er betinget snarere end et klart nej. AWS dokumenterer NAT-gennemgang som den understøttede ordning for IPsec gennem en NAT-gateway. Med NAT-T forhandlet indkapsles ESP i UDP, og gatewayen ser almindelig UDP i stedet for protokol 50.

At tillade UDP 4500 får ikke endepunkterne til at bruge NAT-gennemgang. Det tillader kun pakkerne, hvis de allerede er formet sådan. Bekræft ud fra klientens eget forhandlingsoutput, hvilken indkapsling der blev valgt, og bekræft på modtagersiden, at modparten accepterede det. To endepunkter konfigureret til native ESP vil blive ved med at sende native ESP, uanset hvad regelsættet siger.

Et TCP- eller UDP-baseret VPN passer i det dokumenterede transportsæt og kan stadig fejle af grunde som routing, filtrering eller godkendelse. At passe i sættet er nødvendigt, ikke tilstrækkeligt.

Kontroller vejen, før du udvider politikken

Bekræft arbejdsbyrdens undernets faktiske rute og identiteten af dens næste hop først. En direkte offentlig vej, en NAT-instans, en administreret NAT-gateway og en privat vej gennem en transit-gateway er fire forskellige designs, og kun ét af dem er den administrerede tjeneste, der beskrives her.

Registrer derefter det forsøgte endepunkt, adressefamilien, den ydre protokol og porten, hvor protokollen har en. Brug klientens diagnostik og netværksejerens flowobservationer i stedet for en vellykket browseranmodning, som kun beviser, at TCP og UDP virker. Gennemgå derefter sikkerhedsgruppen, undernets ACL, gæstens firewall og tjenestepolitikken for begge retninger af flowet.

Åbn ikke al trafik for at kompensere for en transport, som tjenesten ikke kan bære. Regelændringen løser det ikke, og den overlever hændelsen.

Når transporten ikke passer

Hvis den ydre protokol ligger uden for det understøttede sæt, er løsningen arkitektonisk: vælg en transport, som vejen kan bære, eller flyt egress til noget, der bærer den, du har brug for. OpenVPN over UDP, WireGuard over UDP og TLS-baserede tunneler passer alle i det dokumenterede sæt. En kundestyret NAT-instans er muligheden, når en bestemt protokol skal igennem, og driftsomkostningen ved at køre den er acceptabel.

Hosting af en indgående VPN-server er et separat problem med et separat svar. En NAT-gateway leverer udgående oversættelse og ingen generel indgående portvideresendelse, så en server bag den har brug for sin godkendte offentlige indgang designet på egne vilkår.

Arbejdsrækkefølge: navngiv den ydre protokol, bekræft det næste hop, sammenlign det med det dokumenterede sæt, og ændr derefter arkitektur eller transport. Et andet portnummer kan ikke gøre GRE til TCP, og en mere tilladende regel kan ikke gøre en fuldført kontroludveksling til en fungerende datakanal.