dnsmasq ei saa porti 53 siduda: leidke socket, mis seda hoiab

dnsmasq lõpetab töö teatega, et aadress on juba kasutusel, ja logi nimetab pordi, mitte süüdlase. Masinas, kus töötab ka VPN, on esimene reaktsioon süüdistada lükatud marsruute, kuid sidumistõrge tekib enne, kui ükski klient päringu saadab. Miski hoiab socketit juba, ja ülesanne on see tuvastada. Marsruudimuudatused ei saa porti vabastada.

Viis sammu selles järjekorras: korrake viga, loetlege kuulajad, mõistke wildcardi, määrake ülesanne ja seejärel kontrollige.

Samm 1: korrake ja lugege viga

Käivitage dnsmasq esiplaanil sama konfiguratsiooniga, mida teenus kasutab, et viga ilmuks teie terminalis, mitte logis, mida peate oletama. Pange tähele aadressiperekonda ja kohalikku aadressi teates. Sidumine kindla aadressiga ja sidumine wildcardiga on erinevad tõrked erinevate omanikega.

Hoidke täpne tekst alles. Aadress on kasutusel, õiguste tõrge ja puuduv liides saabuvad kõik käivitustõrkena ning osutavad kolmele erinevale parandusele.

Samm 2: loetlege omanikud

Loetlege esmalt socketid. Filter lähtepordil 53 näitab mõlemat transporti ja omavat protsessi, kui teil on selle nägemiseks õigus:

ss -lntup 'sport = :53'

Lugege väljundit veergude kaupa: transport, kohalik aadress, port, protsess. TCP-kuulaja ja UDP-kuulaja on eraldi socketid, seega ühe peatamine ei vabasta teist. Wildcard-aadress katab iga liidese, mis tähendab, et VPN-i aadress on juba hõivatud, isegi kui ükski rida seda nimepidi ei nimeta. Ja protsessi nimi ütleb teile, kas tegu on distributsiooni hallatava resolveriga, konteineriga või millegagi, mille varasem katse tööle jättis.

Samm 3: wildcardi lõks

Valik bind-interfaces muudab seda, kas dnsmasq seob wildcard-socketi või ühe socketi iga konfigureeritud liidese kohta, nagu kirjeldab dnsmasqi viide. Ilma selleta võib dnsmasq siduda wildcardi ja filtreerida päringuid hoopis liidese järgi, mis ebaõnnestub kohe, kui teine deemon wildcardi hoiab. Linux lisab bind-dynamici, mis käsitleb pärast käivitust loodud liideseid, mis on tõeline mure, kui VPN-i liides ilmub alles ühendamisel.

Seetõttu põrkuvad kaks deemonit, mis mõlemad näivad olevat konfigureeritud erinevatele liidestele, ikkagi kokku. Konflikt on socketis, mitte kavatsuses. Valige sidumisrežiim teadlikult ja lugege oma versiooni dokumenteeritud käitumist enne selle muutmist.

Samm 4: määrake ülesanne

Otsustage, milline deemon vastab VPN-i klientidele ja milline hostile. Üks tunneliaadressil kuulav ja ülesvoolu edasisaatev resolver on tavaline lahendus; kaks resolverit, millest kumbki eeldab, et omab porti 53, ei ole üldse lahendus.

Seejärel väljendage seda otsust iga teenuse enda konfiguratsioonis: kuulamisadressid, liidesefiltrid ja edasisaatmine. Muutke neid teenuse omaniku kaudu, olgu selleks distributsiooni üksus, võrguhaldur või konteineri runtime, et muudatus jääks püsima ka taaskäivituse järel.

Samm 5: kontrollige socketit, seejärel teed

Pärast taaskäivitust kinnitage, et kavandatud socketid on olemas, enne kui klienti testite. Deemonit, mis ei sidunud kunagi, ei päästa marsruut, ja kliendi tõrge korrektselt seotud socketi vastu on teine probleem teise lahendusega. Seejärel kontrollige kättesaadavust tunnelis olevalt kliendilt. Alles pärast seda tasub küsida, kas vajalikud nimed lahenevad.

Kolm eraldi tulemust, mida tuleb lahus hoida: socket on olemas, klient jõuab selleni, vastus on õige.

Mida mitte teha

Ärge peatage tundmatut resolverit pordi vabastamiseks ilma teadmata, mis sellest sõltub, sest hosti enda päringud sõltuvad tavaliselt. Ärge kopeerige vana retsepti, mis viib teise deemon avalikule kuulamisadressile, sest see otsustab kõrvalmõjuna, kes tohib teilt pärida. Ja ärge lisage edasisaatmist, kui tõrge oli kohalik.

Kui masinat hallatakse, kirjutage omandiotsus sinna, kust järgmine administraator selle leiab. Pordikonfliktid tulevad tagasi iga kord, kui kujutist uuesti ehitatakse.