Android aplikazio batek uko egiten dio VPN bidez funtzionatzeari: zein geruzak erabakitzen du

Android aplikazio bat tunela altxatzen den unetan funtzionatzeari uzten dionean, hiru gauza desberdin izan daitezke erantzule, eta antzeko itxurako hutsegiteak sortzen dituzte. Aplikazioak telefonoaren beraren sare egoera irakurri eta tokian bertan uko egin dezake. Zerbitzariak nondik zatozen helbidea sailkatu eta hura bazter dezake. Edo ukoak ez du zerikusirik VPNarekin. Beheko ordenak frogak biltzen ditu ezer aldatu aurretik, irteera aldatzea pausorik garestiena delako eta egiaztapena tokikoa bada gutxien lagunduko duena.

1. pausoa: jakin aplikazioak noiz egiten dion uko

Denbora da lehen bereizlea. Garbitu erregistroaren bufferra, erreproduzitu hutsegitea eta begiratu zer egin zuen aplikazioak kexatu aurretik:

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

Aplikazioak irteerako eskaeraren bat saiatu aurretik uko egiten badio, tokiko erabaki bat ikusten ari zara. Konektatzen bada, zerbait bidali eta gero errore bat erakusten badu, ukoa beste aldetik etorri da. Tunela itzalita dagoela berdin huts egiten badu, VPNa ez zen inoiz aldagaia izan.

Hartu denbora hori froga gisa, ez baieztapen gisa. Aplikazio batek cachean gordetako erantzun bat erreproduzitu dezake, eta atzeko eskaerek arrakasta edo huts egin zezaketen zu begiratu aurretik. Idatzi azken eskaera onaren eta errorearen denbora markak, ez soilik mezua agertu zen unea.

2. pausoa: irakurri telefonoak sareari buruz duen ikuspegia

Androidek VPNaren egoera sare gaitasun gisa erakusten du, beraz aplikazio batek ez du hornitzaile komertzialen zerrendarik behar tunel bat aktibo dagoela nabaritzeko. Konektagarritasun zerbitzuari galdetzen dio zein den uneko sarea, eta erantzunak VPN garraioaren bita dakar:

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

Egiaztapen hori tokikoa eta merkea da, eta «aplikazio hau ez dabil VPNarekin» motako txostenen klase osoa azaltzen du urruneko sailkapenik gabe. Aplikazioak ikus dezakeena bere sare testuinguruaren araberakoa da oraindik, beraz ez pentsa aplikazio bakoitzak gailuko profil guztiak aztertzen dituenik.

Lanpostu batetik egoera bera ikus dezakezu probako gailu batean adb shell dumpsys connectivity erabiliz eta VPN sarearen sarrera bilatuz. Alderatu tunela altxatuta duen exekuzio bat jaitsita duen beste batekin, eta gorde bi irteerak.

3. pausoa: irakurri zerbitzariak benetan zer ikusten duen

Beste behatzailea zerbitzua da. Heltzen den iturburu helbidea ikusten du, eta helbidearen, haren atzean dagoen hosting sarearen, eskualdearen, operadorearen edo kontuarekin eta gailuarekin lotutako seinaleen arabera joka dezake. Horietako bat ere ez da identitate bakarra, eta helbideratze partekatuak alboko blokeoak normal bihurtzen ditu: helbide murriztu batek itzulpen beraren atzean dauden erabiltzaile erlazionagabeak kanpora ditzake.

Lortu helbidea aplikazioak erabiltzen duen bide beretik, ez eramangarriko nabigatzaile batetik. Telefonoan, helbide oihartzun zerbitzu bati egindako eskaera soilak urruneko aldea zer jasotzen ari den erakusten du, eta hori sare mugikorraren bidezko eskaera batekin alderatzeak helbidea aldatu den ala ez esaten dizu.

Aplikazioak sare mugikorraren bidez funtzionatzen badu eta tunelaren bidez huts egiten badu kontu berarekin, ukoa urruneko muturrean dago edo aplikazioaren beraren politikan. Bi kasuetan huts egiten badu, VPNa ez da bereizlea eta utzi behar diozu muturreko puntuak probatzeari.

4. pausoa: egokitu frogak hiru epaien arteko batera

Hiru konbinaziok ia txosten guztiak estaltzen dituzte. Tunela aktibo dagoela irteerako saiakera orokorrik gabeko ukoa tokiko garraio egiaztapen batera bideratzen da. Irten eta errore batekin, ostalari jakin batean denbora amaituz edo eskualde mezu batekin itzultzen den eskaera urruneko aldera bideratzen da. Tunelik gabe sare mugikorrean errepikatzen den hutsegitea kontura, aplikazioaren bertsiora edo zerbitzuaren beraren politikara bideratzen da, eta VPN aldaketak ez du hura mugituko.

Idatzi epaia sortu zuen frogarekin batera. Pauso honen balioa da eten egiten duela norbait lau aldiz irteera nodoak aldatzen ari den begizta, telefonoan bertan exekutatzen den egiaztapen bat konpontzeko.

Baieztapenak zintzo mantentzen ere laguntzen du. Norberak ostatatzeak muturreko puntua eta haren internet irteera aldatzen ditu; ez dio Androideri ahaztarazten VPN sare bat aktibo dagoenik, eta ez du bermatzen helbideak sailkatzen dituen zerbitzu batek onartuko duenik. Tokiko iragazki batek zure VPN sarean ere abia daiteke, komertzial batean bezain erraz.

5. pausoa: hartu onartutako bidea eta egiaztatu

Hasi produktuaren politika dokumentatuarekin eta haren laguntza arduradunarekin. Bidali bezeroaren bertsioa, mezu zehatza eta hutsegite leiho estua; ez bidali trafiko kaptura osoak edo kredentzialak errore bat badagoela frogatzeko soilik.

Zerbitzuak sarbide zuzena onartzen badu eta gailuaren politikak baimena ematen badu, orduan aplikazio bakarrerako bazterketa da onartutako mekanismoa, eta nahita ateratzen du aplikazio hori tunelatik, tunela ezkutatu beharrean. Aplikazioaren trafikoa bere bide propioan ateratzen da orduan, eta hori norbaiten ardura izan behar duen erabaki politikoa da. VPNik gabe blokeatzen duen konfigurazio batean baztertutako aplikazio batek konektagarritasuna gal dezake, beraz probatu konbinazio hori funtzionatzen duela agindu aurretik.

Edozein aldaketaren ondoren, errepikatu lehen pausoaren denbora proba, egiaztatu aplikazioak funtzionatzen duela eta egiaztatu beste aplikazio guztiek tunela oraindik erabiltzen dutela. Gero leheneratu aurreko konfigurazioa eta egiaztatu hutsegitea itzultzen den, ezin duzun konponketa erreproduzitzea lortzen ez duzulako berriro aurkituko duzun kasualitatea izango litzateke.