Kvifor GRE og ESP feilar gjennom ein AWS NAT-gateway

Tunnelen feilar, tryggingsgruppa lèt allereie all trafikk gjennom, og konklusjonen er at AWS blokkerer VPN-et. Det blokkerer ingenting. Ein administrert NAT-gateway sender eit dokumentert sett av ytre protokollar vidare, og native GRE eller native ESP er ikkje i det, så ingen regel du legg til får gatewayen til å bera dei. Løyveregelen og transportevna er to ulike ting, og berre éin av dei kan du endra.

Regelsettet er ikkje protokollsettet

Eit tryggingsgruppe avgjer kva trafikk som får forlata instansen. NAT-gatewayen avgjer kva han kan omsetja og senda vidare. Når den andre grensa gjeld, gir ein løyvande regel nøyaktig det symptomet folk feiltolkar som eit brannmurproblem: pakkar forlèt instansen, kontrollutvekslinga kan til og med fullførast, og ingenting når fram til motparten.

AWS protokollspesifikasjonen for NAT-gatewayen listar opp TCP, UDP og ICMP for den administrerte tenesta. Det er heile det støtta settet. Ein løyveregel for ein annan IP-protokoll kan ikkje utvida det, fordi regelen blir vurdert lenge før videresendingsvegen til gatewayen blir nådd.

Skilnaden er viktig fordi dei to feila ser identiske ut frå klienten og har heilt ulike rettingar.

PPTP viser kvifor ein porttest lyg

PPTP er det tydelegaste gamle dømet på ein portkontroll som ikkje beviser noko. Han opnar ei TCP-kontrollforbinding på port 1723 og ber deretter tunneldata over GRE, som er IP-protokoll 47. Protokoll 47 er ikkje TCP-port 47, og dei to tala har ingenting med kvarandre å gjera utover å dela siffer.

Ein operatør som testar samband til 1723 og ser eit fullført handtrykk, konkluderer med at vegen verkar. Deretter passerer datakanalen aldri ein einaste pakke, fordi gatewayen ikkje har noko GRE-støtte å bjoda. Det er ei tolking av krava til ein gamal protokoll, ikkje eit råd om å innføra PPTP, som har vore utdatert i årevis.

Same resonnementet gjeld for ein kvar protokoll der kontrollkanalen er TCP eller UDP, medan datavegen ikkje er det.

IPsec overlever berre som UDP

IPsec er tilfellet der svaret er vilkårleg i staden for eit klart nei. AWS dokumenterer NAT-traversering som den støtta ordninga for IPsec gjennom ein NAT-gateway. Med NAT-T forhandla blir ESP kapsla inn i UDP, og gatewayen ser vanleg UDP i staden for protokoll 50.

Å løyva UDP 4500 får ikkje endepunkta til å bruka NAT-traversering. Det løyver berre pakkane om dei allereie er forma slik. Stadfest frå klienten si eiga forhandlingsutdata kva innkapsling som vart vald, og stadfest på mottakarsida at motparten godtok ho. To endepunkt konfigurerte for native ESP vil halda fram med å senda native ESP, uansett kva regelsettet seier.

Eit TCP- eller UDP-basert VPN passar i det dokumenterte transportsettet og kan likevel feila av omsyn til ruting, filtrering eller autentisering. Å passa i settet er naudsynt, ikkje tilstrekkeleg.

Kontroller vegen før du utvidar policyen

Stadfest den faktiske ruta til arbeidslastens undernett og identiteten til det neste hoppet først. Ein direkte offentleg veg, ein NAT-instans, ein administrert NAT-gateway og ein privat veg gjennom ein transit-gateway er fire ulike design, og berre eitt av dei er den administrerte tenesta som er skildra her.

Registrer deretter endepunktet som vart freista, adressefamilien, den ytre protokollen og porten der protokollen har ein. Bruk diagnostikken til klienten og straumobservasjonane til netteigaren i staden for ein vellukka nettlesarførespurnad, som berre beviser at TCP og UDP verkar. Deretter går du gjennom tryggingsgruppa, undernetts-ACL-en, brannmuren til gjesten og tenestepolicyen for båe retningane av straumen.

Ikkje opna all trafikk for å kompensera for ein transport tenesta ikkje kan bera. Regelendringa rettar det ikkje, og ho vil overleva hendinga.

Når transporten ikkje passar

Viss den ytre protokollen er utanfor det støtta settet, er rettinga arkitektonisk: vel ein transport vegen kan bera, eller flytt egress til noko som ber den du treng. OpenVPN over UDP, WireGuard over UDP og TLS-baserte tunnelar passar alle i det dokumenterte settet. Ein kundestyrt NAT-instans er alternativet når ein bestemt protokoll må gjennom, og driftskostnaden ved å køyra han er akseptabel.

Å hosta ein inngåande VPN-server er eit separat problem med eit separat svar. Ein NAT-gateway gir utgåande omsetjing og inga generell inngåande portvideresending, så ein server bak han treng den godkjende offentlege inngangen sin utforma på eigne vilkår.

Arbeidsrekkjefølgje: nemn den ytre protokollen, stadfest neste hopp, samanlikn det med det dokumenterte settet, og endra deretter arkitektur eller transport. Eit anna portnummer kan ikkje gjera GRE til TCP, og ein meir løyvande regel kan ikkje gjera ei fullført kontrollutveksling til ein fungerande datakanal.