Стойност в регистъра за NAT-T в Windows: първо проверете топологията

Връзката VPN под Windows се проваля, търсенето връща стойност в регистъра и стойността се въвежда заедно с рестарт. Тази последователност понякога работи и никога не обяснява нищо. Настройката, за която става дума, отговаря на един въпрос — къде се намира сървърът спрямо устройство NAT — и е безсмислена, докато не знаете кой протокол се е провалил и на кой етап.

Какво всъщност избира стойността

AssumeUDPEncapsulationContextOnSendRule определя дали реализацията на IPsec в Windows ще се опита да установи асоциации с партньор зад устройство NAT. Документираната стойност по подразбиране 0 не позволява този случай, 1 го позволява, когато сървърът е страната зад NAT, а 2 покрива случая, в който се преобразуват и двата края. Това са твърдения за топологията — кой къде е.

Прочетени като последователност, числата описват все повече преобразуване, а не все по-голяма надеждност. Задаването на 2 в мрежа, в която нищо не се преобразува, не прави връзката по-бърза или по-стабилна и не поправя отказ при удостоверяване. Ръководството на Microsoft за NAT при L2TP/IPsec описва политиката и историческия ѝ контекст на платформата. Проверете този контекст спрямо версията и ролята на Windows, които реално използвате, защото документ, преживял няколко издания, не е твърдение за всяка текуща сборка.

Съпоставете топологията преди числото

Начертайте пътя и отбележете точките на преобразуване: клиентът зад домашен рутер ли е, сървърът зад балансьор на натоварването или защитна стена, която пренаписва адреси, и дали някой от краищата е зад преобразуване на оператора, което не контролирате. Едва след тази рисунка можете да решите дали стойността е приложима и за кой край.

Твърдението, че текущите версии на Windows Server просто се доставят с изключен NAT traversal, е твърде широко, за да се действа по него. Важни са политиката във вашата система, топологията пред нея и обменът, който се е провалил — в този ред. Ако и двата края имат публични адреси, настройката не е вашият проблем. Вместо това погледнете предложението, сертификата или акаунта и оставете регистъра на мира.

Проверете първо етапа на отказа

L2TP/IPsec дава поне три различни отказа: партньорът е недостъпен, защитата на IPsec не може да се установи и удостоверяването на потребителя по PPP се отхвърля след установяване на тунела. Отхвърлен акаунт не се поправя чрез промяна на NAT политиката, а несъответствие в предложенията не се поправя с рестарт.

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

Изтичане на времето без отговаряща страна подсказва за достъпност или филтриране, а не за политика. Бърз отказ със съобщение за предложение сочи към алгоритми. Отказ след установяване на тунела принадлежи на етапа на удостоверяване, който е друг собственик и друга поправка.

SSTP през HTTPS и родният IKEv2 имат свои собствени журнали и свои собствени контроли. Нищо от тях не става случай на NAT traversal само защото работят и под Windows.

Направете промяната с път за връщане

Ако документираната политика и наблюдаваната топология заедно го изискват, запишете предишната стойност, приложете промяната чрез управляваната конфигурация, а не чрез скрипт за всеки профил, и планирайте рестарта. На сървър, който поддържа други натоварвания, това не е безобидно редактиране.

Устройството NAT все още трябва да пренася инкапсулирания транспорт и обратния трафик. Стойност в регистъра не създава правило за препращане, не съгласува предложения и не проверява самоличност, затова връзка, която започва да работи след промяната, може да работи по съвсем друга причина. Тествайте отново оригиналния протокол с оригиналната топология, после запишете кой етап се е провалил и защо стойността е трябвало да го реши. Именно това изречение превръща една интернет слухня в конфигурация, която можете да защитите.