VPN-ja juaj shtyn tre serverë DNS: cili përgjigjet?

Hapni faqen e cilësimeve pas lidhjes dhe tre adresa DNS renditen; pyetja e auditimit është cila prej tyre trajtoi kërkesën tuaj të fundit. Vetëm numri nuk përgjigjet asgjë, sepse një shtytje klienti, një ndërfaqe fizike dhe një politikë për domen shkruajnë të gjitha në të njëjtin pamje. Këto zëra mbajnë fusha të ndryshme, dhe fusha, jo pozicioni, vendos kush përgjigjet. Filloni duke i ndarë burimet dhe më pas provoni atë që zotëron emrin që ju intereson.

Pse lista është më e gjatë se profili juaj

Një klient VPN shtyn adresa zgjidhësi për lidhjen e tunelit, dhe sistemi operativ i mban ato pranë asaj që ndërfaqja fizike kishte tashmë. Një ruter, një qira DHCP korporative, një VPN i dytë dhe një politikë për domen kontribuojnë secili me zërin e vet. Prandaj tre adresa në faqe mund të nënkuptojnë tre fusha, jo tre kandidatë për një punë. Të lexosh numrin si provë e një rrjedhjeje është gabimi i parë i këtij auditimi.

Brenda një ndërfaqeje klienti vërtet provon serverat e tij me radhë, kështu që një listë e renditur nuk është e pakuptimtë. Ajo që nuk është radhë është pamja e bashkuar, ku zërat nga profili, lidhja fizike dhe rregullat për domen qëndrojnë krah për krah pa një renditje të vetme. Ai dallim vendos çfarë provoni: radha shpjegon sjelljen brenda një fushe, dhe fusha shpjegon gjithçka tjetër.

DNS i kriptuar e thyen pamjen nga brenda një aplikacioni. Një shfletues ose klient bisede me zgjidhësin e vet DNS-over-HTTPS dërgon kërkesat plotësisht jashtë listës së sistemit operativ, kështu që adresat në faqen e cilësimeve përshkruajnë trafik që aplikacioni nuk e krijoi kurrë. Kontrolloni cilësimin e zgjidhësit të vetë aplikacionit përpara se të fajësoni profilin për një emër që doli gabim.

Çfarë thotë secila prej tre kontrolleve

Secili burim lë gjurmën e vet në një vend tjetër, dhe asnjë komandë e vetme nuk i tregon të gjitha. Ky është hartëzimi që ia vlen të mbahet pranë faqes së cilësimeve:

Në një sistem që përdor systemd-resolved, resolvectl status është autoritative, sepse raporton DNS për çdo lidhje bashkë me domenet e rrugëtimit. macOS përgjigjet përmes scutil --dns, i cili rendit zgjidhësit me fushë sipas rendit të provimit. Windows ndan dy gjysmat: Get-DnsClientServerAddress për serverat për ndërfaqe dhe Get-DnsClientNrptPolicy për rregullat e prapashtesës. Ekzekutoni komandën që i përket zgjidhësit të përdorur në të vërtetë, sepse një makinë me mjedis kontejnerësh dhe një zgjidhës desktop mund të ketë më shumë se një të instaluar.

Një zgjidhës rezervë që nuk mund t'i përgjigjet zonës tuaj

Një zë i dytë zakonisht është aty për disponueshmëri, dhe disponueshmëria funksionon vetëm nëse rezerva i njeh emrat. Pyetni një zgjidhës publik për një emër mikpritësi të brendshëm dhe ai kthen NXDOMAIN, ose një përgjigje me shkronjë të egër nga një domen kërkimi që nuk ka lidhje me ju. Një kalim rezervë që askush nuk e kontrolloi prodhon atëherë një ndërprerje pikërisht në momentin që nevojitet.

Split DNS ekziston për ta penguar këtë: prapashtesat e kompanisë shkojnë te një zgjidhës që mban zonën, dhe emrat publikë mbeten në rrugën e paracaktuar. Dizajni është i shëndoshë, dhe varet nga fakti që lista e prapashtesave është e plotë. Microsoft dokumenton politikën e zgjidhësit për çdo prapashtesë që e drejton këtë në Windows, dhe e njëjta ide shfaqet si domene rrugëtimi në systemd-resolved dhe si zgjidhës me fushë në macOS.

Krahasoni zonat për të cilat rezerva mund të përgjigjet me prapashtesat e pranishme në politikë. Ai krahasim e gjen boshllëkun përpara se një përdorues të raportojë se një sajt i brendshëm pushoi së zgjidhuri pas një ndryshimi tuneli.

Pyetni përmes politikës, jo përreth saj

Pyetni përmes zgjidhësit të sistemit operativ, sepse një kërkesë e drejtpërdrejtë te një server anashkalon politikën dhe raporton vetëm atë që do të thoshte ai server. Dallimi midis dy përgjigjeve është e gjithë çështja:

resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53

Nëse kërkesa e sistemit kthen një adresë private ndërsa kërkesa e drejtpërdrejtë kthen NXDOMAIN, politika funksionon dhe pika e dobët është rezerva. Nëse të dyja kthejnë të njëjtën përgjigje publike, emri po zgjidhet jashtë fushës që kishit ndërmend, dhe lista e prapashtesave është vendi ku duhet parë. Ruani të dyja daljet, sepse një debat për zgjidhësin mbyllet më shpejt me dy rreshta sesa me një pamje ekrani të faqes së cilësimeve.

Më pas ushtroni rrugën e dështimit, sepse një rezervë që askush nuk e provoi është një supozim. Kthejeni zgjidhësin e preferuar në një vrimë të zezë për një kërkesë dhe vëzhgoni cila adresë kthehet:

ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32

Fshijeni atë rrugë sapo kërkesa të mbarojë, ose personi tjetër trashëgon një mister. Nëse emrat e brendshëm ende zgjidhen në atë dritare, diçka jashtë fushës së synuar u përgjigj atyre. Nëse përkundrazi skadojnë, rezerva mungon ose është e kufizuar si duhet, dhe vetë regjistri i zgjidhësit ju tregon cila nga të dyja ishte.

Vendosni: mbajeni, kufizojeni ose hiqeni

Mbani një zgjidhës të dytë kur ai i përgjigjet hapësirës së emrave që ju nevojitet dhe mbetet i arritshëm nën profilin. Kufizojeni kur duhet të shohë vetëm një prapashtesë dhe asgjë tjetër, dhe hiqeni kur nuk ka as fushë as qëllim të dokumentuar. Një zë pa punë është një rrjedhje e ardhshme pa përfitim, dhe vlera e paracaktuar e furnizuesit nuk është qëllim.

Regjistroni rezultatin në katër kolona: prapashtesë, zgjidhës, ndërfaqe dhe pronar. Ai rresht i përgjigjet pyetjes së ardhshme të auditimit më shpejt se çdo pamje ekrani, dhe i mbijeton përditësimit të klientit që e rirendit listën në heshtje.