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 пра злучэнне апісвае зваротныя выклікі, якія адрозніваюць даступнасць ад змены сеткі па змаўчанні, і менавіта гэтае адрозненне патрэбна вашай справаздачы. Усё астатняе — гісторыя пра язду.