Android VPN alkalmazásonként: egy alkalmazás kizárása nem blokkolás

A képernyőn látható alkalmazásonkénti lista egyetlen alagút-tulajdonosé, és egy alkalmazás kizárása az alagút mellett vezeti el, nem viszi le a hálózatról. Kezdje ott.

Két ember ugyanazt a kérdést teszi fel, és egymással össze nem egyeztethető válaszokat kap, mert különböző helyeken állnak. Az egyiknél nyitva van a rendszer VPN-beállításainak képernyője, és alkalmazások listáját szerkeszti. A másik VpnService.Builder.addDisallowedApplication() kódot ír egy szerkesztőben. Mindketten alkalmazásonkénti VPN-szűrőnek nevezik. Csak az egyikük birtokolja az általa leírt vezérlést, és egyikük sem blokkol semmit.

Kezdje azon a képernyőn, amelyet a felhasználó lát

Nyissa meg a Beállításokat, keresse meg a VPN-bejegyzést, és nézze meg a valóban aktív kapcsolatot. Ha a kliens kínál alkalmazásonkénti listát, az a lista a kliens saját alagútjához tartozik. A platform nem tesz közzé olyan általános API-t, amellyel egy nem kapcsolódó alkalmazás egy másik VPN alkalmazásválasztását olvashatná vagy szerkeszthetné, így egy második alkalmazás nem tudja megjavítani azt a listát a felhasználó helyett.

Ez az út első elágazása. Ha a telepített VPN-nek nincs ilyen beállítása, nincs mit megkerülni kóddal: a funkció hiányzik abból a termékből, amely az alagutat birtokolja. Ha van, a helyes javítás azon a képernyőn történik, annak a kezében, aki meg tudja nyitni.

Kövesse a csomagot az alagútba

Amikor a saját alkalmazása alagutat épít, TUN-interfészt hoz létre, és kijelenti, mely alkalmazások forgalma lép be oda. A tagsági hívások az interfész létrehozása előtt történnek, és utána a szabálykészlet rögzített arra a munkamenetre:

val builder = VpnService.Builder()
builder.addAddress("10.8.0.2", 32)
builder.addRoute("0.0.0.0", 0)
builder.addDisallowedApplication("com.example.bypass")
val tun = builder.establish()   // membership decided here

Ezek a hívások arra az alagútra vonatkoznak, amelyet az alkalmazása éppen létrehozott, és semmi másra. Nem eszközszintű szabályzatok, nem maradnak fenn más kliensek számára, és nem érhetnek el másvalaki VPN-jébe. Amikor az építő egyik hívása kivételt dob, mert a csomag nem oldható fel, az interfész soha nem jön létre, ami tiszta, nem pedig csendes hiba.

Miért tűnt a kizárás blokkolásnak

A kizárt alkalmazás forgalma az alagútja mellett a mögöttes hálózatra kerül. Ez a blokkolás ellentéte: a forgalom továbbra is elhagyja az eszközt, csak azon az interfészen kívül, amelyet Ön vezérel. A tűzfalszerű alkalmazás az ellenkezőjét teszi. Beengeti az alkalmazás forgalmát az alagútjába, majd eldobja a csomagokat, vagy megtagadja a továbbításukat, így az interfész ugyanaz, a szabályzat iránya viszont fordított.

Az e mögötti fordítás nem egy konfigurációs kapcsoló. IP-csomagokat olvas az alagút leírójából, folyamonként dönt, majd védett socketen keresztül továbbítja vagy eldobja őket. Amit nem kezel, egyszerűen megáll, és ezért tűnik a félkész alagút törött hálózatnak, nem pedig működő szűrőnek. Ha a cél a blokkolás, tervezze be a csomagkezelést, egy előtér-szolgáltatást és egy írásos szabályzatot a nem osztályozható forgalomra.

Mi törik el, ha saját maga építi

Az Android általában egyszerre csak egy aktív VPN-t engedélyez, így a szűrő alagút és egy adatvédelmi alagút ugyanazért a helyért verseng, hacsak a termékek nem támogatják a láncolást. A mindig bekapcsolt VPN kapcsolatblokkolással megváltoztatja a hiba módját oly módon, ami itt számít: a forgalom, amely nem tud belépni az alagútba, eldobódik ahelyett, hogy közvetlenül elküldenék, amit a szivárgásgátló tervezés akar, és amire egy hibakeresési munkamenet ritkán számít.

A csomagok láthatósága a második csapda. Egy alkalmazás csomagnévének feloldása NameNotFoundException hibával meghiúsulhat, és az újabb Android-verziókon a látható csomagok halmaza az Ön által deklarált lekérdezésektől függ. Kezelje a kivételt ahelyett, hogy feltételezné, minden név feloldódik, és olvassa újra a listát, amikor alkalmazásokat telepítenek vagy távolítanak el, ahelyett hogy örökre gyorsítótárazná.

A felügyelt eszközök harmadik tulajdonost adnak hozzá. Egy vállalati mobilitási szabályzat beállíthat alkalmazásonkénti VPN-t vagy mindig bekapcsolt profilt, és egy közönséges alkalmazás nem írhatja felül. A saját kód hibakeresése előtt ellenőrizze, hogy az eszköz felügyelt-e, mert abban az esetben előfordulhat, hogy a módosítani kívánt listát senki sem tudja szerkeszteni, aki a telefont tartja.

Tesztelje egy Ön által vezérelt alkalmazással

Ne azzal az alkalmazással teszteljen, amelyet szűrni próbál. Használjon egy második alkalmazást, amelynek hálózati viselkedését meg tudja figyelni, és ellenőrizze, hogy annak forgalma átmegy-e az alagútján, miközben a célé nem. Ha mindkettő bent marad, a szabályzat működik, és a cél ki van zárva; ha egyik sem megy ki, maga az alagút hibás, és nem az alkalmazáslista a probléma.

Ezután döntse el, melyik három dolog közül épít valójában. Az alkalmazásonkénti alagút az építő API, a lista a profil része. Az eszköztűzfal csomagkezelés plusz egy védhető életciklus. Másvalaki VPN-jének módosítása egyáltalán nem támogatott út, és az őszinte válasz ott az, hogy a beállítás ahhoz a termékhez tartozik.

Kapcsolódó cikkek