SSH обрывается на VPN каждую минуту? Дело не в keepalive

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

SSH подключается, работает около минуты, а затем каждый раз замирает примерно через один и тот же интервал. Обычное объяснение — тайм-аут простоя, поэтому люди снижают MTU и настраивают keepalive на клиенте. Соединение WireGuard, над которым я работал, уже прошло через всё это: меньший MTU туннеля, настройки client-alive, настроенный keepalive туннеля. Обрывы продолжались без изменений. Причиной оказался асимметричный маршрут в LAN, и этот шаблон стоит узнавать, потому что он побеждает любое исправление на основе таймеров.

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

Миф: keepalive исправляют тихий обрыв

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

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

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

Что на самом деле делает дополнительный шлюз

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

Адреса ниже отражают эту схему:

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

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

Ничего из этого не появляется в конфигурации клиента, поэтому поиск обычно начинается не в том файле.

Выберите один осознанный путь

Для схемы выше маршрутизация удалённой подсети напрямую на VPN-шлюз убирает половину соединения:

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

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

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

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

Проверьте с обеих сторон

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

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

Когда асимметрия нормальна

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

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

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