Почему удалённый маршрут VPN возвращается после переподключения

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

Маршрут, который вы удалили вручную, возвращается после следующего переподключения, и таблица выглядит точно так же, как раньше. Это не ошибка маршрутизации: что-то заново создаёт запись из конфигурации или из действия жизненного цикла соединения. Большинство runbook'ов останавливаются на активной таблице, поэтому удаление как будто работает минуту, а затем срывается. Определите владельца, измените его и докажите это при переподключении.

Кто установил маршрут

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

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

Прочитайте таблицу перед редактированием

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

ip route show
ip route show table all
ip rule show

Поле протокола, метрика и номер таблицы говорят, смотрите ли вы на статическую запись, запись, созданную ядром, или что-то добавленное демоном. Список правил важен, потому что поиск может полностью покинуть основную таблицу, и тогда правка там становится невидимой для приложения, которое вы отлаживаете. Читайте строку слева направо: назначение, шлюз, устройство, протокол и метрика.

Затем спросите ядро, какой маршрут оно на самом деле использовало бы. Защищённый адрес — лучший зонд, чем публичный:

ip route get 10.20.5.7

Меняйте владельца, а не симптом

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

Сохраните исключение конечной точки. Маршрут к хосту, который отправляет собственный публичный адрес сервера VPN через физический шлюз, — это то, что поддерживает поток внешних пакетов туннеля; удалите его, и туннель попытается нести сам себя. В профиле split tunnel та же осторожность относится к локальным подсетям, которые должны обходить туннель.

Переподключитесь и проверьте оба пути

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

ip route get 10.20.5.7
ip route get 198.51.100.20

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

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

Похожие статьи