A telefonján a privát DNS egy szolgáltató hosztnevére van állítva, és közben egy VPN-alkalmazás is fut. Ésszerű azt feltételezni, hogy most valamelyikük irányítja a névkereséseket. Egyik sem teszi ezt abban az értelemben, amelyet ez a mondat sugall, és a leggyorsabb módja annak, hogy lássa miért, egyetlen kérés végigkövetése attól a pillanattól, amikor egy hivatkozásra koppint.

Ez a két funkció ugyanazon utazás különböző pontjain áll. A privát DNS titkosítja a kérdést, amelyet egy feloldónak feltesz. A VPN megváltoztatja azt az útvonalat, amelyen a válasz kapcsolata halad.

Ezért menjen végig rajta sorrendben, egy olyan eszközön, ahol mindkettő engedélyezve van, és jegyezze fel, mit láthat még az egyes rétegek.

Első lépés: a keresés elhagyja az alkalmazást

Egy hivatkozásra koppint. Mielőtt bármi csatlakozna, az alkalmazásnak címre van szüksége ehhez a hosztnévhez. Androidon az érintett képernyő a Beállítások, Hálózat és internet, Privát DNS. Ha a Privát DNS szolgáltató hosztnevét választja, az eszköz szigorú módba kerül: DNS-t végez TLS felett ehhez a hosztnévhez a 853-as porton, és ha a titkosított csere meghiúsul, a keresés meghiúsul ahelyett, hogy csendben visszaesne sima szövegre az 53-as porton.

Ez jelentős különbség az Automatikushoz képest, amely opportunista titkosítást használ, és szívesen használ titkosítatlan feloldót, amikor a hálózat közbeavatkozik. Ha a célja az, hogy a keresések soha ne történjenek nyíltan, a szolgáltató hosztnevével beállított szigorú mód a megfelelő beállítás.

Íme az első dolog, amit ez a végigjárás felfed: a keresés védve van a helyi hálózattól, a feloldó pedig mégis megismeri a nevet. A titkosítás csak az ugrást fedi. A feloldó üzemeltetője látja a kérést, mert a válaszadás a munkája.

Második lépés: a kapcsolat más útvonalat vesz

A feloldó visszaad egy címet, és az alkalmazás csatlakozik hozzá. Ezt a lépést nem befolyásolja, hogyan titkosították a keresést. Tunel nélkül a kapcsolat a szokásos nyilvános címéről lép ki, és a cél IP-címe meg a TLS-kézfogás általában így is láthatóvá teszi a hosztnevet a hálózat számára, titkosított DNS-sel vagy anélkül.

Kapcsolja be a VPN-t, és pontosan ez a lépés változik meg. A kliens útválasztási szabályzatának megfelelő forgalom a tunelen halad át, a helyi hálózat a VPN végpontjához menő kapcsolatot lát, a webhely pedig általában a kilépési címet látja. A névfeloldás is utazhat a tunelben belül, attól függően, mit küld a kliens.

Ez a szétválás a teljes összehasonlítás egyetlen mondatban. A DNS-titkosítás arra válaszol, ki olvashatja a kérdést. A VPN arra válaszol, hová megy a beszélgetés.

Harmadik lépés: a tunelen belül a DNS házirend-kérdéssé válik

Most a két funkció kölcsönhat, és a böngésző a szokásos meglepetésforrás. Egy saját biztonságos DNS-beállítással rendelkező böngésző HTTPS-en keresztül küldheti a kereséseket a választott feloldóhoz ahelyett, hogy az operációs rendszert kérdezné. Az Android privát DNS-beállítása nem ér el ebbe a döntésbe.

A Firefoxban a kapcsoló a Beállítások, Adatvédelem és biztonság, Biztonságos DNS engedélyezése alatt található. A Chrome-ban a Beállítások, Adatvédelem és biztonság, Biztonságos DNS használata alatt. Mindkettő beállítható egy adott szolgáltatóra, vagy kikapcsolva hagyható, és amikor be vannak kapcsolva, a tunel DNS-konfigurációja megkerülődik ezeknél a kereséseknél, bár az oldal forgalma továbbra is a tunelt használja.

Ha a VPN a saját feloldóját küldi, a böngésző pedig ragaszkodik a sajátjához, szétválás történik: a nevek feloldódnak, az oldalak betöltődnek, és a tunelen átmenő keresések közvetlenül kifelé mentek. A VPN végpontjától eltérő feloldócím önmagában nem bizonyíték szivárgásra, de a megadott szándéknak ellentmondó keresési útvonalat érdemes javítani.

Negyedik lépés: a belső nevek azok, ahol eltörik

Csatlakozzon egy munkahelyi VPN-hez, és nyisson meg egy intranetes hostot. Ha a böngésző biztonságos DNS-e be van kapcsolva, és nyilvános feloldóra mutat, az a név nem létezik a böngésző számára. A tunel áll, minden más működik, és egy hosztnév olyan hibával hiúsul meg, amely úgy néz ki, mintha az oldal leállt volna.

Ugyanez a hiba fordítva jelenik meg Androidon. A nyilvános szolgáltatóval használt szigorú privát DNS nem oldja fel azokat a neveket, amelyeket csak a belső feloldó ismer, és a szigorú módnak nincs tartalék útvonala. Egy telefon DNS-ének megosztása egy nyilvános titkosított feloldó és egy vállalati feloldó között nem beállítás; ez útválasztási házirend-kérdés, amelyre annak kell válaszolnia, aki a VPN-t üzemelteti.

Ellenőrizze ezt, mielőtt a tunelt hibáztatja: kérdezze le a belső nevet, majd ugyanazt a nevet a böngésző biztonságos DNS-ének kikapcsolásával. Ha feloldódik, a feloldó kiválasztása volt a probléma, nem a kapcsolat.

Mit mond ez a végigjárás, mit változtasson

Négy képernyő hordozza szinte az egészet. Nézze meg őket ebben a sorrendben, és írja le, mit mond mindegyik, mert a válasz általában a kombinációban látszik:

  1. Android beállítások, Hálózat és internet, Privát DNS: Automatikus vagy szolgáltatói hosztnév, és melyik hosztnév.
  2. A böngésző biztonságos DNS-beállítása: kikapcsolva, vagy egy adott feloldóhoz rögzítve.
  3. A VPN-kliens DNS-házirendje: küld-e feloldót, és a megosztott tunel kizár-e valamit, aminek még nevekre van szüksége?
  4. Belső hosztnév-teszt álló tunellel, kétszer elvégezve, egyszer a böngésző DNS-ével bekapcsolva, egyszer kikapcsolva.

Ezután a javítást a követelményhez igazítsa, nem fordítva. Ha a követelmény az, hogy a keresések titkosítva menjenek ki, és egy Ön által választott feloldóhoz érkezzenek, állítsa be a szigorú privát DNS-t, és érje el, hogy a böngésző egyetértsen. Ha a követelmény az, hogy a forgalom máshol lépjen ki, konfigurálja a tunelt, és hagyja abba annak várását, hogy egy DNS-beállítás áthelyezi a címét.

És tartsa szem előtt a korlátokat. Egyik funkció sem tesz biztonságossá egy ellenséges célpontot, és egyik sem távolít el egy identitást, amellyel bejelentkezett. A titkosítás megváltoztatja, ki olvashatja a kérdést; a tunel megváltoztatja, hová megy a kapcsolat; ezek egyike sem anonimizálja a fiókot.

Kapcsolódó cikkek