Ім’я хоста в LAN не працює через VPN: суфікс, mDNS чи зона?

Поруч із пристроєм принтер відповідає на коротке ім’я, а файловий сервер — на прізвисько. Через тунель обидва імені спливають за тайм-аутом, хоча їхні адреси досі працюють. Маршрут робить свою справу; шлях імен, який робив ці короткі імена робочими, так і не перетнув тунель. Таку поведінку створюють три механізми, і кожен потребує іншої правки.

Почніть із визначення, від якого механізму залежить ім’я.

Три типи імен, які поводяться по-різному

Ім’я з однією міткою, наприклад fileserver, зазвичай спирається на суфікс пошуку DNS, який додає резолвер. Цей суфікс часто надходить із локальною орендою DHCP, тому віддалений клієнт, який отримує адресацію від VPN, не має причин його знати. Додавання маршруту не доставляє суфікс. Коротке ім’я просто перестає існувати як ім’я, хоча адреса за ним доступна.

Ім’я, що закінчується на .local, зазвичай розв’язується через multicast DNS на локальному каналі, як описує RFC 6762. Multicast не проходить крізь маршрутизований тунель, якщо щось навмисно не мостить або не проксіює його, тому ім’я перестає розв’язуватися тієї миті, коли ви залишаєте сегмент.

Повністю визначене ім’я компанії належить внутрішній зоні, яку обслуговують резолвери організації. Воно працює віддалено, коли VPN проштовхує ці резолвери і клієнт налаштований їх використовувати. А localhost згідно з RFC 6761 має особливе призначення: вказує на машину перед вами, ніколи на віддалену службу.

Прочитайте резолвер, перш ніж змінювати маршрут

Запитайте, який сервер імен відповів і який суфікс було додано. Той самий запит через різні резолвери дає різні відповіді, і ця різниця — потрібний вам доказ.

getent hosts fileserver
getent hosts fileserver.corp.example.com
nslookup fileserver.corp.example.com
dig +search fileserver A
resolvectl query fileserver.corp.example.com
scutil --dns | head -30

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

Донесіть правильне ім’я до клієнта

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

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

Збережіть цілісність ідентичності сертифіката

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

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