Windows Server RRAS: разворачиваем VPN-сервер L2TP/IPsec с нуля

MAATRIX

Если у вас уже есть Windows Server и не хочется тащить на него сторонний VPN-софт — встроенная роль Routing and Remote Access (RRAS) поднимает L2TP/IPsec без единого стороннего пакета, штатными средствами системы. Плюс очевиден: клиент есть во всех современных ОС из коробки, ничего ставить на стороне пользователя не нужно. Минус тоже есть — конфигурация размазана по нескольким консолям (RRAS, NPS, Windows Firewall, сертификаты), и львиная доля проблем при первом запуске сводится к NAT-T: сервер вроде настроен правильно, а клиент за домашним роутером или мобильной сетью подключиться не может. Разберём весь путь по шагам — от установки роли до диагностики типичных ошибок.

Установка роли RRAS

Роль ставится через Server Manager или PowerShell — вторым способом быстрее и воспроизводимо, если серверов несколько.

Install-WindowsFeature -Name RemoteAccess -IncludeManagementTools
Install-WindowsFeature -Name RSAT-RemoteAccess-PowerShell

После установки роли сама служба Routing and Remote Access ещё не сконфигурирована — это отдельный шаг. Есть два пути настройки: графический мастер rrasmgmt.msc или PowerShell-командлет Install-RemoteAccess. Для одного сервера удобнее мастер — он нагляднее показывает, что именно включается.

# альтернатива мастеру — минимальная настройка VPN-доступа из PowerShell
Install-RemoteAccess -VpnType Vpn

Если сервер стоит за NAT хостинг-провайдера (частая ситуация с облачными VPS, где «белый» IP проброшен через виртуальный роутер платформы) — это не мешает установке, но важно для диагностики NAT-T дальше по тексту.

Настройка RRAS-мастером как VPN-сервера

Откройте rrasmgmt.msc, кликните правой кнопкой по имени сервера в дереве слева и выберите «Configure and Enable Routing and Remote Access». В мастере:

1. Выберите Custom configuration — стандартный шаблон «VPN access» включает и PPTP, а он нам не нужен: PPTP считается небезопасным протоколом и его стоит отключать явно.
2. Отметьте только VPN access.
3. После завершения мастера служба RRAS запустится, но по умолчанию будет слушать все поддерживаемые протоколы — PPTP, L2TP/IPsec и SSTP одновременно.

Чтобы оставить только L2TP/IPsec, откройте свойства сервера в RRAS (правый клик по имени сервера → Properties) и на вкладке Ports:

• Дважды кликните на «WAN Miniport (PPTP)» и уменьшите число портов до 0 либо снимите флажки «Remote access connections» / «Demand-dial routing connections».
• То же самое сделайте для «WAN Miniport (SSTP)», если SSTP не нужен.
• Оставьте включённым только «WAN Miniport (L2TP)» с нужным числом одновременных подключений (по умолчанию 128 — обычно достаточно с запасом).

Preshared key vs сертификаты: что выбрать

L2TP работает поверх IPsec, а IPsec на стороне сервера аутентифицируется одним из двух способов — общим ключом (preshared key, PSK) или сертификатом. Это принципиальный выбор, влияющий и на безопасность, и на удобство подключения клиентов.

Preshared key — один общий секрет на всех клиентов. Настраивается на вкладке Security в свойствах сервера RRAS: включите «Allow custom IPsec policy for L2TP/IKEv2 connection» и впишите ключ, либо тем же самым через PowerShell:

Set-VpnServerConfiguration -SharedSecret "ваш-длинный-случайный-ключ" -Force

Плюс — заводится за минуту, клиент вводит один и тот же ключ, никаких сертификатов возить не нужно. Минус — секрет действительно общий: если один сотрудник ушёл и ключ не сменили, риск остаётся, а смена PSK требует переконфигурировать вообще всех клиентов одновременно.

Сертификаты — на сервере должен быть установлен сертификат компьютера (в хранилище Local Computer\Personal) с назначением Server Authentication и полем Subject Name/SAN, совпадающим с адресом, по которому клиент обращается к серверу — IP или FQDN. В домене с AD CS сертификат выдаётся автозаявкой (autoenrollment), вне домена — через внешний CA или, для теста, самоподписанный:

