VPN verbindt opnieuw tijdens rijden: radioverwisseling of IP-wisseling?

De oproep valt weg wanneer je langs de rand van de stad rijdt, en het VPN-pictogram verdwijnt op hetzelfde moment. Het is verleidelijk om dat te boekstaven als “mastwissel heeft de tunnel gedood”. Er gebeurden twee verschillende dingen, en slechts één daarvan gaat over masten. Een radio-overdracht kan je IP-adres, standaardroute en sessie volledig intact laten, terwijl een echte adreswijziging elke tunnel breekt die niet mee kan bewegen. Vergelijken hoe clients dat tweede geval afhandelen is de nuttige oefening, want het vertelt je of je ontworpen gedrag of een bug ziet.

Een mastwissel is niet per se een adreswijziging

Mobiele netwerken houden de pakketsessie in leven tijdens overdrachten zolang de mobiliteitsanker van de provider gelijk blijft. De radiolink verandert, de tunnel merkt het niet, en er zou in geen enkel log een herverbinding moeten verschijnen. Dit is het gewone geval voor beweging binnen een stad.

Wat het adres wel verandert, is een verplaatsing tussen ankers, een overgang van Wi-Fi naar mobiel, of een hernieuwde tunnelopbouw aan providerzijde na een lange onderbreking. Die gebeurtenissen vervangen het bronadres dat je pakketten dragen, en een VPN-peer ziet een peer die is verplaatst.

De praktische consequentie is dat beweging geen bewijs is. Een apparaat dat veertig kilometer heeft gereden, kan de hele weg één adres hebben gehouden, en een apparaat dat stil staat, kan twee keer van adres zijn veranderd omdat het netwerk dat zo besloot. De gebeurtenis vastleggen is de enige manier om die twee te onderscheiden.

Twee ontwerpen: verplaats de tunnel of bouw hem opnieuw

Clients verschillen in hoeveel het hun uitmaakt dat de buitenste bron is veranderd. Sommige binden de tunnel aan het adres waarop hij is gebouwd en eisen een volledige heropbouw. Andere authenticeren elk pakket afzonderlijk en werken alleen bij waar ze de antwoorden naartoe sturen.

De bovenste rij verklaart veel verwarrende rapporten. WireGuard heeft geen sessie om te breken: elk pakket draagt de index van de peer en wordt geauthenticeerd, dus een geldig pakket dat van een nieuw adres komt is per definitie van die peer, en het vastgelegde eindpunt volgt het. Een client die tijdens een rit onafgebroken “verbonden” toont, vertelt de waarheid.

De onderste rij is ook geen defect. De sessie opnieuw opbouwen voert de authenticatie opnieuw uit tegen het huidige adres, wat precies is wat je wilt wanneer het oude adres nu van iemand anders kan zijn.

Observeer de gebeurtenis in plaats van de beweging

Op Android meldt het connectiviteitssubsysteem netwerkwijzigingen als gebeurtenissen, en die moet je correleren met het gedrag van de client. De dump is uitgebreid, maar de relevante delen zijn het standaardnetwerk en het adres ervan:

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 de serverkant is er een directe meting voor het roaminggeval. WireGuard bewaart het laatst geauthenticeerde eindpunt per peer, dus een adreswijziging verschijnt als een gewijzigde waarde in plaats van als een herverbinding:

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

Vergelijk het eindpunt voor en na de rit. Als het adres en de poort onveranderd zijn, hoefde de tunnel nooit iets te doen en kwam de herverbinding ergens anders vandaan, meestal de toepassing. Als het eindpunt veranderde terwijl de tijdstempel van de handshake dicht bij het normale sleutelvernieuwingsinterval bleef, is de tunnel verplaatst in plaats van herstart.

Een herstart ziet er anders uit: de tijdstempel van de handshake wordt teruggezet naar het moment van de herverbinding, en de client logt een initialisatiereeks in plaats van een stille voortzetting.

Wanneer de herverbinding het juiste gedrag is

Elke herverbinding als fout behandelen leidt tot configuraties die dode sessies in leven houden. Een peer wiens adres veranderde omdat het netwerk het opnieuw toewees, zou geen verkeer meer moeten ontvangen voor de oude toewijzing, en een client die stil doorgaat kan in een zwart gat sturen terwijl het pictogram groen blijft.

Vergelijk de twee storingen vanuit het perspectief van de gebruiker. Een herverbinding kost een paar seconden en een nieuwe authenticatie. Een verouderde tunnel kost een toepassing die vastloopt zonder fout, wat veel moeilijker uit te leggen is en veel vaker wordt gemeld als “het internet is stuk”.

Er schuilt ook een beleidsvraag onder. In de opening tussen het verliezen van de ene route en het opzetten van een andere vallen sommige clients terug op het rechtstreeks versturen van verkeer. Dat voorkomen is een aparte regeling naast automatisch herstel, en een client kan in het ene goed zijn en in het andere slecht. Bepaal wat je nodig hebt voordat je een van beide afstelt.

Schrijf de waargenomen volgorde op

Een bruikbaar rapport noemt de bron van de gebeurtenis: een wijziging van het standaardnetwerk met een nieuw adres, een overgang van Wi-Fi naar mobiel, of een overdracht zonder enige adreswijziging. Dan vermeldt het wat de client deed, met de tijdstempel van de serverkant in plaats van uit het geheugen.

Als de tunnel is verplaatst, zeg dat en noteer de nieuwe eindpuntenfamilie. Als hij opnieuw is opgebouwd, noteer of de authenticatie bij de eerste poging slaagde en hoe lang de opening duurde. Die drie feiten onderscheiden een gezond mobiel ontwerp van een client die tussen netwerken heen en weer slingert.

En vermijd de uitdrukking “mastwissel”, tenzij het apparaatlog dat echt vaststelt. De Android-documentatie over connectiviteit beschrijft de callbacks die beschikbaarheid onderscheiden van een wijziging van het standaardnetwerk, en dat onderscheid is wat je rapport nodig heeft. Al het andere is een verhaal over rijden.