El DNS de la VPN s’apropia de cada consulta: arregleu dns-priority de NetworkManager

Connecteu la VPN de l’oficina i de cop cada consulta de nom va al resolutor corporatiu. Els noms públics encara es resolen, així que res no sembla trencat fins que falla el nom d’una impressora local o un registre split-horizon retorna l’adreça de l’oficina. En algunes instal·lacions de Fedora passa el contrari: el resolutor del proveïdor continua responent quan el túnel ja és actiu. Totes dues coses són una sola pregunta — quin resolutor és amo d’aquesta consulta — i als sistemes NetworkManager la resposta viu a les propietats DNS de cada connexió.

Dues connexions, un sol resolutor guanyador

Cada connexió declara una prioritat DNS. Les connexions ordinàries tenen 50 per defecte i les de VPN 0, i guanya el valor més baix. Aquest defecte és la raó perquè una connexió VPN superi en silenci l’enllaç per cable per a cada domini que reclama: zero guanya cinquanta sense que ningú ho triï.

La prioritat ordena els candidats. No limita sobre què es pregunta al guanyador. Una connexió VPN sense domini de cerca reclama-ho tot, així que preferir-la també envia les consultes públiques dins del túnel i, en un disseny de túnel dividit, allà on el resolutor corporatiu reenvia.

La prioritat decideix l’ordre, la llista de cerca decideix la propietat

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

La llista de cerca és la declaració de propietat. Un domini nu com corp.example es converteix en sufix de cerca i en domini d’encaminament. La forma només d’encaminament ~corp.example envia les consultes sota aquest sufix a aquesta connexió sense afegir el domini als noms curts. Aquesta titlla és la diferència entre «pregunta a aquest servidor» i «pregunta a aquest servidor i acaba la meva escriptura».

Feu servir les dues formes quan els usuaris escriuen noms d’amfitrió curts i els registres també s’adrecen amb noms totalment qualificats. Feu servir només la forma d’encaminament quan voleu la divisió sense canviar com el resolutor completa un nom nu.

Aleshores feu explícita la preferència i reactiveu la connexió:

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

Una prioritat negativa és la manera documentada de dir «prefereix aquesta connexió», i definir les dues famílies d’adreces manté el comportament coherent en un amfitrió amb connectivitat IPv6. Canviar la propietat sense reactivar la connexió no canvia res del que s’executa ara, per això la seqüència acaba amb un up explícit.

Deixeu que systemd-resolved mantingui la divisió

El connector dnsmasq per defecte aboca les consultes en un sol resolutor local, així que la separació per enllaç queda grollera. systemd-resolved exposa la divisió per enllaç, i resolvectl query anomena l’enllaç que ha respost.

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

Després d’això, l’enllaç corporatiu porta corp.example i un resolutor públic serveix la resta. Quan una consulta arriba a l’enllaç equivocat, l’ordre anomena l’enllaç que hi ha respost, i saber-ho val més que saber només l’adreça.

Adapteu el disseny de DNS al tipus de túnel

Els dissenys de privadesa que ho envien tot pel túnel no haurien de portar una llista de divisió, perquè tornaria els noms públics al resolutor local i desfaria la intenció. Els dissenys de túnel dividit en necessiten una: sense ella el resolutor corporatiu veu cada consulta pública, i la configuració es trenca en el moment que cau el túnel.

Després hi ha el kill switch que bloqueja el DNS fora del túnel. Els noms es resolen per a les zones del túnel i fallen a tota la resta mentre la connexió és perfectament sana. Les respostes viables són un permís explícit per al resolutor de la LAN o una memòria cau local que només reenvia la zona corporativa, i qualsevol de les dues és una excepció amb amo i no un defecte del túnel.

Un perfil que reescriu la configuració del resolutor en arrencar la interfície es comporta gairebé igual: un cop el resolutor local és inabastable, només es resoldran els noms que el túnel coneix. Sigui quin sigui el mecanisme aplicable, apunteu quins noms han de funcionar en cada estat i doneu aquesta llista a qui atén els informes.

Verifiqueu per enllaç i després una altra vegada en reconnectar

Pregunteu un nom intern i un de públic, i mireu on va realment la consulta. Una pàgina de comprovació de fuites us diu quin resolutor ha respost, no quin enllaç ha triat el sistema, així que no diu res de l’ordenació que acabeu de configurar.

Torneu a executar les dues consultes després de desconnectar i reconnectar. Les prioritats es tornen a aplicar quan una connexió s’activa, i un enllaç simbòlic antic pot sobreviure a una actualització que ningú recorda. El que voleu tenir escrit al final és quin resolutor és amo de quin sufix, més una comprovació que encara valgui demà.