Aplikace pro Android odmítá běžet přes VPN: která vrstva rozhoduje

Když aplikace pro Android přestane fungovat ve chvíli, kdy se zvedne tunel, mohou být vinny tři různé věci a všechny dávají podobně vypadající selhání. Aplikace může přečíst stav sítě vlastního telefonu a odmítnout lokálně. Server může klasifikovat adresu, ze které přicházíte, a odmítnout ji. Nebo odmítnutí nemusí mít s VPN nic společného. Pořadí níže shromažďuje důkazy dřív, než cokoli změní, protože změna výstupu je nejdražší krok a ten, který nejméně pravděpodobně pomůže, je-li kontrola lokální.

Krok 1: zjistěte, kdy aplikace odmítá

Časování je první rozlišovač. Vymažte buffer protokolu, zopakujte selhání a podívejte se, co aplikace dělala, než si stěžovala:

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

Pokud aplikace odmítne dřív, než se pokusí o jakýkoli odchozí požadavek, díváte se na lokální rozhodnutí. Pokud se připojí, něco odešle a pak ukáže chybu, odmítnutí přišlo z druhé strany. Pokud aplikace selhává stejně i se zavřeným tunelem, VPN nikdy nebyla proměnnou.

Berte to časování jako důkaz, ne jako potvrzení. Aplikace může přehrát odpověď z mezipaměti a požadavky na pozadí mohly uspět nebo selhat ještě předtím, než jste se podívali. Zapište si časové značky posledního úspěšného požadavku a chyby, ne jen okamžik, kdy se zpráva objevila.

Krok 2: přečtěte si, jak telefon sám vidí síť

Android vystavuje stav VPN jako síťovou schopnost, takže aplikace nepotřebuje seznam komerčních poskytovatelů, aby si všimla, že je tunel aktivní. Zeptá se služby připojení, jaká je aktuální síť, a odpověď 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

Tato kontrola je lokální a levná a vysvětluje celou třídu hlášení typu „tato aplikace přes VPN nefunguje“ bez jakékoli vzdálené klasifikace. Co aplikace vidí, stále závisí na jejím vlastním síťovém kontextu, takže nepředpokládejte, že každá aplikace zkoumá každý profil v zařízení.

Z pracovní stanice uvidíte stejný stav na testovacím zařízení pomocí adb shell dumpsys connectivity a hledáním záznamu sítě VPN. Porovnejte běh se zvednutým tunelem s během se spuštěným tunelem a oba výstupy si uložte.

Krok 3: přečtěte si, co skutečně vidí server

Druhým pozorovatelem je služba. Vidí zdrojovou adresu, která přichází, a může jednat podle adresy, hostingové sítě za ní, regionu, operátora nebo signálů vázaných na účet a zařízení. Nic z toho není jedinečná identita a sdílené adresování dělá vedlejší blokace normálními: jedna omezená adresa může vyřadit nesouvisející uživatele za stejným překladem.

Získejte adresu stejnou cestou, jakou používá aplikace, ne z prohlížeče na notebooku. V telefonu jednoduchý požadavek na službu ozvěny adresy ukáže, co vzdálená strana dostává, a srovnání s požadavkem přes mobilní síť vám řekne, zda se adresa vůbec změnila.

Pokud aplikace funguje přes mobilní síť a selhává přes tunel se stejným účtem, odmítnutí je na vzdálené straně nebo ve vlastní politice aplikace. Pokud selhává v obou případech, VPN není rozlišovačem a měli byste přestat testovat koncové body.

Krok 4: přiřaďte důkazy k jednomu ze tří verdiktů

Tři kombinace pokrývají téměř každé hlášení. Odmítnutí bez pokusu o odchozí spojení při aktivním tunelu ukazuje na lokální kontrolu transportu. Požadavek, který vyjde a vrátí se s chybou, vypršením času na určitém hostiteli nebo zprávou o regionu, ukazuje na vzdálenou stranu. Selhání, které se opakuje přes mobilní síť bez tunelu, ukazuje na účet, verzi aplikace nebo vlastní politiku služby a žádná změna VPN s ním nepohne.

Zapište verdikt spolu s důkazem, který ho vyvolal. Hodnota tohoto kroku je v tom, že zastaví smyčku, v níž někdo čtyřikrát mění výstupní uzly, aby opravil kontrolu, která běží na samotném telefonu.

Zároveň to udržuje tvrzení poctivá. Vlastní hosting mění koncový bod a jeho internetový výstup; nezpůsobí, že Android zapomene na aktivní síť VPN, a nezaručí přijetí službou, která klasifikuje adresy. Lokální filtr se může spustit na vaší vlastní síti VPN stejně snadno jako na komerční.

Krok 5: jděte podporovanou cestou a ověřte ji

Začněte s dokumentovanou politikou produktu a jeho vlastníkem podpory. Pošlete verzi klienta, přesnou zprávu a úzké okno selhání; neposílejte plné záznamy provozu ani přihlašovací údaje jen proto, abyste dokázali, že chyba existuje.

Pokud služba povoluje přímý přístup a politika zařízení to dovoluje, pak vyloučení pro jednotlivou aplikaci je podporovaný mechanismus a záměrně vyjímá tuto aplikaci z tunelu místo toho, aby tunel skrývalo. Provoz aplikace pak odchází vlastní cestou, což je politické rozhodnutí, které musí někdo nést. V konfiguraci, která blokuje bez VPN, může vyloučená aplikace prostě ztratit připojení, takže tuto kombinaci otestujte, než slíbíte, že funguje.

Po každé změně zopakujte časový test z prvního kroku, potvrďte, že aplikace funguje, a potvrďte, že všechny ostatní aplikace tunel stále používají. Potom obnovte předchozí konfiguraci a zkontrolujte, zda se selhání vrací, protože oprava, kterou nedokážete reprodukovat, je náhoda, se kterou se znovu setkáte.