New-SelfSignedCertificate -DnsName "vpn.example.com" `
  -CertStoreLocation "Cert:\LocalMachine\My" `
  -KeyExportPolicy Exportable -KeyUsage DigitalSignature,KeyEncipherment `
  -Type SSLServerAuthentication

Самоподписанный сертификат работает, только если его публичную часть вручную установить на каждом клиенте в хранилище доверенных корневых центров — иначе Windows откажется доверять серверу. Для клиентов вне домена и без своего CA это быстро превращается в ту же ручную рассылку, что и с PSK, только сложнее — поэтому PSK чаще выбирают для небольших разворотов, а сертификаты там, где уже есть корпоративный CA и раздача доверия через групповые политики.

Настройка пула IP-адресов и NPS

VPN-клиентам нужны внутренние адреса. На вкладке IPv4 свойств сервера RRAS задайте статический пул:

Начальный адрес: 10.50.0.10
Конечный адрес:  10.50.0.100

Этот диапазон не должен пересекаться с адресацией локальной сети сервера. Альтернатива — раздача через DHCP-relay, если в сети уже есть DHCP-сервер, но для одиночного VPN-сервера статический пул проще и предсказуемее.

Аутентификацию пользователей RRAS по умолчанию делает через Windows-аутентификацию (локальные учётные записи или домен), но для гибких политик — ограничение по времени, группам, требование определённого метода шифрования — ставится роль Network Policy Server (NPS):

Install-WindowsFeature -Name NPAS -IncludeManagementTools

В консоли NPS (nps.msc) создайте Network Policy для VPN-подключений: условие — тип порта NAS «Virtual (VPN)», разрешённый протокол аутентификации — MS-CHAPv2 (минимально совместимый и поддерживаемый всеми клиентскими ОС вариант для L2TP/IPsec). PAP и CHAP без MS-CHAPv2 сегодня использовать не стоит — они слабее и на многих клиентах отключены по умолчанию.

Учётным записям пользователей, которым разрешён VPN-доступ, нужно явно включить право удалённого доступа — либо в свойствах пользователя в Active Directory (вкладка Dial-in → Allow access), либо через политику NPS с условием группы безопасности, что удобнее при количестве пользователей больше нескольких штук.

Firewall и NAT-T: какие порты открывать

L2TP/IPsec использует три UDP-порта:

При установке роли RRAS Windows Defender Firewall уже создаёт нужные правила, но часть из них выключена или ограничена профилем сети. Проверьте и включите вручную:

Get-NetFirewallRule -DisplayGroup "Routing and Remote Access" |
  Set-NetFirewallRule -Enabled True -Profile Any

New-NetFirewallRule -DisplayName "IPsec IKE UDP 500" `
  -Direction Inbound -Protocol UDP -LocalPort 500 -Action Allow
New-NetFirewallRule -DisplayName "IPsec NAT-T UDP 4500" `
  -Direction Inbound -Protocol UDP -LocalPort 4500 -Action Allow

Если сервер арендован в облаке, одного Windows Firewall часто мало — у самого хостинг-провайдера может быть отдельный сетевой firewall или security group перед виртуальной машиной, и порты нужно открыть на обоих уровнях. Базовые принципы настройки Windows Firewall под туннель разобраны отдельно в статье про файрвол Windows Server для VPN-туннеля — там же логика с закрытием RDP снаружи, которая пригодится и здесь.

Типичные проблемы NAT-T на Windows

Это самая частая причина «сервер настроен правильно, а клиент не подключается» — и почти всегда дело в одном из следующих пунктов.

Ошибка 809 («Не удалось установить сетевое подключение между вашим компьютером и VPN-сервером»). В девяти случаях из десяти это не ошибка настройки L2TP как такового, а блокировка UDP 500/4500/1701 где-то на пути — промежуточным firewall хостера, домашним роутером клиента с урезанной поддержкой IPsec passthrough, или самим Windows Firewall на сервере. Проверяйте по цепочке: сначала Test-NetConnection до сервера по нужным портам с клиентской стороны, потом логи на сервере.

Клиент и сервер оба за NAT. Штатное поведение Windows — по умолчанию IPsec NAT-T отключается, если оба конца соединения находятся за NAT (это защита от specific атак, заложенная в реализацию). Если ваш RRAS-сервер тоже виден клиенту не напрямую, а через NAT хостинг-платформы, потребуется правка реестра — причём на обеих сторонах, и на сервере, и на клиенте:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent" `
  /v AssumeUDPEncapsulationContextOnSendRule /t REG_DWORD /d 2 /f

После правки нужна перезагрузка — без неё ключ не подхватывается сервисом IPsec Policy Agent. Если сервер работает за «белым» публичным IP без NAT (стандартная ситуация для арендованного VPS/выделенного сервера), эта правка на сервере не нужна — только на клиентах, которые сами сидят за NAT.

Несколько клиентов за одним NAT-роутером. Известное ограничение L2TP/IPsec в Windows: если два сотрудника выходят в интернет через один внешний IP, одновременное подключение обоих к одному серверу может конфликтовать — вторая IPsec SA с того же адреса перебивает первую. Проявляется как рабочий туннель у одного человека и постоянные обрывы у второго из той же сети. Радикальное решение — WireGuard или OpenVPN, где такого ограничения нет; сертификатная аутентификация вместо PSK помогает не всегда.

Несовпадение сертификата и адреса подключения. Если выбрали аутентификацию по сертификату — клиент проверяет, что Subject Name или SAN сертификата совпадает с адресом, который он набирает при подключении. Подключаетесь по IP, а сертификат выписан на доменное имя (или наоборот) — получите ошибку валидации ещё на этапе IKE, до какой-либо диагностики L2TP.

Диагностика на сервере — два источника логов одновременно:

Get-EventLog -LogName System -Source "RemoteAccess" -Newest 50
Get-WinEvent -LogName "Microsoft-Windows-Wired-AutoConfig/Operational"

Плюс встроенный трейсинг для глубокого разбора конкретной сессии:

netsh ras set tracing * enabled

Логи трассировки пишутся в %windir%\tracing и по объёму избыточны для повседневного использования, но незаменимы, когда стандартный Event Log не показывает причину отказа.

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