WireGuard DNS a l’iPhone: el domini només és un sufix de cerca

Escriviu una línia amb una adreça de resolutor i un domini d’empresa, esperant que només els noms d’aquest domini utilitzin el resolutor del túnel. Al client d’Apple, ara tots els noms hi van, i els noms curts del domini també es resolen. La línia fa dues coses separades, i només una tracta de quines consultes gestiona el túnel. L’altra és una comoditat d’escriptura que una lectura desitjosa ha elevat a política.

En què es descompon la línia DNS

El client llegeix l’entrada com una llista i classifica cada element per la seva forma. Tot el que sembla una adreça es converteix en un servidor DNS; tot el que sembla un domini es converteix en un sufix de cerca. Tots dos acaben a la configuració del túnel, però en camps diferents. Una línia il·lustrativa per a un túnel que porta un resolutor privat i un domini intern és així.

DNS = 10.24.8.53, lab.internal.example

L’adreça proporciona el resolutor. El domini proporciona un sufix que permet al client escriure un nom curt i al sistema afegir-hi la resta abans de preguntar. Cap dels dos elements diu res sobre limitar el resolutor a aquest domini, i aquesta és la part que la gent espera i no obté. Només un camp de la plataforma pot expressar aquesta restricció, i no és aquest.

Dos camps d’Apple, dues feines diferents

Apple exposa la distinció al seu objecte de configuració DNS. La llista de dominis de cerca es documenta com la llista utilitzada per qualificar noms d’amfitrió d’una sola etiqueta: escriviu un nom d’amfitrió nu i el sistema pot afegir cada sufix per torns. És una regla de compleció, no una regla d’encaminament. Res d’aquesta llista no decideix quin servidor es pregunta.

La llista de dominis de coincidència és una propietat diferent. Decideix quins espais de noms utilitzen aquest conjunt de paràmetres DNS, i una entrada buida significa el domini per defecte i no un sufix concret. generador de paràmetres del túnel de paquets al client d’Apple segueix aquest model. Posa els sufixos de cerca analitzats a la llista de cerca, i quan hi ha servidors, estableix la llista de coincidència a la cadena buida. El resultat és un resolutor del túnel que respon a tot el que el sistema li envia, més un sufix que ajuda amb els noms curts.

Així, un domini en aquesta línia no és un selector d’espai de noms. Afegir-ne un altre no restringeix quines consultes utilitza el túnel, i treure’l tampoc no les amplia. L’única cosa que canvia és quants noms curts es completen.

Per què cada nom encara arriba al resolutor del túnel

Amb l’entrada de coincidència buida, el túnel és un resolutor candidat per als noms ordinaris, no només per al domini de l’empresa. En una configuració de túnel complet això sol importar poc, perquè tot el trànsit ja és al túnel. En un túnel dividit importa molt. Els noms públics ara poden ser resolts per un resolutor que només té una zona privada, i un error sembla un VPN trencat quan en realitat és un resolutor que només respon a una part de l’espai de noms. El túnel va bé, les consultes surten, i les respostes tornen buides.

Hi ha dues reparacions disponibles i són decisions diferents. Feu que el resolutor del túnel sigui un resolutor complet que reenviï els noms públics pel camí aprovat, o deixeu d’enviar-hi noms públics canviant la configuració del client en lloc de la llista de dominis. La primera manté cada consulta al túnel i confia en l’origen superior. La segona manté algunes consultes locals i accepta que els noms privats poden deixar de resoldre’s mentre el túnel està aturat.

Què necessitaria realment un DNS dividit

Una política de resolutor limitada a un espai de noms requereix un client que us permeti expressar-la: feu coincidir dominis a les plataformes d’Apple, o un paràmetre equivalent al producte que feu servir. Un camp de configuració que només accepta servidors i sufixos no pot expressar-la, per molt ben puntuada que estigui. Un perfil pot portar la política perquè descriu una configuració gestionada i no un indici en el moment de connectar. Pot nomenar el domini, els servidors i què hauria de passar quan aquest domini no sigui accessible. Aquesta és la diferència entre un paràmetre i un contracte.

Als dispositius Apple gestionats això normalment es lliura mitjançant un perfil de configuració que porta els paràmetres DNS específics del domini. És un mecanisme diferent del fitxer de configuració de WireGuard, i els dos només poden conviure si el client respecta el perfil. Comproveu com el vostre client anomena realment el camp abans de suposar que els dos productes es comporten igual. Un script wg-quick en un Mac i l’aplicació WireGuard en un iPhone llegeixen línies semblants i les instal·len a través de capes diferents.

Llegiu la configuració instal·lada, no el fitxer

En un Mac podeu inspeccionar amb què ha acabat el sistema, cosa més informativa que rellegir el fitxer que heu escrit. La llista de resolutors mostra quins servidors estan configurats per a quins dominis, i les consultes limitades mostren quin ha guanyat. Un client que malmet la línia ho mostra aquí i no al fitxer que heu escrit. A l’iOS no hi ha cap línia d’ordres equivalent, així que la prova allà és un resultat: un nom privat que es resol pel túnel i un nom públic la resposta del qual revela quin resolutor ha contestat.

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

Aquestes dues ordres imprimeixen la configuració actual del resolutor i els servidors DNS del servei actiu. Si el resolutor del túnel apareix com a resolutor per defecte sense restricció de domini, la configuració fa exactament el que el client ha demanat. Corregiu-ho canviant el mecanisme, no afegint un segon sufix i esperant que el comportament canviï.