Хто насправді застосовує 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.