A e ndryshoi VPN-i DNS-në tim? Krahasoni para dhe pas

Lidh tunelin, hap një panel privat dhe emri zgjidhet në një adresë që nuk e ke parë kurrë. Ose ndodh e kundërta: shfletuesi vazhdon të punojë ndërsa një mjet i linjës së komandës papritur nuk zgjidh asgjë. Të dyja rezultatet vijnë nga i njëjti ndryshim, dhe njerëzit zakonisht e shpjegojnë me një fjali për VPN-në që "përdor DNS-në e vet", e cila nuk është mjaftueshëm e saktë për korrigjim ose verifikim. Në atë fjali fshihen dy pyetje: cilat kërkime duhet të marrë përsipër ky profil, dhe a i dërgoi vërtet makina jote ato te zgjidhësi që iu dha? Mbajtja e tyre të ndara është e gjithë metoda, sepse një test që i përzien jep një përgjigje të gabuar dhe të sigurt në të dy drejtimet.

Pse një profil ofron fare zgjidhës

Brenda një tuneli, emrat prapa skajit të largët zakonisht zgjidhen në adresa që ekzistojnë vetëm në atë rrjet. Një zonë private si corp.internal nuk ka delegim publik, prandaj zgjidhësi që e shërben duhet të jetë i arritshëm nga brenda tunelit. I njëjti mekanizëm shërben një qëllim të dytë: kur kërkimet do të dilnin ndryshe përmes ofruesit tënd, një zgjidhës në anën e largët e mban kërkimin brenda rrugës së kriptuar. Prandaj adresa e serverit DNS vjen si pjesë e politikës së lidhjes dhe jo si një cilësim global që zgjodhe një herë për makinën.

Adresa vetëm nuk vendos asgjë. Një zgjidhës mund të përgjigjet vetëm nëse ka një rrugë drejt tij, dhe dështimi më i zakonshëm është një zgjidhës i arritshëm vetëm sa kohë tuneli është lart. Kur tuneli bie dhe politika mbetet, kërkimet shkojnë në një adresë pa rrugë, dhe simptomi është skadimi i kohës dhe jo një gabim i pastër. Ky ndryshim ka rëndësi kur lexon rezultatin e testit të radhës, sepse skadimi i kohës i dërgon njerëzit në cilësime transporti që nuk ishin përfshirë kurrë.

Krahaso dy modelet para se të krahasosh përgjigjet

Tuneli i plotë dhe DNS i ndarë prodhojnë pritshmëri të kundërta, dhe asnjëri nuk është defekt. Nën një tunel të plotë çdo kërkim mund të kalojë te ofruesi ose te zgjidhësi i korporatës, prandaj një përgjigje ndryshe e emrave publikë pas lidhjes është e pritshme. Nën DNS të ndarë vetëm domenet e listuara shkojnë te zgjidhësi privat ndërsa gjithçka tjetër mbetet lokale; në Windows lista e domeneve jeton në Name Resolution Policy Table, në macOS në domenet përputhëse të cilësimeve të DNS, dhe në një host systemd-resolved në domenet e rrugëzimit për çdo lidhje.

Ky është krahasimi që duhet bërë i pari, sepse vendos se çfarë konsiderohet defekt. Me DNS të ndarë, një emër publik që përgjigjet nga një zgjidhës i ri është ai që meriton hetim, ndërsa një emër i brendshëm që përgjigjet saktë është sistemi që bën punën e vet. Me një tunel të plotë, anomali është një emër publik që ende përgjigjet nga zgjidhësi i ofruesit tënd. Dokumentacioni i Microsoft për zgjidhjen e emrave të VPN përshkruan rendin e Windows të këtyre rregullave, duke përfshirë mënyrën se si një zë politike përputhëse konsultohet përpara serverëve të vetë përshtatësit.

Në dhomë ka edhe një zgjidhës të tretë që harrohet lehtë. DNS i sigurt i shfletuesit i zgjidh emrat vetë dhe mund të vazhdojë të përgjigjet pasi tuneli ka ndryshuar politikën e sistemit operativ, prandaj një faqe që ngarkohet provon se zgjidhësi i shfletuesit punoi, jo se profili u zbatua. Nëse krahason vetëm atë që tregon shfletuesi, gjysmën e kohës po teston shtresën e gabuar.

Regjistro një vijë bazë me vetëm një variabël

