Deter dous servizos de Linux que compiten por /etc/resolv.conf

O DNS volve unha e outra vez ao estado anterior, a reconexión da VPN desfai a súa corrección e alguén do equipo acaba propoñendo bloquear o ficheiro. Esa secuencia é un síntoma, non unha solución: dous compoñentes cren ambos que son donos de /etc/resolv.conf, e gaña o que escribe ao final. Bloquear o ficheiro non resolve o conflito de propiedade, só o agocha mentres rompe o compoñente que vostede realmente quería. Faga as catro comprobacións seguintes en orde e corrixa a disposición no nivel que a posúe, non no ficheiro.

Comprobación 1: é unha ligazón simbólica e cara a que

Empece polo propio ficheiro, porque a ruta que está a editar pode non ser o ficheiro en absoluto. Unha ligazón simbólica ao directorio de execución dun resolutor compórtase de forma completamente distinta a un ficheiro normal que un script de cliente reescribe:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

Unha ligazón a unha ruta stub de systemd-resolved significa que o contido do ficheiro se xera, e a edición manual sobrescribirase no seguinte evento. Un ficheiro normal con liñas nameserver adoita escribilo o cliente ou o gancho DHCP que se executa ao conectar. Ambos son lexítimos; o que importa é saber cal ten antes de cambiar nada.

Comprobación 2: que demonio se está executando

Averigüe que está realmente activo, non que está instalado. Nunha distribución moderna pode haber varios resolutores, e o que ocupa o porto 53 na interface loopback é o que responde:

systemctl status systemd-resolved --no-pager
resolvectl status
ss -lunp | grep ':53'

A saída de estado nomea os servidores DNS por ligazón e os dominios de encamiñamento, que é o mapa que necesita para o DNS dividido. Se os nomes internos deben ir a un servidor interno e todo o demais a un público, esa política vive nos dominios por ligazón, e aplanala nunha lista estática de nameserver dentro do ficheiro perde esa distinción en silencio.

A propia configuración de NetworkManager decide cal destes backends utiliza. O seu axuste dns= no ficheiro de configuración principal escolle entre o seu resolutor interno, dnsmasq, systemd-resolved e none, e pode que a distribución escollese por vostede. Lea ese axuste antes de decidir que significa “arranxar o DNS” neste equipo.

Comprobación 3: que pode escribir o cliente de VPN

Aquí adoita vivir o conflito. Un cliente de VPN que reescribe directamente o ficheiro do resolutor loitará contra calquera servizo que tamén o mantén, e o perdedor é o que se executa primeiro. As versións recentes de OpenVPN poden entregar os axustes de DNS a systemd-resolved en lugar de reescribir o ficheiro, que é o comportamento cooperativo que vostede quere; os scripts máis antigos e os ganchos escritos a man a miúdo chaman un auxiliar obsoleto ou simplemente sobrescriben o ficheiro.

A situación de WireGuard é similar en forma: a configuración da interface non xestiona o DNS, fano as ferramentas que a rodean, mediante un auxiliar de resolutor ou a integración con resolved. Se hai dous deses auxiliares instalados, ambos tentarán aplicar a súa visión do mundo ao conectar.

Lea os ganchos de subida e baixada do cliente en lugar de adiviñar. Unhas poucas liñas de shell en /etc/openvpn/up.sh ou nun directorio equivalente explican un comportamento que doutro xeito parece aleatorio, e tamén son o lugar onde pode facer que o cliente coopere en vez de competir.

Comprobación 4: corríxao no dono, non no ficheiro

Unha vez que coñeza o dono, configure o DNS a través da interface que ese dono admite. Para systemd-resolved iso significa axustes por ligazón e dominios de encamiñamento en lugar dun ficheiro estático; para NetworkManager significa os axustes de DNS do perfil de conexión e o backend escollido; para unha distribución con integración de resolvconf significa escribir a través dese auxiliar.

Non faga o ficheiro inmutable. O atributo inmutable detén as renovacións lexítimas de DHCP e as actualizacións da VPN xunto coas que vostede combatía, e deixa o sistema nun estado no que a seguinte actualización de paquetes ou reconexión produce un fallo que ninguén pode explicar a partir da configuración. Agocha o conflito de propiedade, que é precisamente o que intentaba resolver.

Cando dous compoñentes realmente deben coexistir, déalles traballos distintos. Deixe que o xestor de rede sexa dono da configuración a nivel de interface, deixe que o cliente de VPN achegue DNS e dominios por ligazón mediante a mesma integración, e elimine o terceiro script que escribe o ficheiro directamente. A documentación de systemd-resolved expón os modos que admite e que expón cada un en /etc/resolv.conf. Escolla o modo que encaixe coa cantidade de política que necesita conservar. Se o DNS dividido importa, a disposición stub con dominios por ligazón consérvao, mentres que o modo que copia os servidores upstream ao ficheiro apláñao en silencio.

Verifique despois dunha reconexión, non despois da edición

Un ficheiro que parece correcto xusto despois do seu cambio non demostra nada, porque o seguinte evento aínda non ocorreu. Active a secuencia que antes o rompía: baixe e volva subir o túnel, renove a concesión DHCP ou cambie a interface, e logo lea de novo os mesmos valores.

resolvectl query build.corp.example
resolvectl query example.com
resolvectl status | head -40

Despois confirme a distinción que importa: o nome interno resólvese mediante o servidor interno mentres o nome público segue funcionando. Unha configuración que envía todo ao servidor interno parece correcta ata que alguén tenta chegar a internet polo túnel, e unha configuración que envía todo ao público filtra nomes internos.

Anote o dono, o backend e o modo de ligazón simbólica nas notas de despregamento. Ese único parágrafo converte unha futura actualización de paquetes de incidente en elemento de revisión, e evita que a seguinte persoa redescubra o mesmo conflito cun comando chattr.