Aplikácia v Androide odmieta fungovať cez VPN: ktorá vrstva rozhoduje

Keď aplikácia v Androide prestane fungovať presne v momente, keď sa tunel zdvihne, môžu za to tri rôzne veci a ich prejavy vyzerajú podobne. Aplikácia môže prečítať stav siete samotného telefónu a odmietnuť lokálne. Server môže klasifikovať adresu, z ktorej prichádzate, a odmietnuť ju. Alebo odmietnutie nemá s VPN nič spoločné. Poradie nižšie najprv zhromažďuje dôkazy a až potom niečo mení, pretože zmena výstupu je najdrahší krok a najmenej pravdepodobne pomôže, ak je kontrola lokálna.

Krok 1: zistite, kedy aplikácia odmieta

Čas je prvým rozlišovacím znakom. Vymažte buffer záznamu, reprodukujte zlyhanie a pozrite sa, čo aplikácia urobila, kým sa sťažovala:

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

Ak aplikácia odmietne pred akýmkoľvek pokusom o odchádzajúcu požiadavku, ide o lokálne rozhodnutie. Ak sa pripojí, niečo odošle a až potom zobrazí chybu, odmietnutie prišlo z druhej strany. Ak aplikácia zlyháva rovnako aj s vypnutým tunelom, VPN nikdy nebol premennou.

Berte ten čas ako dôkaz, nie ako rozsudok. Aplikácia môže prehrať odpoveď z vyrovnávacej pamäte a požiadavky na pozadí mohli uspieť alebo zlyhať skôr, než ste sa pozreli. Zaznamenajte časové značky poslednej úspešnej požiadavky a chyby, nielen okamih, keď sa správa objavila.

Krok 2: prečítajte si, ako vidí sieť samotný telefón

Android sprístupňuje stav VPN ako vlastnosť siete, takže aplikácia nepotrebuje zoznam komerčných poskytovateľov, aby si všimla aktívny tunel. Opýta sa služby pripojenia, ktorá sieť je aktuálna, a odpoveď obsahuje bit transportu VPN:

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

Táto kontrola je lokálna a lacná a vysvetľuje celú triedu hlásení typu "táto aplikácia nefunguje cez VPN" bez akejkoľvek vzdialenej klasifikácie. To, čo aplikácia vidí, stále závisí od jej vlastného sieťového kontextu, preto nepredpokladajte, že každá aplikácia kontroluje každý profil v zariadení.

Z pracovnej stanice vidíte ten istý stav na testovacom zariadení pomocou adb shell dumpsys connectivity a hľadaním záznamu siete VPN. Porovnajte beh so zdvihnutým tunelom s behom so spusteným a oba výstupy si ponechajte.

Krok 3: prečítajte si, čo server skutočne vidí

Druhým pozorovateľom je služba. Vidí zdrojovú adresu, ktorá k nej prichádza, a môže konať podľa adresy, hostingovej siete za ňou, regiónu, operátora alebo signálov spojených s účtom a zariadením. Nič z toho nie je jedinečná identita a zdieľanie adries robí vedľajšie blokovania bežnými: jedna obmedzená adresa môže vyradiť nesúvisiacich používateľov za rovnakým prekladom.

Získajte adresu tou istou cestou, akú používa aplikácia, nie z prehliadača na notebooku. Na telefóne obyčajná požiadavka na službu ozveny adresy ukazuje, čo prijíma vzdialená strana, a porovnanie s požiadavkou cez mobilnú sieť povie, či sa adresa vôbec zmenila.

Ak aplikácia funguje cez mobilnú sieť a zlyháva cez tunel s rovnakým účtom, odmietnutie je na vzdialenej strane alebo v politike samotnej aplikácie. Ak zlyháva v oboch prípadoch, VPN nie je rozdielom a mali by ste prestať testovať koncové body.

Krok 4: priraďte dôkazy k jednému z troch verdiktov

Tri kombinácie pokrývajú takmer každé hlásenie. Odmietnutie bez odchádzajúceho pokusu pri aktívnom tuneli ukazuje na lokálnu kontrolu transportu. Požiadavka, ktorá odíde a vráti sa s chybou, vypršanie času na konkrétnom hostiteľovi alebo správa o regióne ukazujú na vzdialenú stranu. Zlyhanie, ktoré sa opakuje v mobilnej sieti bez tunela, ukazuje na účet, verziu aplikácie alebo politiku samotnej služby a žiadna zmena VPN ho nepohne.

Verdikt zapíšte spolu s dôkazmi, ktoré ho priniesli. Hodnota tohto kroku je v tom, že zastaví slučku, v ktorej niekto štyrikrát mení výstupné uzly, aby opravil kontrolu, ktorá beží priamo v telefóne.

Zároveň to drží tvrdenia čestnými. Vlastný server mení koncový bod a jeho internetový výstup; nerobí to, aby Android zabudol, že sieť VPN je aktívna, a negarantuje prijatie službou, ktorá klasifikuje adresy. Lokálny filter sa môže spustiť na VPN sieti, ktorú vlastníte, rovnako ľahko ako na komerčnej.

Krok 5: zvoľte podporovanú cestu a overte ju

Začnite dokumentovanou politikou produktu a jeho vlastníkom podpory. Pošlite verziu klienta, presnú správu a úzke okno zlyhania; neposielajte úplné záznamy prevádzky ani prihlasovacie údaje len aby ste dokázali, že chyba existuje.

Ak služba povoľuje priamy prístup a politika zariadenia to dovoľuje, vylúčenie jednej aplikácie je podporovaný mechanizmus a zámerne odoberá túto aplikáciu z tunela namiesto skrývania tunela. Prevádzka aplikácie potom odchádza vlastnou cestou, čo je politické rozhodnutie, ktoré niekto musí prevziať. V konfigurácii blokovania bez VPN môže vylúčená aplikácia jednoducho stratiť pripojenie, preto túto kombináciu otestujte, kým sľúbite, že funguje.

Po každej zmene zopakujte test času z prvého kroku, potvrďte, že aplikácia funguje, a potvrďte, že všetky ostatné aplikácie tunel stále používajú. Potom obnovte predchádzajúcu konfiguráciu a skontrolujte, či sa zlyhanie vracia, pretože oprava, ktorú nedokážete reprodukovať, je náhoda, s ktorou sa ešte stretnete.