Por qué GRE y ESP fallan a través de una puerta de enlace NAT de AWS

El túnel falla, el grupo de seguridad ya permite todo el tráfico y la conclusión es que AWS bloquea la VPN. No bloquea nada. Una puerta de enlace NAT administrada reenvía un conjunto documentado de protocolos externos, y GRE nativo o ESP nativo no están en él, así que ninguna regla que agregue hará que la puerta de enlace los transporte. La regla de permiso y la capacidad de transporte son dos cosas distintas, y solo una de ellas está en sus manos cambiar.

El conjunto de reglas no es el conjunto de protocolos

Un grupo de seguridad decide qué tráfico puede salir de la instancia. La puerta de enlace NAT decide qué puede traducir y reenviar. Cuando se aplica el segundo límite, una regla permisiva produce exactamente el síntoma que la gente malinterpreta como un problema de firewall: los paquetes salen de la instancia, el intercambio de control puede incluso completarse y nada llega al par.

La especificación de protocolos de la puerta de enlace NAT de AWS enumera TCP, UDP e ICMP para el servicio administrado. Ese es todo el conjunto admitido. Una regla de permiso para otro protocolo IP no puede ampliarlo, porque la regla se evalúa mucho antes de que se alcance la ruta de reenvío de la puerta de enlace.

La distinción importa porque los dos fallos se ven idénticos desde el cliente y tienen soluciones completamente distintas.

PPTP muestra por qué una prueba de puerto miente

PPTP es el ejemplo antiguo más claro de una comprobación de puerto que no demuestra nada. Abre una conexión de control TCP en el puerto 1723 y luego transporta los datos del túnel por GRE, que es el protocolo IP 47. El protocolo 47 no es el puerto TCP 47, y los dos números no tienen nada que ver entre sí más allá de compartir cifras.

Un operador que prueba la conectividad al 1723 y ve un intercambio inicial completado concluye que la ruta funciona. Después el canal de datos nunca atraviesa un solo paquete, porque la puerta de enlace no tiene soporte GRE que ofrecer. Esa es una interpretación de los requisitos de un protocolo antiguo, no un consejo para desplegar PPTP, que está obsoleto desde hace años.

El mismo razonamiento se aplica a cualquier protocolo cuyo canal de control sea TCP o UDP mientras su ruta de datos no lo es.

IPsec solo sobrevive como UDP

IPsec es el caso en el que la respuesta es condicional en lugar de un no rotundo. AWS documenta el NAT traversal como la disposición admitida para IPsec a través de una puerta de enlace NAT. Con NAT-T negociado, ESP se encapsula dentro de UDP y la puerta de enlace ve UDP normal en lugar del protocolo 50.

Permitir UDP 4500 no hace que los extremos usen NAT traversal. Solo permite los paquetes si ya tienen esa forma. Confirme en la salida de negociación del propio cliente qué encapsulación se eligió, y confirme en el lado receptor que el par la aceptó. Dos extremos configurados para ESP nativo seguirán enviando ESP nativo diga lo que diga el conjunto de reglas.

Una VPN basada en TCP o UDP encaja en el conjunto de transportes documentado y aun así puede fallar por motivos de enrutamiento, filtrado o autenticación. Encajar en el conjunto es necesario, no suficiente.

Compruebe la ruta antes de ampliar la política

Verifique la ruta real de la subred de carga de trabajo y la identidad de su siguiente salto primero. Una ruta pública directa, una instancia NAT, una puerta de enlace NAT administrada y una ruta privada a través de una puerta de enlace de tránsito son cuatro diseños distintos, y solo uno de ellos es el servicio administrado que se describe aquí.

Luego registre el extremo intentado, la familia de direcciones, el protocolo externo y el puerto donde el protocolo tiene uno. Utilice los diagnósticos del cliente y las observaciones de flujo del propietario de la red en lugar de una solicitud de navegador exitosa, que solo demuestra que TCP y UDP funcionan. Después de eso, revise el grupo de seguridad, la ACL de la subred, el firewall del invitado y la política del servicio para ambas direcciones del flujo.

No abra todo el tráfico para compensar un transporte que el servicio no puede transportar. El cambio de regla no lo arreglará y sobrevivirá al incidente.

Cuando el transporte no encaja

Si el protocolo externo está fuera del conjunto admitido, la solución es arquitectónica: elija un transporte que la ruta pueda transportar, o mueva la salida a algo que transporte el que necesita. OpenVPN sobre UDP, WireGuard sobre UDP y los túneles basados en TLS encajan todos en el conjunto documentado. Una instancia NAT administrada por el cliente es la opción cuando un protocolo específico debe pasar y el coste operativo de mantenerla es aceptable.

Alojar un servidor VPN de entrada es un problema aparte con una respuesta aparte. Una puerta de enlace NAT proporciona traducción de salida y ningún reenvío de puertos de entrada general, así que un servidor detrás de ella necesita su entrada pública aprobada diseñada en sus propios términos.

Orden de trabajo: nombre el protocolo externo, confirme el siguiente salto, compárelo con el conjunto documentado y luego cambie la arquitectura o el transporte. Un número de puerto distinto no puede convertir GRE en TCP, y una regla más permisiva no puede convertir un intercambio de control completado en un canal de datos funcional.