Az Android DNS helyes olvasása: hálózatonként, nem a resolv.conf-ban

Shellt kapsz az eszközön, elolvasod a /etc/resolv.conf-ot, vagy előásol egy régi net.dns1-értéket, és egy címet kapsz. Az előtted lévő alkalmazás egészen más úton old fel. A jelenlegi Android-kiadásban a resolver hálózatonként értendő: a rendszer minden Network számára szabályt tart, és azt arra a socketre alkalmazza, amely a kérést küldte. A fájl és a régi tulajdonság maradványok, és egyik sem írja le azt az utat, amelyet a lekérdezésed valójában megtett.

Ez a rés a split-tunnel és a Private DNS bevezetésekor látszik, ahol két alkalmazás ugyanazon a telefonon jogosan láthat eltérő válaszokat. Ez az útmutató a hibás vagy hiányzó feloldástól indul, és visszafelé halad a konfigurációig, amelyhez tartozik.

A resolver egy hálózathoz tartozik, nem az eszközhöz

A névfeloldás az Android 9 és újabb verzióiban egy rendszerresolveren keresztül történik, amely arra a Network-re támaszkodik, amelyhez a socket kötve van. Minden hálózat a saját LinkProperties-át hordozza, és ezek a tulajdonságok tartalmazzák a DNS-kiszolgálók listáját, a keresési tartományokat és a Private DNS állapotát csak arra a hálózatra. Ebben a modellben semmi sem felel meg egyetlen, az egész eszközre érvényes listának, amelyet fájlból olvashatnál.

A VPN nyilvánvalóvá teszi a szétválasztást. Amikor az alagút feljön, a VPN-alkalmazás olyan DNS-kiszolgálókat ad, amelyek a VPN saját hálózatán vannak regisztrálva, így a rajta keresztül irányított alkalmazások ezeken a kiszolgálókon oldanak fel, míg a kizárt alkalmazások továbbra is a mögöttes hálózatot használják. Egy eszköz, két válaszút, semmi ellentmondás.

Olvasd ki a pillanatképet az érintett alkalmazásból

Kérdezd meg magát az alkalmazást. Egy olyan metódus, amelynek van Context-je és a szokásos android.permission.ACCESS_NETWORK_STATE engedélye, rendszer tulajdonságainak érintése nélkül olvashatja ki a pillanatképet:

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 a folyamatod alapértelmezett hálózata, nem az egyetlen hálózat az eszközön, és null lehet, ha a hívónak nincs használható alapértelmezett hálózata. A blokkolt alapértelmezett VPN a szokásos ok. Az isPrivateDnsActive megmondja, hogy az adott hálózaton a lekérdezések TLS-en át egy megnevezett resolverhez mennek-e, ami megváltoztatja, mit mutat egy egyszerű UDP 53-os próba. Az API-felület a LinkProperties alatt van dokumentálva, és benne minden érték a konfiguráció pillanatképe, nem annak bizonyítéka, hogy egy adott lekérdezés elért egy adott kiszolgálót.

Amikor az alapértelmezett hálózat nem az, amely a munkát végzi

A pillanatkép csak az alapértelmezett hálózatról nyilatkozik. Egy alkalmazás a folyamatát vagy egyetlen socketet másik hálózathoz köthet, és akkor a feloldás ezt a választást követi, miközben a diagnosztikád továbbra is az alapértelmezettet jelenti. Egy saját DNS-over-HTTPS resolvert hozó böngésző egyáltalán nem kérdezi a rendszerlistát, így a válaszai semmit sem mondanak az eszköz többi részéről. Egy munkahelyi profilú alkalmazás külön felhasználó alatt fut, saját szabállyal. Ellenőrizd a kötést, mielőtt a kiszolgálókat hibáztatnád.

A VPN-integráció a másik fél. Egy dhcp-option DNS sor fogadása egy OpenVPN-profilban és annak a címnek az Android VPN-hálózatán való regisztrálása két külön lépés, és a kiszolgálóhoz hiányzó útvonal ugyanolyan csendesen vall kudarcot, mint egy rossz cím. Fejlesztői gépről az adb shell dumpsys connectivity ugyanazokat a kapcsolati tulajdonságokat nyomtatja hálózatonként, ha a build engedi, ami kód írása nélkül igazolja a listát.

Hasonlítsd össze a konfigurációt egyetlen feloldással, amelyet megtehetsz

Válassz egy nevet, amelynek a privát névtérben fel kell oldódnia, és egy nyilvános nevet, majd jegyezd fel mindkét eredményt a pillanatkép mellé: hálózat, beállított kiszolgálók, Private DNS állapot és a hiba pontos szövege. Egy megnevezett kiszolgálóhoz intézett közvetlen lekérdezés bizonyítja, hogy az a kiszolgáló válaszol neked; nem bizonyítja, hogy a szokásos alkalmazásfeloldás őt választotta. A gyorsítótárból származó válasz nem friss teszt, ezért ürítsd a gyorsítótárat, vagy használj olyan nevet, amelyre ma még senki nem kérdezett rá.

Ha a resolver csak egy adott hozzáférési hálózat ügyfeleit szolgálja ki, az, amit a VPN-kilépés után lát, eldöntheti az eredményt, és ez szabály kérdése annak, aki üzemelteti, nem annak bizonyítéka, hogy a szolgáltatók blokkolják az UDP 53-at. Ahol a Private DNS aktív, egy nem minősített gazdanév tervezés szerint elutasítható, miközben ugyanaz a kiszolgáló a nyilvános nevekre normálisan válaszol. A tulajdonságok olvasása megmondja, melyik mód van érvényben, így abbahagyod a csomagszűrők találgatását.

Javítsd ki azt a réteget, amelyhez az eltérés tartozik

Felfelé dolgozz a globális állapot szerkesztése helyett. Ha az alkalmazás a rossz hálózathoz van kötve, javítsd a kötést. Ha a profil rossz DNS-opciót ad, javítsd a profilt. Ha a Private DNS szigorú egy olyan hálózaton, amelynek resolvere nem tudja kiszolgálni a privát zónádat, az eszközkezelési döntés, nem ok arra, hogy a funkciót mindenhol kikapcsold.

A nyilvános resolverek DHCP-horogba vagy rendszertulajdonságba erőltetése az a javítás, amely folyamatosan incidenseket okoz: a privát nevek feloldása leáll, a változás túléli a VPN-munkamenetet, és az eszközön következő ember tulajdonos nélküli, elavult címet talál. Tartsd a változtatást a VPN-ben, az alkalmazásban vagy a kezelési rétegben, amelyhez az eltérés tartozik, majd olvasd ki újra a pillanatképet, hogy igazold: a kiszolgálólista tényleg megváltozott.

A végén egyetlen alkalmazáskérésre vágysz, amely egy hálózathoz, egy resolverlistához és egy Private DNS-állapothoz kapcsolódik. Ha meg tudod mutatni ezt a láncot, egy ismerős cím egy fájlban már semminek sem bizonyítéka.