Android programėlė atsisako veikti per VPN: kuris sluoksnis nusprendžia

Kai Android programėlė nustoja veikti tą akimirką, kai pakyla tunelis, kalti gali būti trys skirtingi dalykai, ir jie sukuria panašiai atrodančius gedimus. Programėlė gali perskaityti paties telefono tinklo būseną ir atmesti vietoje. Serveris gali klasifikuoti adresą, iš kurio atvykstate, ir jį atmesti. Arba atmetimas gali visai neturėti nieko bendra su VPN. Žemiau pateikta tvarka renka įrodymus prieš ką nors keisdama, nes išėjimo keitimas yra brangiausias žingsnis ir tas, kuris mažiausiai tikėtina padės, jei patikra yra vietinė.

1 žingsnis: išsiaiškinkite, kada programėlė atmeta

Laikas yra pirmasis skiriamasis požymis. Išvalykite žurnalo buferį, atkurkite gedimą ir pažiūrėkite, ką programėlė darė prieš skųsdamasi:

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

Jei programėlė atmeta prieš bandant bet kokią išeinančią užklausą, matote vietinį sprendimą. Jei ji prisijungia, ką nors nusiunčia ir tada rodo klaidą, atmetimas atėjo iš kitos pusės. Jei programėlė taip pat nepavyksta su išjungtu tuneliu, VPN niekada nebuvo kintamasis.

Traktuokite tą laiką kaip įrodymą, o ne kaip patvirtinimą. Programėlė gali pakartoti podėlyje laikomą atsakymą, o foninės užklausos galėjo pavykti arba nepavykti anksčiau, nei pažiūrėjote. Užsirašykite paskutinės sėkmingos užklausos ir klaidos laiko žymas, o ne tik akimirką, kai pasirodė pranešimas.

2 žingsnis: perskaitykite, kaip pats telefonas mato tinklą

Android atskleidžia VPN būseną kaip tinklo galimybę, todėl programėlei nereikia komercinių teikėjų sąrašo, kad pastebėtų aktyvų tunelį. Ji klausia ryšio tarnybos, koks yra dabartinis tinklas, ir atsakyme yra VPN transporto bitas:

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

Ši patikra yra vietinė ir pigi, ir ji paaiškina visą pranešimų klasę „ši programėlė neveikia per VPN“ be jokios nuotolinės klasifikacijos. Tai, ką programėlė gali matyti, vis dar priklauso nuo jos pačios tinklo konteksto, todėl ne manykite, kad kiekviena programėlė tikrina kiekvieną įrenginio profilį.

Iš darbo stoties galite matyti tą pačią būseną bandomajame įrenginyje naudodami adb shell dumpsys connectivity ir ieškodami VPN tinklo įrašo. Palyginkite paleidimą su pakeltu tuneliu su paleidimu su nuleistu, ir išsaugokite abu išvedimus.

3 žingsnis: perskaitykite, ką serveris iš tikrųjų mato

Kitas stebėtojas yra tarnyba. Ji mato ateinantį šaltinio adresą ir gali veikti pagal adresą, už jo esantį prieglobos tinklą, regioną, operatorių arba su paskyra ir įrenginiu susietus signalus. Nė vienas iš jų nėra unikali tapatybė, o bendras adresavimas daro šalutinius blokavimus įprastus: vienas ribojamas adresas gali išmušti nesusijusius naudotojus už to paties vertimo.

Gaukite adresą tuo pačiu keliu, kuriuo naudojasi programėlė, o ne iš naršyklės nešiojamajame kompiuteryje. Telefone paprasta užklausa adreso aidų tarnybai parodo, ką gauna tolimoji pusė, o palyginimas su užklausa per mobilųjį tinklą pasakys, ar adresas apskritai pasikeitė.

Jei programėlė veikia per mobilųjį tinklą, o per tunelį nepavyksta su ta pačia paskyra, atmetimas yra tolimajame gale arba pačios programėlės politikoje. Jei nepavyksta abiem atvejais, VPN nėra skiriamasis veiksnys ir turėtumėte nustoti testuoti galinius taškus.

4 žingsnis: priskirkite įrodymus vienam iš trijų nuosprendžių

Trys deriniai apima beveik kiekvieną pranešimą. Atmetimas be jokio išeinančio bandymo, kai tunelis aktyvus, rodo vietinę transporto patikrą. Užklausa, kuri išeina ir grįžta su klaida, konkrečios hosto laiko limitu arba regiono pranešimu, rodo tolimąją pusę. Gedimas, kuris kartojasi per mobilųjį tinklą be tunelio, rodo paskyrą, programėlės versiją arba pačios tarnybos politiką, ir jokia VPN pakeitimas jo nepajudins.

Užrašykite nuosprendį kartu su įrodymu, kuris jį sukūrė. Šio žingsnio vertė yra ta, kad jis sustabdo ciklą, kai kas nors keturis kartus keičia išėjimo mazgus, kad pataisytų patikrą, kuri vykdoma pačiame telefone.

Jis taip pat išlaiko teiginius sąžiningus. Savo priegloba keičia galinį tašką ir jo interneto išėjimą; ji nepriverčia Android pamiršti, kad VPN tinklas aktyvus, ir negarantuoja, kad priims tarnyba, kuri klasifikuoja adresus. Vietinis filtras gali suveikti jūsų pačių VPN tinkle taip pat lengvai, kaip ir komerciniame.

5 žingsnis: eikite palaikomu keliu ir patikrinkite jį

Pradėkite nuo dokumentuotos produkto politikos ir jos palaikymo savininko. Siųskite kliento versiją, tikslią pranešimą ir siaurą gedimo laiko intervalą; nesiųskite visų srauto įrašų ar prisijungimo duomenų vien tam, kad įrodytumėte, jog klaida egzistuoja.

Jei tarnyba leidžia tiesioginę prieigą ir įrenginio politika tai leidžia, tuomet kiekvienos programėlės išskyrimas yra palaikomas mechanizmas, ir jis sąmoningai išima tą programėlę iš tunelio, o ne slepia tunelį. Tada programėlės srautas išeina savo keliu, o tai yra politikos sprendimas, kurį kažkas turi prisiimti. Konfigūracijoje, kuri blokuoja be VPN, išskirta programėlė gali tiesiog prarasti ryšį, todėl išbandykite tą derinį prieš žadėdami, kad jis veiks.

Po bet kokio pakeitimo pakartokite pirmo žingsnio laiko testą, patvirtinkite, kad programėlė veikia, ir patvirtinkite, kad visos kitos programėlės vis dar naudoja tunelį. Tada atkurkite ankstesnę konfigūraciją ir patikrinkite, ar gedimas grįžta, nes pataisymas, kurio negalite atkurti, yra atsitiktinumas, kurį sutiksite vėl.