Значэнне рэестра 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 па-ранейшаму павінна перадаваць інкапсуляваны транспарт і зваротны трафік. Значэнне рэестра не стварае правіла перанакіравання, не ўзгадняе прапаноў і не правярае асобу, таму злучэнне, якое пачало працаваць пасля змены, можа працаваць зусім з іншай прычыны. Пераправерце зыходны пратакол з зыходнай тапалогіяй, затым запішыце, які этап зламаўся і чаму значэнне павінна было яго вырашыць. Менавіта гэтае сказ ператварае інтэрнэт-чутку ў канфігурацыю, якую можна абараніць.