Запускаете VPN-клиент через SSH? Сначала закрепите собственный маршрут

Вы подключаетесь по SSH к сборочному хосту, запускаете на нём VPN-клиент, и сессия перестаёт отвечать. Ничего не упало, и ничто не выглядит настроенным неправильно в очевидном смысле. Клиент установил маршрут по умолчанию, поэтому ответы на вашу рабочую станцию теперь уходят через туннель, где адрес вашей рабочей станции не маршрутизируется. Интересно то, что этот результат был предсказуем, а исправление — один маршрут, записанный до запуска клиента. Предположим сервер с одной сетевой картой, шлюз 192.0.2.254 и администратора, который подключается с 203.0.113.9.

Запишите путь до начала работы

ip route show default указывает текущий шлюз и интерфейс, а ip route get 203.0.113.9 показывает, какой интерфейс и адрес источника ядро использовало бы для вашей сессии. Сохраните оба вывода. После поднятия туннеля эти две команды должны по-прежнему описывать физический путь, а если они описывают туннель, сессия уже живёт на занятое время.

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

Закрепите адрес в конфигурации самого клиента

Маршрут, добавленный вручную, исчезает при перезагрузке и конкурирует с собственными обновлениями таблицы клиента, поэтому поместите исключение туда, где таблицей управляют. В OpenVPN ключевое слово net_gateway разрешается в шлюз, который существовал до туннеля, поэтому route 203.0.113.9 255.255.255.255 net_gateway оставляет ровно один адрес снаружи. WireGuard требует другого подхода, потому что wg-quick сам управляет маршрутами: задайте Table = off и добавьте исключение в PostUp, с соответствующим PostDown, который его удаляет. Обе формы выражают одно намерение, и обе ограничивают исключение одним адресом вместо ослабления туннеля для всего.

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

Или уберите главную таблицу из уравнения

Когда несколько служб на хосте должны сохранять свой обычный путь, перестаньте редактировать главную таблицу и дайте клиенту его собственную. Сетевое пространство имён с парой veth делает это чисто: маршрут по умолчанию клиента живёт в другом стеке, и туннель используют только процессы, запущенные внутри него. Политическая маршрутизация приходит в похожее место для одного назначения, отправляя подходящий трафик в отдельную таблицу, маршрут по умолчанию которой по-прежнему указывает на физический шлюз. Любой из подходов оставляет главную таблицу хоста без нового маршрута по умолчанию, и именно это свойство сохраняет SSH отвечающим.

Оба — больше механики, чем один маршрут к хосту, и оба стоят того, когда на машине больше одной вещи должно пережить туннель.

Допустите, что закрепление может не сработать

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

Две меры защиты стоят десяти минут. Сторож, который останавливает клиента, если подтверждающий вход не появился за несколько минут, превращает блокировку в задержку, а вторая SSH-сессия, удерживаемая открытой во время изменения, доказывает, что исключение работает, пока туннель поднят. Одни только keepalive здесь не помогают, потому что путь исчез, а не простаивает; они лишь делают смерть заметнее.

Проверяйте в том порядке, который важен

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

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