VPN verbindet sich beim Fahren neu: Funkzellenwechsel oder IP-Wechsel?

Der Anruf bricht ab, wenn Sie am Ortsrand vorbeifahren, und das VPN-Symbol verschwindet im selben Moment. Es liegt nahe, das als „Funkzellenwechsel hat den Tunnel gekillt“ zu verbuchen. Es sind zwei verschiedene Dinge passiert, und nur eines davon hat mit Funkzellen zu tun. Eine Funkübergabe kann Ihre IP-Adresse, die Standardroute und die Sitzung völlig unberührt lassen, während eine echte Adressänderung jeden Tunnel bricht, der nicht mitwandern kann. Der nützliche Vergleich ist, wie Clients den zweiten Fall behandeln, denn er sagt Ihnen, ob Sie ein entworfenes Verhalten oder einen Fehler sehen.

Ein Funkzellenwechsel ist nicht zwingend ein Adresswechsel

Mobilnetze halten die Paketsitzung über Übergaben hinweg am Leben, solange der Mobilitätsanker des Betreibers gleich bleibt. Die Funkstrecke wechselt, der Tunnel merkt es nicht, und in keinem Protokoll sollte eine Neuverbindung auftauchen. Das ist der Normalfall für Bewegung innerhalb einer Stadt.

Was die Adresse ändert, ist ein Wechsel zwischen Ankern, ein Übergang von Wi-Fi zu Mobilfunk oder ein erneuter Tunnelaufbau auf Betreiberseite nach einer langen Pause. Diese Ereignisse ersetzen die Quelladresse, die Ihre Pakete tragen, und ein VPN-Peer sieht einen Peer, der sich bewegt hat.

Die praktische Folge ist, dass Bewegung kein Beweis ist. Ein Gerät, das vierzig Kilometer zurückgelegt hat, kann die ganze Strecke dieselbe Adresse behalten haben, und ein stillstehendes Gerät kann zweimal die Adresse gewechselt haben, weil das Netz es so entschieden hat. Das Ereignis aufzuzeichnen ist der einzige Weg, beides zu unterscheiden.

Zwei Entwürfe: den Tunnel mitnehmen oder neu aufbauen

Clients unterscheiden sich darin, wie sehr es sie stört, dass sich die äußere Quelle geändert hat. Manche binden den Tunnel an die Adresse, auf der er aufgebaut wurde, und verlangen einen vollständigen Neuaufbau. Andere authentifizieren jedes Paket eigenständig und aktualisieren einfach, wohin sie die Antworten senden.

Die oberste Zeile erklärt viele verwirrende Berichte. WireGuard hat keine Sitzung, die brechen könnte: Jedes Paket trägt den Index des Peers und ist authentifiziert, ein gültiges Paket von einer neuen Adresse stammt also per Definition von diesem Peer, und der aufgezeichnete Endpunkt folgt ihm. Ein Client, der während einer Fahrt durchgehend „verbunden“ anzeigt, sagt die Wahrheit.

Die unterste Zeile ist ebenso wenig ein Defekt. Der Neuaufbau der Sitzung führt die Authentifizierung erneut gegen die aktuelle Adresse aus, was genau das ist, was Sie wollen, wenn die alte Adresse inzwischen jemand anderem gehören kann.

Beobachten Sie das Ereignis statt der Bewegung

Unter Android meldet das Konnektivitätssubsystem Netzwerkänderungen als Ereignisse, und diese sollten Sie mit dem Verhalten des Clients korrelieren. Der Dump ist ausführlich, aber die relevanten Teile sind das Standardnetzwerk und seine Adresse:

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

Auf der Serverseite gibt es eine direkte Messung für den Roaming-Fall. WireGuard speichert den zuletzt authentifizierten Endpunkt pro Peer, eine Adressänderung erscheint also als geänderter Wert statt als Neuverbindung:

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

Vergleichen Sie den Endpunkt vor und nach der Fahrt. Sind Adresse und Port unverändert, musste der Tunnel nie etwas tun, und die Neuverbindung kam von woanders, meist von der Anwendung. Hat sich der Endpunkt geändert, während der Handshake-Zeitstempel nahe am normalen Rekey-Intervall blieb, ist der Tunnel gewandert statt neu gestartet.

Ein Neustart sieht anders aus: Der Handshake-Zeitstempel springt auf den Moment der Neuverbindung zurück, und der Client protokolliert eine Initialisierungssequenz statt einer stillen Fortsetzung.

Wann die Neuverbindung das richtige Verhalten ist

Jede Neuverbindung als Fehler zu behandeln führt zu Konfigurationen, die tote Sitzungen am Leben halten. Ein Peer, dessen Adresse sich geändert hat, weil das Netz sie neu vergeben hat, sollte nicht weiter Verkehr für die alte Zuordnung erhalten, und ein Client, der stillschweigend weitermacht, kann ins Leere senden, während das Symbol grün bleibt.

Vergleichen Sie die beiden Fehler aus Nutzersicht. Eine Neuverbindung kostet ein paar Sekunden und eine erneute Authentifizierung. Ein veralteter Tunnel kostet eine Anwendung, die ohne Fehlermeldung hängt, was viel schwerer zu erklären ist und viel eher als „das Internet ist kaputt“ gemeldet wird.

Darunter versteckt sich auch eine politische Frage. In der Lücke zwischen dem Verlust eines Pfades und dem Aufbau eines anderen fallen manche Clients auf direktes Senden zurück. Das zu verhindern ist eine eigene Kontrolle getrennt von der automatischen Wiederherstellung, und ein Client kann in dem einen gut und in dem anderen schlecht sein. Entscheiden Sie, was Sie brauchen, bevor Sie eines von beiden justieren.

Schreiben Sie die beobachtete Abfolge auf

Ein brauchbarer Bericht benennt die Ereignisquelle: eine Änderung des Standardnetzwerks mit neuer Adresse, ein Wechsel von Wi-Fi zu Mobilfunk oder eine Übergabe ganz ohne Adressänderung. Dann gibt er an, was der Client getan hat, mit dem Zeitstempel von der Serverseite statt aus dem Gedächtnis.

Ist der Tunnel gewandert, sagen Sie es und notieren Sie die neue Endpunktfamilie. Wurde er neu aufgebaut, notieren Sie, ob die Authentifizierung im ersten Versuch gelang und wie lange die Lücke dauerte. Diese drei Fakten unterscheiden ein gesundes Mobil-Design von einem Client, der zwischen Netzen hin und her springt.

Und vermeiden Sie die Formulierung „Funkzellenwechsel“, solange das Gerätelog es nicht tatsächlich belegt. Die Android-Dokumentation zur Konnektivität beschreibt die Rückrufe, die Verfügbarkeit von einem Wechsel des Standardnetzwerks unterscheiden, und genau diese Unterscheidung braucht Ihr Bericht. Alles andere ist eine Geschichte übers Fahren.