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-клиент больше не один из писателей. Если значение откатывается через несколько секунд после поднятия соединения, что-то другое всё ещё применяет конфигурацию, и следующий шаг — определить этот компонент, а не добавить ещё один флаг. Желаемое конечное состояние — без событий: один владелец, одна документированная политика и отключённый хост, который разрешает имена точно так же, как до существования туннеля.