In Android-app lost nammen bûten de VPN op: in checklist foar it binen

Android kin fia it standertnetwurk oplosse wylst in VPN aktyf is. Bin it proses oan it VPN-netwurk en kontrolearje hokker resolver de app echt brûkt hat.

In Android-app slagget der net yn in ynterne namme op te lossen, wylst de browser fan de VPN-klant dy namme wol berikt, en deselde build wurket op in oare telefoan. De URL is net de fariabele. De fariabele is hokker netwurk it app-proses foar resolúsje brûke mei, en Android garandearret net dat de aktive VPN itselde netwurk is as dat jo sockets brûke. Wurkje dizze kontrôles yn folchoarder ôf en stopje sadree’t as de resolver-snapshot net mei jo oanname oerienkomt.

Stap 1: bewize op hokker netwurk de app sit

Lês de eigen werjeft e app rather as de statusbalke. Helje fan ConnectivityManager it aktive netwurk, syn LinkProperties, de list fan DNS-servers en de private-DNS-ynstelling op. Sit de resolver fan de VPN yn dy list, dan hat de app in paad derhinne; sit de resolver fan de Wi-Fi der yn, dan is de tunnel net it standertnetwurk fan dat proses.

In VPN-ikoan seit allinnich dat der in tunnel is. It seit net dat it proses fan de app der oan bûn is, en Android rjochtet nammeresolúsje net altyd oer it netwurk dat aktyf liket. Lokale VPN-apps dy’t nei in oar apparaat trochstjoere, Wi-Fi-netwurken sûnder internet en builds fan fabrikanten kinne in app allegear by de standertresolver bringe ynstee fan by de servers fan de tunnel.

Stap 2: freegje it VPN-transport oan en bin it proses

As de app de resolver fan de tunnel brûke moat, freegje dan in netwurk mei it VPN-transport oan en bin it proses yn de callback, sadat de koade net gisket wannear’t it netwurk ferskynt:

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)
    }
})

De oprop feroaret it standertnetwurk fan it hiele proses, sadat elke socket dy’t letter makke wurdt it brûkt. Sockets dy’t al besteane hâlde it netwurk dêr’t se op makke binne, en dêrom kin in ferbiningspool dy’t foar it binen iepene is noch altyd fia it âlde paad oplosse. De weromjefte is in boolean, en in resultaat false betsjut dat it binen net bard is; besykje it opnij nei in koarte skoft en log beide pogingen.

Stap 3: behein it binen ta wat it nedich hat

Binen op prosesnivo is grof. Telemetry, fernijingskontrôles en SDK’s fan tredden geane ek oer de tunnel, en as de tunnel gjin internet hat begjinne se te mislearjen. Brûk foar ien inkeld fersyk de socketfabryk fan it netwurk en hâld de apparaatstandert foar al it oare. Kies bewust ien model: in smel binen per ferbining, of in binen fan it proses mei in eksplisite loskeppeling as de VPN ferdwynt.

Twa resolverfunksjes kinne it binen sûnder ien flater ûnderfine. Private DNS yn strikte modus stjoert fragen nei in neamde DoT-server ynstee fan nei de resolver fan it netwurk, en in app mei in eigen DNS-over-HTTPS-klant giet hielendal bûten de systeemresolver om. Kontrolearje beide foar’t jo konkludearje dat it binen mislearre is. In fraach dy’t nea by de DNS-server fan de VPN komt, sil yn gjin inkeld log oan tunnelkant ferskine.

Stap 4: fertrou gjin CONNECTED-beheining

NetworkType.CONNECTED fan WorkManager betsjut dat der in netwurk ferbûn is, en it VPN-transport foldocht dêroan sels as de ûnderlizzende Wi-Fi- of mobylferbining fuort is. De taak rint, elk fersyk mislearret, en it opnijbesykjen belied makket der in stoarm fan dy’t op in planningsbug liket. De tunnel is in netwurk; de beheining wie nea in internetkontrôle.

Kontrolearje de kapasiteit dy’t it wurk echt nedich hat, lykas falidearre internettagong, en hâld in beheind opnijbesykjen belied mei backoff. As de taak in private namme nedich hat, los dy namme dan op yn it keazen netwurk foar’t jo it wurk dogge, en mislearje fluch mei in dúdlike flater ynstee fan in fersyk te werheljen dat net slagje kin.

Stap 5: lis de bewiis fêst en test it berik opnij

Log de transporttypen fan it keazen netwurk, de DNS-servers út LinkProperties, oft it binen true weromjoech, en de krekte flater fan it earste fersyk. Rin dan in private namme en in publike namme ûnder itselde binen ôf. Dat pear lit sjen oft de app de tunnelresolver brûkt hat of stilwei weromfoel op de apparaatstandert, en dat is krekt it ferskil dat de brûker merkt.

Werhelje dit op de âldste Android-ferzje dy’t jo stypje en op ien aktuele útjefte. It resolverskgedrach dat it standertpaad korrekt lykje lit, is krekt dêr’t apparaten en ferzjes ferskille, en in build dy’t allinnich op it nijste testapparaat slagget is net ferifiearre foar it berik dat jo leverje. adb shell dumpsys connectivity is in flugge manier om te befêstigjen hokker netwurken en kapasiteiten it apparaat meldt wylst jo de flater reprodusearje.

Relatearre artikelen