A përdoret vërtet DNS-i i VPN-së tuaj? Kapni portën 53 dhe shikoni

Pyetni shumicën se çfarë bën një klient VPN me DNS-in dhe ata do të thonë se vendos zgjidhësin, kështu që kërkesat udhëtojnë brenda tunelit. Shtyrja është e vërtetë; supozimi se ajo bëhet kërkesë nuk është. Mes një opsioni të shtyrë dhe një pakete në tel qëndrojnë tre faza, dhe secila dështon në mënyrë të pavarur në forma që të gjitha duken si një server DNS i prishur. Prandaj një faqe testi rrjedhjeje dhe një shfletues që punon mund të mos bien dakord për të njëjtën makinë në të njëjtin moment.

Një opsion i shtyrë nuk është kërkesë

Faza e parë është që serveri të ofrojë cilësime, për shembull një opsion DNS i shtyrë që emërton një zgjidhës brenda tunelit. Faza e dytë është që klienti t'i zbatojë ato cilësime në një ndërfaqe. Faza e tretë është që një aplikacion të dërgojë vërtet një kërkesë në atë adresë. Një dështim në fazën e dytë e lë opsionin të dukshëm në regjistrin e lidhjes ndërsa lista e zgjidhësve mbetet e pandryshuar, dhe një dështim në fazën e tretë e lë një listë zgjidhësish plotësisht të saktë të papërdorur.

Shumica e zgjidhjes së problemeve i shkrin të tre në një dhe fajëson serverin VPN, i cili zakonisht është pala e vetme që mund të provojë se bëri pjesën e vet. Lexoni në vend të kësaj gjendjen reale të zgjidhësit të klientit, pastaj ndiqni një kërkesë duke dalë. Këto dy vëzhgime ndajnë konfigurimin nga rrugëtimi dhe nga politika, dhe kushtojnë rreth pesë minuta. Ruani kapjet, sepse inxhinieri tjetër do para dhe pas, jo një përshkrim të tyre.

Kontrolloni çfarë mban vërtet ndërfaqja

Në Linux zgjidhësi i sistemit mund të jetë skedari i thjeshtë, NetworkManager ose systemd-resolved, dhe cili prej tyre e zotëron vendos ku ulet një server i shtyrë. Një proces OpenVPN nga rreshti i komandës nuk e përditëson vetë zgjidhësin e sistemit, kështu që integrimi i dokumentuar është një skript up/down ose një menaxher lidhjesh që tashmë e di si të zbatojë cilësimet. Të ekzekutosh të dyja është një mënyrë efikase për të krijuar një garë.

resolvectl status
cat /etc/resolv.conf

Në Windows lista është për çdo përshtatës, kështu që përshtatësi i tunelit mund të mbajë serverët e brendshëm ndërsa përshtatësi fizik mban ata lokalë dhe fiton për disa emra. Krahasoni të dy përshtatësit në vend të atij që supozoni se është aktiv.

Ndiqni një kërkesë jashtë makinës

Kapni të dy ndërfaqet njëkohësisht, pastaj zgjidhni një emër që duhet të përdorë zgjidhësin e brendshëm. Ai çift kapjesh përgjigjet për atë që asnjë dalje konfigurimi nuk mund të përgjigjet.

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

Një kërkesë që shfaqet në ndërfaqen fizike dhe kurrë në tunel do të thotë që klienti zgjodhi zgjidhësin e gabuar. Një kërkesë që nuk shfaqet në asnjërën do të thotë që aplikacioni u përgjigj nga cache, pyeti një stub që dëgjon në loopback ose përdori një zgjidhës të kriptuar trafiku i të cilit nuk shfaqet kurrë si portë 53. Kapni edhe përgjigjet, jo vetëm kërkesat, sepse një kërkesë që del përmes tunelit me një përgjigje nga një adresë publike është një defekt tjetër nga mosardhja e asnjë përgjigjeje.

Muri i zjarrit që pranon vetëm DNS-in e vet

Klientët komercialë ndonjëherë instalojnë zinxhirët e tyre të filtrimit. Një model i dokumentuar lejon DNS drejt zgjidhësit të vetë klientit dhe hedh poshtë gjithë trafikun e mbetur UDP në portën 53 që përpiqet të largohet nga një ndërfaqe që nuk është loopback, përfshirë trafikun që përdoruesi e ka drejtuar me qëllim diku tjetër. Kërkesat e demonit zhduken pa gjurmë, gjë që lexohet si dështim i zgjidhësit dhe jo si filtër.

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

Nëse një rregull hedhjeje vlerësohet përpara përjashtimit tuaj, një rregull i shtuar në fund nuk arrihet kurrë, prandaj futeni në pozicionin e parë dhe kufizoni destinacionin te zgjidhësi që keni vërtet ndërmend.

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

Ai përjashtim është diagnostik dhe jo politikë. Nëse rregulli i furnizuesit është i qëllimshëm, riparimi i mbështetur është të konfiguroni klientin që të lejojë atë zgjidhës dhe të regjistroni vendimin, sepse një rregull i futur nuk do t'i mbijetojë përditësimit të ardhshëm të klientit.

Pse një faqe rrjedhjeje provon më pak sesa duket

Ajo që tregon një faqe testi rrjedhjeje është zgjidhësi që foli me operatorin e testit, jo ai që konsultoi makina juaj. Një përcjellës lokal që bën rekursion nga jashtë vendos adresën e vet të daljes në atë faqe, dhe kërkesat e kriptuara mund ta lënë faqen plotësisht bosh. Të dy rezultatet lexohen gabimisht, njëri si rrjedhje dhe tjetri si garanci, dhe asnjëra nga leximet nuk rrjedh nga vëzhgimi.

Prova e mbrojtshme është kapja: ndërfaqja, adresa e destinacionit, përgjigjja dhe stampa kohore. Merrni një përpara se tuneli të ngrihet dhe një pas, dhe krahasoni ato herën tjetër që një emër dështon. Ai çift i thotë edhe personit tjetër nëse defekti ishte në zgjidhje, në rrugëtim apo në politikën e aksesit të vetë zgjidhësit.