dnsmasq kan ikke binde port 53: find den socket, der holder den

dnsmasq afslutter med en adresse, der allerede er i brug, og loggen nævner porten i stedet for synderen. På en maskine, der også kører en VPN, er refleksen at give de push'ede ruter skylden, men en bind-fejl sker, før nogen klient sender en forespørgsel. Noget holder allerede socket'en, og opgaven er at identificere det. Ruteændringer kan ikke frigøre en port.

Fem trin i denne rækkefølge: gengiv fejlen, list lytterne, forstå wildcard'et, tildel opgaven, og verificér derefter.

Trin 1: gengiv og læs fejlen

Start dnsmasq i forgrunden med den samme konfiguration, som tjenesten bruger, så fejlen vises i din terminal i stedet for i en log, du skal gætte dig til. Bemærk adressefamilien og den lokale adresse i meddelelsen. Et bind til en bestemt adresse og et bind til wildcard'et er forskellige fejl med forskellige ejere.

Behold den præcise tekst. En adresse i brug, en tilladelsesfejl og en manglende grænseflade ankommer alle som en startfejl, og de peger på tre forskellige rettelser.

Trin 2: list ejerne

List socket'erne først. Et filter på kildeport 53 viser begge transportlag og den ejende proces, når du har rettighederne til at se det:

ss -lntup 'sport = :53'

Læs outputtet i kolonner: transport, lokal adresse, port, proces. En TCP-lytter og en UDP-lytter er separate sockets, så at stoppe den ene frigør ikke den anden. En wildcard-adresse dækker hver grænseflade, hvilket betyder, at VPN-adressen allerede er optaget, selv om ingen linje nævner den ved navn. Og procesnavnet fortæller dig, om dette er en resolver styret af distributionen, en container eller noget, et tidligere eksperiment lod køre.

Trin 3: wildcard-fælden

Indstillingen bind-interfaces ændrer, om dnsmasq binder en wildcard-socket eller én socket pr. konfigureret grænseflade, som dnsmasq-referencen beskriver. Uden den kan dnsmasq binde wildcard'et og i stedet filtrere forespørgsler pr. grænseflade, hvilket fejler med det samme, når en anden dæmon holder wildcard'et. Linux tilføjer bind-dynamic, som håndterer grænseflader oprettet efter opstart, en reel bekymring, når VPN-grænsefladen først dukker op ved forbindelse.

Derfor støder to dæmoner, der begge ser ud til at være konfigureret til forskellige grænseflader, stadig sammen. Konflikten er ved socket'en, ikke ved hensigten. Vælg bindingstilstand med vilje, og læs den dokumenterede adfærd for din version, før du ændrer den.

Trin 4: tildel opgaven

Afgør, hvilken dæmon der svarer VPN-klienter, og hvilken der svarer værten. Én resolver, der lytter på tunneladressen og videresender opstrøms er en almindelig ordning; to resolvere, der hver antager, at den ejer port 53, er slet ikke nogen ordning.

Udtryk derefter den beslutning i hver tjenestes egen konfiguration: lytteadresser, grænsefladefiltre og videresendelse. Ændr dem gennem tjenestens ejer, uanset om det er distributionsenheden, netværksadministratoren eller container-runtime'en, så ændringen overlever en genstart.

Trin 5: verificér socket'en, derefter stien

Bekræft efter genstarten, at de tilsigtede sockets findes, før du tester en klient. En dæmon, der aldrig bandt, kan ikke reddes af en rute, og en klientfejl mod en korrekt bundet socket er et andet problem med en anden løsning. Kontroller derefter nåbarheden fra en klient på tunnelen. Først derefter er det værd at spørge, om de krævede navne opløses.

Tre separate resultater at holde fra hinanden: socket'en findes, klienten når den, svaret er korrekt.

Hvad man ikke skal gøre

Stop ikke en ukendt resolver for at frigøre porten uden at vide, hvad der afhænger af den, fordi værtens egne opslag normalt gør. Kopiér ikke en gammel opskrift, der flytter den anden dæmon til en offentlig lytteadresse, da det som bivirkning afgør, hvem der må forespørge dig. Og tilføj ikke en videresendelse, når fejlen var lokal.

Hvis maskinen administreres, skal du registrere ejerskabsbeslutningen der, hvor den næste administrator finder den. Portkonflikter vender tilbage, hver gang et image genopbygges.