Kvifor trådlaus feilsøkingstrafikk ikkje er bevis for VPN-lekkasje

Du slo på trådlaus feilsøking, kopla til ein berbar PC, og økta heldt fram med å verke medan VPN-en var på. Det ser ut som om noko smatt forbi tunnelen. Det gjorde han nesten heilt sikkert ikkje. Ei feilsøkingsøkt og ein førespurnad frå ein app til eit nettstad er ulike nettverkstilhøve, og berre eitt av dei skal krysse tunnelen.

Eg har støytt på denne feillesinga to gonger: éin gong med telefonen og den berbare på same Wi-Fi, og éin gong etter ein omstart der paringa overlevde. I båe tilfella gjorde VPN-en nøyaktig det han var konfigurert til.

Namngi observasjonen før du namngir feilen

Tre hendingar kan kome før ein lekkasjepåstand, og dei er ikkje utbytbart. Eit verktøy kan oppdage ein teneste, eininga kan godkjenne ein arbeidsstasjon, eller ei autorisert økt kan faktisk frakte kommandoar og byte. Skriv ned kva for ein du såg, fordi kvar av dei beviser mindre enn folk reknar med.

Oppdaging er vanlegvis mDNS eller ein portskanning. Paring er ei registreringsavgjerd teken på telefonen, stadfesta med ein kode brukaren skriv inn. Ei levande økt tyder at trafikk flytta seg mellom to para endepunkt. Ingenting av dette skildrar kvar ein HTTPS-førespurnad frå ein app går.

Hald destinasjon, grensesnitt, adressefamilie, tidsstempel og brukarprofil knytt til hendinga. Utan desse detaljane kan observasjonen ikkje samanliknast med den tiltenkte policyen for lokalnettet, eller med VPN-bygget som køyrde då.

Kvifor dei to vegane aldri møtest

Trådlaus feilsøking er ei innkomande tilkopling til eininga. adbd lyttar på ein port bunden til Wi-Fi-grensesnittet, og arbeidsstasjonen koplar til etter paringa. Retninga betyr noko: den berbare når inn i telefonen, ikkje omvendt. Det er det motsette av ein utgangslekkasje.

Internettrafikken til ein app forlèt tunellgrensesnittet som VpnService installerer, matcha etter UID og rutingsreglar. adbd er ein systemdemon som køyrer som shell-brukaren, ikkje ein app i det rutingsettet. Han blir på den underliggjande Wi-Fi-lenka sjølv når kvar app er fest til tunnelen.

Låsemodus handhevar tunnelen for dekte appa. Det gjer ikkje ein lyttande socket om til ein utgangsveg.

Difor kan ei fungerande ADB-økt og ein fungerande kill switch sameksistere utan motseiing. For å bevisa ein lekkasje må du observere retninga som skal vere blokkert.

Korleis ein utgangstest faktisk ser ut

Test den dekte appen, ikkje feilsøkingskanalen. Set opp feiltilstanden med vilje, gjer deretter éin ny førespurnad og registrer kva som skjedde.

1. Stadfest at VPN-en er den einaste vegen: slå på alltid-på VPN med blokker tilkoplingar utan VPN.
2. Stopp VPN-en på den støtta måten og stadfest at appen rapporterer ingen tilkopling.
3. Send éin ufarleg førespurnad frå den appen og noter om han mislukkast eller lukkast.
4. Gjenta med trådlaus feilsøking på, og deretter av, slik at variabelen blir isolert.

Ein blokkert førespurnad under desse tilhøva er bevis. Ei vellukka ADB-økt er det ikkje, og heller ikkje éin ping frå ein terminalapp.

Viss førespurnaden faktisk lukkast medan låsemodus er på, registrer UID-en til appen og VPN-løyvet hans, det aktive nettverket og klientversjonen. Den kombinasjonen er eit reelt funn.

Paring overlever økta

Paring er varig tilstand, ikkje eit handtrykk du kan gløyme etter kabeltesten. Feilsøkingsdokumentasjonen til Android skildrar den trådlause arbeidsflyten og merkar seg at tilhøvet varer til det uttrykkjeleg blir gløymt eller autorisasjonane blir trekte tilbake.

Sjekk kva som framleis er autorisert før du gir tunnelen skulda. Opne Trådlaus feilsøking, sjå på Para einingar, og gløym alt du ikkje kjenner att lenger. Køyr adb devices frå arbeidsstasjonen for å sjå kva oppføringar som framleis svarar, og adb disconnect for å sleppe ein utdatert. Slår du av trådlaus feilsøking, blir den lyttande porten heilt lukka.

På eit delt eller utrygt nettverk, lat det vere av. Ein varig autorisasjon på eit nettverk du ikkje kontrollerer er eit større problem enn ein hypotetisk TUN-omgåing.

Før du melder den feilen

Ein nyttig rapport namngir den nøyaktige grensa som feila. Ta med einingsmodell 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 førespurnaden som skapte observasjonen, pluss tidspunktet det skjedde. Utan det kan ingen gjenskape grensa du hevdar er broten.

Ikkje deaktiver handhevinga, og ikkje eksponer feilsøking på eit utrygt nettverk for å få testen til å verke meir dramatisk. Det endrar systemet du måler, og etterlèt bevis ingen kan gjenta.

Viss det einaste beviset ditt er at ADB kopla til medan VPN-en var på, målte du feil veg. Køyr appnivåtesten på nytt først; svaret kjem vanlegvis der.