Чому nslookup розв'язує через VPN, а браузер ні

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

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

Відповідь визначають три політики

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

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

Чому браузер ставить інше питання

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

Перевага сімейства адрес пояснює затримку, а не відмову. Браузер, який у тунелі, що несе лише IPv4, першим запитує записи IPv6, чекає завершення часу очікування, перш ніж відступити. Firefox мав таку перевагу саме для цього, і її вимкнення є діагностичним кроком, а не ремонтом.

Прочитайте список резолверів і правила

У Windows виведіть те, що зберігає система, перш ніж будувати теорії. Get-DnsClientServerAddress показує сервери за інтерфейсами, Get-DnsClientNrptRule перелічує правила простору імен, а Resolve-DnsName відповідає на точне ім'я системним шляхом. Порівняйте цю відповідь із прямим запитом до сервера VPN за адресою. Коли Resolve-DnsName падає, а прямий запит проходить, підозрюваний — список резолверів або правило простору імен.

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

Недоступний проштовхнутий резолвер

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

Якщо резолвер недоступний, ремонт — це маршрут або включена підмережа, а не інший DNS-сервер.

Зашифрований DNS обходить увесь шлях

Браузери з DNS-over-HTTPS самі розв'язують імена через HTTPS-з'єднання з обраним постачальником. Коли це ввімкнено, системний резолвер і правила split DNS повністю обходяться для цих пошуків, тому внутрішні імена падають у браузері, тоді як операційна система розв'язує їх правильно. Буває й навпаки: внутрішні імена проходять у браузері через постачальника, який ніколи не повинен був їх бачити, і це проблема політики, а не зв'язності.

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

Ремонт, що відповідає збою

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

Потім відокремте пошук від з'єднання. Ім'я, що розв'язується у правильну адресу, але відмовляє в з'єднанні, — це проблема служби, брандмауера або сертифіката, і зміни DNS її не виправлять.

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