Por que GRE e ESP fallan a través dunha pasarela NAT de AWS

O túnel falla, o grupo de seguridade xa permite todo o tráfico e a conclusión é que AWS bloquea a VPN. Non bloquea nada. Unha pasarela NAT xestionada reenvía un conxunto documentado de protocolos externos, e GRE nativo ou ESP nativo non están nel, así que ningunha regra que engada fará que a pasarela os transporte. A regra de permiso e a capacidade de transporte son dúas cousas distintas, e só unha delas está nas súas mans cambiar.

O conxunto de regras non é o conxunto de protocolos

Un grupo de seguridade decide que tráfico pode saír da instancia. A pasarela NAT decide que pode traducir e reenviar. Cando se aplica o segundo límite, unha regra permisiva produce exactamente o síntoma que a xente malinterpreta como un problema de firewall: os paquetes saen da instancia, o intercambio de control pode mesmo completarse e nada chega ao par.

A especificación de protocolos da pasarela NAT de AWS enumera TCP, UDP e ICMP para o servizo xestionado. Ese é todo o conxunto admitido. Unha regra de permiso para outro protocolo IP non pode amplialo, porque a regra avalíase moito antes de que se alcance a ruta de reenvío da pasarela.

A distinción importa porque os dous fallos vense idénticos desde o cliente e teñen solucións completamente distintas.

PPTP mostra por que unha proba de porto mente

PPTP é o exemplo antigo máis claro dunha comprobación de porto que non demostra nada. Abre unha conexión de control TCP no porto 1723 e logo transporta os datos do túnel por GRE, que é o protocolo IP 47. O protocolo 47 non é o porto TCP 47, e os dous números non teñen nada que ver entre si máis alá de compartir cifras.

Un operador que proba a conectividade ao 1723 e ve un intercambio inicial completado conclúe que a ruta funciona. Despois o canal de datos nunca atravesa un só paquete, porque a pasarela non ten soporte GRE que ofrecer. Esa é unha interpretación dos requisitos dun protocolo antigo, non un consello para despregar PPTP, que está obsoleto desde hai anos.

O mesmo razoamento aplícase a calquera protocolo cuxo canal de control sexa TCP ou UDP mentres a súa ruta de datos non o é.

IPsec só sobrevive como UDP

IPsec é o caso no que a resposta é condicional en lugar dun non rotundo. AWS documenta o NAT traversal como a disposición admitida para IPsec a través dunha pasarela NAT. Con NAT-T negociado, ESP encapsúlase dentro de UDP e a pasarela ve UDP normal en lugar do protocolo 50.

Permitir UDP 4500 non fai que os extremos usen NAT traversal. Só permite os paquetes se xa teñen esa forma. Confirme na saída de negociación do propio cliente que encapsulación se escolleu, e confirme no lado receptor que o par a aceptou. Dous extremos configurados para ESP nativo seguirán enviando ESP nativo diga o que diga o conxunto de regras.

Unha VPN baseada en TCP ou UDP encaixa no conxunto de transportes documentado e aínda así pode fallar por motivos de enrutamento, filtrado ou autenticación. Encaixar no conxunto é necesario, non suficiente.

Comprobe a ruta antes de ampliar a política

Verifique a ruta real da subrede de carga de traballo e a identidade do seu seguinte salto primeiro. Unha ruta pública directa, unha instancia NAT, unha pasarela NAT xestionada e unha ruta privada a través dunha pasarela de tránsito son catro deseños distintos, e só un deles é o servizo xestionado que se describe aquí.

Despois rexistre o extremo intentado, a familia de enderezos, o protocolo externo e o porto onde o protocolo ten un. Utilice os diagnósticos do cliente e as observacións de fluxo do propietario da rede en lugar dunha solicitude de navegador exitosa, que só demostra que TCP e UDP funcionan. Despois diso, revise o grupo de seguridade, a ACL da subrede, o firewall do convidado e a política do servizo para as dúas direccións do fluxo.

Non abra todo o tráfico para compensar un transporte que o servizo non pode transportar. O cambio de regra non o arranxará e sobrevivirá ao incidente.

Cando o transporte non encaixa

Se o protocolo externo está fóra do conxunto admitido, a solución é arquitectónica: escolla un transporte que a ruta poida transportar, ou mova a saída a algo que transporte o que necesita. OpenVPN sobre UDP, WireGuard sobre UDP e os túneles baseados en TLS encaixan todos no conxunto documentado. Unha instancia NAT xestionada polo cliente é a opción cando un protocolo específico debe pasar e o custo operativo de mantela é aceptable.

Aloxar un servidor VPN de entrada é un problema aparte cunha resposta aparte. Unha pasarela NAT proporciona tradución de saída e ningún reenvío de portos de entrada xeral, así que un servidor detrás dela necesita a súa entrada pública aprobada deseñada nos seus propios termos.

Orde de traballo: nomee o protocolo externo, confirme o seguinte salto, compáreo co conxunto documentado e logo cambie a arquitectura ou o transporte. Un número de porto distinto non pode converter GRE en TCP, e unha regra máis permisiva non pode converter un intercambio de control completado nun canal de datos funcional.