Always On VPN — это не доступ к ЛВС: контрольный список ресурсов

Always On — это жизненный цикл подключения: профиль подключается при входе или до него и восстанавливает соединение без каких-либо действий пользователя. Это не означает, что разрешены любое частное назначение, протокол и пользователь. Практический вопрос в том, какие ресурсы развёрнутый профиль действительно доставляет, и ответ требует проверки по каждому ресурсу, а не взгляда на значок Connected.

Шаг 1: запишите ресурс до проверки

Начните с короткой записи по каждому приложению, взятой из реальной среды: имя, префикс назначения, служба и порт, роль туннеля, группа удостоверений и путь резолвера.

Name: portal.corp.example
Destination: 10.20.5.0/24
Service: HTTPS 443
Tunnel role: user access after sign-in
Identity: assigned employee group
Resolver: corporate private DNS

Запись заставляет задать четыре отдельных вопроса. Маршрут решает, куда идёт адрес; политика DNS решает, как клиент узнаёт адрес; фильтр трафика решает, может ли этот трафик использовать подключение; брандмауэр и разрешения приложения на стороне назначения решают, будет ли запрос принят. Ничто из этого не следует из подключённого туннеля.

Шаг 2: определите, какой туннель должен его нести

В Windows Always On VPN есть туннель устройства и пользовательский туннель, которые настраиваются как отдельные профили с отдельными сертификатами и областями. Туннель устройства обычно несёт только инфраструктуру, нужную до входа, например управление и доменные службы; широкий доступ сотрудников к приложениям относится к пользовательскому туннелю.

Фильтры трафика — функция туннеля устройства, поэтому пример Microsoft использует их для трафика управления. Копирование этого примера в общий профиль доступа к ресурсам даёт туннель, который подключается, но несёт неверный набор. Подтвердите активное подключение с помощью Get-VpnConnection и проверяйте именно под ним.

Шаг 3: проверьте маршрут для реального адреса

Разрешите имя один раз, затем проверьте маршрут: Find-NetRoute -RemoteIPAddress 10.20.5.10 показывает выбранный интерфейс, следующий переход и адрес источника. Если интерфейс — физический адаптер, префикса нет в наборе маршрутов туннеля или клиент исключил его раздельным туннелированием. Сравнивайте с определением профиля, а не добавляйте локальный маршрут.

Локальный route add может дать тесту пройти и исчезнуть при следующем обновлении политики, поэтому изменение должно быть в управляемом профиле. Проверьте префикс и в пользовательском профиле, и в профиле устройства, а также параметр раздельного туннелирования: полному туннелю не нужен маршрут на каждый префикс, раздельному нужен один на каждый частный префикс.

Шаг 4: проверяйте разрешение частных имён отдельно

У частных имён свой путь политики. Профиль может доставлять правила NRPT и список поиска суффиксов DNS, действующие, пока туннель поднят. Прочитайте с помощью Get-DnsClientNrptPolicy, что клиент действительно получил, затем проверьте имя и адрес в той же сессии. Если имена отказывают, а адреса работают, виноват резолвер; если и то и другое — маршрут.

Имя может разрешаться и в адрес вне маршрутов туннеля, что даёт смесь успеха и тайм-аута. Сравните возвращённый адрес с префиксом в вашей записи; если они различаются, частная зона отвечает публичным или альтернативным адресом, и совпавший маршрут — не тот, что проектировался.

Шаг 5: проверьте фильтры, удостоверение и собственные ворота приложения

Фильтры трафика ограничивают, какие протоколы и порты могут использовать туннель устройства, и узкий набор может заблокировать ресурс, который маршрут нёс бы. Профиль назначает подключение группе, но у ресурса есть собственная авторизация: пользователь, который может подключиться, не обязательно принимается файловым сервером.

Меняйте управляемый профиль через его владельца — Intune, развёртывание ProfileXML или скрипт эксплуатации — затем повторяйте тест после обычного переподключения и после перезагрузки: типичная причина — устаревший локальный маршрут или профиль, применённый один раз. Держите версию профиля рядом с результатом теста.