Waarom GRE en ESP deur 'n AWS NAT-gateway misluk

Die tonnel misluk, die sekuriteitsgroep laat reeds alle verkeer deur, en die gevolgtrekking is dat AWS die VPN blokkeer. Dit blokkeer niks nie. ’n Bestuurde NAT-gateway stuur ’n gedokumenteerde stel buitenste protokolle deur, en inheemse GRE of inheemse ESP is nie daarby nie, so geen reël wat jy byvoeg sal die gateway dit laat dra nie. Die toelaatreël en die vervoervermoë is twee verskillende dinge, en net een van hulle is joune om te verander.

Die reëlstel is nie die protokolstel nie

’n Sekuriteitsgroep besluit watter verkeer toegelaat word om die instansie te verlaat. Die NAT-gateway besluit wat dit kan vertaal en deurstuur. Wanneer die tweede beperking geld, lewer ’n toegeeflike reël presies die simptoom wat mense as ’n firewallprobleem mislees: pakkette verlaat die instansie, die beheervisseling kan selfs voltooi, en niks arriveer by die eweknie nie.

AWS se protokolspesifikasie vir NAT-gateways lys TCP, UDP en ICMP vir die bestuurde diens. Dit is die hele ondersteunde stel. ’n Toelaatreël vir ’n ander IP-protokol kan dit nie uitbrei nie, want die reël word geëvalueer lank voordat die gateway se deurstuurpad bereik word.

Die onderskeid maak saak omdat die twee mislukkings van die kliënt se kant identies lyk en heeltemal verskillende oplossings het.

PPTP wys waarom ’n poorttoets lieg

PPTP is die duidelikste ou voorbeeld van ’n poorttoets wat niks bewys nie. Dit open ’n TCP-beheerverbinding op poort 1723 en dra dan die tonneldata oor GRE, wat IP-protokol 47 is. Protokol 47 is nie TCP-poort 47 nie, en die twee getalle het niks met mekaar te doen behalwe dat hulle syfers deel.

’n Operateur wat verbinding na 1723 toets en ’n voltooide handdruk sien, maak die gevolgtrekking dat die pad werk. Die datakanaal stuur dan nooit ’n enkele pakket nie, want die gateway het geen GRE-ondersteuning om te bied nie. Dit is ’n interpretasie van ’n ou protokol se vereistes, nie raad om PPTP te ontplooi nie, wat al jare verouderd is.

Dieselfde redenasie geld vir enige protokol waarvan die beheerkanaal TCP of UDP is terwyl sy datapad dit nie is nie.

IPsec oorleef net as UDP

IPsec is die geval waar die antwoord voorwaardelik is eerder as ’n plat nee. AWS dokumenteer NAT-traversal as die ondersteunde reëling vir IPsec deur ’n NAT-gateway. Met NAT-T onderhandel, word ESP in UDP ingekapsel en die gateway sien gewone UDP eerder as protokol 50.

Om UDP 4500 toe te laat, maak nie dat eindpunte NAT-traversal gebruik nie. Dit laat die pakkette net toe as hulle reeds so gevorm is. Bevestig uit die kliënt se eie onderhandelingsuitset watter inkapseling gekies is, en bevestig aan die ontvangkant dat die eweknie dit aanvaar het. Twee eindpunte wat vir inheemse ESP opgestel is, sal aanhou om inheemse ESP te stuur, maak nie saak wat die reëlstel sê nie.

’n VPN op TCP- of UDP-basis pas in die gedokumenteerde vervoerstel en kan steeds misluk weens roetering, filter of verifikasie redes. Om in die stel te pas is nodig, nie voldoende nie.

Kontroleer die pad voordat jy beleid verbreed

Verifieer die werklike roete van die workload-subnet en die identiteit van sy volgende hop eerste. ’n Direkte openbare pad, ’n NAT-instansie, ’n bestuurde NAT-gateway en ’n private pad deur ’n transit-gateway is vier verskillende ontwerpe, en net een daarvan is die bestuurde diens wat hier beskryf word.

Rekord dan die gepoogde eindpunt, die adresfamilie, die buitenste protokol en die poort waar die protokol een het. Gebruik die kliënt se diagnostiek en die netwerk-eienaar se vloeivaarnemings eerder as ’n suksesvolle blaaiernavraag, wat net bewys dat TCP en UDP werk. Hersien daarna die sekuriteitsgroep, die subnet-ACL, die gas-firewall en die diensbeleid vir beide rigtings van die vloei.

Moet nie alle verkeer oopmaak om te vergoed vir ’n vervoer wat die diens nie kan dra nie. Die reëlverandering sal dit nie regmaak nie, en dit sal die voorval oorleef.

Wanneer die vervoer nie pas nie

As die buitenste protokol buite die ondersteunde stel val, is die oplossing argitektonies: kies ’n vervoer wat die pad kan dra, of skuif die uitgang na iets wat die een dra wat jy nodig het. OpenVPN oor UDP, WireGuard oor UDP en TLS-gebaseerde tonnels pas almal in die gedokumenteerde stel. ’n Klantbestuurde NAT-instansie is die opsie wanneer ’n spesifieke protokol moet deurgaan en die bedryfskoste om dit te bestuur aanvaarbaar is.

Om ’n inkomende VPN-bediener te huisves is ’n aparte probleem met ’n aparte antwoord. ’n NAT-gateway bied uitgaande vertaling en geen algemene inkomende poortdeurstuur nie, so ’n bediener agter hom benodig sy goedgekeurde openbare toegang wat op sy eie terme ontwerp word.

Orde van werk: noem die buitenste protokol, bevestig die volgende hop, vergelyk dit met die gedokumenteerde stel, verander dan argitektuur of vervoer. ’n Ander poortnommer kan nie GRE in TCP verander nie, en nog een toegeeflike reël kan nie ’n voltooide beheervisseling in ’n werkende datakanaal verander nie.