OpenVPN надіслав DNS-сервер, але Linux його ігнорує

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

Перевірка перша: як починається з’єднання

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

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

Запишіть власника, перш ніж продовжити. Кожна наступна перевірка залежить від нього.

Перевірка друга: що насправді містить прив’язка резолвера

На хості з systemd-resolved resolvectl status перелічує кожну прив’язку з її DNS-серверами та доменами. Знайдіть прив’язку тунелю й прочитайте її записи, і не припускайте, що інтерфейс називається tun0, бо нумерація йде в порядку створення. Якщо надісланої адреси в прив’язці немає, то не відбулася передача, а не запит.

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

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

Перевірка третя: чи обирає простір імен цю прив’язку

Резолвер може містити правильний сервер і все одно не опитуватися. Домен на прив’язку вирішує, які запити йдуть до якої прив’язки, а без домену маршрутизації приватний простір імен повертається до того, що каже прив’язка за замовчуванням. Тому resolvectl query для внутрішнього імені може вдатися, тоді як застосунок досі зазнає невдачі. Можливо, застосунок використовує зовсім інший шлях резолвера.

Перевірте призначення домену, а не лише адресу сервера. Домен, записаний як ~corp.example, є доменом маршрутизації, і тильда змінює спосіб зіставлення імені.

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

Перевірка четверта: один власник, а не два

Якщо NetworkManager уже керує VPN і станом резолвера, додавання не пов’язаного hook-скрипта створює конкуруючих письменників. Hook, який пакет надає для systemd-resolved, є підтримуваною інтеграцією і очікує певного життєвого циклу: script-security 2, шлях up, up-restart, шлях down і down-pre. Ці параметри змушують реєстрацію та видалення відбуватися в потрібні моменти, а не лише під час першого з’єднання.

Використовуйте встановлений шлях із пакета, а не ілюстративний, скопійований із посібника. Права також важливі, бо hook запускається після зниження привілеїв.

Редагування скрипта резолвера дистрибутива для зміни його вихідної мети фіксує обхід для одного хоста. Це не загальне виправлення.

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

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

Лише коли всі п’ять перевірок проходять під час перепідключення, можна сказати, що надіслані налаштування використовуються. Усе раніше — знімок щасливого моменту.