Встроенный L2TP/IPsec-клиент Windows 11

MAATRIX

Windows 11 умеет подключаться к L2TP/IPsec без единой сторонней программы — весь клиент уже встроен в систему. Проблема в том, что из коробки он часто не работает: подключение обрывается на этапе согласования безопасности или зависает с ошибкой 809, если и клиент, и сервер сидят за NAT. Ниже — рабочая настройка от начала до конца, включая правку реестра, без которой L2TP из-за домашнего роутера почти никогда не поднимается.

Что нужно подготовить заранее

Перед тем как открывать мастер VPN, соберите четыре вещи — без них подключение либо не создастся, либо упадёт на первой попытке:

• Адрес сервера — IP или домен, на котором поднят L2TP/IPsec (например через libreswan или xl2tpd на Linux, либо RRAS на Windows Server).
• Preshared key (PSK) — общий ключ IPsec, задаётся на сервере отдельно от логина/пароля пользователя.
• Логин и пароль учётной записи, которая настроена именно для L2TP-подключения (это не пароль от Windows и не пароль root на сервере).
• Открытые порты на сервере и на пути к нему: UDP 500 (IKE), UDP 4500 (NAT-T) и protocol 50 (ESP), если между вами и сервером нет NAT — иначе ESP всё равно инкапсулируется в UDP 4500.

Если сервер вы администрируете сами, PSK и учётка создаются на его стороне — процесс описан в статьях про L2TP/IPsec через Libreswan и настройку L2TP/IPsec на Ubuntu 24.04. Если сервер — Windows Server с RRAS, там своя логика выдачи сертификатов и ключей, см. RRAS VPN L2TP/IPsec с нуля.

Проверить, что порты вообще доступны, можно с клиента ещё до создания VPN-подключения:

Test-NetConnection -ComputerName vpn.example.com -Port 500
Test-NetConnection -ComputerName vpn.example.com -Port 4500

Обе команды должны вернуть TcpTestSucceeded : True — да, это UDP-порты, но Test-NetConnection в режиме порта фактически проверяет, что пакет уходит и путь до сервера не блокируется файрволом на маршруте. Полной гарантии открытого UDP это не даёт, но отсекает грубые случаи вроде закрытого провайдером порта или неверного адреса.

Настройка через встроенный мастер VPN

Дальше — сам мастер, шаг за шагом.

1. Откройте Параметры → Сеть и Интернет → VPN.
2. Нажмите Добавить VPN-подключение.
3. В поле Поставщик VPN-услуг выберите Windows (встроенные).
4. Имя подключения — любое понятное, например Office L2TP.
5. Имя или адрес сервера — IP или домен вашего сервера.
6. Тип VPN — выберите L2TP/IPsec с предварительным ключом.
7. Предварительный ключ — вставьте PSK, который выдал сервер.
8. Тип данных для входа — Имя пользователя и пароль.
9. Введите логин и пароль учётной записи VPN, поставьте галочку Запомнить данные для входа, если не хотите вводить их каждый раз.
10. Нажмите Сохранить.

На этом мастер закончил, но у него есть скрытые опции, которые он не показывает напрямую — они открываются через Панель управления → Сеть и Интернет → Сетевые подключения, где нужно найти созданное подключение, кликнуть правой кнопкой → Свойства:

• Вкладка Безопасность — тип VPN должен остаться Layer 2 Tunneling Protocol with IPsec (L2TP/IPsec), шифрование данных — Обязательно (отключиться, если сервер не согласится) или Максимальное, в зависимости от того, что поддерживает сервер.
• Там же кнопка Дополнительные параметры — если сервер настроен строго на PSK (а не на сертификаты), убедитесь, что выбран пункт Использовать предварительный ключ для проверки подлинности и ключ введён без лишних пробелов — это частая причина ошибки 789 «не удалось установить безопасное соединение уровня IPsec».

Если сервер требует протоколы аутентификации, отличные от MSCHAPv2 (например, чистый PAP на некоторых самодельных серверах — что небезопасно и не рекомендуется), их нужно включить на той же вкладке Безопасность в разделе допустимых протоколов. По умолчанию Windows разрешает только MSCHAPv2, и это правильный выбор для продакшена.

Правка реестра для NAT-T: ключевой шаг

Вот главная причина, по которой L2TP/IPsec «не работает» именно на Windows-клиентах, стоящих за NAT (домашний роутер, офисный NAT, мобильная сеть) — Windows по умолчанию не устанавливает IPsec-соединения, если и клиент, и сервер находятся за NAT одновременно, либо ведёт себя непредсказуемо с NAT-T (NAT Traversal, инкапсуляция ESP в UDP 4500).

