Кто должен владеть маршрутами и DNS, когда openfortivpn подключается?

В рабочей сессии openfortivpn четыре этапа накладываются друг на друга. Клиент аутентифицируется на шлюзе и начинает TLS-соединение, затем запускает PPP внутри этого соединения, затем получает адрес и сведения DNS и наконец применяет маршруты хоста и настройки резолвера. Каждый этап может быть живым, пока следующий нет, и поэтому «подключено» — такое скользкое слово в ветках поддержки.

Решение, снимающее большую часть путаницы, — кто владеет последним этапом. Либо VPN-клиент сам применяет изменения хоста, либо это делает другой компонент, и смешивание обоих наполовину — это то, из-за чего маршруты и файлы резолвера начинают описывать разные сессии.

Четыре этапа, которые выглядят как одно соединение

Первый этап — допуск. именованный домен аутентификации или одноразовый код, и получает параметры, необходимые для продолжения. Когда клиент печатает, что подключён к шлюзу, это значит, что транспорт TLS работает. Это не значит, что PPP договорился, и уж точно не значит, что внутреннее приложение доступно.

Второй этап — PPP-соединение. Клиент запускает процесс PPP против туннельного устройства, и обе стороны согласуют параметры соединения и адреса. Только после этого хост знает, какие локальные и удалённые адреса использует сессия, и только тогда маршрут в туннель имеет смысл.

Третий этап — применение этих сведений к хосту, и здесь важна собственность. Клиент может добавить маршруты и переписать конфигурацию резолвера, или ему можно сказать отступить и оставить и то и другое тому, что иначе управляет сетью на этой машине. README проекта описывает это как отдельные обязанности, а не как одно автоматическое поведение.

Кто редактирует таблицу маршрутизации

По умолчанию владельцем является клиент. Он добавляет маршрут к шлюзу через физический интерфейс, маршрут для партнёра туннеля и маршруты для сетей, которые сессии разрешено использовать, а затем удаляет их при завершении процесса. Это значение по умолчанию удобно на ноутбуке с одним сетевым менеджером и без другого VPN-программного обеспечения.

Выбирайте передачу только тогда, когда что-то другое действительно владеет маршрутизацией. Интеграция с сетевым менеджером, сетевое пространство имён контейнера или агент маршрутизации всего сайта могут уже знать, как устанавливать и очищать те же префиксы. Передача параметра no-routes тогда не даёт двум писателям бороться за одну и ту же таблицу, а это гонка, которая проявляется как периодическая потеря одной подсети, а не как чистый сбой.

Перекрытие — вторая причина для передачи. Если проталкиваемые маршруты включают префикс, который локальная сеть уже использует, клиент не может разрешить конфликт за вас. Кто-то должен решить, доступен ли этот префикс через туннель, через физический линк или через более конкретный маршрут, и это решение принадлежит тому, кто владеет топологией.

Очистка — третья. Клиент, который падает до удаления своих маршрутов, оставляет чёрную дыру, которая переживает сессию, и следующее соединение может добавить поверх неё дубликат. Кто владеет маршрутизацией, тот владеет и проверкой, что старые записи исчезли. Сделайте эту проверку частью пути запуска, а не необязательным шагом очистки.

Кто владеет DNS и файлом резолвера

DNS — это то же решение с более острыми краями. Клиент может принять DNS-серверы, которые сообщает шлюз или партнёр PPP, и записать их в конфигурацию резолвера хоста. На простой машине это именно то, что нужно, потому что внутренние имена тогда разрешаются только пока туннель активен.

На современном хосте Linux резолвером может управлять локальный stub, и перезапись файла резолвера за спиной этого stub создаёт конфигурацию, которая выглядит правильной и ведёт себя непоследовательно. Если хост уже запускает менеджер резолвера, позвольте ему владеть DNS и передайте ему серверы туннеля через его поддерживаемый интерфейс. Параметр no-dns клиента — правильный выбор там, а не обходной путь.

Разделённый DNS — отдельный вопрос от того, кто пишет файл. Отправлять каждый запрос через туннель просто и медленно; отправлять через него только внутренние зоны требует конфигурации для каждого домена, которую большинство простых клиентов не предлагают. Решите, какое поведение нужно хосту, прежде чем включать изменения резолвера клиента. Неправильный выбор здесь выглядит как сбой разрешения имён, даже когда сам туннель в порядке.

Права, готовность и передача

Создание туннельного устройства и редактирование маршрутов хоста или состояния резолвера требуют повышенных сетевых полномочий. Частая ошибка — заключить, что поэтому всё должно работать как root, включая браузер или приложение, использующее туннель. Держите привилегированную часть маленькой: клиент и его файл конфигурации, принадлежащие администратору, а пользовательские приложения сохраняют обычную учётную запись.

Готовность следует определять для каждого потребителя. Супервизор может считать службу запущенной, когда процесс клиента работает и туннельное устройство существует. Заданию резервного копирования следует считать VPN пригодным только тогда, когда его хранилище отвечает через туннель. Это разные проверки, и использование более слабой для более сильной цели порождает задания, которые стартуют слишком рано и периодически сбоят. Запишите выбранное определение, потому что супервизор и задание, которые расходятся в готовности, — это заявка в поддержку, ждущая своего часа.

Проверьте контракт четырьмя наблюдениями: этап шлюза завершается, PPP назначает адреса, нужный маршрут присутствует и запрос к внутреннему хосту успешен. Затем остановите клиента и подтвердите, что каждое из этого удалено или восстановлено. Если после закрытия туннеля хост всё ещё разрешает внутренние имена или всё ещё держит маршрут, передача собственности неполна.