Кто владеет адресом, маршрутом, DNS и межсетевым экраном в Linux VPN?

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

Запишите эту карту один раз, и большинство сбоев переподключения перестанут быть загадочными. Важны четыре объекта: устройство и его адреса, маршруты и правила политики, конфигурация DNS и межсетевой экран.

Устройство и его адреса

Туннельное устройство создаёт либо менеджер, знающий профиль, либо демон, которого кто-то запустил вручную. Обе схемы работают сами по себе; их смешивание — нет. Если профилем владеет NetworkManager, пусть он владеет и устройством, и не запускайте неуправляемый OpenVPN процесс против того же имени туннеля.

Запишите, кто удаляет устройство, когда сеанс заканчивается. Устройство, переживающее свой сеанс, — самый частый источник устаревших адресов и следующей за ними путаницы.

Маршруты и правила политики

Именно на маршрутах конфликты владения наносят видимый ущерб. Менеджер соединений устанавливает маршрут по умолчанию для туннеля плюс более конкретный маршрут для удалённой сети; затем написанный вручную скрипт добавляет собственный маршрут по умолчанию с другой метрикой и тихо выигрывает или проигрывает в зависимости от момента. Решите, какие записи привязаны к соединению, какие являются постоянной политикой и какой компонент обновляет их после переподключения. Затем держите остальные компоненты вне этой таблицы.

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

DNS всегда отдельный владелец

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

Миф здесь в том, что запись сервера имён в профиль меняет, куда идут запросы. Она меняет то, что сообщается резолверу, а не сокет, который резолвер использует выше по потоку. Проверяйте запросом и поиском маршрута вместо доверия файлу.

Состояние межсетевого экрана и кто его восстанавливает

Правила межсетевого экрана — самый часто перезаписываемый объект на узле VPN. Менеджер может добавлять правила NAT или пересылки для каждого соединения, пока служба межсетевого экрана при загрузке заново загружает сохранённый набор правил и стирает их. Выберите один орган для политики и сделайте другой его потребителем, или примите, что перезагрузка тихо меняет поведение. Исключения, привязанные к соединению, должны находиться в файле, который загружает тот же владелец, а не в команде iptables, набранной во время диагностики.

Если правила должны переживать переподключение, скажите это явно. Если не должны, скажите и это, потому что следующий инженер предположит более удобный ответ.

Жизненный цикл: загрузка, переподключение, разборка

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

Для наблюдения ip monitor link address route показывает изменения ядра по мере их появления, но сообщает о событиях, а не о намерениях: удалённый маршрут ничего не говорит о том, какой процесс его удалил. Сопоставьте это с картой владения, и запутанное завершение работы превратится в короткий список кандидатов.

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