Внутрішні імена не працюють через VPN, а публічні сайти відкриваються

Один користувач повідомляє, що ім’я хоста у внутрішній мережі не розв’язується через VPN. Друге повідомлення з того самого ноутбука каже, що тест на витік досі показує запити, на які відповідає локальний резолвер. Вони звучать як одна проблема, але їх дві, з різними доказами, і звичайне виправлення першої робить другу гіршою. Розділіть їх, перш ніж чіпати будь-яке налаштування.

Два симптоми, які не є однією несправністю

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

Пастка в тому, що додавання офісного резолвера всюди виправляє першу і гарантує другу. Додавання публічного резолвера всюди робить навпаки.

Запишіть обидва спостереження з позначкою часу, а потім виконайте чотири перевірки нижче по порядку.

Резолвер якого адаптера отримує запит

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

Порядок прив’язки — це лише перша половина. Клієнт також має знати, які імена належать цьому адаптеру, а це питання суфікса, а не порядку.

Поставте ipconfig /all робочої машини поруч із виводом ноутбука, обидва зняті, коли тунель піднято. Робоча машина покаже специфічний для з’єднання суфікс DNS на своєму офісному адаптері, а ноутбук може не показати нічого на тунелі. Ця різниця пояснює цілий клас повідомлень «сервер он там, а ім’я все одно не розв’язується», бо без суфікса коротке ім’я ніколи не доповнюється до зони, яку обслуговує офісний резолвер.

Короткому імені потрібен суфікс раніше, ніж маршрут

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

Скопіюйте суфікс робочої машини у властивості IPv4 VPN-адаптера на вкладці DNS, а потім підключіться знову. У Linux еквівалент — домен пошуку на тунельному інтерфейсі, який systemd-resolved показує для кожного інтерфейсу окремо, а не глобально.

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

Спитайте резолвер напряму, потім ім’я

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

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

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

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

У Linux VPN-клієнт, який переписує /etc/resolv.conf, повністю замінює локальні резолвери. vpnc надає DNSUpdate no, щоб це зупинити, а systemd-resolved може спрямовувати до тунельного інтерфейсу лише перелічені домени. Обидва підходи тримають публічні імена на локальному резолвері, надсилаючи внутрішні імена до офісу.

Витоки — це правило, а не галочка в налаштуваннях

Розв’язання імен — це обмін UDP на порт 53, тож тунель, який несе веб-трафік, але не UDP, залишає запит на фізичному шляху. Доведіть це, знявши дамп на фізичному мережевому адаптері, поки розв’язується публічне ім’я. Запит, видимий на цьому інтерфейсі в читабельному вигляді, означає, що тунель його не несе.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

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

Ця остання частина важливіша, ніж здається. Запустіть OpenVPN з route-nopull, і надісланий параметр DNS зникне разом із маршрутами, якщо фільтр витягування не розширити, щоб його зберегти. А клієнт, який ігнорує dhcp-option DNS, і далі використовуватиме те, що мав раніше. Будь-яка зміна на боці сервера потребує нового сеансу, бо список резолверів доставляється, коли тунель піднімається, а застарілий сеанс продовжує показувати старий стан.

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