VPN підключено, але імена не розв'язуються: де насправді ламається DNS

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

Що насправді потрібно запиту

Запиту потрібні три речі: адреса резолвера, маршрут до цієї адреси й відповідь, що відповідає питанню. Кожна може відмовити сама по собі, а видимий симптом — та сама сторінка, яка не завантажується. Тому сторінка помилки майже нічого не каже, поки ви не знаєте, що саме з трьох зламалося.

Клієнт дізнається свій резолвер із профілю VPN, з DHCP на тунелі або з власної конфігурації, і те, яке джерело переможе, залежить від платформи. У Windows ipconfig /all виводить DNS-сервери за кожним адаптером, тож видно, чи справді надійшло надіслане значення. Надіслане значення, яке так і не дійшло до операційної системи, — тиха й часта відмова. Прочитайте налаштоване значення, перш ніж торкатися профілю.

Linux і macOS відповідають на те саме питання різними командами, і відповідь заслуговує такого самого читання: resolvectl status і scutil --dns обидві перелічують сервери за інтерфейсами. Порівняйте цей список з адресою, яку профіль нібито надсилає. Розбіжність тут пояснює все подальше, тому розберіться з нею до перевірки імен.

Перевірте одне публічне й одне приватне ім'я

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

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

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

nslookup example.com
nslookup host.corp.example 10.20.30.53

Переконайтеся, що клієнт справді досягає цього сервера

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

Кожна платформа відповідає на це одним рядком, і інтерфейс, названий у виводі, — це вся відповідь. Якщо він указує на фізичний адаптер, поки резолвер стоїть за тунелем, профіль не надсилає префікс, який його покриває.

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

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

Пам'ятайте, що браузери можуть обходити системний резолвер

Браузер із увімкненим захищеним DNS може надсилати запити через HTTPS обраному ним постачальнику й повністю ігнорувати резолвер операційної системи. Тоді система виглядає правильно, поки браузер відмовляє, або навпаки. Це питання політики для браузера, а не для тунелю.

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

Очистіть кеш і повторно перевірте реальне завдання

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

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

Далі повторіть початкове завдання, а не синтетичний запит, бо важливе саме завдання. Підключіться ще раз, щоб повторна перевірка охопила стан, у якому користувач справді опиниться. Довідка nslookup від Microsoft — це сторінка, яку варто зберегти для аргументів запиту.

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