Eliminar un registro VPN obsoleto de la base de datos de resolvconf

Un nombre interno todavía se resuelve hacia el servidor VPN un día después de que el túnel se cerró, y el archivo del resolutor sigue volviendo con esa entrada. Donde resolvconf de Debian posee el estado, ese archivo se ensambla a partir de registros de proveedores, y uno de ellos es el resto. Borrar el registro lleva un minuto; demostrar que es seguro borrarlo es el trabajo de verdad. Estas puertas avanzan en orden, y una puerta fallida termina el procedimiento en lugar de enviarlo al siguiente paso.

Confirme que resolvconf posee el estado

Identifique primero al dueño, porque el mismo síntoma bajo systemd-resolved necesita otros comandos y otra reparación. El paquete resolvconf mantiene una base de datos bajo /run/resolvconf y apunta /etc/resolv.conf al archivo que construye a partir de esa base. Dos lecturas resuelven la cuestión: el destino del enlace simbólico y si el paquete está instalado y activo. Un destino bajo /run/systemd/resolve significa el otro diseño, donde nada de lo que sigue se aplica.

dpkg -l resolvconf | tail -1
ls -l /etc/resolv.conf
systemctl is-active resolvconf.service

Si el enlace apunta a otro sitio o falta el paquete, deténgase aquí. Un envoltorio de compatibilidad que tomó prestado el nombre, distribuido por otro gestor de resolutores, no es dueño de esta base de datos.

La base de datos guarda entradas, no la respuesta

La base de datos guarda entradas y el archivo es una salida, así que listar las entradas es la única forma de ver qué programa instaló la entrada que quiere quitar. Los registros son cortos, y sus claves son los asideros que necesitará más adelante. Léalos antes de decidir cuál está obsoleto, porque un nombre que parece una interfaz VPN puede pertenecer a otro cliente. Mantenga las direcciones privadas y los dominios de búsqueda internos fuera de los diagnósticos compartidos; normalmente la clave sola identifica el registro.

sudo resolvconf --list
sudo resolvconf -i

El primer comando imprime los registros suministrados sin procesarlos, y el segundo lista las interfaces que actualmente proporcionan configuración DNS. Las claves se construyen convencionalmente a partir de un nombre de interfaz más el programa proveedor. El manual de resolvconf describe la base de datos a la que dirigen esas claves.

Copie la clave de la salida en lugar de reconstruirla. Una entrada no se llama tun0 solo porque un script antiguo usara ese nombre.

Demuestre que el registro no tiene dueño

Un registro es seguro de borrar cuando ninguna conexión viva lo instaló. Correlacione la clave con la conexión que lo creó y luego confirme que esa conexión desapareció. Esa correlación es toda la puerta, y es el paso que más a menudo se omite de camino al comando de borrado. Si la evidencia es ambigua, trate el registro como vivo y deténgase.

Los nombres de proceso son evidencia débil. OpenConnect llama a vpnc-script, así que comprobar si hay un proceso vpnc no dice nada sobre qué registro es el actual. Una conexión nueva también puede reutilizar un nombre de interfaz que dejó una antigua, lo que hace que la clave parezca más vieja de lo que es. Compare la dirección del servidor dentro del registro con las direcciones de túneles que siguen activos, y deténgase si coinciden.

Una desconexión normal a través del gestor propietario es el primer remedio. Retira lo que esa conexión instaló y deja intactos a los demás proveedores.

Compruebe la eliminación y la reescritura

Con el registro confirmado como obsoleto, bórrelo por la clave exacta y luego lea el resultado en lugar de suponerlo. El comando cambia el estado del resolutor para cada aplicación del host, así que ejecútelo en una ventana que controle. Ponga la clave entre comillas, porque contiene caracteres que el shell expandiría de otro modo. El marcador de posición del bloque representa la clave que copió de la lista, no una cadena literal.

sudo resolvconf -d "RECORD_KEY_FROM_THE_LIST"
sudo resolvconf --list
resolvectl query host.corp.example || getent hosts host.corp.example

El borrado ejecuta los scripts de actualización cuando la actualización está habilitada; con las actualizaciones deshabilitadas aplaza la actualización, así que un registro eliminado y un archivo reescrito son eventos separados. Vuelva a leer la lista y confirme que la clave desapareció antes de mirar el archivo. Luego consulte un nombre que aún debería resolverse a través de los proveedores restantes y un nombre público, y compare ambos con lo que vio antes del cambio. Si un nombre privado deja de resolverse del todo, ese registro todavía lo llevaba.

resolvconf -u solo ejecuta esos scripts de actualización. Nunca identifica ni borra un registro obsoleto, y reconstruir a partir de entradas obsoletas reproduce el mismo archivo no deseado.

Un gancho de desconexión asesinado deja el registro atrás

Una limpieza puntual restaura el estado de hoy, y el siguiente apagado interrumpido vuelve a poner el registro. Recorra la ruta de desmontaje: el gancho de desconexión del cliente, el ayudante que ese gancho llama y qué pasa cuando se mata cualquiera de los dos. Un apagado interrumpido es el origen habitual, porque el gancho no llegó a ejecutarse. Registre el estado de salida del gancho una vez y sabrá si falla en silencio.

Mantenga la configuración y la limpieza bajo un solo dueño. Un segundo script que adivina nombres de interfaz acabará borrando el registro de otra conexión, lo que es peor que la entrada obsoleta con la que empezó. El dueño también debería decidir cuándo un registro está obsoleto, porque sabe qué conexión lo instaló.

Luego ejercite el ciclo de vida: conéctese, desconéctese, liste los registros otra vez. Que la entrada desaparezca por sí sola es la única prueba de que la reparación aguanta.