Ваш разделённый туннель доходит до приложения, но не до его DNS-сервера
Разделённый туннель может маршрутизировать подсеть приложения и при этом оставить резолвер рядом без маршрута. Добавьте маршрут к хосту, затем проверьте, какой сервер Windows выбирает на самом деле.
Маршрутизация подсети приложения — очевидная часть разделённого туннеля, и это не вся работа. Резолвер часто находится по другому адресу, чем приложение, которому он служит, поэтому рабочий туннель всё равно может оставить запрос за своими пределами. Профиль, который несёт 10.80.0.0/16 и больше ничего, отправляет запрос для 10.90.0.53 через локальный интерфейс, где частной зоны не существует. Добавьте маршрут к резолверу, затем посмотрите на вторую половину проблемы: какой сервер клиент на самом деле выбирает.
Миф: один маршрут покрывает всю службу
Разделённый туннель — это список назначений, которые идут через подключение, а не описание службы. Подсеть приложения и адрес резолвера — два назначения, и профиль может нести одно без другого. Когда так происходит, приложение доступно по адресу, а его имя не разрешается, что выглядит как сбой DNS, а не как пробел в маршрутизации.
Подсеть вокруг резолвера тоже не охватывается автоматически. Маршрута к хосту на один адрес достаточно для этого резолвера, и он не открывает соседей. В этом смысл маршрута к хосту: узкий по замыслу и легко забываемый, когда следующая служба появляется в той же подсети.
Чтобы поиск работал, должны выполняться три условия: клиент маршрутизирует адрес резолвера через туннель, шлюз принимает и пересылает этот запрос, а резолвер принимает полученный источник. Ответ тоже должен вернуться по согласованному пути. Если не хватает хотя бы одного, симптом одинаков, поэтому таблицу адресов стоит записать до того, как трогать конфигурацию.
Определите, какие адреса профиль должен нести
Перечислите назначения по порядку: сеть приложения, адрес резолвера и публичная конечная точка, которая завершает сам туннель. Третья никогда не должна маршрутизироваться в туннель, потому что внешнему подключению нужен путь, существующий до туннеля.
| Destination | Coverage this example needs |
|---|---|
| Application network | 10.80.0.0/16 through the VPN |
| Private resolver | 10.90.0.53/32 through the VPN |
| Public VPN endpoint | Normal internet path, outside the tunnel |
Включите и UDP, и TCP для DNS, так как от реализаций ожидается поддержка TCP наряду с UDP, а заблокированный путь TCP даёт медленные, частичные сбои вместо чистых. Если частная зона обслуживается и по IPv6, эквивалентное исключение для хоста использует адрес и префикс IPv6 и является отдельной записью.
Запишите, что профиль уже охватывает, прежде чем что-то добавлять. Дублирующий маршрут безвреден, но неожиданный существующий маршрут говорит о том, что профиль рассчитан на другой план адресов, чем тот, который вам выдали.
Добавьте маршрут к хосту через владельца подключения
Для локально управляемого собственного профиля Windows маршрут принадлежит подключению, а не глобальной таблице маршрутизации машины. Сначала посмотрите добавление в предварительном режиме, затем примените его с той же областью, которую использует профиль.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
Первая команда показывает изменение в предварительном режиме, ничего не устанавливая, а вторая перечисляет маршруты, которые профиль несёт сейчас. Справочник Microsoft по Add-VpnConnectionRoute описывает области для отдельного пользователя и для всех пользователей; профилю для всех пользователей нужен собственный параметр области, а команда для отдельного пользователя против профиля для всех пользователей завершается ошибкой или попадает не туда.
Когда профиль управляется или приходит от клиента поставщика, изменение принадлежит этому владельцу. Наслоение постоянного системного маршрута поверх политики подключения работает, пока политику не применят снова и маршрут не исчезнет, что обычно происходит во время звонка в поддержку, а не во время тестирования. Этот сбой тихий: маршрут исчезает, имя перестаёт разрешаться, и никто не связывает два события. Поместите изменение в собственную запись владельца, чтобы следующее повторное применение несло его, а не стирало.
После применения переподключите профиль, а не предполагайте, что маршрут вступил в силу. Изменения маршрутов на живом подключении не всегда подхватываются, а переподключение также воспроизводит состояние, которое ваши пользователи реально увидят.
Проверьте, какой резолвер клиент действительно использовал
Маршрут управляет пакетами, адресованными резолверу. Он не решает, какие имена туда отправлять, и этот выбор — отдельный механизм. В Windows действующие правила пространства имён могут выбирать резолвер для каждого домена, а параметры DNS профиля дают значение по умолчанию. Эти два слоя могут расходиться, не порождая никакой ошибки, поэтому прямой запрос — только половина доказательства.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
Первая команда печатает действующую политику пространства имён, а вторая спрашивает у частного резолвера напрямую имя приложения. Прямой ответ доказывает, что путь и резолвер работают; он не доказывает, что собственный запрос приложения выбрал этот сервер. Сравните его с обычным запросом того же имени и с ответом, который получает приложение.
Учитывайте кеши и безопасный DNS на уровне браузера, который может полностью обойти системный резолвер для имён, набранных пользователем. Суффикс поиска — ещё одна ложная подсказка: он расширяет короткое имя до полного и не имеет отношения к тому, какой сервер отвечает.
Закончите переподключением и повторением обычного запроса, затем убедитесь, что обычный просмотр по-прежнему следует утверждённой политике. Замена частного резолвера публичным, чтобы разрешилось постороннее имя, — не исправление, и она тихо переносит частные запросы туда, куда они никогда не должны были попадать.