Valoarea de registru NAT-T din Windows: mai întâi topologia

O conexiune VPN din Windows eșuează, o căutare returnează o valoare de registru și valoarea este introdusă împreună cu o repornire. Acea secvență uneori funcționează și nu explică niciodată nimic. Setarea în cauză răspunde la o întrebare despre unde se află serverul față de un dispozitiv NAT și nu are sens până nu știți ce protocol a eșuat și în ce etapă.

Ce selectează de fapt valoarea

AssumeUDPEncapsulationContextOnSendRule determină dacă o implementare IPsec din Windows va încerca asocieri cu un partener aflat în spatele unui dispozitiv NAT. Valoarea implicită documentată 0 nu permite acel caz, 1 îl permite când serverul este partea din spatele NAT, iar 2 acoperă traducerea ambelor capete. Acestea sunt afirmații de topologie despre cine este unde.

Citite ca o secvență, numerele descriu tot mai multă traducere, nu tot mai multă fiabilitate. Setarea 2 într-o rețea în care nimic nu este tradus nu face conexiunea mai rapidă sau mai stabilă și nu repară o eroare de autentificare. Ghidul NAT al Microsoft pentru L2TP/IPsec documentează politica și contextul ei istoric de platformă. Comparați acel context cu versiunea și rolul Windows pe care le rulați efectiv, pentru că un document care a supraviețuit mai multor versiuni nu este o afirmație despre fiecare build actual.

Potriviți topologia înaintea numărului

Desenați traseul și marcați punctele de traducere: clientul este în spatele unui router de acasă, serverul în spatele unui echilibrator de sarcină sau al unui firewall care rescrie adrese, și unul dintre capete este în spatele unei traduceri a operatorului pe care nu o controlați. Numai după acel desen puteți decide dacă valoarea se aplică și la care capăt.

Afirmația că versiunile actuale de Windows Server sunt livrate pur și simplu cu NAT traversal dezactivat este prea largă pentru a acționa pe baza ei. Contează politica din sistemul dumneavoastră, topologia din fața lui și schimbul care a eșuat, în această ordine. Dacă ambele capete au adrese publice, setarea nu este problema dumneavoastră. Priviți în schimb propunerea, certificatul sau contul și lăsați registrul în pace.

Verificați mai întâi etapa eșecului

L2TP/IPsec produce cel puțin trei eșecuri distincte: partenerul nu este accesibil, protecția IPsec nu poate fi stabilită, iar autentificarea utilizatorului PPP este respinsă după ce tunelul există. Un cont respins nu se repară schimbând politica NAT, iar o nepotrivire a propunerilor nu se repară prin repornire.

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 timeout fără respondent sugerează accesibilitate sau filtrare, nu politică. O respingere rapidă cu mesaj de propunere indică algoritmi. Un eșec după ridicarea tunelului aparține etapei de autentificare, care este alt proprietar și altă soluție.

SSTP peste HTTPS și IKEv2 nativ au propriile jurnale și propriile controale. Nimic din toate acestea nu devine un caz de NAT traversal doar pentru că rulează și pe Windows.

Faceți schimbarea cu o cale de întoarcere

Dacă politica documentată și topologia observată o cer amândouă, notați valoarea anterioară, aplicați schimbarea prin configurația administrată, nu printr-un script pentru fiecare profil, și planificați repornirea. Pe un server care găzduiește alte sarcini de lucru, aceasta nu este o modificare inofensivă.

Dispozitivul NAT trebuie în continuare să transporte traficul încapsulat și traficul de retur. O valoare de registru nu creează nicio regulă de redirecționare, nu aliniază propuneri și nu validează identitatea, așa că o conexiune care începe să funcționeze după schimbare poate funcționa dintr-un motiv complet diferit. Retestați protocolul original cu topologia originală, apoi notați care etapă a eșuat și de ce se aștepta ca valoarea să rezolve asta. Acea propoziție este ce transformă un zvon de internet într-o configurație pe care o puteți apăra.