DNS de WireGuard no iPhone: o dominio só é un sufixo de busca

Escribes unha liña cun enderezo de resolutor e un dominio de empresa, esperando que só os nomes dese dominio usen o resolutor do túnel. No cliente de Apple, agora todos os nomes van alí, e os nomes curtos do dominio tamén se resolven. A liña fai dúas cousas separadas, e só unha delas trata de que consultas xestiona o túnel. A outra é unha comodidade de escritura que unha lectura ilusoria elevou a política.

En que se descompón a liña DNS

O cliente le a entrada como unha lista e clasifica cada elemento pola súa forma. Todo o que parece un enderezo convértese nun servidor DNS; todo o que parece un dominio convértese nun sufixo de busca. Ambos acaban na configuración do túnel, pero en campos distintos. Unha liña ilustrativa para un túnel que leva un resolutor privado e un dominio interno vese así.

DNS = 10.24.8.53, lab.internal.example

O enderezo fornece o resolutor. O dominio fornece un sufixo que permite ao cliente escribir un nome curto e ao sistema engadir o resto antes de preguntar. Ningún dos dous di nada sobre limitar o resolutor a ese dominio, e esa é xusto a parte que a xente espera e non obtén. Só un campo da plataforma pode expresar esa restrición, e non é este.

Dous campos de Apple, dous traballos distintos

Apple expón a distinción no seu obxecto de axustes DNS. A lista de dominios de busca está documentada como a lista usada para cualificar nomes de host dunha soa etiqueta: escribe un nome de host espido e o sistema pode engadir cada sufixo por quenda. Esa é unha regra de completado, non unha regra de encamiñamento. Nada desa lista decide que servidor se consulta.

A lista de dominios de coincidencia é unha propiedade distinta. Decide que espazos de nomes usan este conxunto de axustes DNS, e unha entrada baleira significa o dominio predeterminado en vez dun sufixo concreto. xerador de axustes do túnel de paquetes no cliente de Apple segue ese modelo. Coloca os sufixos de busca analizados na lista de busca, e cando hai servidores, establece a lista de coincidencia na cadea baleira. O resultado é un resolutor de túnel que responde a todo o que o sistema lle envía, máis un sufixo que axuda cos nomes curtos.

Así que un dominio nesa liña non é un selector de espazo de nomes. Engadir outro non restrinxe que consultas usa o túnel, e quitalo tampouco as amplía. O único que cambia é cantos nomes curtos se completan.

Por que cada nome segue chegando ao resolutor do túnel

Coa entrada de coincidencia baleira, o túnel é un resolutor candidato para nomes ordinarios, non só para o dominio da empresa. Nunha configuración de túnel completo isto adoita importar pouco, porque todo o tráfico está no túnel de todos xeitos. Nun túnel dividido importa moito. Os nomes públicos agora poden ser resoltos por un resolutor que só ten unha zona privada, e un fallo parece un VPN roto cando en realidade é un resolutor que responde só a parte do espazo de nomes. O túnel está ben, as consultas saen e as respostas volven baleiras.

Hai dous arranxos dispoñibles e son decisións distintas. Fai do resolutor do túnel un resolutor completo que reenvíe os nomes públicos pola ruta aprobada, ou deixa de enviarlle nomes públicos cambiando a configuración do cliente en vez da lista de dominios. O primeiro mantén cada consulta no túnel e confía na orixe superior. O segundo mantén algunhas consultas locais e acepta que os nomes privados poden deixar de resolverse mentres o túnel está caído.

Que necesitaría realmente un DNS dividido

Unha política de resolutor limitada a un espazo de nomes require un cliente que che permita expresala: fai coincidir dominios nas plataformas de Apple, ou un axuste equivalente no produto que uses. Un campo de configuración que só acepta servidores e sufixos non pode expresala, por moi ben puntuado que estea. Un perfil pode levar a política porque describe unha configuración xestionada en vez dunha pista no momento de conectar. Pode nomear o dominio, os servidores e que debería pasar cando ese dominio non sexa accesible. Esa é a diferenza entre un axuste e un contrato.

Nos dispositivos Apple xestionados isto adoita entregarse mediante un perfil de configuración que leva os axustes DNS específicos do dominio. É un mecanismo distinto do ficheiro de configuración de WireGuard, e os dous só poden coexistir se o cliente respecta o perfil. Comproba como chama realmente o teu cliente ao campo antes de supor que os dous produtos se comportan igual. Un script con wg-quick nun Mac e a aplicación WireGuard nun iPhone len liñas parecidas e instálanas a través de capas distintas.

Le os axustes instalados, non o ficheiro

Nun Mac podes inspeccionar con que acabou o sistema, o que é máis informativo que reler o ficheiro que escribiches. A lista de resolutores mostra que servidores están configurados para que dominios, e as consultas delimitadas mostran cal gañou. Un cliente que estraga a liña móstrao aquí en vez de no ficheiro que escribiches. En iOS non hai unha liña de ordes equivalente, así que a proba alí é un resultado: un nome privado que se resolve polo túnel e un nome público cuxa resposta revela que resolutor contestou.

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

Estes dous comandos imprimen a configuración actual do resolutor e os servidores DNS do servizo activo. Se o resolutor do túnel aparece como resolutor predeterminado sen restrición de dominio, a configuración fai exactamente o que pediu o cliente. Corrixe isto cambiando o mecanismo, non engadindo un segundo sufixo e esperando que o comportamento cambie.