Emrat e brendshëm dështojnë në VPN ndërsa faqet publike zgjidhen normalisht

Një përdorues raporton se emri i hostit të intranetit nuk zgjidhet përmes VPN-së. Një raport i dytë, nga i njëjti laptop, thotë se testi i rrjedhjes vazhdon të tregojë pyetje të përgjigjura nga zgjidhësi lokal. Ata tingëllojnë si një problem dhe janë dy, me prova të ndryshme, dhe rregullimi i zakonshëm për të parin e përkeqëson të dytin. Ndajini ata përpara se të prekni ndonjë cilësim.

Dy simptoma që nuk janë një defekt i vetëm

Dështimi për të zgjidhur një emër të brendshëm do të thotë se pyetja shkoi diku që nuk ka përgjigje për të. Pyetjet që largohen nga tuneli do të thotë se pyetja shkoi në vendin e gabuar edhe kur përgjigja ishte e disponueshme. Këto janë dështime të kundërta: njëri është një përgjigje që mungon, tjetri është një destinacion shtesë.

Gracka është se shtimi i zgjidhësit të zyrës kudo rregullon të parin dhe garanton të dytin. Shtimi i një zgjidhësi publik kudo bën të kundërtën.

Shkruajini të dy vëzhgimet me një vulë kohore, pastaj kaloni nëpër katër kontrollet më poshtë me radhë.

Zgjidhësi i cilit përshtatës e merr pyetjen

Në Windows, klienti DNS i zgjedh serverat sipas rendit të lidhjes së përshtatësve, dhe përshtatësi i tunelit nuk është automatikisht i pari. Hapni cilësimet e avancuara të përshtatësit dhe zhvendosni lidhjen e aksesit në distancë mbi përshtatësin fizik, pastaj rilidhuni që ndryshimi të zbatohet në një sesion të ri.

Rendi i lidhjes është vetëm gjysma e parë. Klienti gjithashtu duhet të dijë cilat emra i përkasin atij përshtatësi, dhe kjo është një çështje prapashtese, jo renditjeje.

Vendoseni rezultatin e ipconfig /all pranë atij të laptopit, të dy të marrë ndërsa tuneli është aktiv. Makina që funksionon do të tregojë një prapashtesë DNS specifike të lidhjes në përshtatësin e saj të zyrës, dhe laptopi mund të mos tregojë asnjë në tunel. Ai ndryshim shpjegon një klasë të tërë raportesh sipas të cilave "serveri është pikërisht aty dhe emri prapë dështon", sepse pa një prapashtesë emri i shkurtër nuk plotësohet kurrë në zonën që shërben zgjidhësi i zyrës.

Një emër i shkurtër ka nevojë për një prapashtesë përpara se të ketë nevojë për një rrugë

Shtypja e një emri hosti të pakualifikuar i kërkon zgjidhësit të hamendësojë një domen. Hamendja vjen nga lista e prapashtesave e bashkangjitur lidhjes, dhe nëse ajo listë është bosh, pyetja shkon si një etiketë e vetme që asnjë zonë private nuk do ta përputhë.

Kopjoni prapashtesën e makinës që funksionon në vetitë IPv4 të përshtatësit të VPN-së, në skedën DNS, pastaj rilidhuni. Në Linux ekuivalenti është domeni i kërkimit në lidhjen e tunelit, të cilin systemd-resolved e ekspozon për lidhje dhe jo në mënyrë globale.

Mbani dy cilësimet të ndara në shënimet tuaja. Një prapashtesë ndryshon atë që kërkohet; adresa e zgjidhësit ndryshon kush kërkohet. Rregullimi i njërit ndërsa tjetri është i gabuar prodhon një rezultat që duket i rastësishëm.

Pyetni zgjidhësin drejtpërdrejt, pastaj emrin

Një pyetje e drejtpërdrejtë te zgjidhësi i zyrës e ndan një problem emri nga një problem rruge, sepse anashkalon plotësisht zgjedhjen e zgjidhësit nga klienti.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Komanda e parë i kërkon një serveri të caktuar një emër të plotë të kualifikuar. Nëse përgjigjet, zgjidhësi dhe rruga drejt tij janë në rregull dhe defekti është në zgjedhje ose në prapashtesë. Nëse skadon koha, adresa është e gabuar ose e paarritshme dhe problemi është rrugëzimi, jo DNS. Komanda e dytë tregon çfarë ndodh me emrin e shkurtër, dhe e treta shtyp konfigurimin e zgjidhësit për lidhje në një host systemd.

Kini kujdes për përgjigjet me karaktere të gjera, të cilat disa rrjete i kthejnë për emra të panjohur. Një përgjigje që duket e besueshme nuk është provë se serveri i synuar u përgjigj, ndaj krahasoni adresën e kthyer me atë që përdor në të vërtetë shërbimi i brendshëm. Nëse adresa i përket një faqe parkimi ose një përfaqësuesi, zgjidhësi u përgjigj, por përgjigja nuk ishte kurrë e juaja. Ai dallim kursen një orë duke ndjekur një tunel që funksiononte gjatë gjithë kohës.

Në Linux, një klient VPN që rishkruan /etc/resolv.conf zëvendëson plotësisht zgjidhësit lokalë. vpnc ekspozon DNSUpdate no për ta ndaluar këtë, dhe systemd-resolved mund t'i drejtojë vetëm domenet e listuara te lidhja e tunelit. Të dyja qasjet i mbajnë emrat publikë te zgjidhësi lokal ndërsa dërgojnë emrat e brendshëm te zyra.

Rrjedhjet janë një rregull, jo një kuti kontrolli

Zgjidhja e emrave është një shkëmbim UDP në portën 53, kështu që një tunel që mbart trafik web por jo UDP e lë pyetjen në rrugën fizike. Vërtetojeni duke kapur në NIC-në fizike ndërsa zgjidhet një emër publik. Një pyetje e dukshme në atë ndërfaqe në formë të lexueshme do të thotë se tuneli nuk po e mbart atë.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Nëse pyetja shfaqet në atë ndërfaqe në formë të lexueshme, tuneli nuk po e mbart atë. Rregullimi është një rregull që lejon portën 53 vetëm drejt zgjidhësit që shtyu VPN-ja dhe hedh destinacionet e tjera, plus një konfigurim klienti që nuk e hedh në heshtje opsionin e shtyrë.

Pjesa e fundit ka më shumë rëndësi sesa duket. Nisni OpenVPN me route-nopull dhe opsioni i shtyrë i DNS zhduket bashkë me rrugët, përveç nëse filtri i tërheqjes zgjerohet për ta mbajtur. dhe një klient që injoron dhcp-option DNS do të vazhdojë të përdorë atë që kishte më parë. Çdo ndryshim në anën e serverit kërkon një sesion të ri për të hyrë në fuqi, pasi lista e zgjidhësve dërgohet kur tuneli ngrihet dhe një sesion i vjetëruar vazhdon të tregojë gjendjen e vjetër.

Regjistroni cilin dështim keni vëzhguar në të vërtetë përpara se ta mbyllni biletën. Një përgjigje e brendshme që mungon dhe një pyetje që ikën nga tuneli kërkojnë rregullime të ndryshme, dhe një ndryshim prapashtese që rregullon të parin mund të përkeqësojë në heshtje të dytin. Kushdo që e merr biletën më pas do t'i besojë etiketës, ndaj bëjeni etiketën të saktë.