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