Hová megy a DNS, amikor a Tor-t és egy VPN-t kombinál

Két adatvédelmi eszköz fut, egy oldal nem töltődik be, és egy feloldóteszt szerint valami a böngészőn kívül nevet kapott. Mielőtt ez szivárgásjelentéssé válik, nevezze meg azt a cserét, amelyből származik. Egy Tor plusz VPN beállítás legalább három különböző névkeresés három különböző tulajdonossal tartalmaz, és ezeket abban a sorrendben végigvenni, ahogy történnek, a leggyorsabb módja annak, hogy lássuk, melyik viselkedik rosszul.

Nevezze meg minden cserét, mielőtt szivárgásnak nevezné

Az első csere magát a VPN végpontját oldja fel, és minden védelem létrejötte előtt történik. A második egy célállomást old fel a Tor Browser számára, amely a nevet a proxyhoz adhatja tovább ahelyett, hogy helyben oldaná fel. A harmadik minden mást lefed a gépen, beleértve a frissítésellenőrzéseket, a levelezőklienseket és az operációs rendszer saját szolgáltatáskéréseit. Közülük csak az első történhet meg anélkül, hogy a másik kettő részt venne benne.

Mindegyik más útvonalat követhet, és egyetlen böngészős teszt csak a saját kérését figyeli. Egyetlen eredményt mindhárom állapotának tekinteni ott kezdődik, ahol a legtöbb zavar.

Írja le, mely nevek melyik réteghez tartoznak, mielőtt bármit módosít. A privát szervezeti nevek, egy nyilvános cél és maga az alagút végpontja nem ugyanazt a követelményt hordozzák, és egy szabályzat, amely egyetlen kategóriaként kezeli őket, elront valamit.

A rendszerindítási lekérdezés az alagút előtt történik

A hosztnévvel beállított kliensnek fel kell oldania ezt a nevet az alagút megnyitásához, és abban a pillanatban még nincs alagút, amely a lekérdezést hordozná. Bármelyik feloldó válaszol, amelyet az operációs rendszer a jelenlegi hálózaton kínál, ez lehet captive portal, szállodai feloldó vagy nyilvános. Ez nem szivárgás az alagútban, mert még nincs alagút.

A böngésző biztonságos DNS-beállításának módosítása sem érinti ezt a lekérdezést, mivel az egy olyan szolgáltatáshoz tartozik, amely a böngészőn kívül fut, és bármely oldal megnyitása előtt indul. Ha a végpont neve nem oldható fel, semmilyen alagúton belüli szabályzat nem segít, mert a hiba egy fázissal korábban történik, mint minden, amit a konfiguráció leír.

Ez az egyetlen hely, ahol a végpont szó szerinti címének használata, ha a szolgáltató támogatja, függőséget távolít el ahelyett, hogy hozzáadna egyet. Eltávolítja azt a képességet is, hogy olyan szolgáltatót kövessen, amely a címeket forgatja, tehát a csere valódi, és dönteni kell róla, nem felfedezni.

A böngésző és a gép többi része különbözik

A Tor SOCKS-felülete támogatja a cél hosztnév továbbítását a proxyhoz, ami azt jelenti, hogy a távoli vég végzi a feloldást, és a helyi gép soha nem kérdez. Egy proxyt támogató általános alkalmazás először helyben feloldhatja a nevet, majd csatlakozhat a kapott címhez, ami helyi lekérdezést eredményez egy olyan célhoz, amelyről a felhasználó azt hitte, hogy proxyn megy át. A két alkalmazás tehát különböző helyeken szivároghat, miközben egy proxibeállítást oszt meg. Egy megosztott proxycímben semmi sem mondja meg, melyik viselkedés van használatban.

A böngészők még egy réteget adnak hozzá, amikor a biztonságos DNS engedélyezve van, mert a böngésző saját szolgáltatót választhat, és teljesen megkerülheti a rendszer feloldóját. Az alagút kliens közben feloldót tolhat át az alagúton az egész gép számára. Ez a két beállítás egyszerre lehet helyes, és mégis eltérő viselkedést írhat le különböző programok számára.

Ellenőrizze a kérést indító programot ahelyett, hogy egyetlen tesztoldalból következtetne. Az alagúton belül hordozott lekérdezés és a Tor-t soha el nem érő lekérdezés közötti különbség pontosan az a különbség, amelyet egyetlen feloldócím nem tud megmutatni.

Ellenőrizze minden programot, majd hasonlítsa össze a szándékkal

Végezze el a megfigyeléseket külön: mit használna a rendszer, mire van a böngésző beállítva, és hogy a SOCKS-kapcsolat nevet vagy címet hordoz-e. Az utóbbi a távoli és a helyi feloldás közötti különbség, és SOCKS-bővítmények specifikációja leírja, hogyan továbbítódik a hosztnév ahelyett, hogy először feloldódna.

resolvectl status | grep -E "Current DNS Server|DNS Servers"
ss -tnp '( dport = :9050 )'
dig +short dev.internal.example
getent hosts vpn-endpoint.example.net

Ezután hasonlítsa össze a megfigyelteket a szándékolttal. Egy nyilvános név, amelyet az Ön által választott feloldó az alagúton keresztül old fel, nem ugyanaz a lelet, mint egy privát név, amelyet egy visszaesés során nyilvános feloldónak adnak át, és általában csak a második igényel intézkedést. Az első a tervezés szerint működő konfiguráció, még ha szokatlannak is tűnik egy jelentésben.

Rögzítse az elfogadott kivételeket, beleértve a rendszerindítási lekérdezést, amely nem védhető. A leírt kivétel tervezési döntés, míg ugyanez a kivétel később felfedezve hibának tűnik. Aki megtalálja, annak fogja tekinteni, és a megbeszélést azzal tölti majd, hogy elmagyarázza, miért nem az.