VpnService-ren babesa huts egiten du beste VPN bat aktibo dagoenean

Zure aplikazioak VpnService.prepare deitzen du, null jasotzen du, tunel bat eraikitzen du, eta deskribatzailea baliozkoa dirudi, baina ezerk ez du zerbitzarira iristen. Edo prepare-k Intent bat itzultzen du, erabiltzaileak onartzen du, eta establish-ek huts egiten du oraindik. Bi emaitzek gauza bera esan ohi dute: beste aplikazio batek jada erabiltzaile honen VPN interfazea du, eta zure protect deiek zure tunelak erabili ezin dituen socketak markatzen ari dira. Egin beheko egiaztapenak ordenan eta gelditu huts egiten duen lehenenean, geroagoko pauso batek ezin baititu aurrekoak konpondu.

Egiaztatu VPN lekua protect ukitu aurretik

Androidek erabiltzaile bakoitzari VPN interfaze aktibo bakarra ematen dio. Plataformaren araua da, zure aplikazioak eska dezakeen baimena ez da, beraz tunela izan nahi duten bi bezerok ezin dute elkarrekin bizi.

Beste aplikazio baterako ezarritako beti martxan dagoen VPN bat da kasurik zailena, sistemak aplikazio hura konektatuta mantentzen baitu eta hartze bat ukatzen. Trafiko iragazki batek, AdGuard-ek, enpresa bezero batek edo kontsumitzaile VPN batek lekua har dezakete erabiltzaileak instalatuta dagoela ahaztu duen bitartean. Eskatu erabiltzaileari Ezarpenak ireki eta VPN atalean agertzen den sarrera irakurtzeko; han dagoen izena da lehiatzen ari zaren jabea. Sarrera hori deskonektatu edo beti martxan ezarpena garbitu arte, zure VpnService ezin da interfazea bihurtu.

Pauso 1: irakurri prepare-k zer itzultzen duen

VpnService.prepare-k galdera bakarrari erantzuten dio: aplikazio hau VPN bihur daiteke? Null itzultzen du baimena jadanik badago, eta Intent bat erabiltzaileak oraindik onartu behar duenean, startActivityForResult-ekin abiarazi behar duzuna. Trata ezazu null itzulera jarraitzeko baimen gisa, ez establish arrakastatsua izango den froga gisa.

Intent intent = VpnService.prepare(context);
if (intent != null) {
    startActivityForResult(intent, REQUEST_VPN);
}

Intent bideak itzuli eta erabiltzaileak uko egin badio, prepare-k Intent bat itzultzen jarraituko du hurrengo saioan. Erregistratu emaitzaren kodea begiztan berriro saiatu beharrean, uko egindako baimena erabiltzailearen erabakia delako, ez errore iragankorra.

Pauso 2: berretsi interfazea zure aplikazioarena dela

establish ondoren, jasotzen duzun ParcelFileDescriptor da jabetzaren froga, eta merezi du socket lanen aurretik egiaztatzea. Null den edo jadanik itxita dagoen deskribatzaile batek esan nahi du interfazea ez zela inoiz sortu, salbuespenik agertu ez bazen ere. Konparatu builder-eko interfaze izena sistemak VPN aktiboarentzat ematen duenarekin, dumpsys erabiliz probako gailu batean. Ezberdinak badira, eraiki duzun tunela ez da trafikoa daraman tunela.

adb shell dumpsys connectivity

Desadostasun berak argitzen du konektatutako ikono bat trafiko hilarekin. Sistemak beste aplikazioaren tunela erakusten du, zure kodeak daukan interfaze baten deskribatzailea duen bitartean.

Pauso 3: deitu protect connect aurretik

