Android aplikacija ne uspeva da razreši interno ime dok pregledač samog VPN klijenta do njega stiže, a isto se izdanje ispravno ponaša na drugom telefonu. URL nije promenljiva. Promenljiva je kojoj mreži proces aplikacije sme da koristi za razrešavanje, a Android ne garantuje da je aktivni VPN onaj koji koriste vaši soketi. Prođite ove provere redom i zaustavite se kada se snimak resolvera ne slaže sa vašom pretpostavkom.

Korak 1: dokažite na kojoj je mreži aplikacija

Čitajte sopstveni prikaz aplikacije, a ne statusnu traku. Iz ConnectivityManager uzmite aktivnu mrežu, njene LinkProperties, spisak DNS servera i podešavanje privatnog DNS-a. Ako spisak sadrži resolver VPN-a, aplikacija ima put do njega; ako sadrži Wi-Fi resolver, tunel nije podrazumevana mreža za taj proces.

Ikona VPN-a govori samo da tunel postoji. Ne govori da je proces aplikacije bio vezan za njega, a Android ne usmerava uvek razrešavanje imena kroz mrežu koja izgleda aktivno. Lokalne VPN aplikacije koje prosleđuju drugom uređaju, Wi-Fi mreže bez interneta i izdanja proizvođača mogu ostaviti aplikaciju da pita podrazumevani resolver umesto servera tunela.

Korak 2: zatražite VPN transport i povežite proces

Kada aplikacija mora da koristi resolver tunela, zatražite mrežu sa VPN transportom i povežite proces u povratnom pozivu, da kod ne nagađa kada se mreža pojavi:

val request = NetworkRequest.Builder()
    .addTransportType(NetworkCapabilities.TRANSPORT_VPN)
    .build()

connectivityManager.requestNetwork(request, object : NetworkCallback() {
    override fun onAvailable(network: Network) {
        val bound = connectivityManager.bindProcessToNetwork(network)
        Log.i(TAG, "bound to VPN network: " + bound)
    }
})

Poziv menja podrazumevanu mrežu celog procesa, pa svaki socket stvoren posle toga koristi nju. Socketi koji već postoje zadržavaju mrežu na kojoj su stvoreni, zato skup veza otvoren pre povezivanja može nastaviti da razrešava starim putem. Povratna vrednost je boolean, a rezultat false znači da se povezivanje nije dogodilo; pokušajte ponovo sa kratkom pauzom i zabeležite oba pokušaja.

Korak 3: ograničite povezivanje na ono čemu je potrebno

Povezivanje celog procesa je grubo. Telemetrija, provere ažuriranja i SDK trećih strana takođe prelaze na tunel, a ako tunel nema internet, počinju da otkazuju. Za jedan zahtev upotrebite fabriku soketa mreže, a sve ostalo ostavite na podrazumevanoj vrednosti uređaja. Namerno izaberite jedan model: usko povezivanje po vezi ili povezivanje procesa sa izričitim odvezivanjem kada VPN nestane.

Dve osobine resolvera mogu pobediti povezivanje bez ikakve greške. Privatni DNS u strogom režimu šalje upite imenovanom DoT serveru umesto resolveru mreže, a aplikacija koja donosi sopstveni DNS-over-HTTPS klijent potpuno zaobilazi sistemski resolver. Proverite oboje pre nego što zaključite da je povezivanje neuspešno. Upit koji nikada ne stigne do DNS servera VPN-a neće se pojaviti ni u jednom dnevniku na strani tunela.

Korak 4: ne verujte ograničenju CONNECTED

NetworkType.CONNECTED u WorkManageru znači da je mreža povezana, a VPN transport ga zadovoljava i kada je osnovna Wi-Fi ili mobilna veza nestala. Posao se izvršava, svaki zahtev ne uspeva, a politika ponavljanja pretvara to u oluju koja izgleda kao greška u raspoređivanju. Tunel je mreža; ograničenje nikada nije bilo provera interneta.

Proverite mogućnost koja poslu zaista treba, poput potvrđenog pristupa internetu, i držite ograničenu politiku ponavljanja sa odlaganjem. Ako poslu treba privatno ime, razrešite to ime u izabranoj mreži pre obavljanja posla i brzo otkažite sa jasnom greškom umesto da ponavljate zahtev koji ne može uspeti.

Korak 5: zabeležite dokaze i ponovo proverite opseg

Zabeležite vrste transporta izabrane mreže, DNS servere iz LinkProperties, da li je povezivanje vratilo true i tačan neuspeh prvog zahteva. Zatim pokrenite privatno ime i javno ime pod istim povezivanjem. Taj par pokazuje da li je aplikacija koristila resolver tunela ili je tiho pala na podrazumevanu vrednost uređaja, a to je razlika koju korisnik oseća.

Ponovite na najstarijoj Android verziji koju podržavate i na jednom aktuelnom izdanju. Ponašanje resolvera zbog kojeg podrazumevani put izgleda ispravno upravo je mesto gde se uređaji i verzije razlikuju, a izdanje koje prolazi samo na najnovijem testnom uređaju nije provereno za opseg koji isporučujete. adb shell dumpsys connectivity je brz način da potvrdite koje mreže i mogućnosti uređaj prijavljuje dok reprodukujete kvar.

Povezani članci