Miksi langattoman virheenkorjauksen liikenne ei todista VPN-vuotoa

Otit langattoman virheenkorjauksen käyttöön, liitit kannettavan tietokoneen, ja istunto jatkoi toimintaansa VPN:n ollessa päällä. Se näyttää siltä kuin jotain olisi livahtanut tunnelin ohi. Lähes varmasti ei. Virheenkorjausistunto ja sovelluksen pyyntö verkkosivustolle ovat erilaisia verkkosuhteita, ja vain toisen niistä on tarkoitus ylittää tunneli.

Olen törmännyt tähän väärinluentaan kahdesti: kerran, kun puhelin ja kannettava olivat samassa Wi-Fi-verkossa, ja kerran uudelleenkäynnistyksen jälkeen, kun paritus säilyi. Molemmissa tapauksissa VPN teki täsmälleen sen, mihin se oli määritetty.

Nimeä havainto ennen kuin nimeät vian

Kolme tapahtumaa voi edeltää vuotoväitettä, eivätkä ne ole vaihdettavissa keskenään. Työkalu voi löytää palvelun, laite voi hyväksyä työaseman tai valtuutettu istunto voi todella kuljettaa komentoja ja tavuja. Kirjoita muistiin, minkä näit, sillä kukin niistä todistaa vähemmän kuin ihmiset olettavat.

Löytäminen on yleensä mDNS tai porttiskannaus. Paritus on puhelimessa tehty rekisteröintipäätös, jonka käyttäjä vahvistaa kirjoittamallaan koodilla. Elävä istunto tarkoittaa, että liikenne siirtyi kahden paritetun päätepisteen välillä. Mikään tästä ei kuvaa, minne sovelluksen HTTPS-pyyntö menee.

Pidä kohde, liitäntä, osoiteperhe, aikaleima ja käyttäjäprofiili tapahtumaan liitettyinä. Ilman näitä tietoja havaintoa ei voi verrata aiottuun paikallisverkon käytäntöön tai silloin käynnissä olleeseen VPN-versioon.

Miksi kaksi polkua eivät koskaan kohtaa

Langaton virheenkorjaus on laitteeseen tuleva yhteys. adbd kuuntelee porttia, joka on sidottu Wi-Fi-liitäntään, ja työasema muodostaa siihen yhteyden parituksen jälkeen. Suunnalla on väliä: kannettavasi ulottuu puhelimeen, ei päinvastoin. Se on ulostulovuodon vastakohta.

Sovelluksen internetliikenne lähtee tunneliliitännän kautta, jonka VpnService asentaa, UID:n ja reitityssääntöjen mukaan sovitettuna. adbd on järjestelmädemoni, joka toimii shell-käyttäjänä, ei sovellus tuossa reititysjoukossa. Se pysyy taustalla olevassa Wi-Fi-linkissä, vaikka jokainen sovellus olisi kiinnitetty tunneliin.

Lukitustila pakottaa tunnelin katettujen sovellusten osalta. Se ei muuta kuuntelevaa pistoketta ulostuloreitiksi.

Siksi toimiva ADB-istunto ja toimiva tappokytkin voivat olla olemassa rinnakkain ilman ristiriitaa. Vuodon todistamiseksi sinun on tarkkailtava suuntaa, jonka pitäisi olla estetty.

Miltä ulostulotesti todella näyttää

Testaa katettua sovellusta, älä virheenkorjauskanavaa. Aseta epäonnistumisehto tarkoituksella, tee sitten yksi tuore pyyntö ja kirjaa, mitä tapahtui.

1. Vahvista, että VPN on ainoa polku: kytke päälle aina päällä oleva VPN ja estä yhteydet ilman VPN:ää.
2. Pysäytä VPN tuetulla tavalla ja vahvista, että sovellus ilmoittaa, ettei yhteyttä ole.
3. Lähetä yksi vaaraton pyyntö kyseisestä sovelluksesta ja merkitse, epäonnistuuko se vai onnistuuko.
4. Toista langaton virheenkorjaus päällä ja sitten pois, jotta muuttuja eristetään.

Estetty pyyntö näissä olosuhteissa on todiste. Onnistunut ADB-istunto ei ole, eikä yksi ping pääteohjelmasta.

Jos pyyntö kuitenkin onnistuu lukitustilan ollessa päällä, kirjaa sovelluksen UID ja sen VPN-lupa, aktiivinen verkko ja asiakasohjelman versio. Tämä yhdistelmä on todellinen löydös.

Paritus elää istuntoa pidempään

Paritus on pysyvä tila, ei kättely, jonka voi unohtaa kaapelitestin jälkeen. Androidin virheenkorjausdokumentaatio kuvaa langattoman työnkulun ja huomauttaa, että suhde kestää, kunnes se nimenomaisesti unohdetaan tai valtuutukset peruutetaan.

Tarkista, mikä on vielä valtuutettu, ennen kuin syytät tunnelia. Avaa Langaton virheenkorjaus, katso Paritetut laitteet ja unohda kaikki, mitä et enää tunnista. Suorita adb devices työasemalta nähdäksesi, mitkä merkinnät vielä vastaavat, ja adb disconnect vanhentuneen pudottamiseksi. Langattoman virheenkorjauksen sammuttaminen sulkee kuuntelevan portin kokonaan.

Jaetussa tai epäluotettavassa verkossa jätä se pois päältä. Pysyvä valtuutus verkossa, jota et hallitse, on suurempi ongelma kuin hypoteettinen TUN-ohitus.

Ennen kuin ilmoitat tuosta viasta

Hyödyllinen raportti nimeää tarkan rajan, joka petti. Sisällytä laitemalli ja Android-julkaisu, VPN-asiakasohjelma ja versio, oliko lukitustila käytössä, sovelluksen paketti ja UID sekä verkko, jossa puhelin oli. Lisää komento tai pyyntö, joka tuotti havainnon, sekä ajankohta. Ilman sitä kukaan ei voi toistaa rajaa, jonka väität olevan rikki.

Älä poista pakotusta käytöstä äläkä paljasta virheenkorjausta epäluotettavassa verkossa saadaksesi testistä dramaattisemman. Se muuttaa järjestelmää, jota mittaat, ja jättää todisteita, joita kukaan ei voi toistaa.

Jos ainoa todisteesi on, että ADB yhdisti VPN:n ollessa päällä, mittasit väärää polkua. Aja ensin uudelleen sovellustason testi; vastaus tulee yleensä sieltä.