De ce traficul de depanare wireless nu dovedește o scurgere VPN

Ați activat depanarea wireless, ați conectat un laptop și sesiunea a continuat să funcționeze cât timp VPN-ul era activ. Pare că ceva a alunecat pe lângă tunel. Aproape sigur nu. O sesiune de depanare și cererea unei aplicații către un site web sunt relații de rețea diferite și doar una dintre ele ar trebui să traverseze tunelul.

Am întâlnit această citire greșită de două ori: o dată cu telefonul și laptopul pe același Wi-Fi, și o dată după o repornire, când împerecherea a supraviețuit. În ambele cazuri VPN-ul făcea exact ceea ce era configurat să facă.

Numiți observația înainte de a numi eroarea

Trei evenimente pot precede o afirmație de scurgere și nu sunt interschimbabile. Un instrument poate descoperi un serviciu, dispozitivul poate aproba o stație de lucru sau o sesiune autorizată poate transporta efectiv comenzi și octeți. Notați pe care l-ați văzut, pentru că fiecare dovedește mai puțin decât presupun oamenii.

Descoperirea este de obicei mDNS sau o scanare de porturi. Împerecherea este o decizie de înregistrare luată pe telefon, confirmată cu un cod introdus de utilizator. O sesiune activă înseamnă că traficul s-a deplasat între două puncte terminale împerecheate. Nimic din toate acestea nu descrie unde merge cererea HTTPS a unei aplicații.

Păstrați destinația, interfața, familia de adrese, marcajul temporal și profilul utilizatorului atașate evenimentului. Fără aceste detalii observația nu poate fi comparată cu politica de rețea locală prevăzută sau cu versiunea VPN care rula atunci.

De ce cele două căi nu se întâlnesc niciodată

Depanarea wireless este o conexiune de intrare către dispozitiv. adbd ascultă pe un port legat de interfața Wi-Fi, iar stația de lucru se conectează la el după împerechere. Direcția contează: laptopul ajunge în telefon, nu invers. Este opusul unei scurgeri de ieșire.

Traficul de internet al unei aplicații iese prin interfața de tunel pe care o instalează VpnService, potrivită după UID și reguli de rutare. adbd este un demon de sistem care rulează ca utilizator shell, nu o aplicație din acel set de rutare. Rămâne pe legătura Wi-Fi subiacentă chiar și când fiecare aplicație este fixată pe tunel.

Modul de blocare impune tunelul pentru aplicațiile acoperite. Nu transformă un socket în ascultare într-o cale de ieșire.

De aceea o sesiune ADB funcțională și un întrerupător de siguranță funcțional coexistă fără contradicție. Pentru a dovedi o scurgere, trebuie să observați direcția care ar trebui să fie blocată.

Cum arată de fapt un test de ieșire

Testați aplicația acoperită, nu canalul de depanare. Creați deliberat condiția de eșec, apoi faceți o cerere nouă și înregistrați ce s-a întâmplat.

1. Confirmați că VPN-ul este singura cale: activați VPN-ul mereu pornit cu blocarea conexiunilor fără VPN.
2. Opriți VPN-ul în modul acceptat și confirmați că aplicația raportează lipsa conectivității.
3. Trimiteți o cerere inofensivă din acea aplicație și notați dacă eșuează sau reușește.
4. Repetați cu depanarea wireless activată și apoi dezactivată, pentru a izola variabila.

O cerere blocată în acele condiții este o dovadă. O sesiune ADB reușită nu este, nici un singur ping dintr-o aplicație de terminal.

Dacă cererea reușește totuși cât timp blocarea este activă, înregistrați UID-ul aplicației și permisiunea sa VPN, rețeaua activă și versiunea clientului. Acea combinație este o descoperire reală.

Împerecherea supraviețuiește sesiunii

Împerecherea este o stare persistentă, nu o strângere de mână pe care o uiți după testul cu cablu. Documentația de depanare Android descrie fluxul wireless și notează că relația durează până când este uitată explicit sau autorizările sunt revocate.

Verificați ce este încă autorizat înainte de a da vina pe tunel. Deschideți Depanare wireless, priviți Dispozitive împerecheate și uitați tot ce nu mai recunoașteți. Rulați adb devices de la stația de lucru pentru a vedea ce intrări mai răspund, și adb disconnect pentru a elimina una învechită. Dezactivarea depanării wireless închide complet portul de ascultare.

Pe o rețea partajată sau nesigură, lăsați-o dezactivată. O autorizare persistentă pe o rețea pe care nu o controlați este o problemă mai mare decât o ocolire TUN ipotetică.

Înainte de a raporta acea eroare

Un raport util numește granița exactă care a eșuat. Includeți modelul dispozitivului și versiunea Android, clientul VPN și versiunea, dacă blocarea era activă, pachetul aplicației și UID-ul, și rețeaua pe care se afla telefonul. Adăugați comanda sau cererea care a produs observația, plus momentul în care s-a întâmplat. Fără acestea, nimeni nu poate reproduce granița pe care o declarați ruptă.

Nu dezactivați aplicarea regulilor și nu expuneți depanarea pe o rețea nesigură pentru a face testul mai dramatic. Asta schimbă sistemul pe care îl măsurați și lasă dovezi pe care nimeni nu le poate repeta.

Dacă singura dovadă este că ADB s-a conectat cât timp VPN-ul era activ, ați măsurat calea greșită. Rulați mai întâi din nou testul la nivel de aplicație; răspunsul vine de obicei acolo.