Valor de registro NAT-T do Windows: primeiro a topologia

Uma conexão VPN do Windows falha, uma pesquisa devolve um valor de registro e o valor é inserido junto com uma reinicialização. Essa sequência às vezes funciona e nunca explica nada. A configuração em questão responde a uma pergunta sobre onde o servidor está em relação a um dispositivo NAT, e não faz sentido até você saber qual protocolo falhou e em que estágio.

O que o valor realmente seleciona

AssumeUDPEncapsulationContextOnSendRule determina se uma implementação de IPsec do Windows tentará associações com um par atrás de um dispositivo NAT. O padrão documentado 0 não permite esse caso, 1 o permite quando o servidor é o lado atrás do NAT, e 2 abrange a tradução de ambas as extremidades. São afirmações de topologia sobre quem está onde.

Lidos como uma sequência, os números descrevem cada vez mais tradução, não cada vez mais confiabilidade. Definir 2 em uma rede onde nada é traduzido não torna a conexão mais rápida ou estável, e não repara uma falha de autenticação. O guia de NAT da Microsoft para L2TP/IPsec documenta a política e seu contexto histórico de plataforma. Compare esse contexto com a versão e a função do Windows que você realmente executa, porque um documento que sobreviveu a várias versões não é uma afirmação sobre cada build atual.

Ajuste a topologia antes do número

Desenhe o caminho e marque os pontos de tradução: o cliente está atrás de um roteador doméstico, o servidor atrás de um balanceador de carga ou de um firewall que reescreve endereços, e alguma das extremidades está atrás de uma tradução da operadora que você não controla. Só depois desse desenho você pode decidir se o valor se aplica e a qual extremidade.

A afirmação de que as versões atuais do Windows Server simplesmente vêm com o NAT traversal desativado é ampla demais para agir com base nela. O que importa é a política no seu sistema, a topologia à frente dele e a troca que falhou, nessa ordem. Se as duas extremidades têm endereços públicos, a configuração não é o seu problema. Olhe para a proposta, o certificado ou a conta e deixe o registro em paz.

Verifique primeiro o estágio da falha

L2TP/IPsec produz pelo menos três falhas distintas: o par não é acessível, a proteção IPsec não pode ser estabelecida, e a autenticação de usuário PPP é rejeitada depois que o túnel existe. Uma conta rejeitada não se repara mudando a política de NAT, e uma divergência de propostas não se repara reiniciando.

Get-VpnConnection -Name "Corp L2TP" | Format-List Name, ServerAddress, TunnelType, EncryptionLevel
Get-WinEvent -LogName System -MaxEvents 40 | Where-Object Id -in 20227,20226,20274
netsh interface ipv4 show interfaces

Um tempo limite sem respondedor sugere acessibilidade ou filtragem em vez de política. Uma rejeição rápida com mensagem de proposta aponta para algoritmos. Uma falha depois que o túnel sobe pertence ao estágio de autenticação, que é outro dono e outra correção.

SSTP sobre HTTPS e IKEv2 nativo têm seus próprios logs e seus próprios controles. Nada disso se torna um caso de NAT traversal só porque também roda no Windows.

Faça a mudança com um caminho de volta

Se a política documentada e a topologia observada exigirem ambas, anote o valor anterior, aplique a mudança pela configuração gerenciada e não por um script por perfil, e planeje a reinicialização. Em um servidor que suporta outras cargas de trabalho, isso não é uma edição inofensiva.

O dispositivo NAT ainda precisa transportar o tráfego encapsulado e o tráfego de retorno. Um valor de registro não cria nenhuma regra de encaminhamento, não alinha nenhuma proposta e não valida nenhuma identidade, então uma conexão que começa a funcionar depois da mudança pode estar funcionando por um motivo completamente diferente. Teste novamente o protocolo original com a topologia original, depois anote qual estágio falhou e por que se esperava que o valor resolvesse isso. Essa frase é o que transforma um boato da internet em uma configuração que você pode defender.