Az alkalmazások nem tudnak feloldani egy nevet, miközben az alagút csatlakozva marad, és minden más jelző egészségesnek látszik. Telefonon a szokásos ok egy feloldó, amelyet az eszköz választ, nem a VPN-profil. Két beállítás is igényt tarthat ugyanarra a lekérdezésre. Kideríteni, melyik nyer, és hogy egyáltalán meg tud-e válaszolni a kérdést, gyorsabb, mint az alagúthoz nyúlni.

Két beállítás dönt ugyanarról a névről

A telefon Private DNS beállítása feloldót választ az eszköznek, az automatikus választástól a megnevezett gépnévig terjedő módokban. A VPN-profil ugyanakkor a saját feloldóját is kényszerítheti, és a kettőt különböző képernyőkön, különböző tulajdonosok állítják be. Egyik sem feltétlenül írja felül a másikat minden alkalmazásnál. Ezért létezhet egymás mellett működő alagút és sikertelen lekérdezés ellentmondás nélkül.

A böngésző harmadik réteget adhat hozzá, mert a böngészőn belüli biztonságos DNS saját szolgáltatót választhat. A hibát előidéző alkalmazás az egyetlen megbízható útmutató arra, hogy a három közül melyik válaszolt. A feloldónak is tudnia kell válaszolni. Egy csak vállalaton belüli név nincs benne egy nyilvános feloldó adataiban, ezért a lekérdezés a tartalom miatt hiúsul meg, nem a kapcsolat miatt.

A szükséges nevek szerint válassza meg a módot

Ha az eszköznek belső neveket kell feloldania, a feloldónak kell lennie annak, amely ezeket a zónákat tartja, ami általában az alagút feloldóját vagy egy osztott DNS-megoldást jelent, amelyet a szervezet dokumentál. Ha csak a nyilvános nevek számítanak, a szigorú titkosított feloldó védhető választás, amely a nyílt szövegű lekérdezéseket is megszünteti. A döntés a nevekből következik, nem a titkosítással kapcsolatos preferenciából.

A hiba viselkedése is módtól függ. A szigorú választás, amely nem éri el a feloldóját, minden névnél hibát okoz, míg az engedélyezett visszaesést tartalmazó mód működőben tarthatja a nyilvános neveket és törötten a belsőket. Ez a különbség megmondja, melyik módban van, mielőtt beállítási képernyőt nyit. Kezelt eszközön a jóváhagyott szabályzat dönt, és a felhasználó nem tudja biztonságosan megkerülni. Személyes beállításnál egy dokumentált összehasonlítás elég az ütközés azonosításához, és a kívánt adatvédelmi beállítást utána helyre kell állítani, nem kikapcsolva hagyni.

Ellenőrizze, melyik alkalmazás kérdez

Ismételje meg a hibát abban az alkalmazásban, amely jelezte, és jegyezze fel, hogy névhiba vagy kapcsolathiba. Az egyik alkalmazásban fellépő névhiba és a másikban sikeres oldal két feloldó jegye, nem a törött alagúté.

adb shell settings get global private_dns_mode
adb shell settings get global private_dns_specifier
adb shell dumpsys connectivity | grep -i -m 5 dns

Ezek a parancsok az eszköz jelenlegi konfigurációját olvassák, és a gyártói buildek átnevezhetik vagy korlátozhatják a mögöttes értékeket, ezért a kimenetet tippként kezelje, ne specifikációként. Az Android Private DNS dokumentációja leírja a módokat és azt a gépnévformát, amelyet az eszköz elvár.

Hasonlítsa össze ezt a választ a VPN-profil által kényszerített feloldóval. Ha nem egyeznek, megtalálta az ütközést, és a maradék kérdés, hogy melyiket akarja a szervezet nyertesnek.

Egy összehasonlítás után állítsa vissza a kívánt beállítást

Változtasson meg egy beállítást, tesztelje újra a két nevet, és tegye vissza a beállítást. A megengedő módban hagyott eszköz feloldja a belső neveket, és csendben minden nyilvános lekérdezést az első válaszolóhoz küld, ami olyan adatvédelmi változás, amelyet senki nem rögzített.

Írja le az eredményt szabályként: a belső neveket ez a feloldó oldja fel, a nyilvánosakat az, és a böngésző követi az eszközt vagy nem. A feloldót megnevező szabály ellenőrizhető, míg a VPN megjavultáról szóló feljegyzés nem. Ezután ellenőrizze, hogy az eszközön más is függ-e a megváltoztatott feloldótól. A frissítésellenőrzések, a captive portálok felismerése és a levelezőkliensek a saját kéréseiket küldik, és olyan módokon hibáznak, amelyeket a felhasználók összefüggéstelen problémaként jelentenek.

Kapcsolódó cikkek