dnsmasq kan poort 53 niet binden: vind de socket die hem bezet houdt

dnsmasq stopt met een fout dat het adres al in gebruik is, en het log noemt de poort in plaats van de schuldige. Op een machine die ook een VPN draait, is de reflex de gepushte routes de schuld te geven, maar een bind-fout treedt op voordat een client een query verstuurt. Iets houdt de socket al vast, en de taak is dat te identificeren. Routewijzigingen kunnen een poort niet vrijmaken.

Vijf stappen, in deze volgorde: reproduceer de fout, lijst de luisteraars op, begrijp de wildcard, wijs de taak toe en verifieer daarna.

Stap 1: de fout reproduceren en lezen

Start dnsmasq op de voorgrond met dezelfde configuratie die de dienst gebruikt, zodat de fout in je terminal verschijnt in plaats van in een log dat je moet raden. Let op de adresfamilie en het lokale adres in de melding. Een bind aan een specifiek adres en een bind aan de wildcard zijn verschillende fouten met verschillende eigenaren.

Bewaar de exacte tekst. Een adres in gebruik, een machtigingsfout en een ontbrekende interface komen allemaal binnen als een startfout, en ze wijzen op drie verschillende reparaties.

Stap 2: de eigenaren opsommen

Lijst eerst de sockets op. Een filter op bronpoort 53 toont beide transporten en het bezittende proces wanneer je de rechten hebt om dat te zien:

ss -lntup 'sport = :53'

Lees de uitvoer in kolommen: transport, lokaal adres, poort, proces. Een TCP-luisteraar en een UDP-luisteraar zijn aparte sockets, dus het stoppen van de ene maakt de andere niet vrij. Een wildcard-adres dekt elke interface, wat betekent dat het VPN-adres al bezet is ook al noemt geen enkele regel het bij naam. En de procesnaam vertelt je of dit een door de distributie beheerde resolver, een container of iets is dat een eerder experiment liet draaien.

Stap 3: de wildcard-val

De optie bind-interfaces bepaalt of dnsmasq een wildcard-socket bindt of één socket per geconfigureerde interface, zoals de dnsmasq-referentie beschrijft. Zonder die optie kan dnsmasq de wildcard binden en aanvragen in plaats daarvan per interface filteren, wat onmiddellijk mislukt wanneer een andere daemon de wildcard bezet. Linux voegt bind-dynamic toe, dat interfaces afhandelt die na het starten worden gemaakt, een echte zorg wanneer de VPN-interface pas bij verbinden verschijnt.

Daarom botsen twee daemons die beide voor verschillende interfaces geconfigureerd lijken toch. Het conflict zit bij de socket, niet bij de bedoeling. Kies de bindmodus bewust en lees het gedocumenteerde gedrag voor jouw versie voordat je die wijzigt.

Stap 4: de taak toewijzen

Bepaal welke daemon VPN-clients beantwoordt en welke de host. Eén resolver die op het tunneladres luistert en stroomopwaarts doorstuurt is een gangbare regeling; twee resolvers die elk aannemen dat ze poort 53 bezitten is helemaal geen regeling.

Druk die beslissing vervolgens uit in de configuratie van elke dienst: luisteradressen, interfacefilters en doorsturen. Wijzig ze via de eigenaar van de dienst, of dat nu de distributie-eenheid, de netwerkbeheerder of de containerruntime is, zodat de wijziging een herstart overleeft.

Stap 5: de socket verifiëren, dan het pad

Bevestig na de herstart dat de bedoelde sockets bestaan voordat je een client test. Een daemon die nooit bond, kan niet door een route worden gered, en een clientfout tegen een correct gebonden socket is een ander probleem met een andere oplossing. Controleer daarna de bereikbaarheid vanaf een client op de tunnel. Pas daarna is het de moeite waard om te vragen of de vereiste namen worden opgelost.

Drie afzonderlijke resultaten om uit elkaar te houden: de socket bestaat, de client bereikt hem, het antwoord is correct.

Wat je niet moet doen

Stop geen onbekende resolver om de poort vrij te maken zonder te weten wat ervan afhangt, want de eigen opzoekingen van de host doen dat meestal wel. Kopieer geen oud recept dat de tweede daemon naar een openbaar luisteradres verplaatst, want dat bepaalt als neveneffect wie jou mag bevragen. En voeg geen doorsturing toe wanneer de fout lokaal was.

Als de machine wordt beheerd, leg de eigendomsbeslissing vast waar de volgende beheerder die vindt. Poortconflicten komen terug telkens wanneer een image opnieuw wordt gebouwd.