VPN i lidhur por emrat dështojnë: ku thyhet në të vërtetë DNS-ja

Tuneli është lart, ikona e gjelbër dhe çdo skedë e shfletuesit raporton një dështim të zgjidhjes së emrave. Këtë pamje e krijojnë tre mekanizma të ndryshëm: resolveri mund të jetë i paarritshëm, klienti mund të pyesë një resolver që nuk e prisnit, ose vetëm emrat privatë mund të dështojnë. Ndajini ata përpara se të ndryshoni çdo gjë në protokollin e tunelit, sepse secili rregullohet në një vend tjetër. Rendi më poshtë fillon me vëzhgimet që ndajnë të tre.

Çfarë i duhet vërtet një kërkimi

Një kërkimi i duhen tre gjëra: një adresë resolveri, një rrugë drejt asaj adrese dhe një përgjigje që përputhet me pyetjen. Secila mund të dështojë vetëm, dhe simptoma e dukshme është e njëjta faqe që nuk ngarkohet. Prandaj faqja e gabimit nuk ju thotë pothuajse asgjë derisa të dini cila nga të tre është thyer.

Klienti e mëson resolverin e tij nga profili VPN, nga DHCP në tunel ose nga konfigurimi i vet, dhe cila burim fiton varet nga platforma. Në Windows, ipconfig /all rendit serverët DNS për çdo përshtatës, kështu që shihni nëse vlera e shtyrë ka mbërritur vërtet. Një vlerë e shtyrë që nuk arriti kurrë në sistemin operativ është një dështim i heshtur dhe i zakonshëm. Lexoni vlerën e konfiguruar përpara se të prekni profilin.

Linux dhe macOS i përgjigjen të njëjtës pyetje me komanda të ndryshme, dhe përgjigja meriton të njëjtin lexim: resolvectl status dhe scutil --dns të dyja rendisin serverët për çdo ndërfaqe. Krahasoni atë listë me adresën që profili pretendon se shtyn. Një mospërputhje këtu shpjegon gjithçka më poshtë, prandaj zgjidheni atë përpara se të testoni emrat.

Testoni një emër publik dhe një privat

Pyetni një emër pritësi publik të zakonshëm dhe emrin pritës privat të dokumentuar nga e njëjta makinë, dhe shënoni cili server iu përgjigj secilit. Nëse të dy dështojnë, resolveri ose rruga e tij janë prishur. Nëse dështon vetëm emri privat, resolveri u përgjigj dhe pyetja bëhet zona ose rrugëtimi. Ekzekutoni të dyja pyetjet brenda një minute nga njëra-tjetra, që një ndryshim rruge të mos mund të shpjegojë diferencën.

Mbajini emrat e brendshëm jashtë pamjeve publike të ekranit dhe jashtë resolverëve publikë. Një afat kohor dhe një përgjigje për një domen që nuk ekziston janë vëzhgime të ndryshme: i pari thotë se nuk u kthye asgjë, i dyti se një autoritet u përgjigj se emri nuk ekziston. T'i trajtosh si një gabim të vetëm të çon në shtresën e gabuar, dhe një paralajmërim certifikate është përsëri një gjë e tretë, jo një dështim DNS.

nslookup printon si serverin që pyeti ashtu edhe përgjigjen që mori, dhe pikërisht ai është çifti që ju nevojitet. Ekzekutoni atë dy herë në të njëjtën shell dhe shkruani adresën që u përgjigj pranë çdo përgjigjeje.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Konfirmoni se klienti me të vërtetë arrin në atë server

Një resolver privat i shtyrë nga profili është i dobishëm vetëm nëse klienti arrin në të sa kohë tuneli është lart. Një adresë që duket e saktë pa rrugë prodhon një afat kohor, dhe gjendja e lidhur e tunelit nuk thotë asgjë për atë rrugë. Kontrolli është një kërkim rruge i drejtuar nga vetë resolveri, jo nga pika fundore e VPN.

Çdo platformë i përgjigjet kësaj me një rresht, dhe ndërfaqja e emërtuar në dalje është e gjithë përgjigja. Nëse ajo tregon përshtatësin fizik ndërsa resolveri qëndron pas tunelit, profili nuk shtyn një prefiks që e mbulon.

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

Në një profil tuneli të ndarë, resolveri mund të qëndrojë jashtë rrugëve të shtyra, gjë që është problem profili dhe jo serveri. Krahasoni adresën e resolverit me prefikset e shtyra dhe konfirmoni se njëri prej tyre e mbulon. E njëjta mospërputhje shpjegon pse DNS funksionon në një rrjet dhe dështon në një tjetër me një profil identik.

Mbani mend se shfletuesit mund të anashkalojnë resolverin e sistemit

Një shfletues me DNS të sigurt të aktivizuar mund t'i dërgojë pyetjet përmes HTTPS një ofruesi të zgjedhur prej tij dhe të injorojë plotësisht resolverin e sistemit operativ. Atëherë sistemi duket i saktë ndërsa shfletuesi dështon, ose e kundërta. Kjo është çështje politike për shfletuesin, jo për tunelin.

Kontrolloni cilësimin e DNS të sigurt të shfletuesit dhe çdo politikë të menaxhuar që e kontrollon atë, më pas provoni një aplikacion ose shfletues të dytë me tunelin të pandryshuar. Nëse dështon vetëm një aplikacion, korrigjimi i përket atij aplikacioni. Një dritare private nuk është krahasim i pastër, sepse mund të çaktivizojë shtesat si parazgjedhje në një shfletues e jo në tjetrin, dhe nuk anashkalon kurrë një politikë të menaxhuar. Përdorni në vend të kësaj një profil të dytë shfletuesi ose një aplikacion tjetër.

Pastrojeni cache-in dhe ritestoni detyrën e vërtetë

Pasi të keni korrigjuar një cilësim, pastroni cache-in lokal të resolverit që një përgjigje e vjetër të mos i mbijetojë korrigjimit. Një rikuperim i shkurtër i ndjekur nga një dështim i ri do të thotë që shkaku është ende atje, jo që pastrimi dështoi. Zgjidhni rreshtin që përputhet me makinën në të cilën jeni, sepse tre cache-t janë të ndara.

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

Më pas përsëritni detyrën origjinale në vend të një kërkimi sintetik, sepse detyra është ajo që i intereson përdoruesit. Lidhuni edhe një herë, që ritestimi të mbulojë gjendjen në të cilën përdoruesi do të jetë vërtet. Referenca nslookup e Microsoft është faqja që ia vlen të mbahet për argumentet e pyetjes.

Nëse emrat dështojnë vetëm pas shkëputjes, klienti nuk e rivendosi konfigurimin e mëparshëm, që është një gabim i ciklit të jetës për t'u raportuar, jo një server DNS për t'u zëvendësuar. Një kërkim që funksionon nuk është as test rrjedhjeje, sepse vendi i daljes nuk ju thotë se cili resolver u përgjigj.