openfortivpn постійно перезаписує DNS? Знайдіть справжнього власника

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

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

Почніть з того, що з'єднання дійсно змінило

Підключіться один раз звичайною командою і порівняйте розв'язання до і після. На хості Linux із systemd-resolved resolvectl status друкує DNS-сервери та домени пошуку для кожного з'єднання, а нове з'єднання tun або ppp зі своїми серверами — це відбиток оновлення з боку клієнта. На macOS scutil --dns показує конфігурацію резолвера в тому порядку, у якому до неї звертаються програми.

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

Два перемикачі та записувач, якого придушує кожен

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

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns не дає клієнтові застосувати DNS-сервери, які той дізнався від шлюзу, а --pppd-no-peerdns не дає pppd проштовхнути DNS партнера в систему. Посібник upstream попереджає, що оновлення DNS через PPP можуть змагатися з власними оновленнями DNS клієнта, тому обидва перемикачі належать до фрагмента, а не один із них вважається достатнім.

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

Виберіть власника, перш ніж щось вимикати

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

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

Перевіряйте розв'язання за з'єднаннями, а не за файлами

Один /etc/resolv.conf не є переліком того, що застосунки насправді використовують на хості з обмеженим або доменним розв'язанням, тож читайте стан резолвера так, як його розкриває платформа.

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

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

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

Опустіть з'єднання і повторіть обидва запити. Те, що встановив вибраний власник, має прибрати або відновити саме він, а не залишити клієнт, який ви змусили замовкнути. Застарілий запис за з'єднаннями, що переживає тунель, продовжує надсилати приватні запити на адресу, яка більше недоступна.

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

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