Hvorfor trådløs feilsøkingstrafikk ikke er bevis for VPN-lekkasje

Du slo på trådløs feilsøking, koblet til en bærbar PC, og økten fortsatte å virke mens VPN-en var på. Det ser ut som om noe smatt forbi tunnelen. Det gjorde det nesten helt sikkert ikke. En feilsøkingsøkt og en app sin forespørsel til et nettsted er forskjellige nettverksforhold, og bare ett av dem skal krysse tunnelen.

Jeg har støtt på denne feillesningen to ganger: én gang med telefonen og den bærbare på samme Wi-Fi, og én gang etter en omstart der paringen overlevde. I begge tilfellene gjorde VPN-en nøyaktig det den var konfigurert til.

Navngi observasjonen før du navngir feilen

Tre hendelser kan gå foran en lekkasjepåstand, og de er ikke utbyttbare. Et verktøy kan oppdage en tjeneste, enheten kan godkjenne en arbeidsstasjon, eller en autorisert økt kan faktisk frakte kommandoer og byte. Skriv ned hvilken du så, fordi hver av dem beviser mindre enn folk antar.

Oppdagelse er vanligvis mDNS eller en portskanning. Paring er en registreringsbeslutning tatt på telefonen, bekreftet med en kode brukeren skriver inn. En levende økt betyr at trafikk flyttet seg mellom to parede endepunkter. Ingenting av dette beskriver hvor en app sin HTTPS-forespørsel går.

Hold destinasjon, grensesnitt, adressefamilie, tidsstempel og brukerprofil knyttet til hendelsen. Uten disse detaljene kan observasjonen ikke sammenlignes med den tiltenkte policyen for lokalnettet, eller med VPN-bygget som kjørte da.

Hvorfor de to veiene aldri møtes

Trådløs feilsøking er en innkommende forbindelse til enheten. adbd lytter på en port bundet til Wi-Fi-grensesnittet, og arbeidsstasjonen kobler til etter paringen. Retningen betyr noe: den bærbare når inn i telefonen, ikke omvendt. Det er det motsatte av en utgangslekkasje.

En app sin internettrafikk forlater tunellgrensesnittet som VpnService installerer, matchet etter UID og rutingregler. adbd er en systemdemon som kjører som shell-brukeren, ikke en app i det rutingsettet. Den blir på den underliggende Wi-Fi-lenken selv når hver app er festet til tunnelen.

Låsemodus håndhever tunnelen for dekkede apper. Det gjør ikke en lyttende socket om til en utgangsvei.

Derfor kan en fungerende ADB-økt og en fungerende kill switch sameksistere uten motsigelse. For å bevise en lekkasje må du observere retningen som skal være blokkert.

Hvordan en utgangstest faktisk ser ut

Test den dekkede appen, ikke feilsøkingskanalen. Sett opp feiltilstanden med vilje, og gjør deretter én ny forespørsel og registrer hva som skjedde.

1. Bekreft at VPN-en er den eneste veien: slå på alltid-på VPN med blokker tilkoblinger uten VPN.
2. Stopp VPN-en på den støttede måten og bekreft at appen rapporterer ingen tilkobling.
3. Send én ufarlig forespørsel fra den appen og noter om den mislykkes eller lykkes.
4. Gjenta med trådløs feilsøking på, og deretter av, slik at variabelen isoleres.

En blokkert forespørsel under disse forholdene er bevis. En vellykket ADB-økt er det ikke, og heller ikke én ping fra en terminalapp.

Hvis forespørselen faktisk lykkes mens låsemodus er på, registrer appens UID og dens VPN-tillatelse, det aktive nettverket og klientversjonen. Den kombinasjonen er et reelt funn.

Paring overlever økten

Paring er vedvarende tilstand, ikke et håndtrykk du kan glemme etter kabeltesten. Androids feilsøkingsdokumentasjon beskriver den trådløse arbeidsflyten og bemerker at forholdet varer til det uttrykkelig glemmes eller autorisasjonene tilbakekalles.

Sjekk hva som fortsatt er autorisert før du gir tunnelen skylden. Åpne Trådløs feilsøking, se på Parede enheter, og glem alt du ikke lenger kjenner igjen. Kjør adb devices fra arbeidsstasjonen for å se hvilke oppføringer som fortsatt svarer, og adb disconnect for å droppe en utdatert. Slår du av trådløs feilsøking, lukkes den lyttende porten helt.

På et delt eller utrygt nettverk, la det være av. En vedvarende autorisasjon på et nettverk du ikke kontrollerer er et større problem enn en hypotetisk TUN-omgåelse.

Før du melder den feilen

En nyttig rapport navngir den nøyaktige grensen som feilet. Ta med enhetsmodell og Android-versjon, VPN-klient og versjon, om låsemodus var aktivert, app-pakken og UID, og nettverket telefonen var på. Legg til kommandoen eller forespørselen som skapte observasjonen, pluss tidspunktet det skjedde. Uten det kan ingen gjenskape grensen du hevder er brutt.

Ikke deaktiver håndhevelsen, og ikke eksponer feilsøking på et utrygt nettverk for å få testen til å virke mer dramatisk. Det endrer systemet du måler, og etterlater bevis ingen kan gjenta.

Hvis det eneste beviset ditt er at ADB koblet til mens VPN-en var på, målte du feil vei. Kjør appnivåtesten på nytt først; svaret kommer vanligvis der.