Titkosítja a VPN a DNS-t, vagy csak a következő ugrást?

A titkosított DNS bekapcsolását a VPN-kiszolgálón gyakran szivárgás megszüntetéseként írják le, és ez a leírás elrejti, melyik kapcsolat változott meg. Az ügyféltől a feloldóig tartó ugrás és a feloldótól a felsőbb szintig tartó ugrás külön kapcsolatok, külön tulajdonosokkal. Az egyik titkosítása a másikat pontosan úgy hagyja, ahogy volt.

Írja le, ki kapja meg a lekérdezést az egyes szakaszokban, mielőtt hozzányúlna egy konfigurációs fájlhoz.

Két elrendezés egyformának látszik a beállítások oldalon

Az első elrendezésben az eszköz maga futtat DNS over TLS-t, és az alagút csupán elviszi ezt a kapcsolatot egy Ön által választott feloldóhoz. A TLS-munkamenet a feloldónál ér véget, ami azt jelenti, hogy a feloldó látja a lekérdezést, a VPN kimenete pedig olyan rejtjelet lát, amelyet nem tud elolvasni. A második elrendezésben az eszköz közönséges DNS-t küld az alagúton keresztül a VPN-gazdagépen futó továbbítóhoz, és ez a továbbító saját titkosított kapcsolatot nyit egy felsőbb feloldóhoz. Mindkettő "titkosított DNS VPN-nel" formában jelenik meg egy funkciólistán, és az olvasható lekérdezést különböző épületekbe helyezi.

A különbség mérhető, nem filozófiai. Keresse meg a TLS-munkamenetet az ügyfélen vagy a kiszolgálón, és megtudja, melyik elrendezés van valójában.

Térképezze fel a feloldóláncot, mielőtt megváltoztatja

Számolja meg az útvonalon lévő feloldókat, és nevezze meg mindegyik szerepét. Egy továbbító komponens átadja a kérést egy másik feloldónak, míg egy rekurzív feloldó elvégzi a válasz megtalálásának munkáját, és közvetlenül is beszélhet a mérvadó kiszolgálókkal. Ezeket a szerepeket éppen ezért határozták meg külön, és az RFC 9076 feloldó-definíciói olvasásra érdemesek, mielőtt feltételezi, hogy létezik egyetlen felsőbb cél. Az a gazdagép, amely saját rekurzív feloldót futtat, nem rendelkezik egyetlen "felsőbb" címmel, amelyet titkosítani lehetne, ami az egész tervet érvénytelenné teszi.

Ezután kérdezze meg, melyik komponenst állították be az ügyfélen. A VPN-profil által küldött DNS-cím megmondja, hová mennek a lekérdezések, nem azt, hogy melyik folyamat válaszol rájuk.

Figyelje meg a hiba esetén tanúsított viselkedést is. Ha a titkosított felsőbb szint elérhetetlenné válik, a továbbító zártan hibázik, visszaesik nyílt szövegre, vagy átvált egy másik feloldóra? Ez a döntés a nyilvántartásba tartozik, mert megváltoztatja az adatvédelmi garanciát abban a pillanatban, amikor az alagút a legkevésbé egészséges.

Ellenőrizze, melyik ugrás titkosított

Kezdje az ügyfélen, és erősítse meg, hogy van-e TLS-munkamenete a 853-as porthoz. Az 53-as porton helyesen feloldódó lekérdezés semmit sem bizonyít a titkosításról.

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

Ezután lépjen át a VPN-gazdagépre, és keresse meg a kimenő titkosított kapcsolatot, amelyet a továbbító megnyitott. A socket-tábla megmondja, létezik-e felsőbb TLS-munkamenet, és melyik folyamat birtokolja:

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

Ha az ügyfél TLS-munkamenetet mutat, a kiszolgáló pedig semmit, az első elrendezésben van, és a kiszolgáló nem tudja elolvasni azokat a lekérdezéseket, amelyeket IP-szinten továbbít. Ha a kiszolgáló mutatja a TLS-munkamenetet, az ügyfél pedig közönséges forgalmat az 53-as porton az alagúton belül, a második elrendezésben van: a következő ugrás védett, de a továbbító még mindig elolvassa minden nevet, amelyet az eszköz kér. Ez a második eredmény nem hiba, de végponttól végpontig tartó titkosításnak nevezni téves.

Rögzítse a tulajdonost és a hiba esetén tanúsított viselkedést

A tulajdonjog dönti el, mit ígérhet. Az eszköz tulajdonosa az ügyféloldali titkosított kapcsolatot irányítja, míg a VPN-rendszergazda a továbbítója által létrehozott következő kapcsolatot. Aki egyiket sem üzemelteti, csak leírni tudja az útvonalat.

Mielőtt bármit engedélyezne, ellenőrizze a belső névhasználatot. A szervezeti nevek nyilvános feloldóhoz küldése nem egyenértékű tervezés, és a csak a hálózaton belül létező split-horizon zóna egyáltalán nem oldódik fel felsőbb szinten. A változtatás után teszteljen egy belső és egy nyilvános nevet, és őrizze meg az eredményt a konfigurációváltozással együtt. Ha a titkosított útvonal megtöri a belső gazdagépek feloldását, a javítás egy korlátozott hatókörű feloldószabály, nem pedig egy szélesebb alagút.

Fejezze be azzal, hogy ugrásonként egy mondatot ír: melyik komponens kapta a lekérdezést, titkosítva volt-e ez az ugrás, és ki olvashatja a nevet. Amikor a VPN-gazdagépről szóló mondat még mindig azt mondja, hogy el tudja olvasni a lekérdezéseket, a dokumentációnak ezt kell mondania, mert egy ellenkezőjét állító ábrának majd hisz valaki, aki soha nem futtatta a parancsokat.