Hvorfor trådløs fejlretningstrafik ikke er bevis for en VPN-lækage

Du slog trådløs fejlretning til, tilsluttede en bærbar computer, og sessionen blev ved med at virke, mens VPN var aktiv. Det ser ud som om noget smuttede forbi tunnelen. Det gjorde det næsten helt sikkert ikke. En fejlretningssession og en apps anmodning til et websted er forskellige netværksforhold, og kun ét af dem skal krydse tunnelen.

Jeg er stødt på denne fejllæsning to gange: én gang med telefonen og den bærbare på samme Wi-Fi, og én gang efter en genstart, hvor parringen overlevede. I begge tilfælde gjorde VPN præcis det, den var konfigureret til.

Navngiv observationen, før du navngiver fejlen

Tre begivenheder kan gå forud for en lækagepåstand, og de kan ikke byttes ud med hinanden. Et værktøj kan opdage en tjeneste, enheden kan godkende en arbejdsstation, eller en autoriseret session kan faktisk transportere kommandoer og bytes. Skriv ned, hvilken du så, for hver af dem beviser mindre, end folk antager.

Opdagelse er normalt mDNS eller en portscanning. Parring er en tilmeldingsbeslutning, der træffes på telefonen og bekræftes med en kode, som brugeren taster. En levende session betyder, at trafik bevægede sig mellem to parrede endepunkter. Intet af det beskriver, hvor en apps HTTPS-anmodning går hen.

Hold destination, interface, adressefamilie, tidsstempel og brugerprofil knyttet til begivenheden. Uden de detaljer kan observationen ikke sammenlignes med den tilsigtede politik for det lokale netværk eller med den VPN-build, der kørte dengang.

Hvorfor de to stier aldrig mødes

Trådløs fejlretning er en indgående forbindelse til enheden. adbd lytter på en port, der er bundet til Wi-Fi-interfacet, og arbejdsstationen opretter forbindelse til den efter parring. Retningen betyder noget: din bærbare rækker ind i telefonen, ikke omvendt. Det er det modsatte af en udgående lækage.

En apps internettrafik forlader tunnelforbindelsen, som VpnService installerer, matchet efter UID og routingregler. adbd er en systemdæmon, der kører som shell-brugeren, ikke en app i det routing-sæt. Den bliver på det underliggende Wi-Fi-link, selv når hver app er fastgjort til tunnelen.

Låsetilstand håndhæver tunnelen for omfattede apps. Den gør ikke en lyttende socket til en udgangssti.

Derfor kan en fungerende ADB-session og en fungerende kill switch sameksistere uden modsigelse. For at bevise en lækage skal du observere den retning, der burde være blokeret.

Hvordan en udgangstest faktisk ser ud

Test den omfattede app, ikke fejlretningskanalen. Sæt fejltilstanden op med vilje, lav derefter én ny anmodning, og notér, hvad der skete.

1. Bekræft, at VPN er den eneste vej: slå altid-til VPN til med bloker forbindelser uden VPN.
2. Stop VPN på den understøttede måde, og bekræft, at appen rapporterer ingen forbindelse.
3. Send én uskadelig anmodning fra den app, og notér, om den mislykkes eller lykkes.
4. Gentag med trådløs fejlretning til og derefter fra, så variablen isoleres.

En blokeret anmodning under de betingelser er bevis. En vellykket ADB-session er ikke, og et enkelt ping fra en terminal-app er heller ikke.

Hvis anmodningen faktisk lykkes, mens låsetilstand er slået til, så registrér appens UID og dens VPN-tilladelse, det aktive netværk og klientversionen. Den kombination er et rigtigt fund.

Parring overlever sessionen

Parring er vedvarende tilstand, ikke et håndtryk, du kan glemme efter kabletesten. Androids fejlretningsdokumentation beskriver den trådløse arbejdsgang og bemærker, at forholdet varer, indtil det udtrykkeligt glemmes, eller autorisationerne tilbagekaldes.

Tjek, hvad der stadig er autoriseret, før du giver tunnelen skylden. Åbn Trådløs fejlretning, se på Parrede enheder, og glem alt, du ikke længere genkender. Kør adb devices fra arbejdsstationen for at se, hvilke poster der stadig svarer, og adb disconnect for at droppe en forældet. Slår du trådløs fejlretning fra, lukkes den lyttende port helt.

På et delt eller utroværdigt netværk, lad det være slukket. En vedvarende autorisation på et netværk, du ikke kontrollerer, er et større problem end en hypotetisk TUN-omgåelse.

Før du indberetter den fejl

En brugbar rapport navngiver den præcise grænse, der fejlede. Medtag enhedsmodel og Android-version, VPN-klient og version, om låsetilstand var aktiveret, app-pakken og UID samt det netværk, telefonen var på. Tilføj den kommando eller anmodning, der frembragte observationen, plus tidspunktet, det skete. Uden det kan ingen genskabe den grænse, du påstår er brudt.

Deaktiver ikke håndhævelsen, og eksponér ikke fejlretning på et utroværdigt netværk for at få testen til at virke mere dramatisk. Det ændrer det system, du måler på, og efterlader beviser, som ingen kan gentage.

Hvis dit eneste bevis er, at ADB blev forbundet, mens VPN var slået til, har du målt den forkerte sti. Kør app-niveau-testen igen først; svaret kommer normalt der.