A VPN DNS-tartalék: hová megy valójában a lekérdezés

A feloldó beállítása a magáncímről nyilvánosra vált, és a következtetés azonnal megérkezik: az alagút szivárog. Néha valóban így van. Gyakran azonban a tartalék lekérdezés mégis az alagúton belül utazott egy olyan feloldóhoz, amelyet az adminisztrátor választott, ami politikadöntéssé teszi a hibát. E esetek szétválasztásához három tény kell egy helyett, és az első az, hogy ki válaszolt. Tudja meg, ki kapta meg a lekérdezést, melyik útvonal vitte, és mely nevekre kérdeztek rá.

A tartalék politika, nem egyetlen viselkedés

Minden kliensnek el kell döntenie, mit tesz, amikor az előnyben részesített feloldó nem válaszol tovább. Blokkolhatja a feloldást, újrapróbálkozhat, használhat beállított alternatívát, vagy rábízhatja az operációs rendszerre, és adatvédelmi szempontból ez négy különböző termék. A beállítási képernyő elolvasása megmondja, melyik viselkedés van beállítva; azt nem mondja meg, melyik következett be. Az egyetlen kapcsolót kínáló képernyő nem ír le négy lehetőséget.

A böngészők saját réteget adnak hozzá. Egy biztonságos DNS-t engedélyező böngésző a saját választott szolgáltatóján keresztül oldhat fel egy nevet akkor is, amikor az operációs rendszer máshová mutat, ami azt jelenti, hogy előfordulhat, hogy az alagút kliensének politikáját soha nem kérdezik meg azokról a kérésekről, amelyek igazán számítanak Önnek. Ellenőrizze a kérést indító alkalmazást, ne csak a rendszerbeállítást.

A helyettes feloldó kiléte az első tény, amelyet érdemes megállapítani. Egy olyan szolgáltatóhoz tartozó nyilvános feloldó, amelyben már megbízik, más helyzet, mint a hálózat által biztosított cím, amelyen éppen van. A cím önmagában ritkán árulja el, melyiket látja a kettő közül.

Ki kapja meg a lekérdezést a váltás után

A címzett és az útvonal független, és csak a kettő kombinációja írja le a kitettséget. Az alagúton keresztül elért nyilvános feloldó soha nem látja a hozzáférési hálózatának címét, míg ugyanaz a feloldó közvetlenül elérve látja. Mindkét eset választ ad, és a szivárgásteszt, amely csak a feloldó címét jelenti, azonos módon írja le őket. A kimenet olvasásakor kérdezze meg az interfészt is, nem csak a címet.

A belső nevek konkréttá teszik a különbséget. A nyilvános feloldó általában nem tud válaszolni egy split-horizon névre, így a lekérdezés meghiúsul, miközben a nevet mégis olyan félnek tették ki, akinek semmi köze nem volt hozzá. A rendelkezésre állás és az adatvédelem tehát itt együtt mozog, nem pedig felváltja egymást.

Az alagút a lekérdezést olyan feloldóhoz is elviheti, amelyet nem a VPN-szolgáltató üzemeltet, mert az alagút továbbít, nem pedig felold. A továbbító állomás látja a nyílt szövegű lekérdezést, majd megnyitja a saját kapcsolatát tovább, ami a következő ugrást védi, az elsőt nem.

Ellenőrizze az útvonalat és a címzettet együtt

A csomagokat figyelje, ne a konfigurációt. Kérdezze meg a rendszertől, melyik feloldó lenne használva, majd erősítse meg, hogy a lekérdezés valóban a várt interfészről a várt címre ment el.

resolvectl status | grep -E "Current DNS Server|DNS Servers|DNSOverTLS"
dig +short example.com
tcpdump -ni any udp port 53 or tcp port 853

Ha a rögzítés azt mutatja, hogy a lekérdezés a fizikai interfészt hagyja el, miközben az alagút aktív, a tartalék megkerülte az alagutat, függetlenül attól, mit mond a feloldók listája. Ha az alagút interfészén jelenik meg, a kérdés az lesz, ki üzemelteti a távoli véget, és mit tart meg.

Ismételje meg az ellenőrzést egy belső és egy nyilvános névvel. A belső lekérdezés az, ahol a tartalék konfiguráció általában leleplezi magát, mert a válaszolni képtelen feloldó mégis megkapja a kérdést.

Döntse el, hogy engedélyezhető-e a tartalék

Ha a követelmény az, hogy a feloldás leálljon, amikor az előnyben részesített feloldó nem elérhető, állítson be zárt módon meghiúsuló kikényszerítési politikát, és fogadja el a következményt: a kimaradás alatt a nevek nem oldódnak fel. Ez szándékos rendelkezésre állási csere, nem meghibásodás, és a tervezésnek ezt még a kimaradás előtt ki kell mondania.

Ha a követelmény csak az, hogy a lekérdezések ne utazzanak az alagúton kívülre, az alagúton keresztül elért nyilvános feloldó elfogadható lehet, feltéve hogy az üzemeltető és megőrzési politikája ismert. Az ilyen elfogadás egy harmadik félről szóló ítélet, nem a kriptográfiáról tett állítás, és azt illeti, aki az adatvédelmi állítást birtokolja. Ha a belső neveknek továbbra is működniük kell, a tartaléknak olyan feloldónak kell lennie, amely a belső zónákat tartja, ami általában azt jelenti, hogy a tartalék célpontja másik kiszolgáló, nem másik címcsalád.

Dokumentálja az eredményt a viselkedésről szóló mondatként: melyik feloldó kapja a lekérdezéseket normál működésben, melyik kapja meg őket hiba után, és feloldódnak-e a belső nevek a második esetben. Az a szivárgásteszt, amely végül betölt egy oldalt, kevesebbet bizonyít ennél a mondatnál, mert egy oldal olyan feloldón keresztül is betölthető, amelyet soha nem szabadott volna megkérdezni.