Android DNS ondo irakurri: sarearen arabera, ez resolv.conf

Shell bat lortzen duzu gailuan, /etc/resolv.conf irakurtzen duzu edo net.dns1 balio zaharra ateratzen duzu, eta helbide bat lortzen duzu. Aurrean duzun aplikazioak beste zerbait erabat desberdinaren bidez ebazten du. Egungo Android bertsio batean resolver-a sareko da: sistemak Network bakoitzeko politika bat gordetzen du eta eskaera egin zuen socket-ari aplikatzen dio. Fitxategia eta propietate zaharra hondarrak dira, eta batek ere ez du deskribatzen zure galderak benetan hartu zuen bidea.

Tarte hori split-tunnel eta Private DNS inplementazioetan agertzen da, non telefono bereko bi aplikaziok legez ikus ditzaketen erantzun desberdinak. Ibilbide hau okerra edo falta den ebazpenetik abiatzen da eta hura duen konfiguraziora atzera egiten du.

Resolver-a sare batena da, ez gailuarena

Android 9 eta geroagoko izen-ebazpena socket bat lotuta dagoen Network-ean oinarritzen den sistema-resolver baten bidez egiten da. Sare bakoitzak bere LinkProperties ditu, eta propietate horiek DNS zerrenda, bilaketa-domeinuak eta Private DNS egoera sare horretarako soilik gordetzen dituzte. Eredu horretan ezerk ez du fitxategi batetik irakur dezakezun gailu osorako zerrenda bakar batekin bat egiten.

VPN batek banaketa begi-bistakoa egiten du. Tunela altxatzen denean, VPN aplikazioak VPN-aren sare propioan erregistratutako DNS zerbitzariak ematen ditu, beraz haren bidez bideratutako aplikazioak zerbitzari horien aurka ebazten dira, kanpoan utzitako aplikazioek azpiko sarea erabiltzen jarraitzen duten bitartean. Gailu bat, bi erantzun-bide, kontraesanik ez.

Hartu argazkia eragindako aplikazioaren barnetik

Galdetu aplikazioari berari. Context bat eta ohiko android.permission.ACCESS_NETWORK_STATE baimena dituen metodo batek argazkia irakur dezake sistemaren propietateak ukitu gabe:

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 zure prozesuaren lehenetsia da, ez gailuko sare bakarra, eta null izan daiteke deitzaileak lehenetsi erabilgarririk ez duenean. Blokeatutako VPN lehenetsia da ohiko arrazoia. isPrivateDnsActive sare horretako galderak TLS bidez resolver izendatu batera doazen ala ez esaten dizu, eta horrek aldatu egiten du UDP 53 zunda soil batek erakutsiko duena. API azalera LinkProperties azpian dago dokumentatuta, eta bertako balio bakoitza konfigurazioaren argazkia da, ez galdera jakin batek zerbitzari jakin batera iritsi zela frogatzen duenik.

Lehenetsitako sarea lana egiten duena ez denean

Argazkiak lehenetsiari erantzuten dio soilik. Aplikazio batek bere prozesua edo socket bakarra beste sare batera lot dezake, eta orduan ebazpenak aukera horri jarraitzen dio zure diagnostikoak lehenetsia salatzen jarraitzen duen bitartean. Bere DNS-over-HTTPS resolver propioa dakarren nabigatzaileak ez du inoiz sistemaren zerrenda kontsultatzen, beraz haren erantzunek ez dute ezer esaten gailuaren gainerakoari buruz. Lan-profilaren aplikazio bat beste erabiltzaile batekin eta bere politikarekin exekutatzen da. Egiaztatu lotura zerbitzariei errua bota aurretik.

VPN integrazioa beste erdia da. dhcp-option DNS lerro bat OpenVPN profil batean jasotzea eta helbide hori Android VPN sarean erregistratzea bi urrats bereizi dira, eta zerbitzarirako biderik ez egoteak huts egiten du helbide oker batek bezain isilki. Garapen-makina batetik, adb shell dumpsys connectivity saresteko link propietate berdinak inprimatzen ditu build-ak uzten duenean, eta horrek zerrenda baieztatzen du koderik idatzi gabe.

Konfigurazioa egin dezakezun ebazpen batekin alderatu

Aukeratu espazio pribatuan ebazten derrigorrezkoa den izen bat eta izen publiko bat, eta idatzi bi emaitzak argazkiaren ondoan: sarea, konfiguratutako zerbitzariak, Private DNS egoera eta errore-testu zehatza. Zerbitzari izendatu baterako kontsulta zuzen batek frogatzen du zerbitzari horrek erantzuten dizula; ez du frogatzen ohiko aplikazio-ebazpenak hura aukeratu zuenik. Cachean dagoen erantzuna ez da proba berria, beraz hustu cachea edo erabili gaur inork galdetu ez duen izen bat.

Resolver-ak sarbide-sare jakin bateko bezeroei soilik zerbitzatzen badie, VPN irteeraren ondoren ikusten duenak erabaki dezake emaitza, eta hori hura kudeatzen duenarentzako politika-kontua da, ez operadoreek UDP 53 blokeatzen duten froga. Private DNS aktibo dagoen tokian, host-izen kualifikatu gabea diseinuz uztar daiteke, zerbitzari berak izen publikoak normaltasunez erantzuten dituen bitartean. Propietateak irakurtzeak zein modu dagoen indarrean esaten dizu, beraz pakete-iragazkiei buruz susmoak hartzeari uzten diozu.

Desadostasuna duen geruza konpondu

Gorantz egin, egoera globala editatu beharrean. Aplikazioa sare okerrean lotuta badago, konpondu lotura. Profilak DNS aukera okerra dakarrenean, konpondu profila. Private DNS zurruna bada zure zona pribatua zerbitzatu ezin duen resolver-a duen sare batean, gailuen kudeaketaren erabakia da, ez funtzioa nonahi itzaltzeko arrazoia.

Resolver publikoak DHCP kako batean edo sistema-propietate batean behartzea da etengabe gertaerak eragiten dituen konponketa: izen pribatuak ebazteari uzten diote, aldaketak VPN saioa gainditzen du, eta gailuan hurrengo pertsonak jabe gabeko helbide zaharkitua aurkitzen du. Mantendu aldaketa desadostasuna duen VPN, aplikazio edo kudeaketa-geruzaren barruan, eta gero irakurri berriro argazkia zerbitzari-zerrenda benetan aldatu zela baieztatzeko.

Azkenean nahi duzuna sare batekin, resolver zerrenda batekin eta Private DNS egoera batekin lotutako aplikazio-eskaera bat da. Kate hori erakutsi ahal duzunean, fitxategi bateko helbide ezaguna ez da ezeren froga izateari uzten dio.