Tényleg használja a VPN DNS-ét? Kapja el az 53-as portot, és nézze meg

Kérdezze meg a legtöbb embert, mit tesz egy VPN-kliens a DNS-sel, és azt mondják, beállítja a feloldót, így a lekérdezések az alagúton belül utaznak. A tolás valódi; az a feltevés, hogy abból lekérdezés lesz, nem. Egy tolt beállítás és a vezetéken lévő csomag között három szakasz áll, és mindegyik önállóan hibázik olyan módokon, amelyek mind egy törött DNS-kiszolgálóra hasonlítanak. Ezért mondhat ellent egy szivárgásteszt-oldal és egy működő böngésző ugyanarról a gépről ugyanabban a pillanatban.

A tolt beállítás nem lekérdezés

Az első szakasz, hogy a kiszolgáló beállításokat kínál, például egy tolt DNS-beállítást, amely az alagúton belüli feloldót nevez meg. A második szakasz, hogy a kliens ezeket a beállításokat egy interfészre alkalmazza. A harmadik szakasz, hogy egy alkalmazás ténylegesen lekérdezést küld arra a címre. A második szakasz hibája a beállítást láthatóvá teszi a kapcsolati naplóban, miközben a feloldólista változatlan marad, a harmadik szakasz hibája pedig egy teljesen helyes feloldólistát használatlanul hagy.

A legtöbb hibakeresés ezt a hármat egybe olvasztja, és a VPN-kiszolgálót hibáztatja, amely általában az egyetlen fél, amely bizonyítani tudja, hogy megtette a részét. Olvassa inkább a kliens tényleges feloldóállapotát, majd figyelje meg egy lekérdezés kilépését. Ez a két megfigyelés elválasztja a konfigurációt az útválasztástól és a szabályzattól, és körülbelül öt percet vesz igénybe. Őrizze meg a rögzítéseket, mert a következő mérnök az előtte és az utána állapotot akarja, nem a leírásukat.

Ellenőrizze, mit tart valójában az interfész

Linuxon a rendszer feloldója lehet a sima fájl, a NetworkManager vagy a systemd-resolved, és hogy melyik birtokolja, eldönti, hova érkezik egy tolt kiszolgáló. A parancssori OpenVPN-folyamat magától nem frissíti a rendszer feloldóját, ezért a dokumentált integráció egy up/down szkript vagy egy olyan kapcsolatkezelő, amely már tudja alkalmazni a beállításokat. Mindkettő futtatása hatékony módja a versenyhelyzet létrehozásának.

resolvectl status
cat /etc/resolv.conf

Windowson a lista adapterenként értendő, így az alagút-adapter tarthatja a belső kiszolgálókat, míg a fizikai adapter megtartja a helyieket, és bizonyos neveknél nyer. Hasonlítsa össze mindkét adaptert, ne azt, amelyikről feltételezi, hogy aktív.

Kövessen egy lekérdezést a gép elhagyásáig

Rögzítse mindkét interfészt egyszerre, majd oldjon fel egy nevet, amelynek a belső feloldót kellene használnia. Ez a rögzítéspár válaszol arra, amire semmilyen konfigurációs kimenet nem tud.

sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53

Az a lekérdezés, amely a fizikai interfészen megjelenik és soha az alagútban, azt jelenti, hogy a kliens rossz feloldót választott. Az a lekérdezés, amely egyiken sem jelenik meg, azt jelenti, hogy az alkalmazás a gyorsítótárból válaszolt, egy loopbacken figyelő stubtól kérdezett, vagy titkosított feloldót használt, amelynek forgalma soha nem jelenik meg 53-as portként. Rögzítse a válaszokat is, ne csak a lekérdezéseket, mert egy alagúton kilépő lekérdezés nyilvános címről érkező válasszal más hiba, mint a válasz teljes elmaradása.

A tűzfal, amely csak a saját DNS-ét fogadja el

A kereskedelmi kliensek néha saját szűrőláncokat telepítenek. Egy dokumentált minta engedélyezi a DNS-t a kliens saját feloldójához, és eldobja az összes többi UDP-forgalmat az 53-as porton, amely nem loopback interfészről próbál kilépni, beleértve azt a forgalmat is, amelyet a felhasználó szándékosan máshova irányított. A démon lekérdezései nyom nélkül eltűnnek, amit feloldóhibaként olvasunk, nem szűrőként.

sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'

Ha egy eldobási szabály az Ön kivétele előtt értékelődik ki, egy hozzáfűzött szabály soha nem érhető el, ezért illessze be az első helyre, és korlátozza a célt arra a feloldóra, amelyet valóban szeretne.

sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT

Ez a kivétel diagnosztikai, nem szabályzat. Ha a szállító szabálya szándékos, a támogatott javítás az, hogy a klienst úgy állítsa be, hogy engedélyezze azt a feloldót, és rögzítse a döntést, mert egy beszúrt szabály nem éli túl a következő kliensfrissítést.

Miért bizonyít kevesebbet egy szivárgásoldal, mint látszik

Amit egy szivárgásteszt-oldal mutat, az a feloldó, amely a teszt üzemeltetőjével beszélt, nem az, amelyet a gépe megkérdezett. Egy kifelé rekurzáló helyi továbbító a saját kimenő címét teszi arra az oldalra, és a titkosított lekérdezések teljesen üresen hagyhatják az oldalt. Mindkét eredményt rosszul olvassák, az egyiket szivárgásként, a másikat garanciaként, és egyik olvasat sem következik a megfigyelésből.

A védhető bizonyíték a rögzítés: interfész, célcím, válasz és időbélyeg. Készítsen egyet, mielőtt az alagút feljön, és egyet utána, majd hasonlítsa össze őket, amikor legközelebb egy név meghiúsul. Ez a pár a következő embernek is megmondja, hogy a hiba a feloldásban, az útválasztásban vagy a feloldó saját hozzáférési szabályzatában volt.