Ginagamit ba talaga ang DNS ng iyong VPN? Habulin ang port 53 at tingnan

Tanungin ang karamihan kung ano ang ginagawa ng VPN client sa DNS at sasabihin nilang itinatakda nito ang resolver, kaya naglalakbay ang mga query sa loob ng tunnel. Totoo ang pagtulak; ang palagay na nagiging query ito ay hindi. Sa pagitan ng itinulak na opsyon at ng packet sa kawad may tatlong yugto, at bawat isa ay nabigo nang mag-isa sa mga paraang mukhang sirang DNS server. Kaya nga ang pahina ng leak test at gumaganang browser ay maaaring hindi magkasundo tungkol sa isang makina sa isang sandali.

Ang itinulak na opsyon ay hindi query

Ang unang yugto ay nag-aalok ang server ng mga setting, halimbawa itinulak na opsyon sa DNS na nagtatalaga ng resolver sa loob ng tunnel. Ang ikalawang yugto ay inilalapat ng kliyente ang mga setting na iyon sa isang interface. Ang ikatlong yugto ay aktuwal na nagpapadala ang isang aplikasyon ng query sa address na iyon. Ang kabiguan sa ikalawang yugto ay nag-iiwan sa opsyon na nakikita sa log ng koneksyon habang hindi nagbabago ang listahan ng resolver, at ang kabiguan sa ikatlong yugto ay nag-iiwan sa ganap na tamang listahan ng resolver na hindi ginagamit.

Pinagsasama ng karamihan ng pag-troubleshoot ang tatlong iyon sa isa at sinisisi ang VPN server, na kadalasan ang tanging panig na makapagpapatunay na ginawa nito ang bahagi nito. Basahin sa halip ang tunay na kalagayan ng resolver ng kliyente, pagkatapos ay panoorin ang isang query na lumabas. Ang dalawang obserbasyon na iyon ay naghihiwalay ng konfigurasyon sa routing at sa patakaran, at tumatagal ng mga limang minuto. Itago ang mga capture, dahil gusto ng susunod na inhinyero ang bago at pagkatapos, hindi ang paglalarawan nito.

Tingnan kung ano talaga ang hawak ng interface

Sa Linux ang system resolver ay maaaring ang plain file, NetworkManager o systemd-resolved, at kung alin sa kanila ang nagmamay-ari nito ang nagtatakda kung saan lumapag ang itinulak na server. Ang prosesong OpenVPN sa command line ay hindi mismo nag-a-update ng system resolver, kaya ang dokumentadong integrasyon ay isang up/down script o isang connection manager na alam na kung paano ilapat ang mga setting. Ang pagpapatakbo ng pareho ay isang mahusay na paraan upang lumikha ng karera.

resolvectl status
cat /etc/resolv.conf

Sa Windows ang listahan ay bawat adapter, kaya ang tunnel adapter ay maaaring humawak ng mga panloob na server habang ang pisikal na adapter ay nagpapanatili ng mga lokal at nananalo para sa ilang pangalan. Ihambing ang dalawang adapter sa halip na ang inaakala mong aktibo.

Sundan ang isang query palabas ng makina

Kunin ang capture ng dalawang interface nang sabay, pagkatapos ay lutasin ang isang pangalan na dapat gumamit ng panloob na resolver. Ang pares ng capture na iyon ay sumasagot sa hindi kayang sagutin ng anumang output ng konfigurasyon.

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

Ang query na lumilitaw sa pisikal na interface at hindi kailanman sa tunnel ay nangangahulugang pinili ng kliyente ang maling resolver. Ang query na hindi lumilitaw sa alinman sa dalawa ay nangangahulugang sumagot ang aplikasyon mula sa cache, nagtanong sa isang stub na nakikinig sa loopback, o gumamit ng naka-encrypt na resolver na ang trapiko ay hindi kailanman lumilitaw bilang port 53. Kunin din ang mga sagot, hindi lamang mga query, dahil ang query na lumalabas sa tunnel na may sagot mula sa pampublikong address ay ibang depekto kaysa sa walang sagot na dumarating.

Ang firewall na tumatanggap lamang ng sarili nitong DNS

Ang mga komersyal na kliyente ay kung minsan ay nag-i-install ng sarili nilang mga filter chain. Isang dokumentadong pattern ang nagpapahintulot ng DNS sa sariling resolver ng kliyente at itinatapon ang lahat ng natitirang UDP na trapiko sa port 53 na sumusubok na umalis sa isang interface na hindi loopback, kabilang ang trapikong sadyang itinakda ng user sa ibang lugar. Nawawala ang mga query ng daemon nang walang bakas, na binabasa bilang kabiguan ng resolver at hindi bilang filter.

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

Kung ang isang tuntunin sa pagtatapon ay sinusuri bago ang iyong eksepsyon, ang idinagdag na tuntunin ay hindi kailanman maaabot, kaya ipasok ito sa unang posisyon at limitahan ang destinasyon sa resolver na talagang nilalayon mo.

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

Ang eksepsyon na iyon ay diagnostic at hindi patakaran. Kung ang tuntunin ng vendor ay sinasadya, ang sinusuportahang pagkumpuni ay i-configure ang kliyente upang payagan ang resolver na iyon at itala ang desisyon, dahil ang ipinasok na tuntunin ay hindi makakaligtas sa susunod na pag-upgrade ng kliyente.

Bakit ang pahina ng leak ay nagpapatunay ng mas mababa kaysa sa tila

Ang ipinapakita ng pahina ng leak test ay ang resolver na nakipag-usap sa operator ng pagsubok, hindi ang kinonsulta ng iyong makina. Ang lokal na forwarder na nag-recursion palabas ay naglalagay ng sarili nitong exit address sa pahinang iyon, at ang mga naka-encrypt na query ay maaaring mag-iwan sa pahina na ganap na blangko. Parehong mali ang pagbasa sa dalawang resulta, ang isa bilang leak at ang isa bilang garantiya, at wala sa dalawang pagbasa ang sumusunod mula sa obserbasyon.

Ang maipagtatanggol na ebidensya ay ang capture: interface, destinasyon address, sagot at timestamp. Kumuha ng isa bago umangat ang tunnel at isa pagkatapos, at ihambing ang mga ito sa susunod na mabigo ang isang pangalan. Sinasabi rin ng pares na iyon sa susunod na tao kung ang depekto ay sa resolusyon, routing o sa sariling patakaran sa pag-access ng resolver.