Per què GRE i ESP fallen a través d'una passarel·la NAT d'AWS

El túnel falla, el grup de seguretat ja permet tot el trànsit i la conclusió és que AWS bloqueja la VPN. No bloqueja res. Una passarel·la NAT gestionada reenvia un conjunt documentat de protocols externs, i GRE natiu o ESP natiu no hi són, així que cap regla que afegiu farà que la passarel·la els transporti. La regla de permís i la capacitat de transport són dues coses diferents, i només una d’elles és vostra per canviar.

El conjunt de regles no és el conjunt de protocols

Un grup de seguretat decideix quin trànsit pot sortir de la instància. La passarel·la NAT decideix què pot traduir i reenviar. Quan s’aplica el segon límit, una regla permissiva produeix exactament el símptoma que la gent llegeix malament com un problema de tallafoc: els paquets surten de la instància, l’intercanvi de control pot fins i tot completar-se, i no arriba res a l’altre extrem.

L’especificació de protocols de la passarel·la NAT d’AWS enumera TCP, UDP i ICMP per al servei gestionat. Aquest és tot el conjunt suportat. Una regla de permís per a un altre protocol IP no el pot ampliar, perquè la regla s’avalua molt abans d’arribar al camí de reenviament de la passarel·la.

La distinció importa perquè les dues fallades semblen idèntiques des del client i tenen solucions completament diferents.

PPTP mostra per què una prova de port menteix

PPTP és l’exemple antic més clar d’una comprovació de port que no demostra res. Obre una connexió de control TCP al port 1723 i després transporta les dades del túnel per GRE, que és el protocol IP 47. El protocol 47 no és el port TCP 47, i els dos nombres no tenen res a veure més enllà de compartir xifres.

Un operador que prova la connectivitat a 1723 i veu completat l’intercanvi inicial conclou que el camí funciona. Després el canal de dades no passa mai ni un sol paquet, perquè la passarel·la no té cap suport GRE a oferir. Això és una interpretació dels requisits d’un protocol antic, no un consell de desplegar PPTP, que fa anys que és obsolet.

El mateix raonament s’aplica a qualsevol protocol el canal de control del qual és TCP o UDP mentre el seu camí de dades no ho és.

IPsec només sobreviu com a UDP

IPsec és el cas en què la resposta és condicional en lloc d’un no rotund. AWS documenta el NAT traversal com a disposició suportada per a IPsec a través d’una passarel·la NAT. Amb NAT-T negociat, ESP s’encapsula dins d’UDP i la passarel·la veu UDP ordinari en lloc del protocol 50.

Permetre UDP 4500 no fa que els extrems utilitzin NAT traversal. Només permet els paquets si ja tenen aquesta forma. Confirmeu a la sortida de negociació del propi client quina encapsulació s’ha triat, i confirmeu al costat receptor que l’altre extrem l’ha acceptada. Dos extrems configurats per a ESP natiu continuaran enviant ESP natiu digui el que digui el conjunt de regles.

Una VPN basada en TCP o UDP encaixa en el conjunt de transports documentat i encara pot fallar per motius d’encaminament, filtratge o autenticació. Encaixar en el conjunt és necessari, no suficient.

Comproveu el camí abans d’ampliar la política

Verifiqueu la ruta real de la subxarxa de càrrega i la identitat del seu següent salt primer. Un camí públic directe, una instància NAT, una passarel·la NAT gestionada i un camí privat a través d’una passarel·la de trànsit són quatre dissenys diferents, i només un d’ells és el servei gestionat que es descriu aquí.

Després registreu l’extrem intentat, la família d’adreces, el protocol extern i el port on el protocol en té un. Feu servir el diagnòstic del client i les observacions de flux del propietari de la xarxa en lloc d’una petició de navegador reeixida, que només demostra que TCP i UDP funcionen. Després d’això, reviseu el grup de seguretat, l’ACL de la subxarxa, el tallafoc del convidat i la política del servei per a les dues direccions del flux.

No obriu tot el trànsit per compensar un transport que el servei no pot transportar. El canvi de regla no ho arreglarà i sobreviurà a l’incident.

Quan el transport no encaixa

Si el protocol extern és fora del conjunt suportat, la solució és arquitectònica: trieu un transport que el camí pugui transportar, o moveu la sortida a una cosa que transporti el que necessiteu. OpenVPN sobre UDP, WireGuard sobre UDP i els túnels basats en TLS encaixen tots en el conjunt documentat. Una instància NAT gestionada pel client és l’opció quan un protocol específic ha de passar i el cost operatiu de mantenir-la és acceptable.

Allotjar un servidor VPN d’entrada és un problema separat amb una resposta separada. Una passarel·la NAT proporciona traducció de sortida i cap reenviament de ports d’entrada general, així que un servidor al darrere necessita la seva entrada pública aprovada dissenyada segons els seus propis termes.

Ordre de treball: anomeneu el protocol extern, confirmeu el següent salt, compareu-lo amb el conjunt documentat i després canvieu l’arquitectura o el transport. Un número de port diferent no pot convertir GRE en TCP, i una regla més permissiva no pot convertir un intercanvi de control completat en un canal de dades funcional.