De ce GRE și ESP eșuează printr-un gateway NAT AWS

Tunelul eșuează, grupul de securitate permite deja tot traficul, iar concluzia este că AWS blochează VPN-ul. Nu blochează nimic. Un gateway NAT gestionat transmite un set documentat de protocoale externe, iar GRE nativ sau ESP nativ nu se află în el, așa că nicio regulă adăugată nu va face gateway-ul să le transporte. Regula de permitere și capacitatea de transport sunt două lucruri diferite, iar doar una dintre ele poate fi schimbată de dumneavoastră.

Setul de reguli nu este setul de protocoale

Un grup de securitate decide ce trafic poate părăsi instanța. Gateway-ul NAT decide ce poate traduce și transmite. Când se aplică a doua limită, o regulă permisivă produce exact simptomul pe care oamenii îl citesc greșit drept problemă de firewall: pachetele părăsesc instanța, schimbul de control se poate chiar finaliza, iar la partener nu ajunge nimic.

Specificația protocoalelor gateway-ului NAT de la AWS enumeră TCP, UDP și ICMP pentru serviciul gestionat. Acesta este întregul set acceptat. O regulă de permitere pentru un alt protocol IP nu îl poate extinde, deoarece regula este evaluată mult înainte de a se ajunge la calea de transmitere a gateway-ului.

Distincția contează pentru că cele două eșecuri arată identic din partea clientului și au corecții complet diferite.

PPTP arată de ce un test de port minte

PPTP este cel mai clar exemplu vechi de verificare a portului care nu demonstrează nimic. Deschide o conexiune de control TCP pe portul 1723 și apoi transportă datele tunelului prin GRE, care este protocolul IP 47. Protocolul 47 nu este portul TCP 47, iar cele două numere nu au nimic de-a face unul cu celălalt în afară de faptul că împart cifre.

Un operator care testează conectivitatea la 1723 și vede un handshake finalizat concluzionează că calea funcționează. Apoi canalul de date nu trece niciodată un singur pachet, pentru că gateway-ul nu are niciun suport GRE de oferit. Aceasta este o interpretare a cerințelor unui protocol vechi, nu un sfat de a implementa PPTP, care este depășit de ani buni.

Același raționament se aplică oricărui protocol al cărui canal de control este TCP sau UDP, în timp ce calea sa de date nu este.

IPsec supraviețuiește doar ca UDP

IPsec este cazul în care răspunsul este condiționat, nu un nu categoric. AWS documentează NAT traversal ca aranjamentul acceptat pentru IPsec printr-un gateway NAT. Cu NAT-T negociat, ESP este încapsulat în UDP, iar gateway-ul vede UDP obișnuit în loc de protocolul 50.

Permiterea UDP 4500 nu face punctele finale să folosească NAT traversal. Doar permite pachetele dacă sunt deja modelate astfel. Confirmați din ieșirea de negociere a clientului însuși ce încapsulare a fost aleasă și confirmați pe partea receptoare că partenerul a acceptat-o. Două puncte finale configurate pentru ESP nativ vor continua să trimită ESP nativ, indiferent ce spune setul de reguli.

Un VPN bazat pe TCP sau UDP se potrivește setului de transport documentat și poate eșua totuși din motive de rutare, filtrare sau autentificare. Potrivirea cu setul este necesară, nu suficientă.

Verificați calea înainte de a extinde politica

Verificați ruta reală a subrețelei de lucru și identitatea următorului său salt mai întâi. O cale publică directă, o instanță NAT, un gateway NAT gestionat și o cale privată printr-un gateway de tranzit sunt patru modele diferite, iar doar unul dintre ele este serviciul gestionat descris aici.

Apoi înregistrați punctul final încercat, familia de adrese, protocolul extern și portul acolo unde protocolul are unul. Folosiți diagnosticarea clientului și observațiile de flux ale proprietarului rețelei în locul unei cereri de browser reușite, care dovedește doar că TCP și UDP funcționează. După aceea, examinați grupul de securitate, ACL-ul subrețelei, firewall-ul invitatului și politica serviciului pentru ambele direcții ale fluxului.

Nu deschideți tot traficul pentru a compensa un transport pe care serviciul nu îl poate duce. Modificarea regulii nu o va repara și va supraviețui incidentului.

Când transportul nu se potrivește

Dacă protocolul extern este în afara setului acceptat, corecția este arhitecturală: alegeți un transport pe care calea îl poate duce sau mutați ieșirea pe ceva care îl duce pe cel de care aveți nevoie. OpenVPN prin UDP, WireGuard prin UDP și tunelurile bazate pe TLS se potrivesc toate setului documentat. O instanță NAT gestionată de client este opțiunea când un protocol anume trebuie să treacă și costul operațional de a o întreține este acceptabil.

Găzduirea unui server VPN de intrare este o problemă separată cu un răspuns separat. Un gateway NAT oferă traducere de ieșire și nicio redirecționare generală de porturi de intrare, așa că un server din spatele lui are nevoie de intrarea sa publică aprobată, proiectată pe propriile condiții.

Ordinea de lucru: numiți protocolul extern, confirmați următorul salt, comparați-l cu setul documentat, apoi schimbați arhitectura sau transportul. Un alt număr de port nu poate transforma GRE în TCP, iar o regulă mai permisivă nu poate transforma un schimb de control finalizat într-un canal de date funcțional.