Miért nem bizonyíték a VPN-szivárgásra a vezeték nélküli hibakeresés forgalma

Engedélyezte a vezeték nélküli hibakeresést, csatlakoztatott egy laptopot, és a munkamenet tovább működött, miközben a VPN aktív volt. Ez úgy tűnik, mintha valami kicsúszott volna az alagút mellett. Szinte biztosan nem. A hibakeresési munkamenet és egy alkalmazás webhelyre küldött kérése különböző hálózati kapcsolatok, és csak az egyiküknek kellene átkelnie az alagúton.

Kétszer találkoztam ezzel a félreértelmezéssel: egyszer, amikor a telefon és a laptop ugyanazon a Wi-Fi-n volt, és egyszer újraindítás után, amikor a párosítás túlélte. Mindkét esetben a VPN pontosan azt tette, amire be volt állítva.

Nevezze meg a megfigyelést, mielőtt a hibát megnevezi

Három esemény előzheti meg a szivárgásról szóló állítást, és ezek nem cserélhetők fel. Egy eszköz felfedezhet egy szolgáltatást, az eszköz jóváhagyhat egy munkaállomást, vagy egy engedélyezett munkamenet valóban parancsokat és bájtokat szállíthat. Jegyezze fel, melyiket látta, mert mindegyik kevesebbet bizonyít, mint amit az emberek feltételeznek.

A felfedezés általában mDNS vagy portvizsgálat. A párosítás a telefonon hozott regisztrációs döntés, amelyet a felhasználó által beírt kód erősít meg. Az élő munkamenet azt jelenti, hogy forgalom mozgott két párosított végpont között. Ebből semmi nem írja le, hova megy egy alkalmazás HTTPS-kérése.

Tartsa a célt, az interfészt, a címcsaládot, az időbélyeget és a felhasználói profilt az eseményhez kapcsolva. Ezek nélkül a megfigyelés nem hasonlítható össze a tervezett helyi hálózati szabályzattal, sem az akkor futó VPN-verzióval.

Miért nem találkozik soha a két útvonal

A vezeték nélküli hibakeresés bejövő kapcsolat az eszközhöz. Az adbd a Wi-Fi-interfészhez kötött porton figyel, és a munkaállomás a párosítás után csatlakozik hozzá. Az irány számít: a laptopja befelé ér el a telefonba, nem fordítva. Ez a kimeneti szivárgás ellentéte.

Az alkalmazás internetforgalma a VpnService által telepített alagút-interfészen keresztül lép ki, UID és útválasztási szabályok szerint párosítva. Az adbd rendszerdémon, amely shell-felhasználóként fut, nem alkalmazás ebben az útválasztási halmazban. Az alatta lévő Wi-Fi-kapcsolaton marad akkor is, amikor minden alkalmazás az alagúthoz van rögzítve.

A zárolási mód érvényesíti az alagutat a lefedett alkalmazásoknál. Nem alakítja át a figyelő socketet kimeneti útvonallá.

Ezért létezik együtt egy működő ADB-munkamenet és egy működő vészkapcsoló ellentmondás nélkül. A szivárgás bizonyításához azt az irányt kell megfigyelnie, amelynek blokkolva kellene lennie.

Hogyan néz ki valójában egy kimeneti teszt

A lefedett alkalmazást tesztelje, ne a hibakeresési csatornát. Szándékosan állítsa be a hibaállapotot, majd indítson egy friss kérést, és rögzítse, mi történt.

1. Erősítse meg, hogy a VPN az egyetlen útvonal: kapcsolja be a mindig bekapcsolt VPN-t, a VPN nélküli kapcsolatok blokkolásával.
2. Állítsa le a VPN-t a támogatott módon, és erősítse meg, hogy az alkalmazás nem jelez kapcsolatot.
3. Küldjön egy ártalmatlan kérést abból az alkalmazásból, és jegyezze fel, hogy meghiúsul-e vagy sikerül.
4. Ismételje meg bekapcsolt, majd kikapcsolt vezeték nélküli hibakereséssel, hogy a változót elkülönítse.

Az ilyen körülmények között blokkolt kérés bizonyíték. Egy sikeres ADB-munkamenet nem az, és egyetlen ping egy terminálalkalmazásból sem.

Ha a kérés mégis sikerül a zárolás bekapcsolt állapotában, rögzítse az alkalmazás UID-jét és VPN-engedélyét, az aktív hálózatot és az ügyfél verzióját. Ez a kombináció valódi lelet.

A párosítás túléli a munkamenetet

A párosítás maradandó állapot, nem kézfogás, amelyet a kábeles teszt után elfelejthet. Az Android hibakeresési dokumentációja leírja a vezeték nélküli munkafolyamatot, és megjegyzi, hogy a kapcsolat addig tart, amíg kifejezetten el nem felejtik, vagy vissza nem vonják az engedélyeket.

Ellenőrizze, mi még engedélyezett, mielőtt az alagutat hibáztatná. Nyissa meg a Vezeték nélküli hibakeresést, nézze meg a Párosított eszközöket, és felejtsen el mindent, amit már nem ismer fel. Futtassa az adb devices parancsot a munkaállomásról, hogy lássa, mely bejegyzések válaszolnak még, és az adb disconnect parancsot egy elavult eldobásához. A vezeték nélküli hibakeresés kikapcsolása teljesen bezárja a figyelő portot.

Megosztott vagy nem megbízható hálózaton hagyja kikapcsolva. A maradandó engedélyezés egy olyan hálózaton, amelyet nem irányít, nagyobb probléma, mint egy feltételezett TUN-megkerülés.

Mielőtt bejelenti azt a hibát

Egy hasznos jelentés megnevezi a pontos határt, amely meghiúsult. Adja meg az eszköz modelljét és az Android-verziót, a VPN-ügyfelet és verzióját, hogy a zárolás be volt-e kapcsolva, az alkalmazáscsomagot és az UID-t, valamint a hálózatot, amelyen a telefon volt. Adja hozzá a megfigyelést előidéző parancsot vagy kérést, valamint az időpontot. Enélkül senki nem tudja reprodukálni a határt, amelyről azt állítja, hogy eltört.

Ne kapcsolja ki az érvényesítést, és ne tegye ki a hibakeresést nem megbízható hálózaton, hogy a teszt drámaibbnak tűnjön. Ez megváltoztatja a mért rendszert, és olyan bizonyítékot hagy, amelyet senki nem tud megismételni.

Ha az egyetlen bizonyítéka az, hogy az ADB csatlakozott, miközben a VPN be volt kapcsolva, rossz útvonalat mért. Először futtassa újra az alkalmazásszintű tesztet; a válasz általában ott érkezik.