Поведение регулируется параметром реестра AssumeUDPEncapsulationContextOnSendRule. По умолчанию он либо отсутствует, либо равен 0 — и в этом случае Windows разрешает NAT-T только когда сервер имеет публичный IP без NAT перед собой, что в подавляющем большинстве случаев так и есть (VPS с белым IP), но клиент почти всегда сидит за NAT роутера. Из-за этого сочетания сама возможность построить IPsec SA через NAT оказывается заблокированной на уровне драйвера IKE.

Открываем PowerShell от имени администратора и выполняем:

New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\PolicyAgent" `
  -Name "AssumeUDPEncapsulationContextOnSendRule" `
  -Value 2 -PropertyType DWORD -Force

Значение 2 означает «разрешить NAT-T, даже если и клиент, и сервер за NAT» — это самый разрешающий и практичный режим для домашнего/офисного использования. После изменения обязательна перезагрузка — на лету параметр не подхватывается, перезапуска одной службы IKEEXT недостаточно.

Restart-Computer

Через реестр правится в ручном режиме тем же путём: regedit → HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent → создать параметр DWORD (32 бита) AssumeUDPEncapsulationContextOnSendRule со значением 2.

Важный нюанс: если сервер тоже Windows-машина (RRAS) и она тоже находится за NAT (пробрасываются порты с внешнего роутера на внутренний адрес сервера), тот же параметр нужно выставить и на сервере — иначе туннель поднимается с одной стороны и рвётся с другой. Для Linux-серверов на Libreswan/strongSwan эта проблема не характерна — они изначально ожидают NAT-T с обеих сторон и такого реестра не требуют.

Подключение и проверка, что туннель реально работает

После перезагрузки открываем Параметры → VPN, кликаем на созданное подключение → Подключиться. Если всё настроено верно, статус меняется на «Подключено» за 3–5 секунд.

Проверить, что трафик действительно идёт через туннель, а не просто «висит подключённым»:

ipconfig /all

В списке адаптеров должен появиться виртуальный адаптер PPP с IP-адресом из диапазона, который выдаёт сервер (обычно отдельная подсеть, не пересекающаяся с локальной сетью).

Get-NetIPConfiguration | Where-Object InterfaceAlias -like "*VPN*"

Показывает шлюз и DNS, полученные именно по VPN-соединению. Если DNS остался локальный (от домашнего роутера), а не серверный — это отдельная проблема с маршрутизацией DNS-запросов, а не с самим L2TP, и на факт работы туннеля не влияет, но может путать при диагностике утечек DNS.

Проверить маршрут до внешнего IP через туннель:

tracert 8.8.8.8

Если первым хопом идёт адрес из подсети VPN-сервера — весь трафик действительно завёрнут в туннель.

Типичные ошибки и их причины

Ошибка 809 после правки реестра и перезагрузки почти всегда означает, что проблема не в клиенте, а в роутере: часть бытовых роутеров (особенно с включённым «SPI Firewall» или устаревшей прошивкой) режет UDP 4500 или ломает NAT-T на уровне собственного ALG для IPsec/PPTP. В этом случае помогает отключение встроенного VPN-passthrough/ALG в настройках роутера — как ни странно, эта «помощь» обычно и ломает соединение.

Автоматизация подключения через PowerShell

Если VPN нужно поднимать на нескольких машинах или пересоздавать после переустановки Windows, быстрее сделать это скриптом, чем руками через мастер:

Add-VpnConnection -Name "Office L2TP" `
  -ServerAddress "vpn.example.com" `
  -TunnelType L2tp `
  -L2tpPsk "ваш-preshared-key" `
  -AuthenticationMethod MSChapv2 `
  -EncryptionLevel Required `
  -RememberCredential `
  -Force

Set-VpnConnectionIPsecConfiguration -ConnectionName "Office L2TP" `
  -AuthenticationTransformConstants SHA256128 `
  -CipherTransformConstants AES256 `
  -EncryptionMethod AES256 `
  -IntegrityCheckMethod SHA256 `
  -PfsGroup PFS2048 `
  -Force

New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\PolicyAgent" `
  -Name "AssumeUDPEncapsulationContextOnSendRule" `
  -Value 2 -PropertyType DWORD -Force

Параметры AuthenticationTransformConstants, CipherTransformConstants и EncryptionMethod должны совпадать с тем, что реально настроено на сервере — иначе клиент упадёт в ошибку 789 на этапе Phase 2. Если сервер настроен под дефолтные параметры Libreswan/strongSwan, стоит свериться с его конфигом (ipsec.conf или .conf в /etc/ipsec.d/), а не гадать.

Логин и пароль скриптом не задаются намеренно — их вводит пользователь при первом подключении через rasdial либо через диалог Windows, чтобы не хранить пароль в открытом виде в скрипте:

rasdial "Office L2TP" username password

Для автоматического запуска (например, в задаче планировщика при старте системы) пароль всё же приходится передавать, и это стоит делать только на доверенных машинах — либо выносить его в защищённое хранилище через Get-Credential и Export-Clixml, а не хранить строкой в .ps1-файле.

Частые вопросы