Ваш домен VPN у dnsmasq — це не передавання зони

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

Те, що прийняв клієнт, — не те, що запропонував шлюз

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

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

Два види записів домену

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

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

localhost у resolv.conf — не помилка

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

Заміна цього запису публічним резолвером — класичне хибне виправлення. Воно відновлює публічне розв'язування імен і водночас відкидає умовну політику.

Не плутайте бекенди

Керований екземпляр dnsmasq і системний резолвер — це різні програми з різною конфігурацією та різними поданнями стану. Команда стану для одного не дає нічого корисного про інший.

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

Перевіряйте простір імен, а не лише відповідь

Запитайте одне дозволене приватне ім'я та одне публічне контрольне ім'я звичайним шляхом застосунку. Прямий запит до корпоративного сервера доводить, що запис існує; він не доводить, що клієнт вибрав цей сервер. Другий запит — це той, що перевіряє політику.

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