Valor do rexistro NAT-T de Windows: primeiro a topoloxía

Unha conexión VPN de Windows falla, unha busca devolve un valor do rexistro e o valor introdúcese xunto cun reinicio. Esa secuencia ás veces funciona e nunca explica nada. O axuste en cuestión responde a unha pregunta sobre onde está o servidor respecto dun dispositivo NAT, e non ten sentido ata que sabes que protocolo fallou e en que etapa.

Que selecciona realmente o valor

AssumeUDPEncapsulationContextOnSendRule determina se unha implementación de IPsec de Windows tentará asociacións cun par detrás dun dispositivo NAT. O valor predeterminado documentado 0 non permite ese caso, 1 permíteo cando o servidor é o lado detrás do NAT e 2 cobre a tradución de ambos os extremos. Son afirmacións de topoloxía sobre quen está onde.

Lidos como unha secuencia, os números describen cada vez máis tradución, non cada vez máis fiabilidade. Poñer 2 nunha rede onde non se traduce nada non fai a conexión máis rápida nin máis estable, e non repara un fallo de autenticación. A guía de NAT de Microsoft para L2TP/IPsec documenta a política e o seu contexto histórico de plataforma. Contrasta ese contexto coa versión e o rol de Windows que executas realmente, porque un documento que sobreviviu a varias versións non é unha afirmación sobre cada compilación actual.

Axusta a topoloxía antes que o número

Debuxa a ruta e marca os puntos de tradución: o cliente está detrás dun router doméstico, o servidor detrás dun balanceador de carga ou dun cortafuegos que reescribe enderezos, e algún dos extremos está detrás dunha tradución do operador que non controlas. Só despois dese debuxo podes decidir se o valor se aplica e a que extremo.

A afirmación de que as versións actuais de Windows Server simplemente se entregan coa traversía NAT desactivada é demasiado ampla para actuar sobre ela. O que importa é a política do teu sistema, a topoloxía diante del e o intercambio que fallou, nesa orde. Se ambos os extremos teñen enderezos públicos, o axuste non é o teu problema. Mira a proposta, o certificado ou a conta e deixa o rexistro en paz.

Comproba primeiro a etapa do fallo

L2TP/IPsec produce polo menos tres fallos distintos: o par non é accesible, a protección IPsec non se pode establecer e a autenticación de usuario PPP rexéitase despois de que exista o túnel. Unha conta rexeitada non se repara cambiando a política NAT, e unha discrepancia de propostas non 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

Un tempo de espera sen respondedor suxire accesibilidade ou filtrado máis que política. Un rexeitamento rápido cunha mensaxe de proposta apunta aos algoritmos. Un fallo despois de que o túnel estea levantado pertence á etapa de autenticación, que é outro propietario e outra solución.

SSTP sobre HTTPS e IKEv2 nativo teñen os seus propios rexistros e os seus propios controis. Nada diso se converte nun caso de traversía NAT só porque tamén se executa en Windows.

Fai o cambio cunha vía de volta

Se a política documentada e a topoloxía observada o esixen ambas, anota o valor anterior, aplica o cambio mediante a configuración xestionada e non mediante un script por perfil, e planifica o reinicio. Nun servidor que admite outras cargas de traballo, isto non é unha edición inocua.

O dispositivo NAT aínda ten que transportar o tráfico encapsulado e o tráfico de retorno. Un valor do rexistro non crea ningunha regra de reenvío, non aliña ningunha proposta e non valida ningunha identidade, así que unha conexión que comeza a funcionar despois do cambio pode estar funcionando por un motivo completamente distinto. Volve probar o protocolo orixinal coa topoloxía orixinal e logo anota que etapa fallou e por que se esperaba que o valor o resolvese. Esa frase é o que converte un rumor de internet nunha configuración que podes defender.