VPN rekonektiĝas dum vi veturas: ĉu radio-ŝanĝo aŭ IP-ŝanĝo?

La voko ĉesas kiam vi preterpasas la randon de la urbo, kaj la VPN-ikono malaperas en la sama momento. Estas tente registri tion kiel „ŝanĝo de turo mortigis la tunelon“. Okazis du malsamaj aferoj, kaj nur unu el ili temas pri turoj. Radio-transdono povas lasi vian IP-adreson, la defaŭltan itineron kaj la seancon tute sendifekta, dum vera adresa ŝanĝo rompos ĉiun tunelon, kiu ne povas moviĝi kun ĝi. Kompari kiel klientoj traktas tiun duan kazon estas la utila ekzerco, ĉar ĝi diras al vi, ĉu vi vidas dizajnitan konduton aŭ cimon.

Tura ŝanĝo ne nepre estas adresa ŝanĝo

Movaj retoj tenas la pakaĵan seancon viva dum transdonoj, kondiĉe ke la movebla ankro de la operatoro restas la sama. La radioligilo ŝanĝiĝas, la tunelo tion ne rimarkas, kaj neniu rekonekto devus aperi en iu ajn protokolo. Tio estas la ordinara kazo por moviĝado ene de urbo.

Adreson ŝanĝas moviĝo inter ankroj, transiro de Wi-Fi al poŝtelefona reto, aŭ reestablo de la tunelo ĉe la operatora flanko post longa paŭzo. Tiuj eventoj anstataŭigas la fontan adreson, kiun viaj pakaĵoj portas, kaj VPN-partnero vidas partneron, kiu moviĝis.

La praktika konsekvenco estas, ke moviĝo ne estas pruvo. Aparato, kiu veturis kvardek kilometrojn, eble konservis unu adreson la tutan vojon, kaj senmova aparato eble ŝanĝis sian adreson dufoje, ĉar la reto tiel decidis. Registri la eventon estas la sola maniero distingi ilin.

Du dizajnoj: movu la tunelon aŭ rekonstruu ĝin

Klientoj malsamas laŭ tio, kiom ili zorgas, ke la ekstera fonto ŝanĝiĝis. Iuj ligas la tunelon al la adreso, sur kiu ĝi estis konstruita, kaj postulas plenan reestablon. Aliaj memstarigas ĉiun pakaĵon kaj simple ĝisdatigas, kien ili sendas la respondojn.

La supra vico klarigas multajn konfuzajn raportojn. WireGuard havas neniun seancon por rompi: ĉiu pakaĵo portas la indekson de la partnero kaj estas aŭtentikigita, do valida pakaĵo alvenanta de nova adreso estas laŭdifine de tiu partnero, kaj la registrita finpunkto sekvas ĝin. Kliento, kiu montras „konektita“ seninterrompe dum veturado, diras la veron.

Ankaŭ la malsupra vico ne estas difekto. Rekonstrui la seancon reruligas la aŭtentikigon kontraŭ la nuna adreso, kio estas ekzakte tio, kion vi volas, kiam la malnova adreso nun povas aparteni al iu alia.

Observu la eventon anstataŭ la moviĝon

En Android la konekteca subsistemo raportas retajn ŝanĝojn kiel eventojn, kaj ĝuste tiujn vi devus korelacii kun la konduto de la kliento. La elĵetaĵo estas longa, sed la gravaj partoj estas la defaŭlta reto kaj ĝia adreso:

adb shell dumpsys connectivity | grep -E 'NetworkAgentInfo|Default network'
adb shell ip -br addr show
adb logcat -b main -s Vpn:* | head -n 40

Ĉe la servila flanko ekzistas rekta mezuro por la vojaĝa kazo. WireGuard konservas la laste aŭtentikigitan finpunkton por ĉiu partnero, do adresa ŝanĝo aperas kiel ŝanĝita valoro anstataŭ kiel rekonekto:

sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakes

Komparu la finpunkton antaŭ kaj post la veturado. Se la adreso kaj la pordo ne ŝanĝiĝis, la tunelo neniam devis fari ion, kaj la rekonekto venis de aliloke, kutime de la aplikaĵo. Se la finpunkto ŝanĝiĝis dum la manprema tempomarko restis proksime al sia normala ŝlosila renoviga intervalo, la tunelo moviĝis anstataŭ rekomenciĝi.

Rekomenciĝo aspektas alie: la manprema tempomarko resetiĝas al la momento de la rekonekto, kaj la kliento registras inicializan sekvencon anstataŭ trankvilan daŭrigon.

Kiam la rekonekto estas la ĝusta konduto

Trakti ĉiun rekonekton kiel cimon kondukas al agordoj, kiuj tenas mortintajn seancojn vivaj. Partnero, kies adreso ŝanĝiĝis ĉar la reto realokis ĝin, ne devus daŭre ricevi trafikon por la malnova mapado, kaj kliento, kiu silente daŭrigas, povas fini sendante en nigran truon dum la ikono restas verda.

Komparu la du malsukcesojn el la vidpunkto de la uzanto. Rekonekto kostas kelkajn sekundojn kaj novan aŭtentikigon. Malfreŝa tunelo kostas aplikaĵon, kiu haltas sen eraro, kion multe pli malfacilas klarigi kaj multe pli probable oni raportas kiel „la interreto rompiĝis“.

Sub tio kaŝiĝas ankaŭ politika demando. En la breĉo inter perdo de unu vojo kaj starigo de alia, iuj klientoj revenas al rekta sendado de trafiko. Malhelpi tion estas aparta regilo disde aŭtomata rehavigo, kaj kliento povas esti bona en unu kaj malbona en la alia. Decidu, kion vi bezonas, antaŭ ol agordi iun el ili.

Skribu la observitan sinsekvon

Utila raporto nomas la fonton de la evento: ŝanĝo de la defaŭlta reto kun nova adreso, transiro de Wi-Fi al poŝtelefona reto, aŭ transdono sen iu ajn adresa ŝanĝo. Poste ĝi diras, kion faris la kliento, kun la tempomarko de la servila flanko anstataŭ el la memoro.

Se la tunelo moviĝis, diru tion kaj notu la novan finpunktan familion. Se ĝi reestabliĝis, notu, ĉu la aŭtentikigo sukcesis unuafoje kaj kiom longe daŭris la breĉo. Tiuj tri faktoj distingas sanan movan dizajnon de kliento, kiu ŝanceliĝas inter retoj.

Kaj evitu la esprimon „tura ŝanĝo“, krom se la protokolo de la aparato vere pruvas ĝin. La konekteca dokumentaro de Android priskribas la retrovokojn, kiuj distingas haveblecon disde ŝanĝo de la defaŭlta reto, kaj ĝuste tiu distingo estas tio, kion via raporto bezonas. Ĉio alia estas rakonto pri veturado.