Interfazea existitzen denean, zure aplikazioak irekitzen dituen socketak tunelera bideratzen dira lehenespenez. Kanpoko garraioak ezin du arau hori bete, bestela kapsulatutako paketea interfazera itzuliko bailitzateke, beraz VpnService protect-ek socket bat markatzen du VPNa saihesteko eta azpiko sarea erabiltzeko. Deiak boolean bat itzultzen du, eta hura ez ikusteak osasuntsu dirudien eta ezer eramaten ez duen socket batekin amaitzeko bidea da.

Deitu protect connect edo bind aurretik, ez sekula ondoren. Babesak socket-a konektatu edo lotu aurretik egon behar du, konektatutako socket batek bere ibilbidea aukeratu baitu eta geroagoko protect-ek ez du modu fidagarrian mugitzen. protect-ek false itzultzen badu, gelditu eta berraztertu jabetza: huts egiten du interfazea zure aplikazioarena ez denean, eta horixe da beste VPN batek uzten duen egoera. false itzulera seinale bat da Pauso 1era itzultzeko, ez socket bera berriro saiatzeko.

DatagramSocket socket = new DatagramSocket();
if (!vpnService.protect(socket)) {
    return;
}
socket.connect(serverAddress, serverPort);

Pauso 4: lotu prozesu bat socket bat deserosoa denean

Garraio batzuk ez dira socket bakarra: liburutegi batek hainbat ireki ditzake, edo laguntza prozesu bateko konexio guztiek irteera bera erabiltzea nahi izan dezakezu. ConnectivityManager.bindProcessToNetwork-ek prozesua aukeratutako sarera lotzen du, eta zaharragoak zen setProcessDefaultNetwork-ek gauza bera egiten zuen zaharkitu baino lehen. Eskatu azpiko konexioa NET_CAPABILITY_NOT_VPN-rekin, lotzeak zure tunelaren azpiko sarea aukeratu dezan, ez tunela bera.

NetworkRequest request = new NetworkRequest.Builder()
    .addCapability(NetworkCapabilities.NET_CAPABILITY_INTERNET)
    .addCapability(NetworkCapabilities.NET_CAPABILITY_NOT_VPN)
    .build();

Prozesu bat lotzea ez da bigarren VPN bat. Prozesu horretarako irteera bat aukeratzen du, zure garraioarentzat erabilgarria eta bi tunel aldi berean exekutatzeko alferrikakoa.

Konpondu erabiltzailearen gailua, ez kodearen bidea

Ez dago bi aplikaziok VPN lekua partekatzeko modurik ematen duen APIrik, beraz konponbidea gailuaren egoeran dago. Eskaini erabiltzaileari bi bide zehatz: deskonektatu edo garbitu beste aplikazioaren beti martxan ezarpena, zure prepare-k har dezan, edo ireki aplikazio horren aplikazioko ezarpenak eta baztertu zure aplikazioa haren tunelatik. Bazterketak iragazkia martxan mantentzen du gainerako guztiarentzat eta zure aplikazioari ohiko konexioa erabiltzeko aukera ematen dio, eta hori da maiz erabiltzaileak benetan nahi duen emaitza.

Idatzi bi bideak zure laguntza dokumentazioan, erabiltzaileek gutxitan dakite zein aplikaziok duen VPNaren jabe. Eskatu iezazkiezu Ezarpenetatik VPN aktiboaren izena eta zure logetatik prepare, establish eta protect-en emaitzak, eta minutu batean esan ahal izango duzu zein pausok huts egin zuen. Gero egiaztatu trafiko errealarekin: izen bilaketa bat, TCP konexio bat eta tunelaren bidezko eskaera bat, ez soilik konektatutako ikono bat. Deskribatzaile baliogarri batek eta adierazle berde batek jabetza frogatzen dute gehienez ere, ez garraioak bideratze arauak gainditu dituenik.

Lau egiaztapenek gainditzen badute eta trafikoak hiltzen jarraitzen badu, jabetza ez da zure arazoa jada. Jarraitu bideratzera eta zerbitzariaren irisgarritasunera, eta probatu kredentzial berak VPN aplikaziorik instalatu gabe duen gailu batetik.