dnsmasq kann Port 53 nicht binden: Finden Sie den Socket, der ihn belegt

dnsmasq beendet sich mit der Meldung, die Adresse sei bereits in Verwendung, und das Protokoll nennt den Port statt den Verursacher. Auf einem Rechner, auf dem auch ein VPN läuft, ist der Reflex, die gepushten Routen zu beschuldigen, doch ein Bind-Fehler tritt auf, bevor irgendein Client eine Anfrage sendet. Etwas hält den Socket bereits, und die Aufgabe besteht darin, es zu identifizieren. Routenänderungen können keinen Port freigeben.

Fünf Schritte in dieser Reihenfolge: den Fehler reproduzieren, die Listener auflisten, das Wildcard verstehen, die Aufgabe zuweisen und dann verifizieren.

Schritt 1: den Fehler reproduzieren und lesen

Starten Sie dnsmasq im Vordergrund mit derselben Konfiguration, die der Dienst verwendet, damit der Fehler in Ihrem Terminal erscheint statt in einem Protokoll, das Sie erraten müssen. Achten Sie auf die Adressfamilie und die lokale Adresse in der Meldung. Ein Bind an eine bestimmte Adresse und ein Bind an das Wildcard sind verschiedene Fehler mit verschiedenen Eigentümern.

Bewahren Sie den genauen Text auf. Eine Adresse in Verwendung, ein Berechtigungsfehler und eine fehlende Schnittstelle kommen alle als Startfehler an, und sie deuten auf drei verschiedene Reparaturen hin.

Schritt 2: die Eigentümer auflisten

Listen Sie zuerst die Sockets auf. Ein Filter auf Quellport 53 zeigt beide Transporte und den besitzenden Prozess, wenn Sie die Berechtigung haben, ihn zu sehen:

ss -lntup 'sport = :53'

Lesen Sie die Ausgabe spaltenweise: Transport, lokale Adresse, Port, Prozess. Ein TCP-Listener und ein UDP-Listener sind getrennte Sockets, das Stoppen des einen gibt den anderen also nicht frei. Eine Wildcard-Adresse deckt jede Schnittstelle ab, was bedeutet, dass die VPN-Adresse bereits belegt ist, obwohl keine Zeile sie namentlich nennt. Und der Prozessname sagt Ihnen, ob dies ein von der Distribution verwalteter Resolver, ein Container oder etwas ist, das ein früheres Experiment laufen ließ.

Schritt 3: die Wildcard-Falle

Die Option bind-interfaces entscheidet, ob dnsmasq einen Wildcard-Socket oder einen Socket pro konfigurierter Schnittstelle bindet, wie die dnsmasq-Referenz beschreibt. Ohne sie kann dnsmasq das Wildcard binden und Anfragen stattdessen nach Schnittstelle filtern, was sofort scheitert, wenn ein anderer Daemon das Wildcard hält. Linux fügt bind-dynamic hinzu, das Schnittstellen behandelt, die nach dem Start erstellt werden, eine echte Sorge, wenn die VPN-Schnittstelle erst beim Verbinden erscheint.

Deshalb kollidieren zwei Daemons, die beide für unterschiedliche Schnittstellen konfiguriert aussehen, trotzdem. Der Konflikt liegt am Socket, nicht an der Absicht. Wählen Sie den Bind-Modus bewusst und lesen Sie das dokumentierte Verhalten für Ihre Version, bevor Sie ihn ändern.

Schritt 4: die Aufgabe zuweisen

Entscheiden Sie, welcher Daemon VPN-Clients beantwortet und welcher den Host. Ein Resolver, der auf der Tunneladresse lauscht und stromaufwärts weiterleitet ist eine übliche Anordnung; zwei Resolver, von denen jeder annimmt, Port 53 zu besitzen, ist überhaupt keine Anordnung.

Drücken Sie diese Entscheidung dann in der Konfiguration jedes Dienstes aus: Lauschadressen, Schnittstellenfilter und Weiterleitung. Ändern Sie sie über den Eigentümer des Dienstes, sei es die Distributionseinheit, der Netzwerkmanager oder die Container-Runtime, damit die Änderung einen Neustart übersteht.

Schritt 5: den Socket verifizieren, dann den Pfad

Bestätigen Sie nach dem Neustart, dass die beabsichtigten Sockets existieren, bevor Sie einen Client testen. Ein Daemon, der nie gebunden hat, kann nicht durch eine Route gerettet werden, und ein Client-Fehler gegen einen korrekt gebundenen Socket ist ein anderes Problem mit einer anderen Lösung. Prüfen Sie dann die Erreichbarkeit von einem Client im Tunnel. Erst danach lohnt es sich zu fragen, ob die benötigten Namen aufgelöst werden.

Drei getrennte Ergebnisse auseinanderzuhalten: der Socket existiert, der Client erreicht ihn, die Antwort ist korrekt.

Was man nicht tun sollte

Stoppen Sie keinen unbekannten Resolver, um den Port freizugeben, ohne zu wissen, was davon abhängt, weil die eigenen Abfragen des Hosts es normalerweise tun. Kopieren Sie kein altes Rezept, das den zweiten Daemon auf eine öffentliche Lauschadresse verschiebt, denn das entscheidet als Nebenwirkung, wer Sie abfragen darf. Und fügen Sie keine Weiterleitung hinzu, wenn der Fehler lokal war.

Wenn der Rechner verwaltet wird, halten Sie die Eigentumsentscheidung dort fest, wo der nächste Administrator sie findet. Portkonflikte kehren zurück, sobald ein Image neu gebaut wird.