Рекурсивная маршрутизация: когда туннель перехватывает собственные пакеты

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

Сначала проверьте внешний путь

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

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

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

Почему сеанс держится мгновение

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

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

Найдите владельца исключения для конечной точки

Поддерживаемые клиенты сами устраивают своё исключение: маршрут к хосту сервера через исходный шлюз или метку, которая держит внешний сокет вне туннеля. Вопрос в том, не удалило или не перекрыло ли его что-то другое.

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

Проверьте ещё раз после смены сети

Маршрут к хосту через шлюз Wi-Fi верен до тех пор, пока машина не переедет в другую сеть. Тогда тот же симптом возвращается без каких-либо изменений в конфигурации.

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

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