Ndrysho tunelin. Mos ndrysho në të njëjtin hap edhe emrin, mjetin ose prapashtesën e kërkimit. Zgjidh një emër për të cilin të lejohet të kërkosh, shëno çfarë aplikacioni përdore, dhe shkruaj ose adresën që u kthye ose gabimin e saktë. Në Windows Get-DnsClientServerAddress -AddressFamily IPv4 printon serverët për çdo përshtatës dhe Get-DnsClientNrptPolicy printon zërat e politikës; në Linux me systemd-resolved resolvectl status shfaq serverët DNS dhe domenet e rrugëzimit për çdo lidhje; në macOS scutil --dns printon rendin e zgjidhësve që sistemi do të ndjekë vërtet.

Pastaj lidhu përmes kontrolleve të zakonshme të klientit dhe përsërit saktësisht të njëjtat komanda. Ruaj daljen e parë në vend të një kujtese për të, sepse krahasimi është i gjithë qëllimi dhe leximi i dytë pas zbrazjes së cache-s është tashmë një matje tjetër. Nëse vija bazë u mor me shfletuesin përpara dhe ekzekutimi pas lidhjes bëhet në terminal, po krahason dy zgjidhës, jo dy gjendje të një zgjidhësi.

Një kërkim i qartë dhe një kërkim aplikacioni janë teste të ndryshme

Të pyesësh një server të caktuar, me nslookup name 10.20.0.1 ose dig @10.20.0.1 name, provon një gjë: se serveri që emërove përgjigjet kur mund t’i arrish. Ai anashkalon plotësisht logjikën e zgjedhjes, prandaj nuk mund të tregojë nëse sistemi do ta kishte zgjedhur atë server për këtë emër. Përdore për të provuar nëse zgjidhësi i caktuar është i arritshëm, dhe mos e përdor për të provuar politikën.

Një kërkim përmes zgjidhësit lokal e ushtron vërtet zgjedhjen. resolvectl query name kalon të njëjtat rregulla të domeneve të rrugëzimit dhe raporton cili protokoll u përgjigj, Resolve-DnsName në Windows kalon përmes tabelës së politikës dhe cache-s së klientit, dhe scutil --dns tregon rendin që do të ndiqte një kërkim. Ekzekuto të dyja llojet dhe mbaji në kolona të veçanta të shënimeve të tua. Një kërkim i qartë i suksesshëm pranë një kërkimi aplikacioni të dështuar është problem rrugëzimi ose zgjedhjeje, jo një zgjidhës që refuzon të punojë.

Cache-i qëndron midis teje dhe përgjigjes. Sistemi operativ, zgjidhësi stub lokal, shfletuesi dhe cache-i negativ mbajnë të gjithë rezultate, prandaj një kërkim mund të ketë sukses pa dalë as edhe një paketë nga makina. Regjistro rezultatin para se të zbrazësh çdo gjë: ipconfig /flushdns, resolvectl flush-caches ose sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder në macOS. Anashkalo rivendosjen e gjerë të rrjetit në këtë fazë, sepse shkatërron provat që po mbledh ende.

Çfarë do të thotë ndryshimi

Krahaso dy rreshtat e regjistruar dhe klasifiko ndryshimin para se të prekësh një cilësim të vetëm.

Një rresht meriton theks. Një emër që zgjidhet nuk është një shërbim që punon, dhe suksesi i DNS thotë vetëm se u gjet një adresë. Nuk thotë asgjë për përcjelljen, rregullat e murit të zjarrit ose nëse llogaria jote mund ta përdorë fare shërbimin, prandaj përfundo duke testuar aplikacionin real në vend që të supozosh se defekti u tërhoq vetë.

Rikthe vijën bazë dhe verifikoje atë

Shkëputu përmes kontrolleve të vetë klientit në vend që të vrasesh procesin, pastaj rilexo të njëjtat tri komanda. Serverët për çdo lidhje, zërat e politikës dhe përgjigja për emrin tënd të testit duhet të kthehen në vijën bazë që shkruajte më parë. Një zë politike që mbetet pas një shkëputjeje të pastër është defekt real që meriton regjistrim, dhe kjo është arsyeja pse redaktimet manuale të një skedari zgjidhësi të gjeneruar janë zakon i keq: skedari rishkruhet dhe redaktimi zhduket, ose redaktimi mbijeton dhe gozhdon një zgjidhës që nuk ka më rrugë.

Kalo një herë nëpër këtë listë, sipas radhës. Vendos cilin model zbaton profili përpara se të gjykojë çdo rezultat. Mbaj emrin, mjetin dhe prapashtesën fikse në të dy ekzekutimet. Ndaj kërkimin e qartë nga kërkimi i aplikacionit. Lexo politikën efektive, jo vetëm përgjigjen. Zbraz cache-t në fund, pasi krahasimi të jetë shkruar. Verifiko me aplikacionin real, pastaj rinis një herë dhe konfirmo se gjendja e shkëputur është ende e pastër.