Valor del registre NAT-T de Windows: primer la topologia

Una connexió VPN de Windows falla, una cerca retorna un valor del registre i el valor s’introdueix amb un reinici. Aquesta seqüència de vegades funciona i mai no explica res. El paràmetre en qüestió respon una pregunta sobre on és el servidor respecte d’un dispositiu NAT, i no té sentit fins que saps quin protocol ha fallat i en quina etapa.

Què selecciona realment el valor

AssumeUDPEncapsulationContextOnSendRule decideix si una implementació d’IPsec de Windows intentarà associacions amb un igual darrere d’un dispositiu NAT. El valor predeterminat documentat 0 no permet aquest cas, 1 el permet quan el servidor és la banda darrere del NAT, i 2 cobreix els dos extrems traduïts. Són afirmacions de topologia sobre qui és on.

Llegits com una seqüència, els nombres descriuen cada cop més traducció, no cada cop més fiabilitat. Posar 2 en una xarxa on no es tradueix res no fa la connexió més ràpida ni més estable, i no repara cap fallada d’autenticació. La guia de NAT per a L2TP/IPsec de Microsoft documenta la política i el seu context històric de plataforma. Contrasta aquest context amb la versió i el rol de Windows que executes realment, perquè un document que ha sobreviscut diverses versions no és una afirmació sobre cada compilació actual.

Encara la topologia abans que el número

Dibuixa el camí i marca els punts de traducció: el client és darrere d’un encaminador domèstic, el servidor és darrere d’un balancejador de càrrega o d’un tallafoc que reescriu adreces, i algun dels extrems és darrere d’una traducció de l’operador que no controles. Només després d’aquest dibuix pots decidir si el valor s’aplica i a quin extrem.

L’afirmació que les versions actuals de Windows Server simplement s’envien amb el NAT traversal desactivat és massa àmplia per actuar-hi. El que importa és la política del teu sistema, la topologia que té al davant i l’intercanvi que ha fallat, en aquest ordre. Si els dos extrems tenen adreces públiques, el paràmetre no és el teu problema. Mira la proposta, el certificat o el compte, i deixa el registre tranquil.

Comprova primer l’etapa de la fallada

L2TP/IPsec produeix almenys tres fallades diferents: l’igual no és abastable, la protecció IPsec no es pot establir i l’autenticació de l’usuari PPP es rebutja després que el túnel existeixi. Un compte rebutjat no es repara canviant la política de NAT, i una discrepància de propostes no es repara reiniciant.

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 temps d’espera sense responedor suggereix abastabilitat o filtratge més que no pas política. Un rebuig ràpid amb un missatge de proposta apunta als algorismes. Una fallada després que el túnel estigui aixecat pertany a l’etapa d’autenticació, que és un altre propietari i una altra solució.

SSTP sobre HTTPS i IKEv2 natiu tenen els seus propis registres i els seus propis controls. Res d’ells es converteix en un cas de NAT traversal només perquè també s’executen a Windows.

Fes el canvi amb una via de retorn

Si la política documentada i la topologia observada ho demanen totes dues, anota el valor anterior, aplica el canvi per la configuració gestionada i no per un script per perfil, i planifica el reinici. En un servidor que dóna suport a altres càrregues de treball, això no és una edició innòcua.

El dispositiu NAT encara ha de transportar el trànsit encapsulat i el trànsit de retorn. Un valor del registre no crea cap regla de reenviament, no alinea cap proposta i no valida cap identitat, així que una connexió que comença a funcionar després del canvi pot estar funcionant per un motiu completament diferent. Torna a provar el protocol original amb la topologia original, i després anota quina etapa ha fallat i per què s’esperava que el valor ho resolgués. Aquesta frase és el que converteix un rumor d’internet en una configuració que pots defensar.