DNS-ul VPN-ului tău este chiar folosit? Prinde portul 53 și vezi

Întreabă majoritatea oamenilor ce face un client VPN cu DNS și vor spune că setează resolverul, așa că interogările călătoresc în tunel. Împingerea este reală; presupunerea că devine o interogare nu este. Între o opțiune împinsă și un pachet pe fir stau trei etape, iar fiecare eșuează independent în feluri care arată toate ca un server DNS stricat. De aceea o pagină de test de scurgeri și un browser care funcționează pot să nu fie de acord despre aceeași mașină în același moment.

O opțiune împinsă nu este o interogare

Prima etapă este ca serverul să ofere setări, de exemplu o opțiune DNS împinsă care numește un resolver în interiorul tunelului. A doua etapă este ca clientul să aplice acele setări pe o interfață. A treia etapă este ca o aplicație să trimită într-adevăr o interogare la acea adresă. O defecțiune în a doua etapă lasă opțiunea vizibilă în jurnalul conexiunii în timp ce lista de resolvere rămâne neschimbată, iar o defecțiune în a treia etapă lasă o listă de resolvere perfect corectă nefolosită.

Cea mai mare parte a depanării topește cele trei într-una și dă vina pe serverul VPN, care este de obicei singura parte care poate dovedi că și-a făcut partea. Citește în schimb starea reală a resolverului clientului, apoi urmărește o interogare ieșind. Acele două observații separă configurația de rutare și de politică, și costă aproximativ cinci minute. Păstrează capturile, pentru că următorul inginer vrea înainte și după, nu o descriere a lor.

Verifică ce ține de fapt interfața

Pe Linux resolverul de sistem poate fi fișierul simplu, NetworkManager sau systemd-resolved, iar care dintre ele îl deține decide unde aterizează un server împins. Un proces OpenVPN din linia de comandă nu actualizează singur resolverul de sistem, așa că integrarea documentată este un script up/down sau un manager de conexiuni care știe deja cum să aplice setările. Rularea ambelor este o modalitate eficientă de a crea o cursă.

resolvectl status
cat /etc/resolv.conf

Pe Windows lista este pe adaptor, așa că adaptorul tunelului poate ține serverele interne în timp ce adaptorul fizic le păstrează pe cele locale și câștigă pentru unele nume. Compară ambii adaptori în loc de cel pe care presupui că este activ.

Urmărește o interogare în afara mașinii

Capturează ambele interfețe simultan, apoi rezolvă un nume care ar trebui să folosească resolverul intern. Acea pereche de capturi răspunde la ce nu poate răspunde nicio ieșire de configurație.

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

O interogare care apare pe interfața fizică și niciodată în tunel înseamnă că clientul a ales resolverul greșit. O interogare pe niciuna dintre ele înseamnă că aplicația a răspuns din cache, a întrebat un stub care ascultă pe loopback sau a folosit un resolver criptat al cărui trafic nu apare niciodată ca port 53. Capturează și răspunsurile, nu doar interogările, pentru că o interogare care iese prin tunel cu un răspuns de la o adresă publică este altă defecțiune decât niciun răspuns care sosește.

Firewall-ul care acceptă doar propriul DNS

Clienții comerciali instalează uneori propriile lanțuri de filtrare. Un model documentat permite DNS către resolverul propriu al clientului și aruncă tot restul traficului UDP pe portul 53 care încearcă să părăsească o interfață care nu este loopback, inclusiv traficul pe care utilizatorul l-a rutat deliberat în altă parte. Interogările demonului dispar fără urmă, ceea ce se citește ca o defecțiune a resolverului și nu ca un filtru.

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

Dacă o regulă de aruncare este evaluată înaintea excepției tale, o regulă adăugată la sfârșit nu este niciodată atinsă, așa că insereaz-o pe prima poziție și limitează destinația la resolverul pe care chiar îl vrei.

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

Acea excepție este diagnostică și nu politică. Dacă regula furnizorului este deliberată, reparația acceptată este să configurezi clientul să permită acel resolver și să consemnezi decizia, pentru că o regulă inserată nu va supraviețui următoarei actualizări a clientului.

De ce o pagină de scurgeri demonstrează mai puțin decât pare

Ce arată o pagină de test de scurgeri este resolverul care a vorbit cu operatorul testului, nu cel consultat de mașina ta. Un forwarder local care recursează spre exterior își pune propria adresă de ieșire pe acea pagină, iar interogările criptate pot lăsa pagina complet goală. Ambele rezultate sunt citite greșit, unul ca scurgere și celălalt ca garanție, și niciuna dintre lecturi nu decurge din observație.

Dovada apărăbilă este captura: interfață, adresă de destinație, răspuns și marcă de timp. Ia una înainte ca tunelul să urce și una după, și compară-le data viitoare când un nume eșuează. Acea pereche îi spune și următoarei persoane dacă defecțiunea a fost în rezolvare, în rutare sau în politica de acces a resolverului însuși.