Pse nslookup zgjidh përmes VPN por shfletuesi nuk mundet
nslookup pyet drejtpërdrejt një server; shfletuesi ndjek zgjidhësit e ndërfaqeve, rregullat NRPT dhe DNS-në e kriptuar. Krahasoni këto rrugë përpara se të ndryshoni VPN-në.
nslookup dërgon një kërkesë te serveri që emërtoni dhe shtyp përgjigjen, prandaj mund të ketë sukses ndërsa çdo skedë e shfletuesit dështon. Shfletuesi i kërkon sistemit operativ të zgjidhë, dhe sistemi peshon zgjidhësit për çdo ndërfaqe, rregullat e politikës së zgjidhjes së emrave dhe vendndodhjen rrjetore të përshtatësit. Më pas shfletuesi mund të shtojë sipër DNS-në e vet të kriptuar. Tri rrugë të ndryshme, një simptom, dhe tuneli zakonisht nuk është pjesa e prishur.
Kontrollimet më poshtë ndjekin ato rrugë nga sistemi nga jashtë. Mos e ndryshoni profilin e VPN derisa të dini cila rrugë u përgjigj dhe cila dështoi.
Tri politika vendosin përgjigjen
Çdo ndërfaqe mban listën e vet të zgjidhësve dhe prapashtesat e kërkimit. Një përshtatës VPN shton serverë ndërsa përshtatësi fizik mban të vetët, dhe sistemi mund të marrë atë që përgjigjet i pari, kështu që një kërkim mund të shërbehet jashtë tunelit pa e zgjedhur askush. Rregullat e tabelës së politikës së zgjidhjes së emrave mund të dërgojnë domenet e zgjedhura te serverët e zgjedhur, kështu shprehet zakonisht split DNS në Windows. Dhe klienti ose porta e VPN-së mund të shtyjnë një adresë zgjidhësi që ekziston vetëm brenda rrjetit privat.
Këta të tre ndërveprojnë në mënyra që nga shfletuesi duken arbitrare. Një zgjidhës i shtyrë në një adresë private pa rrugë përmes tunelit të ndarë bën që çdo kërkim të bllokohet dhe më pas të dështojë. Një rregull politike që mbulon prapashtesën e brendshme dhe tregon një server të fikur prodhon të njëjtin gabim të dukshëm si një rrugë që mungon. Një prapashtesë kërkimi që mungon në përshtatësin VPN e kthen një emër të shkurtër në një kërkesë publike për domenin e gabuar. Secili prej tyre kërkon një riparim tjetër.
Pse shfletuesi bën një pyetje tjetër
nslookup lëshon kërkesën e vet te serveri që zgjedh dhe nuk ndjek as politikën e hapësirës së emrave as cilësimin e DNS-së së kriptuar të shfletuesit. Prandaj një kërkesë me dorë te një zgjidhës publik përgjigjet ndërsa shfletuesi raporton se faqja nuk ekziston. Po krahasoni dy programe, jo dy gjendje të një programi.
Preferenca e familjes së adresave shpjegon vonesën, jo dështimin. Një shfletues që kërkon fillimisht regjistrime IPv6 në një tunel që mbart vetëm IPv4 pret skadimin e afatit përpara se të tërhiqet. Firefox ka mbajtur një preferencë pikërisht për këtë, dhe çaktivizimi i saj është hap diagnostik, jo riparim.
Lexoni listën e zgjidhësve dhe rregullat
Në Windows, printoni atë që mban sistemi përpara se të teorizoni. Get-DnsClientServerAddress shfaq serverët sipas ndërfaqes, Get-DnsClientNrptRule liston rregullat e hapësirës së emrave, dhe Resolve-DnsName përgjigjet emrit të saktë përmes rrugës së sistemit. Krahasoni atë përgjigje me një kërkesë të drejtpërdrejtë te serveri i VPN-së sipas adresës. Kur Resolve-DnsName dështon dhe kërkesa e drejtpërdrejtë ka sukses, i dyshuari është lista e zgjidhësve ose një rregull i hapësirës së emrave.
Kontrolloni edhe vetë emrin. Një emër i shkurtër i brendshëm mund të ketë nevojë për prapashtesën private që ofron vetëm përshtatësi VPN, ndërsa emri plotësisht i kualifikuar zgjidhet mirë. Një paralajmërim certifikate pas një kërkimi të suksesshëm i përket një problemi tjetër.
Zgjidhësi i shtyrë i paarritshëm
Porta ose klienti mund të shtyjnë një adresë zgjidhësi, dhe ajo adresë duhet të jetë e arritshme përmes tunelit. Në një tunel të ndarë, intervali privat që mban zgjidhësin mund të mos jetë ndër rrugët e përfshira, gjë që prodhon një kërkim që nuk merr kurrë përgjigje. Konfirmoni se rruga ekziston, më pas pyesni pikërisht atë adresë përmes tunelit. Ky është dështimi pas gabimit të domenit në shfletues ndërsa një zgjidhës publik ende përgjigjet.
Nëse zgjidhësi është i paarritshëm, riparimi është një rrugë ose një nënrrjet i përfshirë, jo një server tjetër DNS.
DNS i kriptuar anashkalon të gjithë rrugën
Shfletuesit me DNS-over-HTTPS i zgjidhin emrat vetë përmes një lidhjeje HTTPS me një ofrues të zgjedhur. Kur kjo është aktive, zgjidhësi i sistemit dhe rregullat split DNS anashkalohen plotësisht për ato kërkime, kështu që emrat e brendshëm dështojnë në shfletues ndërsa sistemi operativ i zgjidh saktë. Ndodh edhe e kundërta: emra të brendshëm kanë sukses në shfletues përmes një ofruesi që nuk duhej t'i kishte parë kurrë, dhe ky është problem politike, jo lidhjeje.
Vendosni me vetëdije nëse DNS i kriptuar lejohet në pajisjet e menaxhuara, më pas konfiguroni atë përmes sipërfaqes së menaxhimit të shfletuesit që zgjedhja të jetë e dukshme. Lënia te preferenca individuale prodhon një flotë ku i njëjti VPN sillet ndryshe në çdo laptop.
Riparime që përputhen me dështimin
Nëse VPN shtyn zgjidhësin e vet, bëni që tuneli të mbartë trafik drejt tij dhe i njëjti cilësim të jetë i dukshëm në përshtatësit që marrin pjesë në zgjidhje. Nëse faqet lokale nuk zgjidhen më gjatë kohës që jeni të lidhur, shtoni përjashtime të qarta të hapësirës së emrave ose një përcjellës të kushtëzuar në vend që të zëvendësoni zgjidhësin plotësisht. Nëse DNS i kriptuar i shfletuesit anashkalon politikën, ai është cilësimi që duhet ndryshuar. Kurrë mos shtoni një zgjidhës publik për të rregulluar një emër të brendshëm: rrjedh kërkesa private dhe nuk e zgjidh emrin.
Më pas ndani kërkimin nga lidhja. Një emër që zgjidhet në adresën e saktë por refuzon lidhjen është problem shërbimi, firewalle ose certifikate, dhe ndryshimet e DNS nuk e rregullojnë.
Shënoni cila rrugë u përgjigj, cila dështoi dhe çfarë ndryshuat. Raporti i ardhshëm i të njëjtit simptom do të kërkojë atëherë një komandë në vend të një pasdite.