dnsmasq non pode enlazar o porto 53: atope o socket que o ocupa

dnsmasq remata cun erro de enderezo xa en uso, e o rexistro nomea o porto en lugar do culpable. Nunha máquina que tamén executa unha VPN, o reflexo é culpar as rutas empurradas, pero un fallo de enlace ocorre antes de que ningún cliente envíe unha consulta. Algo xa ten o socket, e a tarefa é identificalo. Os cambios de ruta non poden liberar un porto.

Cinco pasos, nesta orde: reproduza o erro, liste os oíntes, entenda o comodín, asigne a tarefa e logo verifique.

Paso 1: reproduza e lea o erro

Inicie dnsmasq en primeiro plano coa mesma configuración que usa o servizo, para que o erro apareza no seu terminal en lugar dun rexistro que debe adiviñar. Anote a familia de enderezos e o enderezo local da mensaxe. Un enlace a un enderezo concreto e un enlace ao comodín son fallos distintos con propietarios distintos.

Conserve o texto exacto. Un enderezo en uso, un fallo de permisos e unha interface ausente chegan todos como un fallo de arranque, e apuntan a tres reparacións distintas.

Paso 2: liste os propietarios

Liste primeiro os sockets. Un filtro polo porto de orixe 53 mostra ambos os transportes e o proceso propietario cando ten privilexios para velo:

ss -lntup 'sport = :53'

Lea a saída por columnas: transporte, enderezo local, porto, proceso. Un oínte TCP e un oínte UDP son sockets separados, así que deter un non libera o outro. Un enderezo comodín cobre todas as interfaces, o que significa que o enderezo da VPN xa está ocupado aínda que ningunha liña o nomee. E o nome do proceso dille se se trata dun resolutor xestionado pola distribución, un contedor ou algo que deixou en marcha un experimento anterior.

Paso 3: a trampa do comodín

A opción bind-interfaces cambia se dnsmasq enlaza un socket comodín ou un socket por interface configurada, tal como describe a referencia de dnsmasq. Sen ela, dnsmasq pode enlazar o comodín e filtrar as peticións por interface no seu lugar, o que falla de inmediato cando outro demonio ten o comodín. Linux engade bind-dynamic, que xestiona interfaces creadas despois do arranque, unha preocupación real cando a interface da VPN só aparece ao conectar.

Por iso dous demonios que ambos parecen configurados para interfaces distintas seguen chocando. O conflito está no socket, non na intención. Escolla o modo de enlace a propósito e lea o comportamento documentado para a súa versión antes de cambialo.

Paso 4: asigne a tarefa

Decida que demonio responde aos clientes da VPN e cal ao anfitrión. Un resolutor que escoita no enderezo do túnel e reenvía cara arriba é unha disposición habitual; dous resolutores que cada un asume que posúe o porto 53 non é ningunha disposición.

Logo exprese esa decisión na configuración de cada servizo: enderezos de escoita, filtros de interface e reenvío. Cámbieos a través do propietario do servizo, sexa a unidade da distribución, o xestor de rede ou a contorna de execución de contedores, para que o cambio sobreviva a un reinicio.

Paso 5: verifique o socket e logo a ruta

Tras o reinicio, confirme que existen os sockets previstos antes de probar un cliente. Un demonio que nunca se enlazou non se pode salvar cunha ruta, e un fallo de cliente contra un socket ben enlazado é outro problema con outra solución. Logo comprobe a accesibilidade desde un cliente no túnel. Só despois paga a pena preguntar se os nomes necesarios se resolven.

Tres resultados separados que hai que manter distintos: o socket existe, o cliente o alcanza, a resposta é correcta.

Que non facer

Non deteña un resolutor descoñecido para liberar o porto sen saber que depende del, porque as consultas do propio anfitrión adoitan depender. Non copie unha receita antiga que traslada o segundo demonio a un enderezo de escoita público, xa que iso decide como efecto secundario quen pode consultarlle. E non engada un reenvío cando o fallo era local.

Se a máquina está xestionada, anote a decisión de propiedade onde a atope o seguinte administrador. Os conflitos de porto volven cada vez que se reconstrúe unha imaxe.