Android VPN root nélkül: kié a hozzájárulás, az útvonalak és a blokkolás
A hozzájárulás, a TUN interfész és a rendszer blokkolási házirendje három különböző engedély. Kövesse nyomon, melyik összetevő birtokolja mindegyiket, mielőtt átvizsgál egy Android VPN-alkalmazást.
A root nem az, ami lehetővé teszi egy Android VPN-alkalmazásnak, hogy forgalmat vigyen, szivárgásokat blokkoljon vagy túléljen egy újraindítást. Az emberek ezt mind úgy foglalják össze, hogy „az alkalmazásnak van VPN-engedélye“, ami három külön mechanizmust rejt el: a felhasználó által adott hozzájárulást, a rendszer által létrehozott csomaginterfészt és a platform blokkolási házirendjét, amelyet nem az alkalmazás határoz meg. Egy Android VPN-terv átvizsgálása azt jelenti, hogy megkérdezzük, melyikre támaszkodik valójában egy állítás, mert mindegyiknek más a tulajdonosa és más a hibamódja.
A hozzájárulás rendszertevékenységen keresztül érkezik
VpnService.prepare() semmit nem ad. Intentet ad vissza a rendszer hozzájárulási tevékenységének, amikor hiányzik a hozzájárulás, és az alkalmazás elindítja ezt a párbeszédablakot, hogy a felhasználó jóváhagyja a szolgáltatást. Az alkalmazás saját folyamatának elindítása, engedély hozzáadása a manifesthez vagy egyéni „VPN engedélyezése“ képernyő megjelenítése nem hozza létre az engedélyt.
Az engedély hatóköre is korlátozott. Egy felhasználói profilban lévő csomaghoz tartozik, így a személyes példány és a munkapéldány külön döntés, és az eszköz tulajdonosa a felügyelt profilt másképp készítheti elő, mint a személyest. Ha a párbeszédablak soha nem jelenik meg, és a prepare() null értéket ad vissza, a hozzájárulás már létezik ehhez a csomaghoz abban a profilban; ez nem bizonyítja, hogy az alkalmazás megbízható, csak azt, hogy az engedély rendben van.
Az interfész egy kérés, amelyet a rendszer teljesít
A hozzájárulás után az alkalmazás a VpnService.Builder segítségével írja le, mit akar: címeket, útvonalakat, DNS-kiszolgálókat, MTU-t és ahol támogatott, a belefoglalandó vagy kizárandó alkalmazásokat. A establish() arra kéri a rendszert, hogy hozza létre az alagút-interfészt, és irányítsa bele a megfelelő forgalmat. Az útválasztási döntés a rendszeré; az alkalmazás megkapja a fájlleírót, és utána valami hasznosat kell tennie a csomagokkal.
| What you observe | Who actually owns it |
|---|---|
| VPN consent dialog | The system, triggered by prepare() |
| Routes, DNS and app lists | The app requests them; the system applies them |
| One active VPN per profile | The platform; a new service replaces the old one |
| Always-on and block-without-VPN | Device policy enforced by the platform |
Ez a táblázat az architektúra egy helyen. Az alkalmazás részt vesz a csomagkezelésben; nem birtokolja az interfészt, az útválasztási táblázatot vagy a futtatható szolgáltatások számát.
Az alagút socketjének ki kell menekülnie a saját alagútjából
A titkosított forgalmat vivő kapcsolat maga is socket. Ha visszairányítják abba az interfészbe, amelyet az alkalmazás éppen létrehozott, az alagút az alagúttól függ, és megakad. A VpnService.protect() ehhez a sockethez köti a mögöttes hálózatot, hogy megkerülje az elfogást, és ezért egy helyes kliens még az első kézfogás előtt megvédi a külső socketjét.
adb shell dumpsys connectivity | grep -i -A5 vpn
adb shell settings get global always_on_vpn_app
adb shell settings get global always_on_vpn_lockdownEzek a parancsok a telepített VPN-hálózatot, az always-on csomagot és a zárolás beállítását mutatják. Csak olvasható megfigyelések: ha az értékek nem egyeznek azzal, amit a terv állít, az állítás az alkalmazás felületéről szól, nem a rendszer állapotáról.
A blokkolás a platformé lehet
Az Android dokumentál egy házirendet, amely blokkolja azokat a kapcsolatokat, amelyek nem használják a VPN-t. Ez a kényszerítés platformszerződés, nem pedig egy alkalmazás, amely ciklusban újrapróbálja a kapcsolatokat. A kapcsoló az eszköz VPN-beállításaiban található VPN nélküli kapcsolatok blokkolása néven, felügyelt eszközön pedig a tulajdonos az egész profilra bekapcsolhatja. A megkülönböztetés akkor számít, amikor egy marketingállítást értékel: a kliens mutathat lakatikont és agresszíven újracsatlakozhat, miközben a közvetlen forgalom továbbra is lehetséges, vagy a lefedett alkalmazások offline maradhatnak, mert a rendszer érvényesíti a zárolást.
A lakatikont az alkalmazás rajzolja, tehát csak azt bizonyítja, hogy az alkalmazás úgy hiszi, csatlakozva van. Hogy egy másik alkalmazás elveszíti-e a hálózati hozzáférést, azt a platform dönti el, ezért a hasznos ellenőrzés annak megfigyelése, hogy az az alkalmazás meghiúsul, miközben az alagút aktív.
Az alkalmazásbolt „mindig bekapcsolva“ címkéje sem helyettesíti ezt a szerződést. Az always-on és a zárolás eszközbeállítások, amelyeket gyakran az eszköz tulajdonosa alkalmaz, és a kizárt alkalmazásokra vonatkozó viselkedésüket a platform határozza meg. A beállítást olvassa, ne a jelvényt.
Négy kérdés egy tervátvizsgáláshoz
Először, ki adott hozzájárulást: melyik csomag, melyik profil, és a felhasználó vagy egy felügyelt eszköz házirendje volt-e? Másodszor, mit kért az alkalmazás: mely útvonalakat, mely címcsaládokat, mely belefoglalt vagy kizárt alkalmazásokat? Harmadszor, mi történik, ha az alagút nem elérhető: blokkol a rendszer, vagy a forgalom visszaesik a mögöttes hálózatra? Negyedszer, mit tesz az alkalmazás a fogadott csomagokkal?
A negyedik kérdés az, amelyre az engedélymodell nem tud válaszolni. A hozzájárulás és a TUN interfész bizonyítja, hogy az alkalmazás fogadhat forgalmat, nem azt, hogy titkosítja, hitelesíti a partnert vagy tisztán helyreáll. Ezek megvalósítási tulajdonságok, és egy őszinte átvizsgálás itt tölti az idejét.
A fölösleges root-kérés nem válik jogszerűvé azzal, hogy az eredményt kill switchnek nevezik, és a hozzájárulási párbeszédablak nem biztonsági audit. Tartsa külön a három engedélyt, és minden állítás ellenőrizhetővé válik.