Вредност NAT-T у регистру Windows-а: прво проверите топологију

VPN веза у Windows-у не успева, претрага враћа вредност из регистра и та вредност се уноси уз поновно покретање. Тај редослед понекад делује и никада ништа не објашњава. Дотично подешавање одговара на једно питање о томе где се сервер налази у односу на NAT уређај, и бесмислено је док не знате који је протокол и у којој фази заказао.

Шта вредност заправо бира

AssumeUDPEncapsulationContextOnSendRule одређује да ли ће Windows IPsec имплементација покушати да успостави асоцијације са партнером иза NAT уређаја. Документована подразумевана вредност 0 не дозвољава тај случај, 1 га дозвољава када је сервер страна иза NAT-а, а 2 покрива превођење оба краја. То су тврдње о топологији — ко је где.

Читани као низ, бројеви описују све више превођења, а не све већу поузданост. Постављање 2 на мрежи где се ништа не преводи не чини везу бржом ни стабилнијом и не поправља неуспех аутентикације. Упутство Microsoft-а о NAT-у за L2TP/IPsec документује политику и њен историјски контекст платформе. Упоредите тај контекст са верзијом и улогом Windows-а које стварно извршавате, јер документ који је преживео неколико издања није тврдња о сваком тренутном build-у.

Ускладите топологију пре броја

Нацртајте пут и означите тачке превођења: да ли је клијент иза кућног рутера, да ли је сервер иза балансера оптерећења или заштитног зида који преписује адресе, и да ли је неки крај иза превођења оператера које не контролишете. Тек после тог цртежа можете одлучити да ли вредност важи и за који крај.

Тврдња да тренутне верзије 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 уређај и даље мора да преноси инкапсулирани саобраћај и повратни саобраћај. Вредност у регистру не ствара правило прослеђивања, не усклађује предлоге и не проверава идентитет, па веза која почне да ради после измене може да ради из потпуно другог разлога. Поново тестирајте оригинални протокол са оригиналном топологијом, затим запишите која је фаза заказала и зашто се очекивало да вредност то реши. Управо та реченица претвара интернет гласину у конфигурацију коју можете да браните.