dnsmasq ei voi sitoa porttia 53: etsi socket, joka pitää sitä

dnsmasq päättyy virheeseen osoitteen olevan jo käytössä, ja loki nimeää portin syyllisen sijaan. Koneella, jolla ajetaan myös VPN:ää, ensimmäinen reaktio on syyttää työnnettyjä reittejä, mutta bind-virhe tapahtuu ennen kuin yksikään asiakas lähettää kyselyn. Jokin pitää socketia jo, ja tehtävä on tunnistaa se. Reittimuutokset eivät voi vapauttaa porttia.

Viisi vaihetta tässä järjestyksessä: toista virhe, luettele kuuntelijat, ymmärrä wildcard, kohdista tehtävä ja varmista sitten.

Vaihe 1: toista ja lue virhe

Käynnistä dnsmasq etualalla samalla kokoonpanolla, jota palvelu käyttää, jotta virhe näkyy päätteessäsi eikä lokissa, jota sinun täytyy arvailla. Huomaa viestin osoiteperhe ja paikallinen osoite. Bind tiettyyn osoitteeseen ja bind wildcardiin ovat eri virheitä, joilla on eri omistajat.

Säilytä tarkka teksti. Käytössä oleva osoite, käyttöoikeusvirhe ja puuttuva verkkoliitäntä saapuvat kaikki käynnistysvirheenä, ja ne osoittavat kolmeen eri korjaukseen.

Vaihe 2: luettele omistajat

Luettele ensin socketit. Suodatin lähdeportilla 53 näyttää molemmat kuljetukset ja omistavan prosessin, kun sinulla on oikeus nähdä se:

ss -lntup 'sport = :53'

Lue tuloste sarakkeittain: kuljetus, paikallinen osoite, portti, prosessi. TCP-kuuntelija ja UDP-kuuntelija ovat erillisiä socketeja, joten toisen pysäyttäminen ei vapauta toista. Wildcard-osoite kattaa jokaisen verkkoliitännän, mikä tarkoittaa, että VPN-osoite on jo varattu, vaikka mikään rivi ei nimeä sitä. Ja prosessin nimi kertoo, onko kyseessä jakelun hallinnoima resolveri, kontti vai jotain, jonka aiempi kokeilu jätti käyntiin.

Vaihe 3: wildcardin ansa

bind-interfaces-asetus muuttaa sitä, sitooko dnsmasq wildcard-socketin vai yhden socketin jokaista määritettyä verkkoliitäntää kohden, kuten dnsmasq-viite kuvaa. Ilman sitä dnsmasq voi sitoa wildcardin ja suodattaa pyynnöt sen sijaan verkkoliitännän mukaan, mikä epäonnistuu heti, kun toinen taustaprosessi pitää wildcardia. Linux lisää bind-dynamicin, joka käsittelee käynnistyksen jälkeen luodut verkkoliitännät, todellinen huoli silloin, kun VPN-liitäntä ilmestyy vasta yhdistettäessä.

Siksi kaksi taustaprosessia, jotka molemmat näyttävät määritetyiltä eri verkkoliitännöille, törmäävät silti. Ristiriita on socketissa, ei aikomuksessa. Valitse bind-tila tarkoituksella ja lue versiosi dokumentoitu käyttäytyminen ennen sen muuttamista.

Vaihe 4: kohdista tehtävä

Päätä, mikä taustaprosessi vastaa VPN-asiakkaille ja mikä isäntäkoneelle. Yksi resolveri, joka kuuntelee tunnelin osoitteessa ja välittää ylöspäin on tavallinen järjestely; kaksi resolveria, joista kumpikin olettaa omistavansa portin 53, ei ole järjestely lainkaan.

Ilmaise sitten tämä päätös kunkin palvelun omassa kokoonpanossa: kuunteluosoitteet, verkkoliitäntäsuodattimet ja välitys. Muuta niitä palvelun omistajan kautta, oli se sitten jakeluyksikkö, verkkohallinta tai konttiajoympäristö, jotta muutos säilyy uudelleenkäynnistyksen yli.

Vaihe 5: varmista socket ja sitten polku

Varmista uudelleenkäynnistyksen jälkeen, että aiotut socketit ovat olemassa ennen asiakkaan testaamista. Taustaprosessia, joka ei koskaan sitonut, ei voi pelastaa reitillä, ja asiakkaan virhe oikein sidottua socketia vastaan on toinen ongelma, jolla on toinen korjaus. Tarkista sitten tavoitettavuus tunnelissa olevalta asiakkaalta. Vasta sen jälkeen kannattaa kysyä, ratkeavatko tarvittavat nimet.

Kolme erillistä tulosta pidettävä erillään: socket on olemassa, asiakas saavuttaa sen, vastaus on oikea.

Mitä ei pidä tehdä

Älä pysäytä tuntematonta resolveria portin vapauttamiseksi tietämättä, mitä siitä riippuu, koska isäntäkoneen omat haut yleensä riippuvat. Älä kopioi vanhaa reseptiä, joka siirtää toisen taustaprosessin julkiseen kuunteluosoitteeseen, sillä se päättää sivutuotteena, kuka saa kysyä sinulta. Äläkä lisää välitystä, kun virhe oli paikallinen.

Jos konetta hallitaan, kirjaa omistajuuspäätös sinne, mistä seuraava ylläpitäjä löytää sen. Porttiristiriidat palaavat aina, kun levykuva rakennetaan uudelleen.