Kas teie VPN-i DNS-i tõesti kasutatakse? Püüdke port 53 ja vaadake

Küsige enamikult inimestelt, mida VPN-klient DNS-iga teeb, ja nad ütlevad, et see seab resolveri, nii et päringud liiguvad tunneli sees. Tõuge on tõeline; eeldus, et sellest saab päring, ei ole. Tõugatud valiku ja juhtmel oleva paketi vahel on kolm etappi ning igaüks nurjub iseseisvalt viisil, mis kõik näevad välja nagu katkine DNS-server. Seetõttu võivad lekketesti leht ja töötav brauser samal hetkel sama masina kohta eriarvamusel olla.

Tõugatud valik ei ole päring

Esimene etapp on see, et server pakub seadeid, näiteks tõugatud DNS-valik, mis nimetab tunnelis olevat resolverit. Teine etapp on see, et klient rakendab need seaded liidesele. Kolmas etapp on see, et rakendus saadab tõesti päringu sellele aadressile. Teise etapi nurjumine jätab valiku ühenduse logis nähtavaks, samal ajal kui resolverite loend jääb muutumatuks, ja kolmanda etapi nurjumine jätab täiesti korrektse resolverite loendi kasutamata.

Enamik tõrkeotsingut sulatab need kolm üheks ja süüdistab VPN-serverit, kes on tavaliselt ainus pool, kes suudab tõestada, et tegi oma osa. Lugege selle asemel kliendi tegelikku resolveri olekut ja jälgige siis ühe päringu lahkumist. Need kaks vaatlust eraldavad konfiguratsiooni marsruutimisest ja poliitikast ning maksavad umbes viis minutit. Hoidke salvestised alles, sest järgmine insener tahab enne ja pärast, mitte nende kirjeldust.

Kontrollige, mida liides tegelikult hoiab

Linuxis võib süsteemi resolver olla tavaline fail, NetworkManager või systemd-resolved, ja see, milline neist seda omab, määrab, kuhu tõugatud server maandub. Käsurea OpenVPN protsess ei uuenda süsteemi resolverit ise, seega dokumenteeritud integratsioon on up/down skript või ühenduse haldur, mis juba oskab seadeid rakendada. Mõlema käivitamine on tõhus viis võidusõidu tekitamiseks.

resolvectl status
cat /etc/resolv.conf

Windowsis on loend adapteri kohta, seega tunneliadapter võib hoida sisemisi servereid, samal ajal kui füüsiline adapter hoiab kohalikke ja võidab mõne nime puhul. Võrrelge mõlemat adapterit, mitte seda, mida peate aktiivseks.

Jälgige üht päringut masinast välja

Salvestage mõlemad liidesed korraga, seejärel lahendage üks nimi, mis peaks kasutama sisemist resolverit. See salvestiste paar vastab sellele, millele ükski konfiguratsiooni väljund ei suuda vastata.

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

Päring, mis ilmub füüsilisele liidesele ja mitte kunagi tunnelisse, tähendab, et klient valis vale resolveri. Päring, mida ei ole kummaski, tähendab, et rakendus vastas vahemälust, küsis loopbackil kuulavat stubi või kasutas krüpteeritud resolverit, mille liiklus ei ilmu üldse port 53-na. Salvestage ka vastused, mitte ainult päringud, sest päring, mis lahkub tunnelist avaliku aadressi vastusega, on teine tõrge kui vastuse üldse mittesaabumine.

Tulemüür, mis aktsepteerib ainult oma DNS-i

Kommertsliidesed paigaldavad mõnikord oma filtreerimisahelad. Üks dokumenteeritud muster lubab DNS-i kliendi enda resolverile ja viskab ära kogu ülejäänud UDP liikluse pordil 53, mis üritab lahkuda liidesest, mis ei ole loopback, sealhulgas liikluse, mille kasutaja suunas teadlikult mujale. Deemoni päringud kaovad jäljetult, mida loetakse resolveri tõrkeks, mitte filtriks.

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

Kui äraviskamisreegel hinnatakse enne teie erandit, ei jõuta lisatud reeglini kunagi, seega sisestage see esimesele positsioonile ja piirduge sihtkohas resolveriga, mida tegelikult mõtlete.

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

See erand on diagnostiline, mitte poliitika. Kui tarnija reegel on sihilik, on toetatud parandus konfigureerida klient seda resolverit lubama ja otsus kirja panna, sest sisestatud reegel ei ela üle järgmist kliendi uuendust.

Miks lekke leht tõestab vähem, kui tundub

Mida lekketesti leht näitab, on resolver, kes rääkis testi operaatoriga, mitte see, kellega teie masin konsulteeris. Lokaalne edastaja, mis rekursioonib väljapoole, paneb oma väljumisaadressi sellele lehele, ja krüpteeritud päringud võivad jätta lehe täiesti tühjaks. Mõlemat tulemust loetakse valesti, üht lekkena ja teist garantiina, ning kumbki lugemine ei tulene vaatlusest.

Kaitstav tõend on salvestis: liides, sihtaadress, vastus ja ajatempel. Tehke üks enne, kui tunnel tõuseb, ja üks pärast, ning võrrelge neid järgmisel korral, kui nimi ebaõnnestub. See paar ütleb ka järgmisele inimesele, kas tõrge oli lahendamises, marsruutimises või resolveri enda juurdepääsupoliitikas.