dnsmasq kan ikkje binda port 53: finn socketen som held han

dnsmasq avsluttar med at adressa alt er i bruk, og loggen nemner porten i staden for syndaren. På ein maskin som òg køyrer ein VPN, er refleksen å gje dei dytta rutene skulda, men ein bind-feil skjer før nokon klient sender ei spørjing. Noko held alt socketen, og jobben er å identifisere det. Ruteendringar kan ikkje frigjere ein port.

Fem steg i denne rekkjefølgja: reproduser feilen, list opp lyttarane, forstå wildcardet, tildel jobben og verifiser til slutt.

Steg 1: reproduser og les feilen

Start dnsmasq i forgrunnen med same konfigurasjon som tenesta brukar, slik at feilen viser seg i terminalen din i staden for i ein logg du må gjette deg til. Legg merke til adressefamilien og den lokale adressa i meldinga. Ein bind mot ei bestemt adresse og ein bind mot wildcardet er ulike feil med ulike eigarar.

Ta vare på den nøyaktige teksten. Ei adresse i bruk, ein løyvefeil og eit manglande grensesnitt kjem alle som ein startfeil, og dei peikar på tre ulike reparasjonar.

Steg 2: list opp eigarane

List opp socketane først. Eit filter på kjeldeport 53 viser begge transportane og prosessen som eig han når du har rettane til å sjå det:

ss -lntup 'sport = :53'

Les utdata i kolonnar: transport, lokal adresse, port, prosess. Ein TCP-lyttar og ein UDP-lyttar er separate socketar, så å stoppe den eine frigjer ikkje den andre. Ei wildcard-adresse dekkjer kvart grensesnitt, noko som tyder at VPN-adressa alt er oppteken sjølv om inga linje nemner henne ved namn. Og prosessnamnet fortel deg om dette er ein resolver styrt av distribusjonen, ein container eller noko eit tidlegare eksperiment lét køyre.

Steg 3: wildcard-fella

Valet bind-interfaces endrar om dnsmasq bind ein wildcard-socket eller éin socket per konfigurerte grensesnitt, slik dnsmasq-referansen skildrar. Utan det kan dnsmasq binda wildcardet og i staden filtrere førespurnader per grensesnitt, noko som feilar med ein gong når ein annan daemon held wildcardet. Linux legg til bind-dynamic, som handterer grensesnitt som blir laga etter oppstart, ei reell uro når VPN-grensesnittet berre dukkar opp ved tilkopling.

Difor kolliderer to daemonar som begge ser ut til å vere konfigurerte for ulike grensesnitt likevel. Konflikten er ved socketen, ikkje ved hensikta. Vel bindingsmodus med vilje, og les den dokumenterte åtferda for din versjon før du endrar han.

Steg 4: tildel jobben

Avgjer kva daemon som svarar VPN-klientar og kven som svarar verten. Éin resolver som lyttar på tunneladressa og videresender oppstraums er ei vanleg ordning; to resolverar som kvar trur at dei eig port 53 er inga ordning i det heile.

Utrykk deretter den avgjerda i konfigurasjonen til kvar teneste: lyttaradresser, grensesnittfilter og videresending. Endre dei gjennom eigaren av tenesta, anten det er distribusjonseininga, nettverkshandsamaren eller container-runtime, slik at endringa overlever ein omstart.

Steg 5: verifiser socketen, deretter stien

Etter omstarten, stadfest at dei tiltenkte socketane finst før du testar ein klient. Ein daemon som aldri batt, kan ikkje reddast av ei rute, og ein klientfeil mot ein korrekt bunden socket er eit anna problem med ei anna løysing. Kontroller deretter nåbarheita frå ein klient på tunnelen. Først etter det er det verdt å spørje om dei nødvendige namna blir løyste.

Tre separate resultat å halde frå kvarandre: socketen finst, klienten når han, svaret er korrekt.

Kva ein ikkje bør gjere

Ikkje stopp ein ukjend resolver for å frigjere porten utan å vite kva som er avhengig av han, fordi verten sine eigne oppslag vanlegvis er det. Ikkje kopier ei gammal oppskrift som flyttar den andre daemonen til ei open lytteadresse, sidan det som biverknad avgjer kven som kan spørje deg. Og ikkje legg til videresending når feilen var lokal.

Viss maskinen blir administrert, registrer eigedomsavgjerda der den neste administratoren finn henne. Portkonfliktar kjem tilbake kvar gong eit image blir bygd på nytt.