VPN verbind weer tydens ry: radiowisseling of IP-wisseling?

Die oproep val weg wanneer jy verby die rand van die dorp ry, en die VPN-ikoon verdwyn op dieselfde oomblik. Dit is aanloklik om dit te boek as “sellatoringwisseling het die tonnel doodgemaak”. Twee verskillende dinge het gebeur, en net een daarvan gaan oor torings. ’n Radiowisseling kan jou IP-adres, verstekroete en sessie heeltemal ongeskonde laat, terwyl ’n werklike adreswisseling enige tonnel sal breek wat nie saam daarmee kan beweeg nie. Om te vergelyk hoe kliënte daardie tweede geval hanteer, is die nuttige oefening, want dit sê vir jou of jy ’n ontwerpte gedrag of ’n fout sien.

’n Toringwisseling is nie noodwendig ’n adreswisseling nie

Mobiele netwerke hou die pakketsessie lewendig oor oorhandigings heen solank die vervoerder se mobiliteitsanker dieselfde bly. Die radiokakel verander, die tonnel merk dit nie, en geen herverbinding behoort in enige log te verskyn nie. Dit is die gewone geval vir beweging binne ’n stad.

Wat die adres wel verander, is ’n beweging tussen ankers, ’n oorskakeling van Wi-Fi na sellulêr, of ’n hervestiging van die tonnel aan die vervoerder se kant ná ’n lang pouse. Daardie gebeurtenisse vervang die bronadres wat jou pakkette dra, en ’n VPN-eweknie sien ’n eweknie wat beweeg het.

Die praktiese gevolg is dat beweging nie bewys is nie. ’n Toestel wat veertig kilometer gereis het, het dalk die hele pad een adres behou, en ’n toestel wat stil staan, het dalk twee keer van adres verander omdat die netwerk so besluit het. Om die gebeurtenis te teken is die enigste manier om dié twee uitmekaar te hou.

Twee ontwerpe: skuif die tonnel of bou dit weer

Kliënte verskil in hoeveel hulle omgee dat die buitenste bron verander het. Sommige bind die tonnel aan die adres waarop dit gebou is en vereis ’n volledige hervestiging. Ander verifieer elke pakket onafhanklik en werk bloot by waarheen hulle die antwoorde stuur.

Die boonste ry verduidelik baie verwarrende verslae. WireGuard het geen sessie om te breek nie: elke pakket dra die indeks van die eweknie en word geverifieer, so ’n geldige pakket wat van ’n nuwe adres aankom, is per definisie van daardie eweknie, en die aangetekende eindpunt volg dit. ’n Kliënt wat “gekoppel” wys deurlopend oor ’n rit, vertel die waarheid.

Die onderste ry is ook nie ’n fout nie. Om die sessie te herbou, verifieer weer teen die huidige adres, wat presies is wat jy wil hê wanneer die ou adres moontlik nou aan iemand anders behoort.

Let op die gebeurtenis eerder as die beweging

Op Android rapporteer die konnektiwiteit-subsisteem netwerkveranderinge as gebeurtenisse, en dit is waarmee jy die kliënt se gedrag moet korreleer. Die dump is breedvoerig, maar die relevante dele is die versteknetwerk en sy adres:

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

Aan die bedienerkant is daar ’n direkte meting vir die swerfgeval. WireGuard stoor die laaste geverifieerde eindpunt per eweknie, so ’n adresverandering verskyn as ’n veranderde waarde eerder as ’n herverbinding:

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

Vergelyk die eindpunt voor en ná die rit. As die adres en poort onveranderd is, het die tonnel nooit iets hoef te doen nie en het die herverbinding van elders gekom, gewoonlik die toepassing. As die eindpunt verander het terwyl die handdruk-tydstempel naby sy normale hersleutelinterval gebly het, het die tonnel beweeg eerder as herbegin.

’n Herbegin lyk anders: die handdruk-tydstempel stel terug na die oomblik van herverbinding, en die kliënt teken ’n inisialiseringsreeks eerder as ’n stille voortsetting.

Wanneer die herverbinding die korrekte gedrag is

Om elke herverbinding as ’n fout te behandel, lei tot konfigurasies wat dooie sessies lewendig hou. ’n Eweknie wie se adres verander het omdat die netwerk dit hertoegewys het, behoort nie aanhou om verkeer vir die ou kartering te ontvang nie, en ’n kliënt wat stilweg voortgaan, kan in ’n swart gat stuur terwyl die ikoon groen bly.

Vergelyk die twee mislukkings uit ’n gebruiker se perspektief. ’n Herverbinding kos ’n paar sekondes en ’n herverifiëring. ’n Verouderde tonnel kos ’n toepassing wat hang sonder ’n fout, wat baie moeiliker is om te verduidelik en baie waarskynliker gerapporteer word as “die internet is stukkend”.

Daar is ook ’n beleidsvraag wat hieronder skuil. Tydens die gaping tussen die verlies van een pad en die vestiging van ’n ander, val sommige kliënte terug op die stuur van verkeer direk. Om dit te voorkom, is ’n aparte beheer van outomatiese herstel, en ’n kliënt kan goed wees in die een en swak in die ander. Besluit watter een jy nodig het voordat jy enigeen instel.

Skryf die waargenome volgorde neer

’n Nuttige verslag noem die gebeurtenisbron: ’n versteknetwerkverandering met ’n nuwe adres, ’n oorskakeling van Wi-Fi na sellulêr, of ’n oorhandiging sonder enige adresverandering. Dit sê dan wat die kliënt gedoen het, met die tydstempel van die bedienerkant eerder as uit die geheue.

As die tonnel beweeg het, sê so en let op die nuwe eindpuntfamilie. As dit hervestig is, let op of verifiëring die eerste poging geslaag het en hoe lank die gaping geduur het. Dié drie feite onderskei ’n gesonde mobiele ontwerp van ’n kliënt wat tussen netwerke wissel.

En vermy die frase “toringwisseling” tensy die toestel se log dit werklik vasstel. Die Android-konnektiwiteitsdokumentasie beskryf die terugroepe wat beskikbaarheid van ’n versteknetwerkverandering onderskei, en daardie onderskeid is die een wat jou verslag nodig het. Alles anders is ’n verhaal oor ry.