Aplikacioni Android i zgjidh emrat jashtë VPN: listë kontrolli për lidhjen

Një aplikacion Android nuk arrin të zgjidhë një emër të brendshëm ndërsa shfletuesi i vetë klientit VPN e arrin atë, dhe i njëjti build funksionon në një telefon tjetër. URL-ja nuk është variabla. Variabla është rrjeti që procesit të aplikacionit i lejohet të përdorë për zgjidhje, dhe Android nuk garanton që VPN-i aktiv është rrjeti që përdorin socket-ët e tu. Kryej këto kontrolle me radhë dhe ndalu kur fotografia e resolver-it nuk përputhet me supozimin tënd.

Hapi 1: vërteto në cilin rrjet është aplikacioni

Lexo pamjen e vetë aplikacionit, jo shiritin e statusit. Nga ConnectivityManager merr rrjetin aktiv, LinkProperties e tij, listën e serverëve DNS dhe cilësimin e DNS privat. Nëse lista përmban resolver-in e VPN-it, aplikacioni ka një rrugë drejt tij; nëse përmban resolver-in e Wi-Fi, tuneli nuk është rrjeti i parazgjedhur për atë proces.

Një ikonë VPN thotë vetëm se ekziston një tunel. Nuk thotë se procesi i aplikacionit ishte lidhur me të, dhe Android nuk e drejton gjithmonë zgjidhjen e emrave përmes rrjetit që duket aktiv. Aplikacionet VPN lokale që përcjellin në një pajisje tjetër, rrjetet Wi-Fi pa internet dhe build-et e prodhuesve mund ta lënë aplikacionin të pyesë resolver-in e parazgjedhur në vend të serverëve të tunelit.

Hapi 2: kërko transportin VPN dhe lidh procesin

Kur aplikacioni duhet të përdorë resolver-in e tunelit, kërko një rrjet me transport VPN dhe lidh procesin në callback, që kodi të mos hamendësojë kur shfaqet rrjeti:

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

Thirrja ndryshon rrjetin e parazgjedhur të të gjithë procesit, kështu që çdo socket i krijuar më pas e përdor atë. Socket-ët që ekzistojnë tashmë mbajnë rrjetin në të cilin u krijuan, prandaj një grup lidhjesh i hapur para lidhjes mund të vazhdojë të zgjidhë përmes rrugës së vjetër. Vlera e kthyer është boolean, dhe një rezultat false do të thotë që lidhja nuk ndodhi; provo përsëri me një vonesë të shkurtër dhe regjistro të dyja përpjekjet.

Hapi 3: kufizo lidhjen në atë që i nevojitet

Lidhja e të gjithë procesit është e ashpër. Telemetria, kontrollet e përditësimit dhe SDK-të e palëve të treta kalojnë gjithashtu në tunel, dhe nëse tuneli nuk ka internet, ato fillojnë të dështojnë. Për një kërkesë të vetme, përdor fabrikën e socket-ëve të rrjetit dhe lëre parazgjedhjen e pajisjes për gjithçka tjetër. Zgjidh qëllimisht një model: lidhje e ngushtë për çdo lidhje, ose lidhje procesi me shkëputje të qartë kur VPN-i zhduket.

Dy veçori të resolver-it mund ta mundin lidhjen pa asnjë gabim. DNS privat në modalitetin e rreptë i dërgon kërkesat te një server DoT i emërtuar në vend të resolver-it të rrjetit, dhe një aplikacion që sjell klientin e vet DNS-over-HTTPS anashkalon plotësisht resolver-in e sistemit. Kontrollo të dyja përpara se të përfundosh që lidhja dështoi. Një kërkesë që nuk arrin kurrë te serveri DNS i VPN-it nuk do të shfaqet në asnjë log në anën e tunelit.

Hapi 4: mos i beso një kufizimi CONNECTED

NetworkType.CONNECTED në WorkManager do të thotë që një rrjet është i lidhur, dhe transporti VPN e plotëson atë edhe kur lidhja Wi-Fi ose celulare nën të ka humbur. Puna ekzekutohet, çdo kërkesë dështon, dhe politika e përsëritjes e shndërron atë në një stuhi që duket si një bug planifikimi. Tuneli është një rrjet; kufizimi nuk ishte kurrë një kontroll interneti.

Kontrollo aftësinë që puna i nevojitet vërtet, siç është aksesi i verifikuar në internet, dhe mbaj një politikë të kufizuar përsëritjeje me tërheqje. Nëse punës i duhet një emër privat, zgjidhe atë emër në rrjetin e zgjedhur përpara se ta kryesh punën, dhe dështo shpejt me një gabim të qartë në vend që të përsëritësh një kërkesë që nuk mund të ketë sukses.

Hapi 5: regjistro provat dhe ritesto gamën

Regjistro llojet e transportit të rrjetit të zgjedhur, serverët DNS nga LinkProperties, nëse lidhja ktheu true, dhe dështimin e saktë të kërkesës së parë. Më pas ekzekut një emër privat dhe një emër publik nën të njëjtën lidhje. Ai çift tregon nëse aplikacioni përdori resolver-in e tunelit ose ra në heshtje në parazgjedhjen e pajisjes, dhe kjo është ndryshimi që përjeton përdoruesi.

Përsërite në versionin më të vjetër të Android-it që mban dhe në një version aktual. Sjellja e resolver-it që e bën rrugën e parazgjedhur të duket e saktë është pikërisht ajo ku pajisjet dhe versionet ndryshojnë, dhe një build që kalon vetëm në pajisjen më të re testuese nuk është verifikuar për gamën që dërgon. adb shell dumpsys connectivity është një mënyrë e shpejtë për të konfirmuar cilat rrjete dhe aftësi raporton pajisja ndërsa riprodhoni dështimin.