Android aplikacija razrješava imena izvan VPN-a: popis provjera za povezivanje

Android aplikacija ne uspijeva razriješiti interno ime dok preglednik samog VPN klijenta do njega dolazi, a ista se gradnja ispravno ponaša na drugom telefonu. URL nije varijabla. Varijabla je kojoj mreži proces aplikacije smije koristiti za razrješavanje, a Android ne jamči da je aktivni VPN onaj koji koriste vaši socketi. Prođite ove provjere redom i zaustavite se kada se snimka resolvera ne slaže s vašom pretpostavkom.

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

Čitajte vlastiti pogled aplikacije, a ne statusnu traku. Iz ConnectivityManager dohvatite aktivnu mrežu, njezine LinkProperties, popis DNS poslužitelja i postavku privatnog DNS-a. Ako popis sadrži resolver VPN-a, aplikacija ima put do njega; ako sadrži Wi-Fi resolver, tunel nije zadana mreža za taj proces.

Ikona VPN-a govori samo da tunel postoji. Ne govori da je proces aplikacije bio vezan uz njega, a Android ne usmjerava uvijek razrješavanje imena kroz mrežu koja izgleda aktivno. Lokalne VPN aplikacije koje prosljeđuju promet drugom uređaju, Wi-Fi mreže bez interneta i tvorničke gradnje mogu ostaviti aplikaciju da pita zadani resolver umjesto poslužitelja tunela.

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

Kada aplikacija mora koristiti resolver tunela, zatražite mrežu s VPN transportom i povežite proces u povratnom pozivu, kako kod ne bi nagađao 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 mijenja zadanu mrežu cijelog procesa, pa svaki socket stvoren nakon toga nju koristi. Socketi koji već postoje zadržavaju mrežu na kojoj su stvoreni, zato skup veza otvoren prije povezivanja može nastaviti razrješavati kroz stari put. Povratna vrijednost je boolean, a rezultat false znači da se povezivanje nije dogodilo; pokušajte ponovno s kratkom odgodom i zabilježite oba pokušaja.

Korak 3: Ograničite povezivanje na ono što ga treba

Povezivanje cijelog procesa je grubo. Telemetrija, provjere ažuriranja i SDK trećih strana također prelaze na tunel, a ako tunel nema interneta, počinju otkazivati. Za jedan zahtjev upotrijebite socket tvornicu mreže, a sve ostalo ostavite na zadanoj vrijednosti uređaja. Namjerno odaberite jedan model: usko povezivanje po vezi ili povezivanje procesa s izričitim odvezivanjem kada VPN nestane.

Dvije značajke resolvera mogu pobijediti povezivanje bez ikakve pogreške. Privatni DNS u strogom načinu šalje upite imenovanom DoT poslužitelju umjesto resolveru mreže, a aplikacija koja donosi vlastiti DNS-over-HTTPS klijent potpuno zaobilazi sistemski resolver. Provjerite oboje prije nego zaključite da je povezivanje neuspješno. Upit koji nikada ne stigne do DNS poslužitelja VPN-a neće se pojaviti ni u jednom dnevniku na strani tunela.

Korak 4: Ne vjerujte ograničenju CONNECTED

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

Provjerite mogućnost koja poslu stvarno treba, poput potvrđenog pristupa internetu, i držite ograničenu politiku ponavljanja s odgodom. Ako poslu treba privatno ime, razriješite to ime u odabranoj mreži prije obavljanja posla i brzo otkažite s jasnom pogreškom umjesto ponavljanja zahtjeva koji ne može uspjeti.

Korak 5: Zabilježite dokaze i ponovno provjerite raspon

Zabilježite vrste transporta odabrane mreže, DNS poslužitelje iz LinkProperties, je li povezivanje vratilo true i točan neuspjeh prvog zahtjeva. Zatim pokrenite privatno ime i javno ime pod istim povezivanjem. Taj par pokazuje je li aplikacija koristila resolver tunela ili je tiho pala na zadanu vrijednost uređaja, a to je razlika koju korisnik osjeća.

Ponovite na najstarijoj Android verziji koju podržavate i na jednom aktualnom izdanju. Ponašanje resolvera zbog kojeg zadani put izgleda ispravno upravo je mjesto gdje se uređaji i verzije razlikuju, a gradnja koja prolazi samo na najnovijem testnom uređaju nije provjerena za raspon koji isporučujete. adb shell dumpsys connectivity brz je način da potvrdite koje mreže i mogućnosti uređaj prijavljuje dok reproducirate kvar.