Por que GRE e ESP falham através de um gateway NAT da AWS

O túnel falha, o grupo de segurança já permite todo o tráfego, e a conclusão é que a AWS está bloqueando a VPN. Ela não bloqueia nada. Um gateway NAT gerenciado encaminha um conjunto documentado de protocolos externos, e GRE nativo ou ESP nativo não estão nele, então nenhuma regra adicionada fará o gateway transportá-los. A regra de permissão e a capacidade de transporte são duas coisas diferentes, e apenas uma delas está ao seu alcance mudar.

O conjunto de regras não é o conjunto de protocolos

Um grupo de segurança decide qual tráfego pode sair da instância. O gateway NAT decide o que ele consegue traduzir e encaminhar. Quando o segundo limite se aplica, uma regra permissiva produz exatamente o sintoma que as pessoas leem errado como problema de firewall: os pacotes saem da instância, a troca de controle pode até se completar, e nada chega ao par.

A especificação de protocolos do gateway NAT da AWS lista TCP, UDP e ICMP para o serviço gerenciado. Esse é todo o conjunto suportado. Uma regra de permissão para outro protocolo IP não pode ampliá-lo, porque a regra é avaliada bem antes de o caminho de encaminhamento do gateway ser alcançado.

A distinção importa porque as duas falhas parecem idênticas do lado do cliente e têm correções completamente diferentes.

O PPTP mostra por que um teste de porta mente

O PPTP é o exemplo antigo mais claro de uma verificação de porta que não prova nada. Ele abre uma conexão de controle TCP na porta 1723 e depois transporta os dados do túnel pelo GRE, que é o protocolo IP 47. O protocolo 47 não é a porta TCP 47, e os dois números não têm nada a ver um com o outro além de compartilharem dígitos.

Um operador que testa a conectividade com a 1723 e vê um handshake concluído conclui que o caminho funciona. Depois o canal de dados nunca passa um único pacote, porque o gateway não tem suporte a GRE a oferecer. Isso é uma interpretação dos requisitos de um protocolo antigo, não um conselho para implantar PPTP, que está obsoleto há anos.

O mesmo raciocínio vale para qualquer protocolo cujo canal de controle seja TCP ou UDP enquanto o caminho de dados não é.

O IPsec só sobrevive como UDP

O IPsec é o caso em que a resposta é condicional em vez de um não redondo. A AWS documenta o NAT traversal como a disposição suportada para IPsec através de um gateway NAT. Com NAT-T negociado, o ESP é encapsulado em UDP e o gateway vê UDP comum em vez do protocolo 50.

Permitir UDP 4500 não faz os endpoints usarem NAT traversal. Apenas permite os pacotes se eles já estiverem nesse formato. Confirme na saída de negociação do próprio cliente qual encapsulamento foi escolhido, e confirme no lado receptor que o par o aceitou. Dois endpoints configurados para ESP nativo continuarão enviando ESP nativo, diga o que disser o conjunto de regras.

Uma VPN baseada em TCP ou UDP cabe no conjunto de transportes documentado e ainda pode falhar por motivos de roteamento, filtragem ou autenticação. Caber no conjunto é necessário, não suficiente.

Verifique o caminho antes de ampliar a política

Verifique a rota real da sub-rede de carga de trabalho e a identidade do próximo salto primeiro. Um caminho público direto, uma instância NAT, um gateway NAT gerenciado e um caminho privado através de um gateway de trânsito são quatro projetos diferentes, e apenas um deles é o serviço gerenciado descrito aqui.

Em seguida, registre o endpoint tentado, a família de endereços, o protocolo externo e a porta onde o protocolo tiver uma. Use o diagnóstico do cliente e as observações de fluxo do dono da rede em vez de uma requisição de navegador bem-sucedida, que só prova que TCP e UDP funcionam. Depois disso, revise o grupo de segurança, a ACL da sub-rede, o firewall do convidado e a política do serviço para as duas direções do fluxo.

Não abra todo o tráfego para compensar um transporte que o serviço não consegue transportar. A mudança de regra não vai corrigir isso, e ela sobreviverá ao incidente.

Quando o transporte não cabe

Se o protocolo externo está fora do conjunto suportado, a correção é arquitetural: escolha um transporte que o caminho consiga transportar, ou mova a saída para algo que transporte o que você precisa. OpenVPN sobre UDP, WireGuard sobre UDP e túneis baseados em TLS cabem todos no conjunto documentado. Uma instância NAT gerenciada pelo cliente é a opção quando um protocolo específico precisa passar e o custo operacional de mantê-la é aceitável.

Hospedar um servidor VPN de entrada é um problema separado com uma resposta separada. Um gateway NAT fornece tradução de saída e nenhum encaminhamento de porta de entrada geral, então um servidor atrás dele precisa da sua entrada pública aprovada projetada nos próprios termos.

Ordem de trabalho: nomeie o protocolo externo, confirme o próximo salto, compare-o com o conjunto documentado e então mude a arquitetura ou o transporte. Um número de porta diferente não transforma GRE em TCP, e uma regra mais permissiva não transforma uma troca de controle concluída em um canal de dados funcional.