VPN переподключается во время движения: смена радиосоты или смена IP?
Передача между вышками может оставить IP-путь нетронутым. Сравните клиентов, которые переносят туннель, с теми, что строят его заново, и читайте сетевое событие, а не поездку.
Звонок обрывается, когда вы проезжаете окраину города, и значок VPN исчезает в тот же момент. Соблазнительно записать это как «смена вышки убила туннель». Произошли две разные вещи, и только одна из них связана с вышками. Радиопередача может оставить ваш IP-адрес, маршрут по умолчанию и сеанс совершенно нетронутыми, а настоящая смена адреса разорвёт любой туннель, который не может двигаться вместе с ней. Полезное упражнение — сравнить, как клиенты справляются со вторым случаем, потому что это говорит вам, видите ли вы задуманное поведение или ошибку.
Смена вышки не обязательно смена адреса
Мобильные сети поддерживают пакетный сеанс во время передач, пока якорь мобильности оператора остаётся тем же. Радиоканал меняется, туннель этого не замечает, и ни в одном журнале не должно появиться повторное подключение. Это обычный случай для движения внутри города.
Адрес меняют перемещение между якорями, переключение с Wi-Fi на сотовую сеть или восстановление туннеля на стороне оператора после долгой паузы. Эти события заменяют исходный адрес, который несут ваши пакеты, и партнёр VPN видит партнёра, который переместился.
Практическое следствие: движение не является доказательством. Устройство, проехавшее сорок километров, могло удерживать один адрес всю дорогу, а неподвижное устройство могло дважды сменить адрес, потому что сеть так решила. Запись события — единственный способ их различить.
Две схемы: перенести туннель или построить заново
Клиенты различаются тем, насколько им важно, что внешний источник изменился. Некоторые привязывают туннель к адресу, на котором он был построен, и требуют полного восстановления. Другие проверяют каждый пакет независимо и просто обновляют, куда отправляют ответы.
| Mechanism | Behaviour after the source changes | What the user notices |
|---|---|---|
| WireGuard | Endpoint updated on the next authenticated packet | Usually nothing; the tunnel continues |
| IKEv2 with MOBIKE | Security association moves to the new address | Short pause, no re-authentication |
| OpenVPN over UDP with float | Peer address may change without a restart | Might survive, depending on timing |
| Client bound to one address | Session dies and is rebuilt | A visible reconnect and a new authentication |
Верхняя строка объясняет много запутанных отчётов. У WireGuard нет сеанса, который можно разорвать: каждый пакет несёт индекс партнёра и проверяется, поэтому валидный пакет, приходящий с нового адреса, по определению от этого партнёра, и записанная конечная точка следует за ним. Клиент, который во время поездки непрерывно показывает «подключено», говорит правду.
Нижняя строка тоже не дефект. Пересборка сеанса повторно выполняет проверку по текущему адресу, и это именно то, что нужно, когда старый адрес теперь может принадлежать кому-то другому.
Наблюдайте событие, а не движение
В Android подсистема связи сообщает об изменениях сети как о событиях, и именно их следует сопоставлять с поведением клиента. Вывод объёмный, но важные части — сеть по умолчанию и её адрес:
adb shell dumpsys connectivity | grep -E 'NetworkAgentInfo|Default network'
adb shell ip -br addr show
adb logcat -b main -s Vpn:* | head -n 40На стороне сервера есть прямое измерение для случая роуминга. WireGuard хранит последнюю проверенную конечную точку для каждого партнёра, поэтому смена адреса выглядит как изменённое значение, а не как переподключение:
sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakesСравните конечную точку до и после поездки. Если адрес и порт не изменились, туннелю не нужно было ничего делать, и переподключение пришло откуда-то ещё, обычно из приложения. Если конечная точка изменилась, а метка времени рукопожатия осталась близка к обычному интервалу обновления ключа, туннель переместился, а не перезапустился.
Перезапуск выглядит иначе: метка времени рукопожатия сбрасывается на момент переподключения, и клиент записывает последовательность инициализации вместо тихого продолжения.
Когда переподключение — правильное поведение
Если считать каждое переподключение дефектом, появляются конфигурации, которые держат мёртвые сеансы живыми. Партнёр, чей адрес изменился потому, что сеть перераспределила его, не должен продолжать получать трафик для старого сопоставления, а клиент, который тихо продолжает, может в итоге отправлять в чёрную дыру, пока значок остаётся зелёным.
Сравните два отказа с точки зрения пользователя. Переподключение стоит нескольких секунд и новой проверки. Устаревший туннель стоит приложения, которое зависает без ошибки, а это гораздо труднее объяснить и гораздо чаще сообщают как «интернет сломался».
Под этим скрывается и вопрос политики. В промежутке между потерей одного пути и установлением другого некоторые клиенты возвращаются к прямой отправке трафика. Предотвращение этого — отдельный контроль от автоматического восстановления, и клиент может быть хорош в одном и плох в другом. Решите, что вам нужно, прежде чем настраивать любое из двух.
Запишите наблюдаемую последовательность
Полезный отчёт называет источник события: изменение сети по умолчанию с новым адресом, переключение с Wi-Fi на сотовую сеть или передача вообще без смены адреса. Затем он сообщает, что сделал клиент, с меткой времени со стороны сервера, а не из памяти.
Если туннель переместился, скажите об этом и отметьте новое семейство конечных точек. Если он был восстановлен, отметьте, удалась ли проверка с первой попытки и сколько длился промежуток. Эти три факта отличают здоровый мобильный дизайн от клиента, который мечется между сетями.
И избегайте фразы «смена вышки», если журнал устройства действительно этого не подтверждает. Документация Android о подключениях описывает обратные вызовы, которые отличают доступность от изменения сети по умолчанию, и именно это различие нужно вашему отчёту. Всё остальное — история про вождение.