Androidi rakendus keeldub VPN-i kaudu töötamast: milline kiht otsustab

Kui Androidi rakendus lakkab töötamast hetkel, mil tunnel tõuseb, võivad süüdi olla kolm erinevat asja ja need tekitavad sarnaselt näivaid tõrkeid. Rakendus võib lugeda telefoni enda võrguolekut ja keelduda kohapeal. Server võib liigitada aadressi, kust te tulete, ja selle tagasi lükata. Või ei pruugi keeldumisel VPN-iga üldse mingit seost olla. Allolev järjekord kogub tõendeid enne, kui midagi muudab, sest väljundi vahetamine on kalleim samm ja kõige vähem tõenäoliselt aitab, kui kontroll on kohalik.

Samm 1: tehke kindlaks, millal rakendus keeldub

Ajastus on esimene eristaja. Tühjendage logi puhver, korjake tõrge uuesti esile ja vaadake, mida rakendus enne kaebamist tegi:

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

Kui rakendus keeldub enne, kui ühtki väljuvat päringut on üritatud, näete kohalikku otsust. Kui see ühendub, saadab midagi ja näitab seejärel viga, tuli keeldumine teiselt poolelt. Kui rakendus ebaõnnestub tunneliga väljas samamoodi, ei olnud VPN kunagi muutuja.

Käsitlege seda ajastust tõendina, mitte kinnitusena. Rakendus võib vahemällu salvestatud vastust uuesti esitada ning taustapäringud võisid enne teie vaatamist õnnestuda või ebaõnnestuda. Kirjutage üles viimase õnnestunud päringu ja vea ajatemplid, mitte ainult hetk, mil teade ilmus.

Samm 2: lugege telefoni enda vaadet võrgule

Android paljastab VPN-i oleku võrguvõimalusena, seega ei vaja rakendus äriühingute pakkujate nimekirja, et märgata aktiivset tunnelit. See küsib ühendusteenuselt, milline on praegune võrk, ja vastus sisaldab VPN-i transpordibitti:

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

See kontroll on kohalik ja odav ning selgitab tervet klassifikatsiooni «see rakendus ei tööta VPN-i kaudu» ilma igasuguse kaugliigituseta. See, mida rakendus näeb, sõltub endiselt selle enda võrgukontekstist, seega ärge eeldage, et iga rakendus uurib seadme igat profiili.

Tööjaamast näete sama olekut testseadmes käsuga adb shell dumpsys connectivity ja otsides VPN-i võrgukirjet. Võrrelge jooksu, kus tunnel on üleval, jooksuga, kus see on maas, ja hoidke mõlemad väljundid alles.

Samm 3: lugege, mida server tegelikult näeb

Teine vaatleja on teenus. See näeb saabuvat lähteaadressi ja võib tegutseda aadressi, selle taga oleva majutusvõrgu, piirkonna, operaatori või kontoga ja seadmega seotud signaalide põhjal. Miski sellest ei ole unikaalne identiteet ning jagatud adresseerimine muudab kõrvalmõjuga blokeeringud tavaliseks: üks piiratud aadress võib välja lülitada kõrvalisi kasutajaid sama tõlke taga.

Hankige aadress sama teed pidi, mida rakendus kasutab, mitte sülearvuti brauserist. Telefonis näitab lihtne päring aadressi kaja teenusele, mida kaugpool vastu võtab, ja selle võrdlemine mobiilivõrgu kaudu tehtud päringuga ütleb, kas aadress üldse muutus.

Kui rakendus töötab mobiilivõrgu kaudu ja ebaõnnestub tunneliga sama kontoga, on keeldumine kaugpool või rakenduse enda poliitika. Kui see ebaõnnestub mõlemal, ei ole VPN eristaja ja peaksite lõpetama lõpp-punktide testimise.

Samm 4: sobitage tõendid ühega kolmest otsusest

Kolm kombinatsiooni katavad peaaegu iga raporti. Keeldumine ilma väljuva katsega aktiivse tunneli ajal osutab kohalikule transpordikontrollile. Päring, mis väljub ja naaseb vea, konkreetse hosti aegumise või piirkonnateatega, osutab kaugpoolele. Tõrge, mis kordub mobiilivõrgus ilma tunnelita, osutab kontole, rakenduse versioonile või teenuse enda poliitikale ja ükski VPN-i muudatus ei liiguta seda.

Kirjutage otsus üles koos tõendiga, mis selle tekitas. Selle sammu väärtus on see, et see peatab tsükli, kus keegi vahetab neli korda väljundsõlmi, et parandada kontrolli, mis jookseb telefoni enda peal.

See hoiab ka väited ausad. Ise majutamine muudab lõpp-punkti ja selle internetiväljundit; see ei pane Androidi unustama, et VPN-võrk on aktiivne, ega taga vastuvõttu teenuses, mis liigitab aadresse. Kohalik filter võib käivituda teie enda VPN-võrgus sama kergesti kui äriühingu omas.

Samm 5: minge toetatud teed ja kontrollige seda

Alustage toote dokumenteeritud poliitikast ja selle tugiomanikust. Saatke kliendi versioon, täpne teade ja kitsas tõrkeaken; ärge saatke täielikke liiklusjäädvustusi ega volitusi ainult selleks, et tõestada vea olemasolu.

Kui teenus lubab otsest juurdepääsu ja seadme poliitika seda võimaldab, siis rakendusepõhine väljajätmine on toetatud mehhanism ja see eemaldab selle rakenduse teadlikult tunnelist, mitte ei peida tunnelit. Rakenduse liiklus väljub siis oma teed, mis on poliitikaotsus, mille keegi peab enda kanda võtma. Konfiguratsioonis, mis blokeerib ilma VPN-ita, võib väljajäetud rakendus lihtsalt ühenduse kaotada, seega testige seda kombinatsiooni enne, kui lubate, et see töötab.

Pärast iga muudatust korrake esimese sammu ajatest, kinnitage, et rakendus töötab, ja kinnitage, et kõik teised rakendused kasutavad endiselt tunnelit. Seejärel taastage eelmine konfiguratsioon ja kontrollige, kas tõrge naaseb, sest parandus, mida te ei suuda korrata, on kokkusattumus, millega te taas kohtute.