Az Android-alkalmazás nem hajlandó VPN-en futni: melyik réteg dönt

Amikor egy Android-alkalmazás abban a pillanatban leáll, hogy feljön az alagút, három különböző dolog lehet a felelős, és hasonlóan kinéző hibákat okoznak. Az alkalmazás kiolvashatja a telefon saját hálózati állapotát, és helyben elutasíthat. A kiszolgáló osztályozhatja a címet, ahonnan érkezik, és visszautasíthatja. Vagy az elutasításnak semmi köze a VPN-hez. Az alábbi sorrend bizonyítékokat gyűjt, mielőtt bármit megváltoztatna, mert a kimenet cseréje a legdrágább lépés, és ez segít a legkevésbé, ha az ellenőrzés helyi.

1. lépés: derítse ki, mikor utasít el az alkalmazás

Az időzítés az első megkülönböztető. Ürítse ki a naplópuffert, reprodukálja a hibát, és nézze meg, mit tett az alkalmazás, mielőtt panaszkodott:

adb logcat -c
# reproduce the failure in the app
adb logcat -d | grep -iE 'vpn|network|connect|http' | tail -60

Ha az alkalmazás azelőtt utasít el, hogy bármilyen kimenő kérés megkísérelt volna, helyi döntést lát. Ha csatlakozik, küld valamit, majd hibát mutat, az elutasítás a másik oldalról jött. Ha az alagút kikapcsolásával ugyanúgy meghibásodik, a VPN soha nem volt a változó.

Ezt az időzítést bizonyítéknak tekintse, nem megerősítésnek. Az alkalmazás visszajátszhat egy gyorsítótárazott választ, és a háttérkérések sikeresek vagy sikertelenek lehettek, mielőtt Ön ránézett. Jegyezze fel az utolsó sikeres kérés és a hiba időbélyegét, ne csak azt a pillanatot, amikor az üzenet megjelent.

2. lépés: olvassa el a telefon saját hálózatképét

Az Android a VPN állapotát hálózati képességként teszi elérhetővé, így egy alkalmazásnak nincs szüksége kereskedelmi szolgáltatók listájára ahhoz, hogy észlelje egy alagút aktív voltát. Megkérdezi a csatlakozási szolgáltatást, melyik a jelenlegi hálózat, és a válasz tartalmaz egy VPN-átviteli bitet:

val cm = context.getSystemService(ConnectivityManager::class.java)
val caps = cm.getNetworkCapabilities(cm.activeNetwork)
val onVpn = caps?.hasTransport(NetworkCapabilities.TRANSPORT_VPN) == true

Ez az ellenőrzés helyi és olcsó, és egy egész jelentésosztályt megmagyaráz – „ez az alkalmazás nem működik VPN-en” – bármilyen távoli osztályozás nélkül. Az, hogy mit láthat az alkalmazás, továbbra is a saját hálózati környezetétől függ, ezért ne feltételezze, hogy minden alkalmazás minden profilt megvizsgál az eszközön.

Munkaállomásról ugyanez az állapot látható egy teszteszközön a adb shell dumpsys connectivity segítségével és a VPN-hálózati bejegyzés keresésével. Hasonlítson össze egy futást felhúzott alagúttal egy futással leengedett alagút mellett, és őrizze meg mindkét kimenetet.

3. lépés: olvassa el, mit lát valójában a kiszolgáló

A másik megfigyelő a szolgáltatás. Látja az érkező forrás címet, és cselekedhet a cím, a mögötte lévő tárhelyhálózat, a régió, a szolgáltató vagy a fiókhoz és eszközhöz kötött jelek alapján. Ezek egyike sem egyedi identitás, és a megosztott címzés miatt a mellékes blokkolások normálisak: egy korlátozott cím ugyanazon fordítás mögött álló, független felhasználókat is kiüthet.

A címet ugyanazon az úton szerezze be, amelyet az alkalmazás használ, ne laptop böngészőjéből. A telefonon egy egyszerű kérés egy címvisszhang-szolgáltatáshoz megmutatja, mit kap a távoli fél, és a mobilhálózaton át küldött kéréssel való összehasonlítás megmondja, változott-e egyáltalán a cím.

Ha az alkalmazás mobilhálózaton működik, és az alagúton ugyanazzal a fiókkal meghibásodik, az elutasítás a távoli végponton vagy az alkalmazás saját házirendjében van. Ha mindkettőn meghibásodik, a VPN nem megkülönböztető tényező, és abba kell hagynia a végpontok tesztelését.

4. lépés: illessze a bizonyítékokat a három ítélet egyikéhez

Három kombináció szinte minden jelentést lefed. Az elutasítás kimenő kísérlet nélkül, aktív alagút mellett helyi átvitel-ellenőrzésre utal. Az a kérés, amely kimegy és hibával, egy adott hoszt időtúllépésével vagy régióüzenettel tér vissza, a távoli oldalra utal. Az alagút nélkül, mobilhálózaton megismétlődő hiba a fiókra, az alkalmazás verziójára vagy a szolgáltatás saját házirendjére utal, és semmilyen VPN-változtatás nem mozdítja el.

Írja le az ítéletet azzal a bizonyítékkal együtt, amely létrehozta. Ennek a lépésnek az az értéke, hogy megállítja azt a hurkot, amelyben valaki négyszer cserél kimeneti csomópontot egy olyan ellenőrzés javítására, amely magán a készüléken fut.

Ez az állításokat is becsületessé teszi. A saját tárhely a végpontot és annak internetes kimenetét változtatja meg; nem felejteti el az Androiddal, hogy aktív a VPN-hálózat, és nem garantálja egy címeket osztályozó szolgáltatás elfogadását. Egy helyi szűrő a saját VPN-hálózatán is ugyanolyan könnyen aktiválódhat, mint egy kereskedelmin.

5. lépés: a támogatott utat válassza, és ellenőrizze

Kezdje a termék dokumentált házirendjével és annak támogatási felelősével. Küldje el az ügyfélverziót, a pontos üzenetet és egy szűk hibaidőablakot; ne küldjön teljes forgalomrögzítést vagy hitelesítő adatokat csak azért, hogy bizonyítsa egy hiba létezését.

Ha a szolgáltatás engedélyezi a közvetlen hozzáférést, és az eszközházirend is engedi, akkor az alkalmazásonkénti kizárás a támogatott mechanizmus, és az szándékosan kiveszi azt az alkalmazást az alagútból, ahelyett hogy elrejtené az alagutat. Az alkalmazás forgalma ekkor a saját útján megy ki, ami olyan házirend-döntés, amelyet valakinek vállalnia kell. Egy VPN nélkül blokkoló beállításban a kizárt alkalmazás egyszerűen elveszítheti a kapcsolatot, ezért tesztelje ezt a kombinációt, mielőtt megígéri, hogy működik.

Minden változtatás után ismételje meg az első lépés időzítéses tesztjét, erősítse meg, hogy az alkalmazás működik, és azt is, hogy minden más alkalmazás továbbra is az alagutat használja. Ezután állítsa vissza az előző beállítást, és ellenőrizze, visszatér-e a hiba, mert a javítás, amelyet nem tud reprodukálni, olyan véletlen, amellyel újra találkozni fog.