dnsmasq no puede enlazar el puerto 53: encuentre el socket que lo ocupa

dnsmasq termina con un error de dirección ya en uso, y el registro nombra el puerto en lugar del culpable. En una máquina que también ejecuta una VPN, el reflejo es culpar a las rutas empujadas, pero un fallo de enlace ocurre antes de que ningún cliente envíe una consulta. Algo ya tiene el socket, y la tarea es identificarlo. Los cambios de ruta no pueden liberar un puerto.

Cinco pasos, en este orden: reproduzca el error, liste los oyentes, entienda el comodín, asigne la tarea y luego verifique.

Paso 1: reproduzca y lea el error

Inicie dnsmasq en primer plano con la misma configuración que usa el servicio, para que el error aparezca en su terminal en lugar de en un registro que debe adivinar. Anote la familia de direcciones y la dirección local del mensaje. Un enlace a una dirección concreta y un enlace al comodín son fallos distintos con propietarios distintos.

Conserve el texto exacto. Una dirección en uso, un fallo de permisos y una interfaz ausente llegan todos como un fallo de arranque, y apuntan a tres reparaciones distintas.

Paso 2: liste los propietarios

Liste primero los sockets. Un filtro por el puerto de origen 53 muestra ambos transportes y el proceso propietario cuando tiene privilegios para verlo:

ss -lntup 'sport = :53'

Lea la salida por columnas: transporte, dirección local, puerto, proceso. Un oyente TCP y un oyente UDP son sockets separados, así que detener uno no libera el otro. Una dirección comodín cubre todas las interfaces, lo que significa que la dirección de la VPN ya está ocupada aunque ninguna línea la nombre. Y el nombre del proceso le dice si se trata de un resolutor gestionado por la distribución, un contenedor o algo que dejó en marcha un experimento anterior.

Paso 3: la trampa del comodín

La opción bind-interfaces cambia si dnsmasq enlaza un socket comodín o un socket por interfaz configurada, tal como describe la referencia de dnsmasq. Sin ella, dnsmasq puede enlazar el comodín y filtrar las peticiones por interfaz en su lugar, lo que falla de inmediato cuando otro demonio tiene el comodín. Linux añade bind-dynamic, que gestiona interfaces creadas después del arranque, una preocupación real cuando la interfaz de la VPN solo aparece al conectar.

Por eso dos demonios que ambos parecen configurados para interfaces distintas siguen chocando. El conflicto está en el socket, no en la intención. Elija el modo de enlace a propósito y lea el comportamiento documentado para su versión antes de cambiarlo.

Paso 4: asigne la tarea

Decida qué demonio responde a los clientes de la VPN y cuál al anfitrión. Un resolutor que escucha en la dirección del túnel y reenvía hacia arriba es una disposición habitual; dos resolutores que cada uno asume que posee el puerto 53 no es ninguna disposición.

Luego exprese esa decisión en la configuración de cada servicio: direcciones de escucha, filtros de interfaz y reenvío. Cámbielos a través del propietario del servicio, sea la unidad de la distribución, el gestor de red o el entorno de ejecución de contenedores, para que el cambio sobreviva a un reinicio.

Paso 5: verifique el socket y luego la ruta

Tras el reinicio, confirme que existen los sockets previstos antes de probar un cliente. Un demonio que nunca se enlazó no puede salvarse con una ruta, y un fallo de cliente contra un socket bien enlazado es otro problema con otra solución. Luego compruebe la accesibilidad desde un cliente en el túnel. Solo después vale la pena preguntar si los nombres necesarios se resuelven.

Tres resultados separados que hay que mantener distintos: el socket existe, el cliente lo alcanza, la respuesta es correcta.

Qué no hacer

No detenga un resolutor desconocido para liberar el puerto sin saber qué depende de él, porque las consultas del propio anfitrión suelen depender. No copie una receta antigua que traslade el segundo demonio a una dirección de escucha pública, ya que eso decide como efecto secundario quién puede consultarle. Y no añada un reenvío cuando el fallo era local.

Si la máquina está gestionada, anote la decisión de propiedad donde la encuentre el siguiente administrador. Los conflictos de puerto vuelven cada vez que se reconstruye una imagen.