Kizárt alkalmazás mégis online? Az alkalmazás- és útvonalszabályok eltérnek

Egy csomag kizárása útvonal-utasítás, nem blokkolás, ezért a VPN csatlakozása után betöltődő oldalak várhatók, és nem egy hiba bizonyítékai. A kizárás kiveszi az alkalmazást az alagútból ahelyett, hogy blokkolná, és a forgalmát a hagyományos hálózat viszi. Itt két külön szabály találkozik: az egyik folyamatokat választ, a másik célokat. Ebben a sorrendben olvasva megmagyarázza, miért nem ellentmondás egy csatlakozott ikon és egy működő alkalmazás.

Miért tartja nyitva a hálózatot a kizárás

A VpnService.Builder vagy engedélyezési listát, vagy tiltólistát fogad el, soha nem mindkettőt. Csak az engedélyezési listán szereplő csomagok haladnak át az alagúton. A tiltólista ezt megfordítja: minden csomag a felsoroltakon kívül az alagutat használja, a felsoroltak pedig a fizikai úton maradnak. Az engedélyezési listán nem szereplő csomag szintén az alagúton kívül van, tehát ebben a módban a kizárás a normális állapot a legtöbb alkalmazás számára.

Ez a helyi tiltólista-bejegyzést útválasztási döntéssé teszi, nem tűzfalszabállyá. Ha a követelmény az, hogy egy alkalmazás ne érjen el egy gazdagépet, az alagútnak le kell fednie, és a kiszolgálónak vagy egy helyi szabálynak el kell utasítania a forgalmat. Egy alkalmazás kivétele az alagútból csak azt változtatja meg, melyik interfész viszi a csomagjait.

A Play Store esete a szokásos szándékos példa. Az áruház csomagjának kizárása engedi, hogy a letöltések a mögöttes kapcsolatot használják, amikor a VPN-kimenet zavarja az átvitelt, és megmutatja, hogy a kizárás megkerülést jelent, nem blokkolást.

Egy profil, egy lista

Az építő kivételt dob, ha mindkét hívást használják, tehát az előtted lévő profil vagy engedélyezési, vagy tiltólista. Ez az egyetlen tény határozza meg, hogyan kell olvasni minden későbbi megfigyelést. A kódot vagy a kezelt konfigurációt nézd meg az útválasztási tábla előtt, mert a lista dönti el, mit jelent a kimenet többi része. A hibrid profil nem olyan állapot, amelyet nézhetnél.

A különbség azt is megjósolja, mit tesz egy újonnan telepített alkalmazás. Engedélyezési lista alatt kívül marad, amíg valaki hozzá nem adja, tiltólista alatt viszont alapértelmezés szerint csatlakozik az alagúthoz.

A kezelt konfigurációk ugyanezt a választást más kulcsnevek alatt kínálják, és egyes konzolok alkalmazásonkénti VPN-módként írják le, nem listaként. A viselkedés mégis arra a két hívásra redukálódik, ezért kövesd vissza a beállítást a csomaglistáig, ahelyett hogy a címkében bíznál. Ha a címke és a lista ellentmond, a lista győz.

Kövesd az UID-szabályt az alagút táblájáig

Az Android minden alkalmazásnak saját Linux-felhasználó-azonosítót ad, és a VPN-szolgáltatás UID-tartományokhoz illeszkedő házirend-szabályokat telepít. Az illeszkedő forgalom egy útválasztási táblába kerül, amelynek alapértelmezett útvonala a tun-eszközre mutat. A táblaszámot VPN-példányonként osztják ki, ezért újracsatlakozás vagy egy második VPN-profil létrehozása után megváltozik.

A szabályok kimenete a térkép. Minden sor megnevez egy keresőtáblát, és az a tábla tartja az alapértelmezett útvonalat, amely eldönti, belépnek-e az illeszkedő csomagok az alagútba.

adb shell ip rule show
adb shell ip route show table all
adb shell cmd package list packages -U | grep <package>

Először futtasd a harmadik parancsot az UID megszerzéséhez, majd keresd meg azt a szabályt, amelynek tartománya tartalmazza. Az a szabály egy táblaszámra mutat, és ip route show table <n> ezzel a számmal mutatja meg, létezik-e alapértelmezett útvonal a tun-eszközön át. Ha a táblának nincs alapértelmezett útvonala, az alkalmazás ki van választva, de nincs útja, ami másfajta hiba.

Ezek a parancsok hibakereshető buildet vagy olyan eszközt igényelnek, ahol az adb shell olvasni tudja a hálózat állapotát. Gyártási készüléken a csomagkezelő még válaszol, de az útválasztás vizsgálata elutasítható, ezért rögzítsd, amit tudsz, a többit pedig tekintsd ellenőrizetlennek.

Az útvonal előtagot igényel, nem alkalmazást

A Builder.addRoute cél-előtagokat igényel az alagút számára. Egy profil, amely csak 10.0.0.0/8 ad hozzá, azt az előtagot az alagúton küldi, és minden más célt a fizikai úton hagy. Ez a szokásos osztott alagút, és független attól, mely alkalmazásokat választottak a szabályok.

A kiszolgáló által küldött konfiguráció ugyanezt a modellt tükrözi. Az egyedi útvonal-küldések előtagokat adnak hozzá, míg a redirect-gateway irányelv lecseréli az alapértelmezett útvonalat, és mindent befog az alagút által lefedett alkalmazások számára. Az irányelv eltávolítása egy működő alagutat egyetlen alhálózatra zsugoríthat anélkül, hogy bármi változna az eszközön.

Egy szokatlan átjárójú vagy metrikus minősítőjű küldött útvonal szintén nem települhet. Részesítsd előnyben az egyszerű előtagformát, és hagyd a kiszolgálóra a továbbítást és a NAT-ot.

Olvasd el a metszetet, mielőtt beállítást változtatsz

Az alagút a lefedett folyamatok és az igényelt célok metszetét viszi. Egy lefedett alkalmazás, amely a közzétett előtagokon kívüli címet kér, a fizikai hálózaton lép ki. Egy tiltott csomag kívül marad akkor is, amikor az előtagokon belüli címet kér. Egyik eset sem hiba; mindkettő a két szabály, amely a dolgát végzi.

Az alkalmazásonkénti VPN egy társított alkalmazást kapcsolat nélkül is hagyhat. Amikor az on-demand ki van kapcsolva és az alagút le van állva, az alkalmazás az alkalmazásonkénti VPN-hez kötve marad, és nincs tartalék útja, ami inkább tűnik törött alkalmazásnak, mint szabályállapotnak. Az on-demand bekapcsolása vagy a társítás kezelésen keresztüli eltávolítása ezt megváltoztatja.

Egyszerre egy tengelyt diagnosztizálj. Először igazold az engedélyezést vagy tiltást, másodszor olvasd ki a telepített UID-szabályokat és táblákat, végül tesztelj egy második alkalmazást ugyanarra a célra. A második alkalmazás egyetlen kérésben választja szét a folyamatválasztást a célválasztástól.

Írd fel az eredményt alkalmazásként, célként és táblaszámként. Pontosan ezt a hármast kell a következő változtatásnak megőriznie.