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

MAATRIX

Если нужно дать сотрудникам доступ к внутренним ресурсам, а ставить сторонний VPN-клиент на их ноутбуки нельзя или неудобно — штатный клиент Windows и протокол SSTP закрывают вопрос без лишнего софта. SSTP заворачивает трафик в TLS и ходит поверх 443-го порта, который почти никогда не режут корпоративные файрволы и домашние роутеры. Ниже — весь путь на Windows Server 2022: роль RRAS, сертификат, пул адресов, файрвол и разбор типичных ошибок по журналу событий.

Почему SSTP и при чём тут RRAS

SSTP (Secure Socket Tunneling Protocol) — протокол Microsoft, который упаковывает PPP-трафик в HTTPS-соединение. С точки зрения сети это обычный TLS-трафик на 443-й порт: снаружи он не отличим от захода на сайт, поэтому проходит через большинство NAT, прокси и файрволов без дополнительной настройки портов. Это его главное преимущество перед PPTP (давно небезопасен, режется провайдерами) и IKEv2/L2TP (используют UDP 500/4500, которые часто блокируются).

Минус тоже очевиден: SSTP — протокол Microsoft, полноценная поддержка есть только в Windows (начиная с Vista SP1 / Server 2008). Есть сторонние клиенты для Linux (sstp-client) и роутеров, но это уже не "из коробки". Если нужен кроссплатформенный вариант — присмотритесь к WireGuard на Windows Server: он быстрее и работает везде, но не маскируется под HTTPS и требует открытого UDP-порта.

RRAS (Routing and Remote Access Service) — встроенная роль Windows Server, которая умеет поднимать VPN-сервер сразу по нескольким протоколам (PPTP, L2TP/IPsec, SSTP, IKEv2), раздавать клиентам адреса, маршрутизировать трафик и работать как NAT. Именно она стоит за окном "VPN-сервер" в Windows Server — настраивать SSTP вручную через реестр не нужно, всё делается через мастер RRAS плюс один сертификат.

Подготовка сервера

Прежде чем включать роль, закройте три момента:

• у сервера должен быть статический IP (или закреплённый за интерфейсом адрес — если арендуете VPS, обычно он уже статический);
• нужен DNS-адрес, который резолвится на этот IP, — он же пойдёт в сертификат (например, vpn.example.com);
• порт 443 не должен быть занят другой службой — если на сервере уже стоит IIS или другой веб-сервер со слушателем на 443, SSTP с ним конфликтует.

Роль ставится через PowerShell:

Install-WindowsFeature -Name RemoteAccess -IncludeManagementTools
Install-WindowsFeature -Name Routing -IncludeManagementTools
Install-WindowsFeature -Name DirectAccess-VPN

Через GUI это тот же результат: Server Manager → Add Roles and Features → Remote Access → отметить Routing и DirectAccess and VPN (RAS). После установки сервер обычно просит перезагрузку — сделайте это сразу, чтобы не ловить странные ошибки на этапе настройки мастера.

Сертификат для SSTP: самоподписанный или AD CS

SSTP жёстко требует сертификат с приватным ключом в хранилище LocalMachine\My, у которого Subject/SAN совпадает с именем, на которое подключаются клиенты. Без этого мастер RRAS не даст включить SSTP или клиенты будут падать с ошибкой доверия.

Вариант 1 — самоподписанный сертификат. Подходит для небольших внедрений, где вы контролируете все клиентские машины:

