Адрес партнёра изменился посреди сеанса: что делает float в OpenVPN

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

Что float ослабляет и что не ослабляет никогда

Обычно сеанс продолжает говорить с тем внешним адресом и портом, с которых начался, а пакеты, приходящие откуда-либо ещё, игнорируются. Параметр float снимает эту жёсткую привязку после того, как партнёр уже доказал себя, поэтому изменённое отображение источника может продолжить тот же сеанс вместо того, чтобы быть отброшенным. В криптографических проверках ничего не меняется: ключи, сертификаты и любая защита HMAC остаются в точности такими, как настроено.

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

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

Пакет, который перемещает сеанс, должен пройти аутентификацию

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

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

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

Обнаружение — совершенно отдельный механизм

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

Повторное добавление параметра не компенсирует отсутствие маршрута к новому адресу. Оно не поможет и тогда, когда партнёр молчит, потому что молчащий партнёр никогда не отправляет тот аутентифицированный пакет, который что-то сдвинул бы.

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

Когда профилем владеет NetworkManager

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

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

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

Докажите переход вместо того, чтобы предполагать его

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

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

Наконец, описывайте только тот случай, который вы проверили. Успешная смена адреса во время сеанса не доказывает, что миграции DNS, другая реализация клиента или пересобранный профиль поведут себя так же. Документация link-options точно указывает область действия параметра; в журнале теста должно быть сказано, какую часть этой области вы действительно покрыли.