Кто на самом деле применяет DNS-настройки OpenConnect в Windows?

Поднять туннель — не то же самое, что установить его DNS-значения. OpenConnect ведёт переговоры, а помощник на стороне Windows применяет. Разрыв между этими двумя шагами объясняет большинство сбоев частных имён у этого клиента, и помощник почти никогда не является страницей настроек VPN в Windows.

Отделите то, что предложил шлюз, от того, что установил Windows

Клиент передаёт данные подключения интерфейсу скриптов, а варианты для Unix и Windows — это отдельные программы. В Windows реализация обычно представляет собой помощник на JavaScript, который читает переменные вроде внутреннего DNS-сервера и внутреннего домена, прежде чем коснуться любого адаптера. Ничто в самом туннеле не записывает состояние резолвера.

Это разделение важно, потому что значение может существовать в переговорах и так и не дойти до адаптера. Отсутствующий, срывающийся на полпути или являющийся старой копией, встроенной в оболочку GUI, помощник оставляет Windows точно такими, какими они были. Сеанс выглядит подключённым, частное имя по-прежнему разрешается через местного провайдера, и ничто в окне клиента не указывает на разницу. Чтение собственного вывода помощника — единственный надёжный способ узнать, на каком этапе всё сломалось.

Оболочка GUI может поставляться с собственной копией клиента и помощника, поэтому второй openconnect.exe в другом месте на диске ничего не доказывает. Найдите исполняемый файл, запустивший сеанс, прежде чем судить о его конфигурации.

Прочитайте состояние резолвера, не меняя его

Три запроса только для чтения покрывают обычную путаницу, и каждый отвечает на свой вопрос:

Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix
Get-DnsClientNrptPolicy -Effective

Сервер на уровне адаптера — это то, что большинство людей понимают под DNS для VPN. Суффикс, специфичный для подключения, решает, будет ли короткое имя вообще разворачиваться. Список политик пространства имён применяется к совпадающим именам независимо от порядка адаптеров, и пустой результат там не является дефектом, когда помощник никогда не собирался его создавать. Прочитать все три до правки — это то, что предотвращает исправление, которое лишь переносит симптом в другое место.

Начните с полного имени. Если FQDN разрешается, а короткое имя нет, то разрыв — это суффикс или список поиска, а не адрес сервера.

Вторым шагом спросите предполагаемый сервер напрямую любым уже установленным инструментом резолвера. Прямой ответ доказывает, что сервер доступен и авторитетен для зоны. Он ничего не доказывает о том, какой сервер приложение спрашивает по умолчанию.

Назовите компонент, которому принадлежит подключение

Обычны две схемы. Клиент, запущенный из терминала, явно передаёт путь к своему скрипту, поэтому владелец виден в выполненной команде. Упакованное приложение запускает клиент за вас и держит помощник в своём каталоге, а значит, поставщик решает, когда он изменится.

Сравните версии помощника между установками, прежде чем что-либо менять. Запуск помощника, полученного с зеркала, с повышенными правами только потому, что имя файла выглядит знакомым, превращает разрыв в DNS в инцидент безопасности.

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

Исправляйте владельца, а не адаптер

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

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

Проверьте приложение, которое действительно сбоит

Браузер с собственной настройкой шифрованного DNS игнорирует всё вышесказанное и продолжает отвечать из публичного резолвера. Приложение, держащее кэшированный отрицательный ответ с времён до поднятия туннеля, ведёт себя так же. Сравните его с обычным системным запросом на той же машине, прежде чем снова менять адреса резолвера.

Если системный запрос верен, а приложение нет, оставшийся дефект находится внутри DNS-конфигурации этого приложения, а не в пути VPN.