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