O DNS da VPN fica con cada consulta: corrixe dns-priority en NetworkManager

Conecta a VPN da oficina e de súpeto cada consulta de nome vai ao resolutor corporativo. Os nomes públicos seguen resolvendo, así que nada parece roto ata que falla o nome dunha impresora local ou un rexistro split-horizon devolve o enderezo da oficina. Nalgunhas instalacións de Fedora ocorre o contrario: o resolutor do provedor segue respondendo cando o túnel xa está levantado. As dúas cousas son unha soa pregunta — que resolutor posúe esta consulta — e nos sistemas NetworkManager a resposta vive nas propiedades DNS de cada conexión.

Dúas conexións, un resolutor gañador

Cada conexión declara unha prioridade DNS. As conexións normais teñen 50 por defecto e as de VPN 0, e gaña o valor máis baixo. Ese defecto é a razón de que unha conexión VPN supere en silencio a ligazón por cable para cada dominio que reclama: cero gaña a cincuenta sen que ninguén o escolla.

A prioridade ordena os candidatos. Non limita sobre que se pregunta ao gañador. Unha conexión VPN sen dominio de busca reclama todo, así que preferila tamén envía as consultas públicas dentro do túnel e, nun deseño de túnel dividido, cara a onde o resolutor corporativo reenvía.

A prioridade decide a orde, a lista de busca decide a propiedade

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

A lista de busca é a declaración de propiedade. Un dominio espido como corp.example convértese nun sufixo de busca e nun dominio de encamiñamento. A forma só de encamiñamento ~corp.example envía as consultas baixo ese sufixo a esta conexión sen engadir o dominio aos nomes curtos. Ese til é a diferenza entre «pregunta a este servidor» e «pregunta a este servidor e remata a miña escritura».

Usa ambas as formas cando os usuarios escriben nomes de host curtos e os rexistros tamén se enderezan con nomes totalmente cualificados. Usa só a forma de encamiñamento cando queiras a división sen cambiar como o resolutor completa un nome espido.

Despois fai explícita a preferencia e reactiva:

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"

Unha prioridade negativa é a forma documentada de dicir «prefire esta conexión», e definir as dúas familias de enderezos mantén o comportamento coherente nun equipo con conectividade IPv6. Cambiar a propiedade sen reactivar a conexión non cambia nada do que está a correr agora, por iso a secuencia remata cun up explícito.

Deixa que systemd-resolved manteña a división

O complemento dnsmasq por defecto canaliza as consultas nun só resolutor local, así que a separación por ligazón queda grosa. systemd-resolved expón a división por ligazón, e resolvectl query nomea a ligazón que respondeu.

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

Despois diso a ligazón corporativa leva corp.example e un resolutor público serve o resto. Cando unha consulta chega á ligazón incorrecta, o comando nomea a ligazón que lle respondeu, e sabelo vale máis que saber só o enderezo.

Axusta o deseño de DNS ao tipo de túnel

Os deseños de privacidade que o envían todo polo túnel non deberían levar unha lista de división, porque devolvería os nomes públicos ao resolutor local e desfaría a intención. Os deseños de túnel dividido necesitan unha: sen ela o resolutor corporativo ve cada consulta pública, e a configuración rompe no momento en que cae o túnel.

Logo está o kill switch que bloquea o DNS fóra do túnel. Os nomes resólvense para as zonas do túnel e fallan en todo o demais mentres a conexión está perfectamente sá. As respostas viables son un permiso explícito para o resolutor da LAN ou unha caché local que só reenvía a zona corporativa, e calquera das dúas é unha excepción con dono e non un defecto do túnel.

Un perfil que reescribe a configuración do resolutor ao arrincar a interface compórtase case igual: unha vez que o resolutor local é inalcanzable, só se resolverán os nomes que coñece o túnel. Calquera que sexa o mecanismo aplicable, anota que nomes deben funcionar en cada estado e pasa esa lista a quen atenda os informes.

Verifica por ligazón e despois outra vez tras reconectar

Pregunta un nome interno e un público, e mira cara a onde vai realmente a consulta. Unha páxina de comprobación de fugas diche que resolutor respondeu, non que ligazón escolleu o sistema, así que non di nada sobre a orde que acabas de configurar.

Executa as dúas consultas outra vez tras desconectar e reconectar. As prioridades volven aplicarse cando se activa unha conexión, e unha ligazón simbólica vella pode sobrevivir a unha actualización que ninguén recorda. O que queres deixar escrito ao final é que resolutor posúe que sufixo, máis unha comprobación que siga valendo mañá.