Waarom draadloos foutopsporingsverkeer geen bewijs van een VPN-lek is

Je schakelde draadloos foutopsporing in, verbond een laptop en de sessie bleef werken terwijl de VPN aan stond. Dat ziet eruit alsof er iets langs de tunnel glipte. Vrijwel zeker niet. Een foutopsporingssessie en de aanvraag van een app aan een website zijn verschillende netwerkrelaties, en slechts één ervan hoort de tunnel te passeren.

Ik ben deze verkeerde lezing twee keer tegengekomen: één keer met de telefoon en de laptop op dezelfde Wi-Fi, en één keer na een herstart toen de koppeling overleefde. In beide gevallen deed de VPN precies waarvoor die was geconfigureerd.

Benoem de observatie voordat je de bug benoemt

Drie gebeurtenissen kunnen aan een lekuitspraak voorafgaan, en ze zijn niet uitwisselbaar. Een hulpmiddel kan een dienst ontdekken, het apparaat kan een werkstation goedkeuren, of een geautoriseerde sessie kan daadwerkelijk commando's en bytes vervoeren. Noteer welke je zag, want elk bewijst minder dan mensen aannemen.

Ontdekking is meestal mDNS of een poortscan. Koppelen is een registratiebeslissing op de telefoon, bevestigd met een code die de gebruiker typt. Een live sessie betekent dat verkeer tussen twee gekoppelde eindpunten bewoog. Niets daarvan beschrijft waar de HTTPS-aanvraag van een app heen gaat.

Houd bestemming, interface, adresfamilie, tijdstempel en gebruikersprofiel aan de gebeurtenis gekoppeld. Zonder die details kan de observatie niet worden vergeleken met het beoogde beleid voor het lokale netwerk, of met de VPN-build die toen draaide.

Waarom de twee paden elkaar nooit ontmoeten

Draadloos foutopsporing is een inkomende verbinding naar het apparaat. adbd luistert op een poort die aan de Wi-Fi-interface is gebonden, en het werkstation maakt daarna verbinding. De richting is belangrijk: je laptop reikt de telefoon in, niet andersom. Dat is het tegenovergestelde van een uitgaand lek.

Het internetverkeer van een app verlaat de tunnelinterface die VpnService installeert, gematcht op UID en routeringsregels. adbd is een systeemdaemon die als shell-gebruiker draait, geen app binnen die routeringsset. Hij blijft op de onderliggende Wi-Fi-verbinding, zelfs wanneer elke app aan de tunnel is vastgezet.

Vergrendelingsmodus dwingt de tunnel af voor gedekte apps. Het maakt van een luisterende socket geen uitgangspad.

Daarom kunnen een werkende ADB-sessie en een werkende kill switch zonder tegenspraak naast elkaar bestaan. Om een lek te bewijzen, moet je de richting observeren die geblokkeerd zou moeten zijn.

Hoe een uitgangstest er werkelijk uitziet

Test de gedekte app, niet het foutopsporingskanaal. Zet de foutconditie bewust op, doe daarna één nieuwe aanvraag en noteer wat er gebeurde.

1. Bevestig dat de VPN het enige pad is: schakel altijd-aan VPN in met verbindingen zonder VPN blokkeren.
2. Stop de VPN op de ondersteunde manier en bevestig dat de app geen connectiviteit meldt.
3. Stuur één onschadelijke aanvraag vanuit die app en noteer of die mislukt of slaagt.
4. Herhaal met draadloos foutopsporing aan en daarna uit, zodat de variabele geïsoleerd is.

Een geblokkeerde aanvraag onder die omstandigheden is bewijs. Een geslaagde ADB-sessie niet, en één ping vanuit een terminal-app evenmin.

Als de aanvraag toch slaagt terwijl de vergrendeling aan staat, leg dan de UID van de app en de VPN-toestemming, het actieve netwerk en de clientversie vast. Die combinatie is een echte bevinding.

Koppeling overleeft de sessie

Koppelen is blijvende toestand, geen handdruk die je na de kabeltest kunt vergeten. Androids foutopsporingsdocumentatie beschrijft de draadloze werkwijze en merkt op dat de relatie blijft tot die expliciet wordt vergeten of de autorisaties worden ingetrokken.

Controleer wat nog geautoriseerd is voordat je de tunnel de schuld geeft. Open Draadloos foutopsporing, kijk bij Gekoppelde apparaten en vergeet alles wat je niet meer herkent. Voer adb devices uit vanaf het werkstation om te zien welke vermeldingen nog antwoorden, en adb disconnect om een verouderde te laten vallen. Draadloos foutopsporing uitschakelen sluit de luisterende poort volledig.

Op een gedeeld of onvertrouwd netwerk laat je het uit. Een blijvende autorisatie op een netwerk dat je niet beheert is een groter probleem dan een hypothetische TUN-omzeiling.

Voordat je die bug meldt

Een bruikbaar rapport benoemt de exacte grens die faalde. Vermeld apparaatmodel en Android-versie, VPN-client en versie, of vergrendeling was ingeschakeld, het app-pakket en de UID, en het netwerk waarop de telefoon zat. Voeg het commando of de aanvraag toe die de observatie veroorzaakte, plus het tijdstip. Zonder dat kan niemand de grens reproduceren waarvan je zegt dat die stuk is.

Schakel de handhaving niet uit en stel foutopsporing niet bloot op een onvertrouwd netwerk om de test dramatischer te laten lijken. Dat verandert het systeem dat je meet en laat bewijs achter dat niemand kan herhalen.

Als je enige bewijs is dat ADB verbond terwijl de VPN aan stond, heb je het verkeerde pad gemeten. Voer eerst de test op app-niveau opnieuw uit; het antwoord komt meestal daar.