dnsmasq kan ikke binde port 53: finn socketen som holder den

dnsmasq avslutter med at adressen allerede er i bruk, og loggen nevner porten i stedet for synderen. På en maskin som også kjører en VPN, er refleksen å gi de dyttede rutene skylden, men en bind-feil skjer før noen klient sender en spørring. Noe holder allerede socketen, og jobben er å identifisere det. Ruteendringer kan ikke frigjøre en port.

Fem trinn i denne rekkefølgen: reproduser feilen, list opp lytterne, forstå wildcardet, tilordne jobben og verifiser til slutt.

Trinn 1: reproduser og les feilen

Start dnsmasq i forgrunnen med samme konfigurasjon som tjenesten bruker, slik at feilen vises i terminalen din i stedet for i en logg du må gjette deg til. Legg merke til adressefamilien og den lokale adressen i meldingen. En bind mot en bestemt adresse og en bind mot wildcardet er forskjellige feil med forskjellige eiere.

Ta vare på den nøyaktige teksten. En adresse i bruk, en tillatelsesfeil og et manglende grensesnitt kommer alle som en startfeil, og de peker på tre forskjellige reparasjoner.

Trinn 2: list opp eierne

List opp socketene først. Et filter på kildeport 53 viser begge transportene og den eide prosessen når du har rettighetene til å se det:

ss -lntup 'sport = :53'

Les utdata i kolonner: transport, lokal adresse, port, prosess. En TCP-lytter og en UDP-lytter er separate sockets, så å stoppe den ene frigjør ikke den andre. En wildcard-adresse dekker hvert grensesnitt, noe som betyr at VPN-adressen allerede er opptatt selv om ingen linje nevner den ved navn. Og prosessnavnet forteller deg om dette er en resolver styrt av distribusjonen, en container eller noe et tidligere eksperiment lot kjøre.

Trinn 3: wildcard-fellen

Valget bind-interfaces endrer om dnsmasq binder en wildcard-socket eller én socket per konfigurerte grensesnitt, slik dnsmasq-referansen beskriver. Uten det kan dnsmasq binde wildcardet og i stedet filtrere forespørsler per grensesnitt, noe som feiler umiddelbart når en annen daemon holder wildcardet. Linux legger til bind-dynamic, som håndterer grensesnitt som opprettes etter oppstart, en reell bekymring når VPN-grensesnittet bare dukker opp ved tilkobling.

Derfor kolliderer to daemoner som begge ser ut til å være konfigurert for forskjellige grensesnitt likevel. Konflikten er ved socketen, ikke ved hensikten. Velg bindingsmodus med vilje, og les den dokumenterte oppførselen for din versjon før du endrer den.

Trinn 4: tilordne jobben

Avgjør hvilken daemon som svarer VPN-klienter og hvilken som svarer verten. Én resolver som lytter på tunneladressen og videresender oppstrøms er en vanlig ordning; to resolvere som hver antar at den eier port 53 er ikke noen ordning i det hele tatt.

Uttrykk deretter den beslutningen i hver tjenestes egen konfigurasjon: lytteadresser, grensesnittfiltre og videresending. Endre dem gjennom tjenestens eier, enten det er distribusjonsenheten, nettverksbehandleren eller container-runtimeen, slik at endringen overlever en omstart.

Trinn 5: verifiser socketen, deretter stien

Etter omstarten, bekreft at de tiltenkte socketene finnes før du tester en klient. En daemon som aldri bandt, kan ikke reddes av en rute, og en klientfeil mot en korrekt bundet socket er et annet problem med en annen løsning. Kontroller deretter nåbarheten fra en klient på tunnelen. Først etter det er det verdt å spørre om de nødvendige navnene løses opp.

Tre separate resultater å holde fra hverandre: socketen finnes, klienten når den, svaret er korrekt.

Hva man ikke bør gjøre

Ikke stopp en ukjent resolver for å frigjøre porten uten å vite hva som avhenger av den, fordi vertens egne oppslag vanligvis gjør det. Ikke kopier en gammel oppskrift som flytter den andre daemonen til en offentlig lytteadresse, siden det som bivirkning avgjør hvem som kan spørre deg. Og ikke legg til videresending når feilen var lokal.

Hvis maskinen administreres, registrer eierskapsbeslutningen der den neste administratoren finner den. Portkonflikter kommer tilbake hver gang et image bygges på nytt.