Android-App léist Nimm baussent der VPN: Checkliste fir d'Bindung

Android kann iwwer de Standardnetzwierk Nimm léisen, och wann d'VPN aktiv ass. Bind de Prozess un de VPN-Netz a kontrolléier, wéi en Resolver d'App tatsächlech benotzt huet.

Eng Android-App kritt en internen Numm net geléist, wärend de Browser vum VPN-Client selwer en erreecht, an déiselwecht Build schafft op engem aneren Telefon. D'URL ass net d'Variabel. D'Variabel ass, wéi en Netzwierk dem App-Prozess fir d'Léisung erlaabt ass, an Android garantéiert net, datt déi aktiv VPN dee selwechten Netzwierk ass, deen deng Sockets benotzen. Maach dës Kontrollen an der Rei an hal op, wou de Resolver-Snapshot net mat denger Unhuel passt.

Schrëtt 1: Beweis, op wéi engem Netzwierk d'App ass

Lies d'App hir eege Vue an net d'Statusleiste. Vun ConnectivityManager aus huel dee aktiven Netzwierk, seng LinkProperties, d'Lëscht vun den DNS-Serveren an d'Astellung fir de private DNS. Wann d'Lëscht de Resolver vun der VPN enthält, huet d'App e Wee dohinner; wann se de Resolver vum Wi-Fi enthält, ass den Tunnel net den Standardnetzwierk fir dee Prozess.

Eng VPN-Ikon seet just, datt en Tunnel existéiert. Se seet net, datt den App-Prozess un en gebonnen war, an Android leet d'Nimm-Léisung net ëmmer iwwer dee Netzwierk, deen aktiv ausgesäit. Lokal VPN-Appen, déi op en anert Apparat weiderleeden, Wi-Fi-Netzwierker ouni Internet a Vendor-Buildë kënnen d'App dozou bréngen, de Standardresolver ze froen amplaz vun de Serveren vum Tunnel.

Schrëtt 2: Fuer de VPN-Transport un a bind de Prozess

Wann d'App de Resolver vum Tunnel benotze muss, fuer en Netzwierk mat VPN-Transport un a bind de Prozess am Callback, sou datt de Code net rodet, wéini den Netzwierk erschéngt:

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

Den Opruff ännert den Standardnetzwierk vum ganze Prozess, dofir benotzt all Socket, deen duerno entsteet, deen. Sockets, déi schonn existéieren, behalen den Netzwierk, op deem se erstallt goufen, dofir kann e Verbindungspool, deen virun der Bindung opgemaach gouf, weider iwwer de ale Wee léisen. Den zeréckginnene Wäert ass e Boolean, an e Resultat vun false heescht, datt d'Bindung net geschitt ass; probéier et mat enger kuerzer Verzögerung nach eng Kéier a log béid Versich.

Schrëtt 3: Begrenz d'Bindung op dat, wat se brauch

D'Bindung vum ganze Prozess ass grob. Telemetrie, Update-Kontrollen an SDKë vun Drëtten zéien och op den Tunnel, an wann den Tunnel keen Internet huet, fänken se u feelzeschloen. Fir eng eenzeg Demande benotz d'Socket-Fabrik vum Netzwierk a looss de Standard vum Apparat fir alles anescht. Wiel bewosst ee Modell: eng schmuel Bindung pro Verbindung, oder eng Prozessbindung mat engem kloeren Unbind, wann d'VPN verschwënnt.

Zwee Funktioune vum Resolver kënnen d'Bindung ouni all Feeler aushebielen. De private DNS am strikte Modus schéckt d'Ufroen un en ernannten DoT-Server amplaz un den Resolver vum Netzwierk, an eng App, déi hire eegene DNS-over-HTTPS-Client matbréngt, ëmgeet de Systemresolver komplett. Kontrolléier béid, ier s du schléiss, datt d'Bindung feelgeschloe huet. Eng Ufro, déi ni beim DNS-Server vun der VPN ukommt, erschéngt an engem Log op der Tunnelsäit.

Schrëtt 4: Verlooss dech net op d'CONNECTED-Bedingung

NetworkType.CONNECTED am WorkManager heescht, datt en Netzwierk verbonnen ass, an den VPN-Transport erfëllt dat och, wann de Wi-Fi- oder Mobilfunk-Link drënner fort ass. Den Job leeft, all Demande feelt, an d'Retry-Politik mécht eng Stuerm doraus, déi wéi e Planungsfeeler ausgesäit. Den Tunnel ass en Netzwierk; d'Bedingung war ni eng Internetkontroll.

Kontrolléier d'Kapazitéit, déi d'Aarbecht wierklech brauch, zum Beispill validéierten Internetzougang, a behal eng begrenzt Retry-Politik mat Backoff. Wann d'Aarbecht en private Numm brauch, léis deen Numm am gewielten Netzwierk, ier s d'Aarbecht méchs, a schléiss séier mat engem kloere Feeler of, amplaz eng Demande ze widderhuelen, déi net kann erfollegräich sinn.

Schrëtt 5: Hal d'Beweiser fest a test de Beräich nach emol

Log d'Transporttype vum gewielten Netzwierk, d'DNS-Serveren aus LinkProperties, ob d'Bindung true zréckginn huet, an den exakte Feeler vun der éischter Demande. Da fuer e private Numm an en ëffentlechen Numm ënner der selwechter Bindung. Dat Paar weist, ob d'App de Resolver vum Tunnel benotzt huet oder still op de Standard vum Apparat zréckgefall ass, an dat ass den Ënnerscheed, deen de Benotzer erlieft.

Widderhuel et op der eelster Android-Versioun, déi s du ënnerstëtzen, an op enger aktueller Release. D'Verhalen vum Resolver, dat den Standardwee richteg ausgesäit, ass genee do, wou Apparater a Versiounen sech ënnerscheeden, an eng Build, déi just um neiste Testapparat duerchkënnt, ass net fir de Beräich verifizéiert, deen s du verschécks. adb shell dumpsys connectivity ass eng séier Manéier ze bestätegen, wéi eng Netzwierker a Kapazitéiten den Apparat mellt, wärend s de Feeler reproduzéiers.

Ähnlech Artikelen