Lexo DNS-në e Android saktë: për rrjet, jo në resolv.conf

Merr një shell në pajisje, lexon /etc/resolv.conf ose nxjerr një vlerë të vjetër net.dns1, dhe merr një adresë. Aplikacioni përpara teje zgjidh përmes diçkaje krejt tjetër. Në një version aktual të Android resolver-i është për rrjet: sistemi mban një politikë për çdo Network dhe e zbaton atë në socket-in që bëri kërkesën. Skedari dhe vetia e vjetër janë mbetje, dhe asnjëri prej tyre nuk përshkruan rrugën që mori në të vërtetë kërkesa jote.

Ky hendek shfaqet gjatë vendosjes së split-tunnel dhe Private DNS, ku dy aplikacione në të njëjtin telefon mund të shohin legjitimisht përgjigje të ndryshme. Ky udhëzim nis nga zgjidhja e gabuar ose që mungon dhe shkon mbrapsht te konfigurimi që e zotëron atë.

Resolver-i i përket një rrjeti, jo pajisjes

Zgjidhja e emrave në Android 9 dhe më vonë kalon përmes një resolver-i sistemi që bazohet në Network-in me të cilin është lidhur një socket. Çdo rrjet mbart LinkProperties e vet, dhe ato veti përmbajnë listën e serverëve DNS, domenet e kërkimit dhe gjendjen e Private DNS vetëm për atë rrjet. Asgjë në atë model nuk korrespondon me një listë të vetme për të gjithë pajisjen që mund ta lexosh nga një skedar.

Një VPN e bën ndarjen të dukshme. Kur tuneli ngrihet, aplikacioni VPN furnizon serverë DNS të regjistruar në rrjetin e vet të VPN-së, kështu që aplikacionet e drejtuara përmes tij zgjidhin te ata serverë, ndërsa aplikacionet e përjashtuara vazhdojnë të përdorin rrjetin themelor. Një pajisje, dy rrugë përgjigjeje, pa kundërshtim.

Lexo fotografinë nga brenda aplikacionit të prekur

Pyet vetë aplikacionin. Një metodë që ka një Context dhe lejen normale android.permission.ACCESS_NETWORK_STATE mund ta lexojë fotografinë pa prekur vetitë e sistemit:

val cm = getSystemService(ConnectivityManager::class.java) ?: return
val network = cm.activeNetwork
val links = network?.let { cm.getLinkProperties(it) }

val dnsServers = links?.dnsServers
val privateDnsActive = links?.isPrivateDnsActive
val privateDnsName = links?.privateDnsServerName

activeNetwork është parazgjedhja për procesin tënd, jo rrjeti i vetëm në pajisje, dhe mund të jetë null kur thirrësi nuk ka një parazgjedhje të përdorshme. Një VPN parazgjedhje e bllokuar është arsyeja e zakonshme. isPrivateDnsActive të tregon nëse kërkesat në atë rrjet shkojnë përmes TLS te një resolver i emërtuar, gjë që ndryshon atë që do të tregojë një provë e thjeshtë UDP 53. Sipërfaqja e API-t është dokumentuar te LinkProperties, dhe çdo vlerë në të është një fotografi e konfigurimit, jo provë se një kërkesë e caktuar arriti te një server i caktuar.

Kur rrjeti i parazgjedhur nuk është ai që bën punën

Fotografia përgjigjet vetëm për parazgjedhjen. Një aplikacion mund ta lidhë procesin ose një socket të vetëm me një rrjet tjetër, dhe atëherë zgjidhja ndjek atë zgjedhje, ndërsa diagnostikimi yt vazhdon të raportojë parazgjedhjen. Një shfletues që sjell resolver-in e vet DNS-over-HTTPS nuk e konsulton fare listën e sistemit, kështu që përgjigjet e tij nuk thonë asgjë për pjesën tjetër të pajisjes. Një aplikacion i profilit të punës ekzekutohet nën një përdorues të veçantë me politikën e vet. Kontrollo lidhjen para se t’u vësh fajin serverëve.

Integrimi i VPN është gjysma tjetër. Marrja e një rreshti dhcp-option DNS në një profil OpenVPN dhe regjistrimi i asaj adrese në rrjetin VPN të Android janë dy hapa të veçantë, dhe një rrugë që mungon drejt serverit dështon po aq në heshtje sa një adresë e gabuar. Nga një makinë zhvillimi, adb shell dumpsys connectivity printon të njëjtat veti lidhjeje për rrjet kur build-i e lejon, gjë që e konfirmon listën pa shkruar kod.

Krahaso konfigurimin me një zgjidhje që të lejohet ta bësh

Zgjidh një emër që duhet të zgjidhet brenda hapësirës private dhe një emër publik, dhe shëno të dy rezultatet pranë fotografisë: rrjeti, serverët e konfiguruar, gjendja e Private DNS dhe teksti i saktë i gabimit. Një kërkesë e drejtpërdrejtë te një server i emërtuar provon se ai server të përgjigjet; nuk provon se zgjidhja normale e aplikacionit e zgjodhi atë. Një përgjigje në cache nuk është provë e re, prandaj pastro cache-in ose përdor një emër që askush nuk e ka kërkuar sot.

Nëse resolver-i u shërben vetëm klientëve nga një rrjet i caktuar aksesi, ajo që sheh pas daljes nga VPN mund të vendosë rezultatin, dhe kjo është çështje politike për atë që e drejton, jo provë se operatorët bllokojnë UDP 53. Aty ku Private DNS është aktiv, një emër hosti i pakualifikuar mund të refuzohet sipas dizajnit, ndërsa i njëjti server u përgjigjet normalisht emrave publikë. Leximi i vetive të tregon cili regjim është në fuqi, kështu që nuk hamendëson më filtra paketash.

Rregullo shtresën që zotëron mospërputhjen

Puno lart në vend që të redaktosh gjendjen globale. Nëse aplikacioni është lidhur me rrjetin e gabuar, rregullo lidhjen. Nëse profili sjell opsionin e gabuar DNS, rregullo profilin. Nëse Private DNS është i rreptë në një rrjet, resolver-i i të cilit nuk mund t’i shërbejë zonës tënde private, ai është vendim i menaxhimit të pajisjes dhe jo arsye për ta fikur funksionin kudo.

Të detyrosh resolver-ë publikë në një grep DHCP ose në një veti sistemi është rregullimi që vazhdon të shkaktojë incidente: emrat privatë ndalojnë së zgjidhuri, ndryshimi i mbijeton sesionit të VPN, dhe personi tjetër në pajisje gjen një adresë të vjetruar pa pronar. Mbaje ndryshimin brenda VPN-së, aplikacionit ose shtresës së menaxhimit që zotëron mospërputhjen, dhe pastaj rilexo fotografinë për të konfirmuar se lista e serverëve ndryshoi vërtet.

Ajo që do në fund është një kërkesë aplikacioni e lidhur me një rrjet, një listë resolver-ësh dhe një gjendje Private DNS. Pasi të mund ta tregosh atë zinxhir, një adresë e njohur në një skedar nuk është më provë për asgjë.