Waarom GRE en ESP falen via een AWS NAT-gateway

De tunnel faalt, de beveiligingsgroep staat al al het verkeer toe, en de conclusie is dat AWS de VPN blokkeert. Het blokkeert niets. Een beheerde NAT-gateway stuurt een gedocumenteerde set buitenste protocollen door, en native GRE of native ESP zitten daar niet bij, dus geen regel die u toevoegt zal de gateway ze laten dragen. De toestemmingsregel en het transportvermogen zijn twee verschillende dingen, en slechts één ervan kunt u wijzigen.

De regelset is niet de protokolset

Een beveiligingsgroep bepaalt welk verkeer de instantie mag verlaten. De NAT-gateway bepaalt wat hij kan vertalen en doorsturen. Wanneer de tweede grens geldt, levert een toestemmende regel precies het symptoom op dat mensen verkeerd lezen als een firewallprobleem: pakketten verlaten de instantie, de controle-uitwisseling kan zelfs voltooid worden, en niets komt bij de peer aan.

De protocolspecificatie van de NAT-gateway van AWS noemt TCP, UDP en ICMP voor de beheerde dienst. Dat is de hele ondersteunde set. Een toestemmingsregel voor een ander IP-protocol kan die niet uitbreiden, omdat de regel lang wordt beoordeeld voordat het doorstuurpad van de gateway wordt bereikt.

Het onderscheid is belangrijk omdat de twee storingen er vanaf de client identiek uitzien en volledig verschillende oplossingen hebben.

PPTP laat zien waarom een poorttest liegt

PPTP is het duidelijkste oude voorbeeld van een poortcontrole die niets bewijst. Het opent een TCP-controleverbinding op poort 1723 en draagt daarna de tunnelgegevens over GRE, dat IP-protocol 47 is. Protocol 47 is geen TCP-poort 47, en de twee nummers hebben niets met elkaar te maken behalve dat ze cijfers delen.

Een operator die connectiviteit naar 1723 test en een voltooide handshake ziet, concludeert dat het pad werkt. Daarna passeert het datakanaal nooit één pakket, omdat de gateway geen GRE-ondersteuning te bieden heeft. Dat is een interpretatie van de eisen van een oud protocol, geen advies om PPTP in te zetten, dat al jaren verouderd is.

Dezelfde redenering geldt voor elk protocol waarvan het controlekanaal TCP of UDP is terwijl het datapad dat niet is.

IPsec overleeft alleen als UDP

IPsec is het geval waarin het antwoord voorwaardelijk is in plaats van een plat nee. AWS documenteert NAT-traversal als de ondersteunde regeling voor IPsec via een NAT-gateway. Met onderhandelde NAT-T wordt ESP in UDP ingekapseld en ziet de gateway gewone UDP in plaats van protocol 50.

UDP 4500 toestaan zorgt er niet voor dat eindpunten NAT-traversal gebruiken. Het staat de pakketten alleen toe als ze al zo gevormd zijn. Controleer in de eigen onderhandelingsuitvoer van de client welke inkapseling is gekozen, en bevestig aan de ontvangende kant dat de peer die heeft geaccepteerd. Twee eindpunten die voor native ESP zijn geconfigureerd, blijven native ESP sturen, wat de regelset ook zegt.

Een op TCP of UDP gebaseerde VPN past in de gedocumenteerde transportset en kan toch falen door routering, filtering of authenticatie. In de set passen is noodzakelijk, niet voldoende.

Controleer het pad voordat u het beleid verbreedt

Verifieer de werkelijke route van het workload-subnet en de identiteit van de volgende hop eerst. Een direct openbaar pad, een NAT-instantie, een beheerde NAT-gateway en een privépad via een transit-gateway zijn vier verschillende ontwerpen, en slechts één ervan is de hier beschreven beheerde dienst.

Noteer daarna het geprobeerde eindpunt, de adresfamilie, het buitenste protocol en de poort waar het protocol er een heeft. Gebruik de diagnostiek van de client en de stroomwaarnemingen van de netwerkeigenaar in plaats van een geslaagd browserverzoek, dat alleen bewijst dat TCP en UDP werken. Bekijk daarna de beveiligingsgroep, de subnet-ACL, de firewall van de gast en het servicebeleid voor beide richtingen van de stroom.

Open niet al het verkeer om een transport te compenseren dat de dienst niet kan dragen. De regelwijziging lost het niet op, en ze overleeft het incident.

Als het transport niet past

Als het buitenste protocol buiten de ondersteunde set valt, is de oplossing architectonisch: kies een transport dat het pad kan dragen, of verplaats de egress naar iets dat het benodigde draagt. OpenVPN via UDP, WireGuard via UDP en op TLS gebaseerde tunnels passen allemaal in de gedocumenteerde set. Een door de klant beheerde NAT-instantie is de optie wanneer een specifiek protocol erdoor moet en de operationele kosten ervan acceptabel zijn.

Het hosten van een inkomende VPN-server is een apart probleem met een apart antwoord. Een NAT-gateway biedt uitgaande vertaling en geen algemene inkomende port-forwarding, dus een server erachter heeft zijn goedgekeurde openbare ingang nodig, ontworpen op eigen voorwaarden.

Werkvolgorde: benoem het buitenste protocol, bevestig de volgende hop, vergelijk die met de gedocumenteerde set en wijzig dan de architectuur of het transport. Een ander poortnummer kan GRE niet in TCP veranderen, en één toestemmender regel kan een voltooide controle-uitwisseling niet in een werkend datakanaal veranderen.