Warum Datenverkehr von drahtlosem Debugging kein VPN-Leck beweist

Sie haben drahtloses Debugging aktiviert, einen Laptop verbunden, und die Sitzung lief weiter, während das VPN aktiv war. Das sieht aus, als wäre etwas am Tunnel vorbeigerutscht. Mit ziemlicher Sicherheit nicht. Eine Debugging-Sitzung und die Anfrage einer App an eine Website sind verschiedene Netzwerkbeziehungen, und nur eine davon soll den Tunnel überqueren.

Ich bin dieser Fehldeutung zweimal begegnet: einmal mit Telefon und Laptop im selben Wi-Fi, und einmal nach einem Neustart, bei dem die Kopplung überlebte. In beiden Fällen tat das VPN genau das, wofür es konfiguriert war.

Benennen Sie die Beobachtung, bevor Sie den Fehler benennen

Drei Ereignisse können einer Leck-Behauptung vorausgehen, und sie sind nicht austauschbar. Ein Werkzeug kann einen Dienst entdecken, das Gerät kann eine Workstation genehmigen, oder eine autorisierte Sitzung kann tatsächlich Befehle und Bytes übertragen. Notieren Sie, welches Sie gesehen haben, denn jedes belegt weniger, als man annimmt.

Die Entdeckung ist meist mDNS oder ein Portscan. Die Kopplung ist eine Anmeldeentscheidung auf dem Telefon, bestätigt durch einen Code, den der Nutzer eintippt. Eine aktive Sitzung bedeutet, dass Datenverkehr zwischen zwei gekoppelten Endpunkten floss. Nichts davon beschreibt, wohin die HTTPS-Anfrage einer App geht.

Halten Sie Ziel, Schnittstelle, Adressfamilie, Zeitstempel und Benutzerprofil an das Ereignis gekoppelt. Ohne diese Details lässt sich die Beobachtung weder mit der vorgesehenen Richtlinie für das lokale Netz noch mit dem damals laufenden VPN-Build vergleichen.

Warum sich die beiden Pfade nie treffen

Drahtloses Debugging ist eine eingehende Verbindung zum Gerät. adbd lauscht auf einem an die Wi-Fi-Schnittstelle gebundenen Port, und die Workstation verbindet sich nach der Kopplung dorthin. Die Richtung zählt: Ihr Laptop greift in das Telefon hinein, nicht umgekehrt. Das ist das Gegenteil eines Ausgangslecks.

Der Internetverkehr einer App verlässt das Tunnel-Interface, das VpnService einrichtet, abgeglichen über UID und Routingregeln. adbd ist ein Systemdaemon, der als Benutzer shell läuft, keine App innerhalb dieser Routingmenge. Er bleibt auf der darunterliegenden Wi-Fi-Verbindung, selbst wenn jede App an den Tunnel gebunden ist.

Der Sperrmodus erzwingt den Tunnel für abgedeckte Apps. Er macht aus einem lauschenden Socket keinen Ausgangspfad.

Deshalb können eine funktionierende ADB-Sitzung und ein funktionierender Kill-Switch ohne Widerspruch koexistieren. Um ein Leck zu beweisen, müssen Sie die Richtung beobachten, die blockiert sein sollte.

Wie ein Ausgangstest tatsächlich aussieht

Testen Sie die abgedeckte App, nicht den Debugging-Kanal. Stellen Sie die Fehlerbedingung absichtlich her, senden Sie dann eine frische Anfrage und protokollieren Sie, was passiert ist.

1. Bestätigen Sie, dass das VPN der einzige Pfad ist: Aktivieren Sie Always-on-VPN mit Verbindungen ohne VPN blockieren.
2. Stoppen Sie das VPN auf dem unterstützten Weg und bestätigen Sie, dass die App keine Konnektivität meldet.
3. Senden Sie eine harmlose Anfrage aus dieser App und notieren Sie, ob sie scheitert oder gelingt.
4. Wiederholen Sie das mit aktiviertem und dann deaktiviertem drahtlosen Debugging, damit die Variable isoliert ist.

Eine blockierte Anfrage unter diesen Bedingungen ist ein Beweis. Eine erfolgreiche ADB-Sitzung ist keiner, und ein einzelner Ping aus einer Terminal-App ebenso wenig.

Wenn die Anfrage bei aktivem Sperrmodus doch gelingt, erfassen Sie die UID der App und ihre VPN-Berechtigung, das aktive Netz und die Client-Version. Diese Kombination ist ein echter Befund.

Die Kopplung überlebt die Sitzung

Kopplung ist dauerhafter Zustand, kein Handshake, den man nach dem Kabeltest vergessen kann. Androids Debugging-Dokumentation beschreibt den drahtlosen Ablauf und merkt an, dass die Beziehung besteht, bis sie ausdrücklich vergessen oder die Autorisierungen widerrufen werden.

Prüfen Sie, was noch autorisiert ist, bevor Sie den Tunnel beschuldigen. Öffnen Sie Drahtloses Debugging, sehen Sie unter Gekoppelte Geräte nach und vergessen Sie alles, was Sie nicht mehr erkennen. Führen Sie adb devices von der Workstation aus, um zu sehen, welche Einträge noch antworten, und adb disconnect, um einen veralteten zu entfernen. Drahtloses Debugging auszuschalten schließt den lauschenden Port vollständig.

In einem geteilten oder nicht vertrauenswürdigen Netz lassen Sie es aus. Eine dauerhafte Autorisierung in einem Netz, das Sie nicht kontrollieren, ist ein größeres Problem als eine hypothetische TUN-Umgehung.

Bevor Sie diesen Fehler melden

Ein nützlicher Bericht benennt die genaue Grenze, die versagt hat. Geben Sie Gerätemodell und Android-Version an, VPN-Client und Version, ob der Sperrmodus aktiv war, das App-Paket und die UID sowie das Netz, in dem das Telefon war. Fügen Sie den Befehl oder die Anfrage hinzu, die die Beobachtung erzeugt hat, samt dem Zeitpunkt. Ohne das kann niemand die Grenze reproduzieren, die Sie als defekt bezeichnen.

Deaktivieren Sie nicht die Durchsetzung und legen Sie Debugging nicht in einem nicht vertrauenswürdigen Netz offen, damit der Test dramatischer wirkt. Das verändert das System, das Sie messen, und hinterlässt Beweise, die niemand wiederholen kann.

Wenn Ihr einziger Beweis ist, dass ADB verbunden war, während das VPN lief, haben Sie den falschen Pfad gemessen. Wiederholen Sie zuerst den Test auf App-Ebene; die Antwort kommt meistens dort.