Hodnota registru NAT-T ve Windows: nejprve zkontrolujte topologii

Připojení VPN ve Windows selže, hledání vrátí hodnotu registru a ta se zapíše spolu s restartem. Tento sled někdy funguje a nikdy nic nevysvětlí. Dotčené nastavení odpovídá na jednu otázku — kde je server vůči zařízení NAT — a nemá smysl, dokud nevíte, který protokol selhal a v jaké fázi.

Co hodnota vlastně volí

AssumeUDPEncapsulationContextOnSendRule určuje, zda se implementace IPsec ve Windows pokusí vytvořit asociace s protějškem za zařízením NAT. Dokumentovaná výchozí hodnota 0 tento případ nepovoluje, 1 jej povoluje, když je server stranou za NAT, a 2 pokrývá případ, kdy se překládají oba konce. To jsou výroky o topologii — kdo je kde.

Čteno jako posloupnost, čísla popisují stále více překladu, nikoli stále více spolehlivosti. Nastavení 2 v síti, kde se nic nepřekládá, neučiní připojení rychlejším ani stabilnějším a neopraví selhání ověřování. Pokyny Microsoftu k NAT u L2TP/IPsec dokumentují politiku a její historický kontext platformy. Porovnejte tento kontext s verzí a rolí Windows, které skutečně používáte, protože dokument, který přežil několik vydání, není tvrzením o každém aktuálním sestavení.

Nejprve sladit topologii, potom číslo

Nakreslete cestu a označte body překladu: je klient za domácím routerem, je server za vyvažovačem zátěže nebo firewallem, který přepisuje adresy, a je některý konec za překladem operátora, který nekontrolujete. Teprve po tomto náčrtu můžete rozhodnout, zda se hodnota vztahuje, a na který konec.

Tvrzení, že současné verze Windows Serveru se prostě dodávají s vypnutým NAT traversalem, je příliš široké na to, aby se podle něj jednalo. Důležité jsou zásady ve vašem systému, topologie před ním a výměna, která selhala, v tomto pořadí. Pokud mají oba konce veřejné adresy, nastavení není váš problém. Podívejte se místo toho na návrh, certifikát nebo účet a registr nechte být.

Nejprve zkontrolujte fázi selhání

L2TP/IPsec produkuje nejméně tři různé poruchy: protějšek není dostupný, ochranu IPsec nelze navázat a ověření uživatele PPP je odmítnuto poté, co tunel existuje. Odmítnutý účet nelze opravit změnou zásad NAT a neshodu návrhů nelze opravit restartem.

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

Časový limit bez odpovědi naznačuje spíše dostupnost nebo filtrování než zásady. Rychlé odmítnutí se zprávou o návrhu ukazuje na algoritmy. Selhání po navázání tunelu patří k fázi ověřování, což je jiný vlastník a jiná oprava.

SSTP přes HTTPS a nativní IKEv2 mají vlastní protokoly a vlastní ovládání. Nic z toho se nestane případem NAT traversal jen proto, že běží také ve Windows.

Proveďte změnu s cestou zpět

Pokud to dokumentované zásady i pozorovaná topologie vyžadují, poznamenejte předchozí hodnotu, proveďte změnu spravovanou konfigurací, nikoli skriptem pro každý profil, a naplánujte restart. Na serveru, který podporuje jiné úlohy, to není neškodná úprava.

Zařízení NAT stále musí přenášet zapouzdřený provoz a zpětný provoz. Hodnota registru nevytváří žádné pravidlo předávání, neslaďuje návrhy a neověřuje identitu, takže spojení, které po změně začne fungovat, může fungovat z úplně jiného důvodu. Otestujte znovu původní protokol s původní topologií, pak zapište, která fáze selhala a proč měla hodnota tento problém řešit. Právě tato věta mění internetovou pověst v konfiguraci, kterou můžete obhájit.