Чи змінив VPN мій DNS? Порівняйте до і після
Профіль може навмисно переміщати ваші запити. Порівняйте політику резолвера та фактичну відповідь до і після підключення VPN, зберігаючи одну змінну.
Ви підключаєте тунель, відкриваєте приватну панель, і ім'я розв'язується в адресу, якої ви ніколи не бачили. Або відбувається протилежне: браузер продовжує працювати, а інструмент командного рядка раптом нічого не розв'язує. Обидва результати походять від однієї зміни, і люди зазвичай пояснюють це однією фразою про VPN, який «використовує власний DNS», а цього недостатньо точно для діагностики чи перевірки. У цій фразі приховані два питання: які запити має взяти на себе цей профіль і чи справді ваша машина надіслала їх тому резолверу, який їй видали? Розділяти їх — це і є весь метод, бо тест, що їх змішує, дає впевнену неправильну відповідь в обидва боки.
Чому профіль взагалі надає резолвер
Усередині тунелю імена за далеким кінцем зазвичай розв'язуються в адреси, що існують лише в цій мережі. Приватна зона на кшталт corp.internal не має публічного делегування, тому резолвер, який її обслуговує, має бути доступним зсередини тунелю. Той самий механізм слугує другій меті: коли запити інакше виходили б через вашого провайдера, резолвер на далекому боці утримує запит усередині зашифрованого шляху. Тому адреса DNS-сервера надходить як частина політики з'єднання, а не як глобальне налаштування, обране один раз для машини.
Сама адреса нічого не вирішує. Резолвер може відповісти лише тоді, коли до нього є маршрут, і найпоширеніша несправність — резолвер, доступний лише поки тунель піднятий. Коли тунель падає, а політика залишається, запити йдуть на адресу без шляху, і симптомом є тайм-аут, а не чиста помилка. Ця різниця важлива, коли ви читаєте наступний результат тесту, бо тайм-аут відправляє людей у налаштування транспорту, які ніколи не були задіяні.
Порівняйте дві схеми до порівняння відповідей
Повний тунель і розділений DNS дають протилежні очікування, і жодна зі схем не є несправністю. При повному тунелі кожен запит може перейти до провайдера або до корпоративного резолвера, тому різна відповідь публічних імен після підключення очікувана. При розділеному DNS лише перелічені домени йдуть до приватного резолвера, а все інше залишається локальним; у Windows список доменів живе в Name Resolution Policy Table, у macOS — у відповідних доменах налаштувань DNS, а на хості з systemd-resolved — у доменах маршрутизації для кожного з'єднання.
Саме це порівняння треба зробити першим, бо воно вирішує, що вважати дефектом. При розділеному DNS публічне ім'я, що відповідає від нового резолвера, — це те, що варто дослідити, тоді як внутрішнє ім'я, що відповідає правильно, — це система, яка виконує свою роботу. При повному тунелі аномалією є публічне ім'я, яке досі відповідає від резолвера вашого провайдера. Документація Microsoft про розв'язання імен VPN описує порядок Windows для цих правил, зокрема те, як відповідний запис політики враховується раніше за власні сервери адаптера.
У кімнаті є й третій резолвер, про який легко забути. Безпечний DNS браузера сам розв'язує імена й може продовжувати відповідати після того, як тунель змінив політику операційної системи, тому сторінка, що завантажується, доводить, що резолвер браузера працював, а не що профіль застосовано. Якщо ви порівнюєте лише те, що показує браузер, половину часу ви перевіряєте не той рівень.
Запишіть базову лінію лише з однією змінною
Змініть тунель. Не змінюйте в тому самому кроці також ім'я, інструмент чи суфікс пошуку. Виберіть ім'я, яке вам дозволено запитувати, занотуйте, який застосунок використовували, і запишіть або адресу, що повернулася, або точну помилку. У Windows Get-DnsClientServerAddress -AddressFamily IPv4 друкує сервери за адаптером, а Get-DnsClientNrptPolicy — записи політики; у Linux із systemd-resolved resolvectl status показує DNS-сервери та домени маршрутизації для кожного з'єднання; у macOS scutil --dns друкує порядок резолверів, якого система справді дотримуватиметься.
Потім підключіться через звичайні елементи керування клієнта й повторіть точно ті самі команди. Збережіть перший вивід, а не спогад про нього, бо порівняння і є весь сенс, а друге читання після очищення кешу — це вже інший вимір. Якщо базову лінію знімали з браузером попереду, а запуск після підключення відбувається в терміналі, ви порівнюєте два резолвери, а не два стани одного резолвера.
Явний запит і пошук застосунку — різні тести
Запитати один конкретний сервер, через nslookup name 10.20.0.1 або dig @10.20.0.1 name, доводить одну річ: що названий вами сервер відповідає, коли до нього можна дістатися. Він повністю обходить логіку вибору, тож не може сказати, чи обрала б система цей сервер для цього імені. Використовуйте його, щоб перевірити доступність призначеного резолвера, і не використовуйте для перевірки політики.
Пошук через локальний резолвер справді задіює вибір. resolvectl query name проходить ті самі правила доменів маршрутизації й повідомляє, який протокол відповів, Resolve-DnsName у Windows проходить через таблицю політик і кеш клієнта, а scutil --dns показує порядок, якого дотримувався б пошук. Запустіть обидва типи й тримайте їх в окремих стовпцях нотаток. Успішний явний запит поруч із невдалим пошуком застосунку — це проблема маршрутизації або вибору, а не резолвер, що відмовляється працювати.
Кеш стоїть між вами та відповіддю. Операційна система, локальний stub-резолвер, браузер і негативний кеш зберігають результати, тож пошук може вдатися без жодного пакета, що залишив машину. Запишіть результат, перш ніж щось очищати: ipconfig /flushdns, resolvectl flush-caches або sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder у macOS. Пропустіть широке скидання мережі на цьому етапі, бо воно знищує докази, які ви ще збираєте.
Що означає різниця
Порівняйте два записані рядки та класифікуйте зміну, перш ніж торкнутися бодай одного налаштування.
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
Один рядок заслуговує наголосу. Ім'я, що розв'язується, — це не сервіс, що працює, а успіх DNS каже лише, що адресу знайдено. Він нічого не говорить про пересилання, правила брандмауера чи про те, чи ваш обліковий запис узагалі може користуватися сервісом, тож завершіть перевіркою реального застосунку, а не припущенням, що несправність минула сама.
Відновіть базову лінію та перевірте її
Відключіться через власні елементи керування клієнта, а не вбиваючи процес, і потім прочитайте ті самі три команди знову. Сервери за з'єднанням, записи політики та відповідь для вашого тестового імені мають повернутися до базової лінії, яку ви записали раніше. Залишковий запис політики після чистого відключення — це реальний дефект, який варто зафіксувати, і саме тому ручні правки згенерованого файлу резолвера — погана звичка: файл перезаписується і правка зникає, або правка виживає й закріплює резолвер, що більше не має маршруту.
Пройдіть цей список один раз, за порядком. Вирішіть, яку схему реалізує профіль, перш ніж оцінювати будь-який результат. Тримайте ім'я, інструмент і суфікс фіксованими в обох запусках. Відокремте явний запит від пошуку застосунку. Читайте чинну політику, а не лише відповідь. Очищайте кеші останніми, після того як порівняння записано. Перевірте реальним застосунком, потім один раз перезавантажтеся й підтвердьте, що відключений стан досі чистий.