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 про підключення описує зворотні виклики, які відрізняють доступність від зміни мережі за замовчуванням, і саме ця різниця потрібна вашому звіту. Усе інше — історія про водіння.