Waarom draadlose ontfoutingverkeer nie 'n VPN-lek bewys nie

Jy het draadlose ontfouting aangeskakel, ’n skootrekenaar gekoppel, en die sessie het bly werk terwyl die VPN aan was. Dit lyk of iets verby die tonnel geglip het. Dit het byna seker nie. ’n Ontfoutingsessie en ’n app se versoek aan ’n webwerf is verskillende netwerkverhoudings, en net een van hulle is veronderstel om die tonnel oor te steek.

Ek het hierdie verkeerde lesing twee keer teegekom: een keer met die selfoon en skootrekenaar op dieselfde Wi-Fi, en een keer ná ’n herbegin toe die koppeling behoue gebly het. In albei gevalle het die VPN presies gedoen waarvoor dit opgestel is.

Benoem die waarneming voordat jy die fout benoem

Drie gebeure kan aan ’n lekbewering voorafgaan, en hulle is nie uitruilbaar nie. ’n Gereedskap kan ’n diens ontdek, die toestel kan ’n werkstasie goedkeur, of ’n gemagtigde sessie kan werklik opdragte en grepe dra. Skryf neer watter een jy gesien het, want elkeen bewys minder as wat mense aanneem.

Ontdekking is gewoonlik mDNS of ’n poortskandering. Koppeling is ’n inskrywingsbesluit wat op die selfoon geneem word, bevestig met ’n kode wat die gebruiker tik. ’n Lewende sessie beteken verkeer het tussen twee gekoppelde eindpunte beweeg. Niks daarvan beskryf waar ’n app se HTTPS-versoek heen gaan nie.

Hou die bestemming, koppelvlak, adresfamilie, tydstempel en gebruikersprofiel by die gebeurtenis. Sonder daardie besonderhede kan die waarneming nie met die beoogde plaaslike-netwerkbeleid vergelyk word nie, of met die VPN-bou wat destyds geloop het.

Waarom die twee paaie nooit ontmoet nie

Draadlose ontfouting is ’n inkomende verbinding na die toestel. adbd luister op ’n poort wat aan die Wi-Fi-koppelvlak gebind is, en die werkstasie koppel daaraan ná die koppeling. Die rigting maak saak: jou skootrekenaar reik in die selfoon in, nie omgekeerd nie. Dit is die teenoorgestelde van ’n uitgangslek.

’n App se internetverkeer verlaat die tonnelkoppelvlak wat VpnService installeer, gepas deur UID en routeringsreëls. adbd is ’n stelseldaemon wat as die shell-gebruiker loop, nie ’n app binne daardie routeringstel nie. Dit bly op die onderliggende Wi-Fi-skakel selfs wanneer elke app aan die tonnel vasgepen is.

Sluitmodus dwing die tonnel af vir gedekte apps. Dit verander nie ’n luisterende sokkie in ’n uitgangspad nie.

Dit is waarom ’n werkende ADB-sessie en ’n werkende doodskakelaar sonder teëspraak saam bestaan. Om ’n lek te bewys, moet jy die rigting waarneem wat veronderstel is om geblokkeer te word.

Hoe ’n uitgangstoets werklik lyk

Toets die gedekte app, nie die ontfoutingskanaal nie. Stel die fouttoestand doelbewus op, maak dan een vars versoek en teken op wat gebeur het.

1. Bevestig die VPN is die enigste pad: skakel altyd-aan VPN aan met blokkeer verbindings sonder VPN.
2. Stop die VPN op die ondersteunde manier en bevestig die app meld geen konnektiwiteit nie.
3. Rig een onskadelike versoek vanaf daardie app en let op of dit misluk of slaag.
4. Herhaal met draadlose ontfouting aan, dan af, sodat die veranderlike geïsoleer is.

’n Geblokkeerde versoek onder daardie toestande is bewyse. ’n Suksesvolle ADB-sessie is nie, en ’n enkele ping vanaf ’n terminaal-app ook nie.

As die versoek wel slaag terwyl sluitmodus aan is, teken die app se UID en sy VPN-toelating, die aktiewe netwerk en die kliëntweergawe op. Daardie kombinasie is ’n werklike bevinding.

Koppeling oorleef die sessie

Koppeling is blywende toestand, nie ’n handdruk wat jy ná die kabeltoets kan vergeet nie. Android se ontfoutingsdokumentasie beskryf die draadlose werkvloei en merk op dat die verhouding duur totdat dit uitdruklik vergeet of die magtigings herroep word.

Kontroleer wat steeds gemagtig is voordat jy die tonnel blameer. Maak Draadlose ontfouting oop, kyk by Gekoppelde toestelle, en vergeet enigiets wat jy nie meer herken nie. Voer adb devices vanaf die werkstasie uit om te sien watter inskrywings nog antwoord, en adb disconnect om ’n verouderde een te laat vaar. Om draadlose ontfouting af te skakel, sluit die luisterpoort heeltemal.

Op ’n gedeelde of onbetroubare netwerk, laat dit af. ’n Blywende magtiging op ’n netwerk wat jy nie beheer nie is ’n groter probleem as ’n hipotetiese TUN-omseiling.

Voordat jy daardie fout rapporteer

’n Nuttige verslag noem die presiese grens wat gefaal het. Sluit die toestelmodel en Android-weergawe in, die VPN-kliënt en weergawe, of sluitmodus geaktiveer was, die app-pakket en UID, en die netwerk waarop die selfoon was. Voeg die opdrag of versoek by wat die waarneming veroorsaak het, plus die tyd toe dit gebeur het. Sonder dit kan niemand die grens wat jy sê gebreek is, reproduseer nie.

Moenie afdwinging deaktiveer of ontfouting op ’n onbetroubare netwerk blootstel om die toets meer dramaties te laat lyk nie. Dit verander die stelsel wat jy meet en laat bewyse agter wat niemand kan herhaal nie.

As jou enigste bewys is dat ADB gekoppel het terwyl die VPN aan was, het jy die verkeerde pad gemeet. Herhaal eers die toets op app-vlak; die antwoord kom gewoonlik daar.