VPN DNS kontra böngészős DoH: amit egy szivárgásteszt nem tud megmondani

A szivárgásteszt oldala azt mondja, hogy a DNS rendben van, a böngésző jelvénye azt, hogy biztonságos, a belső wiki mégis nem töltődik be. Mindhárom igaz lehet egyszerre, mert egy feloldó címe nem ugyanaz, mint az őt kiválasztó szabályzat vagy az útvonal, amelyet a lekérdezés megtett. Amit az emberek DNS-szivárgásnak neveznek, valójában egyetlen kérdés: melyik feloldó kapta meg a nevet, és szándékos volt-e ez a választás? Ennek tisztázása három ellenőrzést igényel, és csak az utolsó jár egy beállítás módosításával.

Első mítosz: a jelvény megnevezi a feloldót

A szivárgásteszt felold egy próbanevet, és jelenti a válaszoló címet. Nem jelenti azt a szabályzatot, amely ezt a feloldót választotta, és amikor a lekérdezés DNS over HTTPS-be van csomagolva, az útvonalon lévő köztes egység egyáltalán nem látja a nevet. Két nagyon különböző gép ugyanazt a megnyugtató jelvényt állítja elő: az egyik, ahol a VPN beküldte a 10.8.0.1 címet, és a böngésző használja, a másik pedig, ahol a böngésző figyelmen kívül hagyta a rendszerlistát, és a nevet az alagúton át a saját titkosított szolgáltatójához küldte.

A különbség abban a pillanatban számít, amikor egy privát név meghiúsul. Az első elrendezésben a VPN feloldója válaszol a vállalati zónáért; a másodikban a böngésző soha nem kérdezte meg, ezért a rövid gépnév nem oldódik fel, és a hiba törött VPN-nek látszik. Az ellenőrzés nem újabb szivárgásteszt, hanem egy olyan név keresése, amelyet csak egy feloldó ismer.

Második mítosz: a böngésző elhagyja az alagutat

A DNS címet választ, az útválasztás viszi a kapcsolatot, és ez két külön réteg. Egy nyilvános DoH-szolgáltatónak küldött lekérdezés továbbra is TCP 443-as port egy útválasztható cím felé. Ha az útválasztási táblád az alapértelmezett útvonalat az alagútba küldi, az a lekérdezés is az alagúton megy keresztül. A feloldó márkája nem dönti el az útvonalat.

Amit a böngészős DoH megváltoztat, az a nevek címzettje. Ez valódi adatvédelmi döntés és valódi szabályzati döntés, de nem útválasztási megkerülés. Ha a követelményed az, hogy a nevek a VPN-üzemeltetőnél maradjanak, akkor egy valaki máshoz küldött titkosított lekérdezés nem teljesíti ezt a követelményt, miközben a tényleges kapcsolathoz továbbra is az alagutat használja.

Harmadik mítosz: minden VPN felülír minden böngészőt

A böngésző biztonságos DNS-ének módjai vannak, nem kapcsolója: kikapcsolva, alapértelmezett szolgáltató tartalékkal, egyéni sablon vagy az operációs rendszer vagy a szervezet által kikényszerített szabályzat. Éppen a tartalék eset az, amely időszakos jelentéseket termel. Amikor a titkosított végpont nem érhető el, a böngésző visszaeshet a rendszer feloldójára, így ugyanaz a laptop hétfőn helyesen oldja fel a privát nevet, kedden pedig nem.

Ugyanakkor a legtöbb VPN-kliens beállítja a rendszer feloldóját, amikor a kapcsolat felépül, és visszaállítja az előzőt, amikor megszakad. Az egyéni titkosított feloldót tartó böngésző ezt a visszaállítást egyáltalán nem érzékeli. Ezért viselkedik ugyanaz a profil másként két laptopon, és ezért tűnik helyesnek a resolv.conf, miközben a böngésző még mindig valaki mást kérdez.

resolvectl status                 # per-link DNS servers and split-DNS domains
scutil --dns | head -30           # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1   # ask the VPN resolver directly

Futtasd ezeket kapcsolódva, jegyezd fel, mely domaineket igényli mindegyik feloldó, és hasonlítsd össze azzal, amit a böngésző a saját módjáról jelent. A Mozilla DoH-dokumentációja ésszerű leírása annak, hogyan kell a böngésző alapértelmezett és tartalék viselkedésének működnie.

A döntésnek három bemenete van, nem egy

A privát nevek, az üzemeltetőbe vetett bizalom és az elérhetőség dönti el a helyes elrendezést. Azok a nevek, amelyeket csak a VPN feloldója ismer, megosztott DNS-t kényszerítenek: a privát utótag a beküldött feloldóhoz megy, minden más pedig azt a szabályzatot követi, amelyet a nyilvános nevekhez választottál. Az üzemeltetőbe vetett bizalom dönti el, hogy a nyilvános neveknek is ahhoz a feloldóhoz vagy egy külön szolgáltatáshoz kell-e menniük. Az elérhetőség dönti el, hogy a választott titkosított feloldó egyáltalán használható-e ezen a hálózaton.

E sorok egyike sem általános ajánlás. A VPN által üzemeltetett feloldó az észleléseket annál az üzemeltetőnél összpontosítja; egy külön szolgáltatás még egy címzettet ad a lekérdezett nevekhez. Egyik elrendezés sem bizonyít semmit a megőrzésről, hacsak nem olvasod el a szabályzatot.

Írd le a döntést profilonként, mert ezek a beállítások elcsúsznak. Egy profil, amely múlt hónapban beküldött egy feloldót, ma talán semmit sem küld be, és a böngésző szívesen megtart egy régi egyéni végpontot, amely még válaszol. A feljegyzésbe a feloldó címe, a tulajdonában lévő utótagok és a böngésző módja tartozik, nem a szolgáltatás márkája.

Teszteld azt a szabályzatot, amelyet hiszed, hogy beállítottál

Név szerint tesztelj, ne jelvény szerint. Oldj fel egy nyilvános és egy privát nevet a rendszer feloldóján keresztül, majd ismételd meg a böngészőben a saját biztonságos DNS-beállításával, abban a módban, amelyet használni szándékozol. Ha a privát név csak a böngészőben hiúsul meg, megtaláltad a címzett eltérését anélkül, hogy egyetlen VPN-beállításhoz is hozzányúltál volna.

Utána csatlakozz újra, és ellenőrizd a visszaállítást, mert ott élnek az átadási hibák: bontsd a kapcsolatot, igazold, hogy visszatért az előző feloldó, csatlakozz újra, igazold, hogy visszatért a beküldött. Végül tesztelj egy felügyelt szabályzatú böngészőt, ha van ilyened, mert az a mód teljesen elutasíthatja a változtatásodat, és csendben megtarthatja az előző feloldót.

Kezdd a névtér kérdésével, és a legtöbbet elkerülöd ebből. Ha a gépnek belső neveket kell elérnie, a böngésző titkosított feloldója csak a nyilvános félről szóló döntés, a privát fél pedig annál marad, amit a VPN beküldött.