OpenVPN обрывается после продления DHCP: сохраните маршрут к конечной точке

Туннель подключается, затем продление аренды на канале доступа убивает его, а журнал винит таймаут, а не маршрут. В конфигурации VPN ничего не изменилось, и это и есть подсказка: изменилось что-то вне её. Событие DHCP переписало адрес или шлюз, и маршрут к узлу, который держал конечную точку туннеля доступной, теперь указывает на следующий переход, которого больше нет. Это проблема владения раньше, чем проблема маршрутизации.

Сравните симптом с полудефолтными маршрутами

С redirect-gateway def1 OpenVPN устанавливает 0.0.0.0/1 и 128.0.0.0/1 вместо замены маршрута по умолчанию. Вместе эти два покрывают всё адресное пространство и побеждают 0.0.0.0/0 уже одной длиной префикса. Поэтому любой пункт назначения без более точного совпадения попадает в туннель.

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

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

Почему полудефолтные побеждают без изменения метрики

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

Проверьте выбор с ip route get 203.0.113.10, подставив реальный адрес сервера. Ответ называет интерфейс и следующий переход, которые ядро действительно использовало бы, и это информативнее, чем читать таблицу и рассуждать о ней.

Выполните эту команду до запуска туннеля, во время его работы и после события аренды. Три ответа из одной команды, и точка расхождения становится видимой.

Сделайте три снимка, а не один

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

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

Когда конечная точка настроена как имя, а не как адрес, разрешайте его и в каждом снимке. Изменение DNS на канале доступа может сдвинуть конечную точку, вообще не затронув ни одного маршрута.

Решите, какой компонент обновляет исключение

В системе dhcpcd хуки запускаются из каталога хуков и из хука выхода, а режим менеджера по охвату отличается от режима на интерфейс. Что бы ни делал хук, он должен быть идемпотентным, потому что продления могут приходить пачками.

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

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

Проверяйте жизненный цикл, а не только переподключение

Принудительно продлите аренду с dhcpcd -n eth0 или освободив и снова взяв её, затем снова проверьте ip route get для конечной точки. Сделайте это дважды, потому что второй прогон ловит хуки, добавляющие дубликаты маршрутов. Затем перезагрузитесь, потому что устойчивость — это другое свойство, чем корректность.

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