WireGuard DNS në iPhone: domeni është vetëm një prapashtesë kërkimi

Ju shkruani një rresht me një adresë zgjidhësi dhe një domen kompanie, duke pritur që vetëm emrat në atë domen të përdorin zgjidhësin e tunelit. Në klientin Apple, tani të gjithë emrat shkojnë atje, dhe emrat e shkurtër në domen zgjidhen gjithashtu. Rreshti bën dy gjëra të veçanta, dhe vetëm njëra prej tyre ka të bëjë me atë se cilat kërkesa trajton tuneli. Tjetra është një lehtësi shtypi që u ngrit në politikë nga një lexim dëshirues.

Në çfarë zbërthehet rreshti DNS

Klienti e lexon hyrjen si listë dhe klasifikon çdo artikull sipas formës. Çdo gjë që duket si adresë bëhet server DNS; çdo gjë që duket si domen bëhet prapashtesë kërkimi. Të dyja përfundojnë në cilësimet e tunelit, por në fusha të ndryshme. Një rresht ilustrues për një tunel që mbart një zgjidhës privat dhe një domen të brendshëm duket kështu.

DNS = 10.24.8.53, lab.internal.example

Adresa siguron zgjidhësin. Domeni siguron një prapashtesë që i lejon klientit të shkruajë një emër të shkurtër dhe sistemit të shtojë pjesën tjetër para se të pyesë. Asnjëri prej tyre nuk thotë asgjë për kufizimin e zgjidhësit në atë domen, dhe pikërisht kjo është pjesa që njerëzit presin dhe nuk e marrin. Vetëm një fushë në platformë mund ta shprehë atë kufizim, dhe nuk është kjo fusha.

Dy fusha Apple, dy detyra të ndryshme

Apple e ekspozon dallimin në objektin e cilësimeve DNS. Lista e domeneve të kërkimit është dokumentuar si lista që përdoret për të kualifikuar emrat e hosteve me një etiketë: shkruani një emër hosti të zhveshur dhe sistemi mund të shtojë çdo prapashtesë me radhë. Ky është një rregull plotësimi, jo një rregull rrugëtimi. Asgjë në atë listë nuk vendos se cili server pyetet.

Lista e domeneve të përputhjes është një veti tjetër. Ajo vendos se cilat hapësira emrash përdorin këtë grup cilësimesh DNS, dhe një hyrje bosh nënkupton domenin e parazgjedhur dhe jo një prapashtesë të caktuar. gjenerator i cilësimeve të tunelit të paketave në klientin Apple ndjek atë model. Ai i vendos prapashtesat e analizuara të kërkimit në listën e kërkimit, dhe kur ka serverë, e vendos listën e përputhjes në vargun bosh. Rezultati është një zgjidhës tuneli që u përgjigjet gjithçkaje që sistemi i dërgon, plus një prapashtesë që ndihmon me emrat e shkurtër.

Pra, një domen në atë rresht nuk është përzgjedhës i hapësirës së emrave. Shtimi i një tjetri nuk i ngushton kërkesat që përdor tuneli, dhe heqja e tij as nuk i zgjeron ato. E vetmja gjë që ndryshon është sa emra të shkurtër plotësohen.

Pse çdo emër ende arrin te zgjidhësi i tunelit

Me hyrjen e përputhjes bosh, tuneli është një zgjidhës kandidat për emrat e zakonshëm, jo vetëm për domenin e kompanisë. Në një konfigurim tuneli të plotë kjo zakonisht ka pak rëndësi, sepse i gjithë trafiku është gjithsesi në tunel. Në një tunel të ndarë kjo ka shumë rëndësi. Emrat publikë tani mund të zgjidhen nga një zgjidhës që mban vetëm një zonë private, dhe një dështim duket si VPN i prishur kur në fakt është një zgjidhës që përgjigjet vetëm për një pjesë të hapësirës së emrave. Tuneli është në rregull, kërkesat dalin, dhe përgjigjet kthehen bosh.

Ka dy rregullime dhe janë vendime të ndryshme. Bëjeni zgjidhësin e tunelit një zgjidhës të plotë që përçon emrat publikë përmes rrugës së miratuar, ose ndaloni dërgimin e emrave publikë atje duke ndryshuar konfigurimin e klientit dhe jo listën e domeneve. I pari e mban çdo kërkesë në tunel dhe i beson burimit të sipërm. I dyti mban disa kërkesa lokalisht dhe pranon që emrat privatë mund të ndalojnë së zgjidhuri sa kohë tuneli është i fikur.

Çfarë do të kërkonte vërtet një DNS i ndarë

Një politikë zgjidhësi e kufizuar në një hapësirë emrash kërkon një klient që ju lejon ta shprehni: përputhni domenet në platformat Apple, ose një cilësim ekuivalent në produktin që përdorni. Një fushë konfigurimi që pranon vetëm serverë dhe prapashtesa nuk mund ta shprehë, sido që të pikëzohet. Një profil mund ta mbajë politikën sepse përshkruan një konfigurim të menaxhuar dhe jo një sugjerim në kohën e lidhjes. Ai mund të emërtojë domenin, serverët dhe çfarë duhet të ndodhë kur ai domen nuk është i arritshëm. Ky është ndryshimi midis një cilësimi dhe një kontrate.

Në pajisjet Apple të menaxhuara kjo zakonisht dorëzohet përmes një profili konfigurimi që mbart cilësimet DNS specifike për domenin. Ky është një mekanizëm i ndryshëm nga skedari i konfigurimit të WireGuard, dhe të dy mund të bashkëjetojnë vetëm nëse klienti respekton profilin. Kontrolloni si e quan klienti juaj fushën në të vërtetë përpara se të supozoni që dy produktet sillen njësoj. Një skript me wg-quick në një Mac dhe aplikacioni WireGuard në një iPhone lexojnë rreshta të ngjashëm dhe i instalojnë ata përmes shtresave të ndryshme.

Lexoni cilësimet e instaluara, jo konfigurimin

Në një Mac mund të inspektoni se ku përfundoi sistemi, gjë që është më informuese sesa të rilexoni skedarin që shkruat. Lista e zgjidhësve tregon cilët serverë janë konfiguruar për cilat domene, dhe kërkesat e kufizuara tregojnë cili fitoi. Një klient që e prish rreshtin e tregon këtu dhe jo në skedarin që shkruat. Në iOS nuk ka rresht komandash ekuivalent, pra prova atje është një rezultat: një emër privat që zgjidhet përmes tunelit, dhe një emër publik përgjigja e të cilit zbulon cili zgjidhës u përgjigj.

scutil --dns | grep -A3 resolver
networksetup -getdnsservers Wi-Fi

Këto dy komanda shtypin konfigurimin aktual të zgjidhësit dhe serverët DNS të shërbimit aktiv. Nëse zgjidhësi i tunelit shfaqet si zgjidhës i parazgjedhur pa kufizim domeni, konfigurimi po bën pikërisht atë që kërkoi klienti. Rregulloni këtë duke ndryshuar mekanizmin, jo duke shtuar një prapashtesë të dytë dhe duke shpresuar që sjellja të ndryshojë.