dnsmasq kan inte binda port 53: hitta socketen som håller den

dnsmasq avslutas med att adressen redan används, och loggen nämner porten i stället för boven. På en maskin som också kör en VPN är reflexen att skylla på de pushade rutterna, men ett bind-fel inträffar innan någon klient skickar en fråga. Något håller redan socketen, och uppgiften är att identifiera det. Ruttändringar kan inte frigöra en port.

Fem steg i den här ordningen: återskapa felet, lista lyssnarna, förstå wildcardet, tilldela uppgiften och verifiera sedan.

Steg 1: återskapa och läs felet

Starta dnsmasq i förgrunden med samma konfiguration som tjänsten använder, så att felet syns i din terminal i stället för i en logg du måste gissa dig till. Notera adressfamiljen och den lokala adressen i meddelandet. En bind mot en specifik adress och en bind mot wildcardet är olika fel med olika ägare.

Behåll den exakta texten. En adress som används, ett behörighetsfel och ett saknat gränssnitt kommer alla som ett startfel, och de pekar på tre olika reparationer.

Steg 2: lista ägarna

Lista socketarna först. Ett filter på källport 53 visar båda transporterna och den ägande processen när du har behörighet att se det:

ss -lntup 'sport = :53'

Läs utdata i kolumner: transport, lokal adress, port, process. En TCP-lyssnare och en UDP-lyssnare är separata sockets, så att stoppa den ena frigör inte den andra. En wildcard-adress täcker varje gränssnitt, vilket betyder att VPN-adressen redan är upptagen även om ingen rad nämner den vid namn. Och processnamnet berättar om detta är en resolver som distributionen hanterar, en container eller något som ett tidigare experiment lämnade körande.

Steg 3: wildcard-fällan

Alternativet bind-interfaces ändrar om dnsmasq binder en wildcard-socket eller en socket per konfigurerat gränssnitt, som dnsmasq-referensen beskriver. Utan det kan dnsmasq binda wildcardet och i stället filtrera förfrågningar per gränssnitt, vilket misslyckas direkt när en annan daemon håller wildcardet. Linux lägger till bind-dynamic, som hanterar gränssnitt som skapas efter start, en verklig oro när VPN-gränssnittet bara dyker upp vid anslutning.

Därför kolliderar två daemoner som båda ser ut att vara konfigurerade för olika gränssnitt ändå. Konflikten ligger vid socketen, inte vid avsikten. Välj bindningsläge med avsikt och läs det dokumenterade beteendet för din version innan du ändrar det.

Steg 4: tilldela uppgiften

Avgör vilken daemon som svarar VPN-klienter och vilken som svarar värden. En resolver som lyssnar på tunneladressen och vidarebefordrar uppströms är ett vanligt arrangemang; två resolvers som var och en antar att den äger port 53 är inget arrangemang alls.

Uttryck sedan det beslutet i varje tjänsts egen konfiguration: lyssnaradresser, gränssnittsfilter och vidarebefordran. Ändra dem via tjänstens ägare, vare sig det är distributionsenheten, nätverkshanteraren eller container-runtime, så att ändringen överlever en omstart.

Steg 5: verifiera socketen, sedan vägen

Efter omstarten, bekräfta att de avsedda socketarna finns innan du testar en klient. En daemon som aldrig band kan inte räddas av en rutt, och ett klientfel mot en korrekt bunden socket är ett annat problem med en annan lösning. Kontrollera sedan nåbarheten från en klient på tunneln. Först efter det är det värt att fråga om de nödvändiga namnen löses upp.

Tre separata resultat att hålla isär: socketen finns, klienten når den, svaret är korrekt.

Vad man inte ska göra

Stoppa inte en okänd resolver för att frigöra porten utan att veta vad som beror på den, eftersom värdens egna uppslag vanligtvis gör det. Kopiera inte ett gammalt recept som flyttar den andra daemonen till en offentlig lyssnaradress, eftersom det som bieffekt avgör vem som får fråga dig. Och lägg inte till vidarebefordran när felet var lokalt.

Om maskinen hanteras, registrera ägarbeslutet där nästa administratör hittar det. Portkonflikter kommer tillbaka varje gång en avbildning byggs om.