WireGuard DNS pe iPhone: domeniul este doar un sufix de căutare

Scrii o linie cu o adresă de resolver și un domeniu al companiei, așteptându-te ca doar numele din acel domeniu să folosească resolverul tunelului. Pe clientul Apple, acum toate numele merg acolo, iar numele scurte din domeniu sunt și ele rezolvate. Linia face două lucruri separate, și doar unul dintre ele este despre ce interogări gestionează tunelul. Celălalt este o comoditate de tastare promovată la politică de o lectură doritoare.

În ce este descompusă linia DNS

Clientul citește intrarea ca pe o listă și clasifică fiecare element după formă. Orice pare o adresă devine server DNS; orice pare un domeniu devine sufix de căutare. Ambele ajung în setările tunelului, dar în câmpuri diferite. O linie ilustrativă pentru un tunel care transportă un resolver privat și un domeniu intern arată astfel.

DNS = 10.24.8.53, lab.internal.example

Adresa furnizează resolverul. Domeniul furnizează un sufix care îi permite clientului să tasteze un nume scurt, iar sistemului să adauge restul înainte de a întreba. Niciunul dintre ele nu spune nimic despre limitarea resolverului la acel domeniu, și exact aceasta este partea pe care oamenii o așteaptă și nu o primesc. Doar un câmp din platformă poate exprima această restricție, și nu este acesta.

Două câmpuri Apple, două sarcini diferite

Apple expune distincția în obiectul său de setări DNS. Lista de domenii de căutare este documentată ca lista folosită pentru a califica nume de gazdă cu o singură etichetă: tastează un nume de gazdă gol și sistemul poate adăuga fiecare sufix pe rând. Este o regulă de completare, nu o regulă de rutare. Nimic din acea listă nu decide ce server este întrebat.

Lista de domenii de potrivire este o altă proprietate. Decide ce spații de nume folosesc acest set de setări DNS, iar o intrare goală înseamnă domeniul implicit, nu un sufix anume. generator de setări pentru tunelul de pachete în clientul Apple urmează acel model. Pune sufixele de căutare analizate în lista de căutare, iar când există servere setează lista de potrivire la șirul gol. Rezultatul este un resolver de tunel care răspunde la tot ce îi trimite sistemul, plus un sufix care ajută la numele scurte.

Deci un domeniu pe acea linie nu este un selector de spațiu de nume. Adăugarea altuia nu restrânge ce interogări folosește tunelul, iar eliminarea lui nu le lărgește. Singurul lucru care se schimbă este câte nume scurte sunt completate.

De ce fiecare nume ajunge totuși la resolverul tunelului

Cu intrarea de potrivire goală, tunelul este un resolver candidat pentru nume obișnuite, nu doar pentru domeniul companiei. Într-o configurație de tunel complet acest lucru contează de obicei puțin, pentru că tot traficul este oricum în tunel. Într-un tunel divizat contează foarte mult. Numele publice pot fi acum rezolvate de un resolver care deține doar o zonă privată, iar o defecțiune arată ca un VPN stricat când de fapt este un resolver care răspunde doar la o parte a spațiului de nume. Tunelul este în regulă, interogările ies, iar răspunsurile se întorc goale.

Există două remedieri și sunt decizii diferite. Fă din resolverul tunelului un resolver complet care redirecționează numele publice pe calea aprobată, sau oprește trimiterea numelor publice acolo schimbând configurația clientului, nu lista de domenii. Prima păstrează fiecare interogare pe tunel și are încredere în sursa superioară. A doua păstrează unele interogări local și acceptă că numele private pot înceta să se rezolve cât timp tunelul este oprit.

De ce ar avea nevoie de fapt un DNS divizat

O politică de resolver limitată la un spațiu de nume necesită un client care să îți permită să o exprimi: potrivește domenii pe platformele Apple, sau o setare echivalentă în produsul pe care îl folosești. Un câmp de configurare care acceptă doar servere și sufixe nu poate exprima asta, oricum ar fi punctat. Un profil poate purta politica pentru că descrie o configurație administrată, nu un indiciu la momentul conectării. Poate numi domeniul, serverele și ce ar trebui să se întâmple când acel domeniu nu este accesibil. Aceasta este diferența dintre o setare și un contract.

Pe dispozitivele Apple administrate, acest lucru este livrat de obicei printr-un profil de configurare care poartă setările DNS specifice domeniului. Este un mecanism diferit de fișierul de configurare WireGuard, iar cele două pot coexista doar dacă clientul respectă profilul. Verifică cum își numește clientul câmpul de fapt înainte de a presupune că cele două produse se comportă la fel. Un script cu wg-quick pe un Mac și aplicația WireGuard pe un iPhone citesc linii similare și le instalează prin straturi diferite.

Citește setările instalate, nu configurația

Pe un Mac poți inspecta cu ce a rămas sistemul, ceea ce este mai informativ decât să recitești fișierul pe care l-ai scris. Lista de resolveri arată ce servere sunt configurate pentru ce domenii, iar interogările limitate arată care a câștigat. Un client care strică linia arată asta aici, nu în fișierul pe care l-ai scris. Pe iOS nu există o linie de comandă echivalentă, așa că dovada acolo este un rezultat: un nume privat care se rezolvă prin tunel și un nume public al cărui răspuns dezvăluie ce resolver a răspuns.

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

Aceste două comenzi afișează configurația actuală a resolverului și serverele DNS ale serviciului activ. Dacă resolverul tunelului apare ca resolver implicit fără restricție de domeniu, configurația face exact ce a cerut clientul. Remediază asta schimbând mecanismul, nu adăugând un al doilea sufix și sperând că comportamentul se va schimba.