dnsmasq não consegue ligar à porta 53: encontre o socket que a ocupa

dnsmasq termina com um erro de endereço já em uso, e o registo nomeia a porta em vez do culpado. Numa máquina que também executa uma VPN, o reflexo é culpar as rotas empurradas, mas uma falha de bind ocorre antes de qualquer cliente enviar uma consulta. Algo já detém o socket, e a tarefa é identificá-lo. Alterações de rota não libertam uma porta.

Cinco passos, nesta ordem: reproduza o erro, liste os ouvintes, compreenda o curinga, atribua a tarefa e depois verifique.

Passo 1: reproduzir e ler o erro

Inicie o dnsmasq em primeiro plano com a mesma configuração que o serviço usa, para que o erro apareça no seu terminal em vez de num registo que tem de adivinhar. Repare na família de endereços e no endereço local da mensagem. Um bind a um endereço específico e um bind ao curinga são falhas diferentes com proprietários diferentes.

Guarde o texto exato. Um endereço em uso, uma falha de permissões e uma interface ausente chegam todos como falha de arranque, e apontam para três reparações diferentes.

Passo 2: listar os proprietários

Liste primeiro os sockets. Um filtro pela porta de origem 53 mostra ambos os transportes e o processo proprietário quando tem privilégios para o ver:

ss -lntup 'sport = :53'

Leia a saída em colunas: transporte, endereço local, porta, processo. Um ouvinte TCP e um ouvinte UDP são sockets separados, por isso parar um não liberta o outro. Um endereço curinga cobre todas as interfaces, o que significa que o endereço da VPN já está ocupado mesmo que nenhuma linha o nomeie. E o nome do processo diz-lhe se se trata de um resolvedor gerido pela distribuição, um contentor ou algo que uma experiência anterior deixou a correr.

Passo 3: a armadilha do curinga

A opção bind-interfaces altera se o dnsmasq liga um socket curinga ou um socket por interface configurada, como descreve a referência do dnsmasq. Sem ela, o dnsmasq pode ligar o curinga e filtrar os pedidos por interface, o que falha imediatamente quando outro daemon detém o curinga. O Linux acrescenta bind-dynamic, que trata de interfaces criadas após o arranque, uma preocupação real quando a interface da VPN só aparece ao ligar.

É por isso que dois daemons que ambos parecem configurados para interfaces diferentes continuam a colidir. O conflito está no socket, não na intenção. Escolha o modo de bind deliberadamente e leia o comportamento documentado para a sua versão antes de o alterar.

Passo 4: atribuir a tarefa

Decida qual daemon responde aos clientes da VPN e qual responde ao anfitrião. Um resolvedor que escuta no endereço do túnel e reencaminha para montante é uma disposição comum; dois resolvedores que cada um assume possuir a porta 53 não é disposição nenhuma.

Depois expresse essa decisão na configuração de cada serviço: endereços de escuta, filtros de interface e reencaminhamento. Altere-os através do proprietário do serviço, seja a unidade da distribuição, o gestor de rede ou o runtime de contentores, para que a alteração sobreviva a um reinício.

Passo 5: verificar o socket, depois o caminho

Após o reinício, confirme que os sockets pretendidos existem antes de testar um cliente. Um daemon que nunca se ligou não pode ser salvo por uma rota, e uma falha de cliente contra um socket corretamente ligado é outro problema com outra solução. Depois verifique a acessibilidade a partir de um cliente no túnel. Só depois vale a pena perguntar se os nomes necessários são resolvidos.

Três resultados separados que devem ser mantidos distintos: o socket existe, o cliente alcança-o, a resposta está correta.

O que não fazer

Não pare um resolvedor desconhecido para libertar a porta sem saber o que depende dele, porque as consultas do próprio anfitrião costumam depender. Não copie uma receita antiga que move o segundo daemon para um endereço de escuta público, pois isso decide como efeito secundário quem pode consultá-lo. E não acrescente reencaminhamento quando a falha era local.

Se a máquina for gerida, registe a decisão de propriedade onde o próximo administrador a encontre. Os conflitos de porta voltam sempre que uma imagem é reconstruída.