$cert = New-SelfSignedCertificate `
  -DnsName "vpn.example.com" `
  -CertStoreLocation "Cert:\LocalMachine\My" `
  -KeyExportPolicy Exportable `
  -KeyLength 2048 `
  -NotAfter (Get-Date).AddYears(3) `
  -KeyUsage DigitalSignature,KeyEncipherment `
  -Type SSLServerAuthentication

Дальше сертификат нужно экспортировать (публичную часть, без приватного ключа) и вручную положить в "Доверенные корневые центры сертификации" на каждом клиентском компьютере — иначе Windows покажет ошибку недоверенного сертификата при подключении. В домене это делается одной групповой политикой (Computer Configuration → Windows Settings → Security Settings → Public Key Policies → Trusted Root Certification Authorities), вне домена — руками или скриптом.

Вариант 2 — сертификат от AD CS (внутреннего CA). Если в инфраструктуре уже есть служба сертификации, это удобнее: клиенты, входящие в домен, уже доверяют корневому CA, и ничего вручную разносить не нужно. Запрос делается через certreq или оснастку "Сертификаты" (MMC) с шаблоном, где Subject Alternative Name = FQDN сервера и Enhanced Key Usage включает Server Authentication (1.3.6.1.5.5.7.3.1).

Вариант 3 — публичный SSL-сертификат (Let's Encrypt или коммерческий) на реальный домен. Самый безболезненный для клиентов вне домена — не нужно разносить корневые сертификаты, но домен должен резолвиться публично и потребует продления (Let's Encrypt — раз в 90 дней, придётся автоматизировать перевыпуск и переустановку в RRAS).

Проверить, что сертификат встал в хранилище и виден системе, можно так:

Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Subject -like "*vpn.example.com*" }

Настройка RRAS: SSTP и пул адресов

Открываете консоль "Routing and Remote Access" (rrasmgmt.msc), правый клик по имени сервера → Configure and Enable Routing and Remote Access. В мастере:

1. Выбираете Custom configuration (не "Remote access (dial-up or VPN)" — так проще контролировать, какие протоколы включены).
2. Отмечаете VPN access.
3. После завершения мастера служба RRAS перезапускается — дайте ей 10-15 секунд.

Дальше открываете свойства сервера в консоли:

• Вкладка Security — здесь выбирается сертификат для SSTP (если он один подходящий в хранилище, мастер подставит его сам; если несколько — выберите нужный по отпечатку).
• Вкладка IPv4 — задаёте, как клиенты получают адрес: либо Static address pool с диапазоном (например, 10.10.10.10 — 10.10.10.100, отдельная подсеть, не пересекающаяся с вашей LAN), либо через DHCP-сервер в сети (RRAS тогда работает как DHCP-relay).

Если сертификат нужно привязать вручную (например, обновили его и RRAS не подхватил новый отпечаток), это делается через netsh:

netsh http show sslcert ipport=0.0.0.0:443

netsh http delete sslcert ipport=0.0.0.0:443
netsh http add sslcert ipport=0.0.0.0:443 certhash=<ОТПЕЧАТОК_СЕРТИФИКАТА> appid="{ba195980-cd49-458b-9e23-c84ee0adcd75}"

appid в примере — идентификатор самой службы RRAS, он одинаковый на всех серверах, менять его не нужно. После смены привязки службу RemoteAccess стоит перезапустить (Restart-Service RemoteAccess).

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

Клиентское подключение, файрвол и NAT

На клиенте (Windows 10/11) подключение добавляется через Параметры → Сеть и Интернет → VPN → Добавить VPN-подключение, тип — Secure Socket Tunneling Protocol (SSTP). Быстрее — через PowerShell, особенно если разворачиваете подключения массово:

Add-VpnConnection -Name "Office SSTP" `
  -ServerAddress "vpn.example.com" `
  -TunnelType Sstp `
  -EncryptionLevel Required `
  -AuthenticationMethod MSChapv2 `
  -RememberCredential `
  -AllUserConnection

На сервере нужно открыть входящий TCP 443. Мастер RRAS обычно сам создаёт нужные правила Windows Firewall, но если фильтрация идёт на внешнем файрволе облака/VPS-провайдера — там правило добавляете отдельно:

New-NetFirewallRule -DisplayName "SSTP VPN 443" -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow

В отличие от IPsec-протоколов, SSTP не требует пробрасывать GRE или заниматься NAT-T — весь трафик идёт одним TCP-соединением, что сильно упрощает жизнь, если сервер сам стоит за NAT. Подробнее про общую настройку файрвола под туннели — в статье про файрвол Windows Server для VPN.

Если сервер должен ещё и выпускать клиентов в интернет (полный туннель, а не только доступ к локальной сети), включите NAT на "внешнем" интерфейсе через тот же узел Routing and Remote Access → IPv4 → NAT → New Interface, либо мастером Routing and Remote Access для "NAT". Для сценария "только доступ к офисным ресурсам, интернет клиент берёт свой" NAT не нужен — оставляйте маршрутизацию только до внутренней подсети, это и безопаснее, и не грузит канал сервера чужим трафиком.

Диагностика: журнал событий RRAS и типичные ошибки

Первое место, куда стоит смотреть при проблемах, — Просмотр событий (eventvwr.msc):

• на сервере: Applications and Services Logs → Microsoft → Windows → RemoteAccess-MgmtClient/Operational и классический системный журнал с источником RemoteAccess — там события об успешных/неуспешных подключениях с кодом ошибки;
• на клиенте: Applications and Services Logs → Microsoft → Windows → RasClient/Operational.

Для более детальной трассировки PPP-уровня включается расширенное логирование RRAS:

netsh ras set tracing * enabled

Логи после этого пишутся в %windir%\tracing\ — там гораздо подробнее видно, на каком шаге падает установка соединения (TLS-хендшейк, аутентификация пользователя, назначение адреса). После отладки логирование стоит выключить (netsh ras set tracing * disabled) — иначе трейсы быстро съедают место на диске.

Частые коды и что за ними стоит:

Если ошибка воспроизводится не у всех клиентов, а точечно — почти всегда дело либо в недоверенном сертификате на конкретной машине, либо в правах доступа именно этого пользователя, а не в самом сервере. Стоит держать отдельный чек по здоровью туннелей — как именно, описано в статье про мониторинг VPN-подключений на Windows Server.

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