O DNS de OpenVPN queda atrás tras SIGKILL: revise primeiro o propietario

O DNS deixa de resolver despois de que se mate un cliente de OpenVPN, e o primeiro instinto é reescribir /etc/resolv.conf. Ese cambio pode romper un resolutor que funciona mentres o verdadeiro estado obsoleto está noutro sitio. A cuestión que hai que resolver primeiro é quen posúe os axustes de DNS que instalou o túnel, e se a saída que saltou a limpeza realmente importou.

Tres condicións deciden a reparación: o sinal que rematou o proceso, o compoñente do resolutor que recibiu os axustes e se o enlace do túnel aínda existe. Respóndaa nesa orde e a corrección adoita chegar sen tocar ningún ficheiro global.

Decida que tipo de saída ocorreu

Na edición Community de OpenVPN, tanto SIGINT como SIGTERM son peticións de saída ordenada. SIGKILL non se pode capturar: non se pode bloquear nin xestionar, así que ningunha rutina de apagado ten ocasión de executarse. Un Ctrl+C normal nunha terminal en primeiro plano xera SIGINT, mentres que un supervisor que deixa de esperar adoita escalar a SIGKILL. A diferenza importa porque só o segundo caso garante que se saltaron os ganchos.

Executalo dentro de screen ou tmux non cambia que sinal envía Ctrl+C. Comprobe que recibiu realmente o proceso, non que fai normalmente a terminal.

Cando un servizo ou un xestor de conexións executa o túnel, deteña esa conexión concreta a través do seu propietario en lugar de matar o pid. Un xestor pode volver levantar o proceso, deixándolle un túnel novo e un estado do resolutor confuso. Un proceso autónomo só necesita unha petición de terminación normal para que se execute a limpeza.

Decida quen posúe o resolutor

systemd-resolved, un script ao estilo de resolvconf e unha simple reescritura de ficheiro son tres propietarios distintos. O primeiro mantén os axustes por enlace na memoria e descártaos cando a interface desaparece. O segundo mantén rexistros que persisten ata que algo os elimina. O terceiro escribe un ficheiro e deixa a restauración a quen o escribiu.

Identifique o propietario antes de escoller un comando de reparación. O mesmo síntoma ten tres respostas correctas distintas segundo cal estea en uso.

Unha VPN xestionada por NetworkManager pode posuír xa os cambios do resolutor. Engadir un segundo axudante por riba crea dous propietarios que compiten polo mesmo enlace, e o estado do perdedor reaparece na seguinte reconexión. Se un xestor manda, corrixa o axuste no xestor e non nun script.

Que pode e que non pode facer o gancho down

O script down execútase unha vez que se pechou o dispositivo TUN/TAP. Engadir down-pre inverte esa orde e executa o script mentres o dispositivo aínda existe, algo que requiren os axudantes que necesitan o enlace activo.

Ningunha das dúas directivas fai que un gancho se execute tras SIGKILL. Os privilexios tampouco se restauran con down-pre: se o demo baixa a un user ou group ou entra nun chroot, o gancho execútase co acceso que iso lle deixe. Un gancho invocado pode aínda así fallar ao actualizar o resolutor. A referencia de OpenVPN cobre os sinais e o ciclo de vida da retrollamada.

Comprobe o erro propio do gancho xunto ao estado de saída do proceso. Unha limpeza ausente e unha limpeza fallida vense igual no resolutor e distinto nos rexistros.

Comprobe o estado que realmente queda

Nun sistema que usa systemd-resolved, resolvectl status mostra que enlace segue levando os servidores DNS da VPN ou os dominios de enrutamento. Ese enlace pode pertencer a unha conexión que xa non está ou a outro túnel que segue levantado.

Unha interface que desaparece leva consigo a súa configuración por enlace, así que un gancho saltado pode convivir cun DNS limpo. Se o enlace segue rexistrado e o posúe en exclusiva a conexión detida, o xestor propietario debería eliminalo. Se un script máis antigo reescribiu un ficheiro global do resolutor, busque no seu lugar o paso de restauración documentado dese script.

Recupere sen roubar outro enlace

Cando os axustes por enlace son seus de xestionar, resolvectl revert toma o nome do enlace e borra a configuración DNS en tempo de execución para esa interface. É unha acción en tempo de execución e non unha edición de perfil, así que a configuración persistente da conexión queda intacta. Nomee o enlace equivocado e borrará o DNS dun túnel que funciona, por iso o nome sae da saída de estado.

Confirme que /etc/resolv.conf é un enlace simbólico xestionado antes de editalo, logo deteña o cliente con normalidade unha vez máis e volva mirar o DNS. Se a segunda parada limpa, o problema anterior era a saída forzada e non a configuración.