Чому DNS перестає працювати після підключення OpenVPN у Windows

Порт 53 нікуди не веде, хоч резолвер і далі відповідає на ping. Перевірте, чи не фільтрує block-outside-dns, а потім надайте резолвер, до якого тунель дістанеться.

Ping до офісного резолвера й далі отримує відповідь після підключення "OpenVPN", і при цьому кожен пошук імені зривається. Адреса доступна, а порт ні, поєднання, яке набуває сенсу, коли відомо, що Windows уміє фільтрувати DNS за адаптером. Якщо в профілі є block-outside-dns, цей фільтр і є перший підозрюваний, а таблиця маршрутів — не те місце для пошуку. Два тести нижче розділяють рівні за секунди.

Доступна адреса, мертвий порт

Успішний ping доводить, що хост працює і шлях існує. Про дозвіл дістатися порту 53 він не каже нічого, бо розглянутий фільтр працює на іншому рівні й прив'язаний до адаптера. Тому та сама машина може відповідати на ICMP і відхиляти кожен запит, надісланий на ту саму адресу. Запустіть обидва тести в одній сесії, перш ніж змінювати будь-яку конфігурацію.

ping <resolver-ip>
nslookup <name> <resolver-ip>

Ця пара і є діагноз. Звичайний трафік до підмережі триває, а розв'язання імен умирає, і люди роблять висновок, що сервер зламався або що DNS ніколи не передавався. Обидва пояснення дорого перевіряти, а докази вказують на щось вужче. Підтвердьте пару, перш ніж торкатися налаштування.

Цей параметр — правило платформи фільтрування

Довідка OpenVPN описує block-outside-dns як обмеження Windows Filtering Platform, яке не дає застосункам дістатися DNS на адаптерах поза тунелем. Воно охоплює TCP і UDP на порту 53. Оскільки фільтр живе в WFP, а не у звичайному списку правил брандмауера, правило дозволу, додане в іншому місці, не обов'язково змінює результат. Тому звична порада дозволити DNS і далі не спрацьовує.

Налаштування може прийти з імпортованого профілю або із сервера, а файл, який ви редагували останнім, "не доводить, що завантажив клієнт". Читайте чинну конфігурацію і журнал підключення разом. Параметр також специфічний для Windows, і ставлення до нього як до переносного дає поради, що не працюють.

Шукайте клієнтський компонент, якому належить обмеження, замість того щоб додавати нові правила. Власник — це те, що справді може його прибрати.

Фільтр — не резолвер

Блокування трафіку поза тунелем не встановлює всередині нього робочий резолвер. Параметр прибирає шлях і залишає DNS-конфігурацію тунелю тому, хто налаштовував профіль. Профіль, який ніколи не передавав резолвер, тепер не має жодного.

Пройдіть три перевірки по порядку. Перша: який резолвер насправді використовує застосунок, що зривається. Друга: чи застосував клієнт налаштування DNS для VPN. Третя: який інтерфейс несе трафік до цього резолвера.

  1. Використовуваний резолвер: порівняйте Resolve-DnsName -Server <resolver-ip> <name> з DNS-серверами, які перелічує ipconfig /all.
  2. DNS для VPN застосовано: перегляньте записи DNS тунельного адаптера в тому самому виводі ipconfig /all.
  3. Використаний інтерфейс: Find-NetRoute -RemoteIPAddress <resolver-ip> називає вихідний інтерфейс для цього адресата.

LAN-резолвер за задумом стає недоступним за такої політики, навіть поки інший LAN-трафік працює. Це параметр виконує свою роботу. Якщо за задумом потрібен DNS через VPN, виправте реєстрацію резолвера і шлях тунелю; якщо потрібен split DNS з локальними винятками, власник конфігурації має виразити ці винятки підтримуваним способом.

Чого параметр не покриває

Порт 53 — не все розв'язання імен. DNS over HTTPS і DNS over TLS використовують інший транспорт, а деякі застосунки виконують власну логіку резолвера незалежно від системних налаштувань. Тому браузер може розв'язувати імена, а командний рядок — ні.

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

Тримайте висновок вузьким, коли записуєте його. Цей параметр обмежує один транспорт на одній платформі, а решта шляху розв'язання — окреме питання проєктування зі своїм власником.

Перевірте стан до і після відключення

Запустіть той самий пошук під час підключення і знову після того, як клієнт-власник відключиться. Перший має зриватися для зовнішнього резолвера, поки тунель піднятий, а другий має проходити після зняття фільтра. Якщо після відключення він усе ще зривається, фільтр не було очищено.

ipconfig /displaydns
nslookup <name> <resolver-ip>

Перезапуск клієнтської служби або машини зазвичай знімає застарілий фільтр. Це підтверджує діагноз, не доводячи постійного виправлення. Запишіть побачене, бо фільтр, що пережив відключення, зробить це знову, і саме запис обґрунтовує звіт про помилку.

Лише після цих перевірок має сенс замінити резолвер або перебудувати політику брандмауера. Обидві зміни більші, ніж дозволяють докази.

Схожі статті