Імена хостів VPN не працюють, а IP-адреси працюють: де шукати

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

Ім’я ставить питання, якого адреса не ставить

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

Працюйте від адреси назовні: спершу повне ім’я, потім голе ім’я хоста, і зазначте, яке з трьох працює. Шаблон підказує, який рівень перевіряти, перш ніж відкрити хоч один екран налаштувань. Вгадувати маршрути, коли FQDN розв’язується, — марна праця.

Прочитайте резолвер, який тунель справді встановив

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

resolvectl status
nslookup fileserver.corp.example
nslookup fileserver

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

Get-DnsClientNrptPolicy
ipconfig /all

Зупиніться, якщо внутрішня зона розв’язується через правильний сервер. Резолвер — не ваша проблема.

Суфікси пояснюють короткі імена, які не працюють

Ім’я з однією міткою розширюється списком суфіксів підключення перед надсиланням запиту. Якщо VPN не доставляє внутрішній суфікс, fileserver ніколи не стає fileserver.corp.example, і запит виходить як ім’я, якого не знає жоден публічний резолвер. Нав’язування суфікса або введення повного імені перевіряє гіпотезу, нічого не змінюючи на сервері.

nslookup fileserver.corp.example
ping -a 192.168.50.20

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

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

NetBIOS і WINS — інший механізм

Старий SMB усе ще може шукати голе ім’я службою імен NetBIOS, яка відповідає широкомовно або через сервер WINS. Широкомовлення залишається в одному широкомовному домені й зупиняється на першому маршрутизаторі, тож не може пройти тунель; WINS працює, бо клієнт має одноадресну адресу, на якій реєструється й яку опитує. Тому VPN, що несе лише IP, усе ще може підтримувати старі імена, коли WINS налаштований і доступний.

nbtstat -n
nbtstat -R

Для сучасного SMB покладайтеся на DNS і повне ім’я, а старий шлях відправте на пенсію. Якщо він справді старий, надайте WINS або замініть застосунок; середина — це черга підтримки, яка ніколи не порожніє.

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