dnsmasq ne peut pas se lier au port 53 : trouvez le socket qui le détient

dnsmasq s’arrête sur une adresse déjà utilisée, et le journal nomme le port plutôt que le coupable. Sur une machine qui fait aussi tourner un VPN, le réflexe est d’accuser les routes poussées, mais un échec de liaison survient avant qu’un client n’envoie la moindre requête. Quelque chose détient déjà le socket, et le travail consiste à l’identifier. Les changements de route ne peuvent pas libérer un port.

Cinq étapes, dans cet ordre : reproduire l’erreur, lister les écouteurs, comprendre le joker, attribuer la tâche, puis vérifier.

Étape 1 : reproduire et lire l’erreur

Lancez dnsmasq au premier plan avec la même configuration que celle du service, pour que l’erreur apparaisse dans votre terminal plutôt que dans un journal qu’il faut deviner. Notez la famille d’adresses et l’adresse locale dans le message. Une liaison à une adresse précise et une liaison au joker sont deux échecs différents, avec deux propriétaires différents.

Conservez le texte exact. Une adresse déjà utilisée, un échec de permission et une interface manquante arrivent tous comme un échec de démarrage, et ils désignent trois réparations différentes.

Étape 2 : lister les propriétaires

Listez d’abord les sockets. Un filtre sur le port source 53 montre les deux transports et le processus propriétaire lorsque vous avez le privilège de le voir :

ss -lntup 'sport = :53'

Lisez la sortie en colonnes : transport, adresse locale, port, processus. Un écouteur TCP et un écouteur UDP sont des sockets distincts, donc arrêter l’un ne libère pas l’autre. Une adresse joker couvre toutes les interfaces, ce qui signifie que l’adresse du VPN est déjà prise même si aucune ligne ne la nomme. Et le nom du processus vous dit s’il s’agit d’un résolveur géré par la distribution, d’un conteneur ou de quelque chose qu’une expérience précédente a laissé tourner.

Étape 3 : le piège du joker

L’option bind-interfaces change selon que dnsmasq lie un socket joker ou un socket par interface configurée, comme le décrit la référence dnsmasq. Sans elle, dnsmasq peut lier le joker et filtrer les requêtes par interface à la place, ce qui échoue immédiatement quand un autre démon détient le joker. Linux ajoute bind-dynamic, qui gère les interfaces créées après le démarrage, une vraie préoccupation quand l’interface du VPN n’apparaît qu’à la connexion.

C’est pourquoi deux démons qui semblent tous deux configurés pour des interfaces différentes entrent quand même en collision. Le conflit est au niveau du socket, pas de l’intention. Choisissez le mode de liaison délibérément et lisez le comportement documenté pour votre version avant de le changer.

Étape 4 : attribuer la tâche

Décidez quel démon répond aux clients VPN et lequel répond à l’hôte. Un résolveur qui écoute sur l’adresse du tunnel et transmet en amont est un agencement courant ; deux résolveurs qui supposent chacun posséder le port 53 ne sont pas un agencement du tout.

Exprimez ensuite cette décision dans la configuration de chaque service : adresses d’écoute, filtres d’interface et transfert. Modifiez-les via le propriétaire du service, qu’il s’agisse de l’unité de la distribution, du gestionnaire de réseau ou du moteur de conteneurs, afin que le changement survive à un redémarrage.

Étape 5 : vérifier le socket, puis le chemin

Après le redémarrage, confirmez que les sockets prévus existent avant de tester un client. Un démon qui ne s’est jamais lié ne peut pas être sauvé par une route, et un échec de client face à un socket correctement lié est un autre problème avec une autre correction. Vérifiez ensuite l’accessibilité depuis un client sur le tunnel. C’est seulement après qu’il vaut la peine de demander si les noms requis se résolvent.

Trois résultats distincts à ne pas confondre : le socket existe, le client l’atteint, la réponse est correcte.

Ce qu’il ne faut pas faire

N’arrêtez pas un résolveur inconnu pour libérer le port sans savoir ce qui en dépend, car les recherches de l’hôte lui-même en dépendent généralement. Ne copiez pas une vieille recette qui déplace le second démon sur une adresse d’écoute publique, car cela décide en effet de bord qui peut vous interroger. Et n’ajoutez pas de transfert quand l’échec était local.

Si la machine est gérée, consignez la décision de propriété là où le prochain administrateur la trouvera. Les conflits de port reviennent chaque fois qu’une image est reconstruite.