dnsmasq getur ekki bundið port 53: finnið sokkinn sem heldur honum

dnsmasq hættir með villunni að heimilisfangið sé þegar í notkun, og loggið nefnir portið frekar en sektarann. Á vél sem keyrir einnig VPN er fyrsta viðbragðið að kenna ýttu leiðunum um, en bind-bilun verður áður en nokkur biðlari sendir fyrirspurn. Eitthvað heldur þegar sokkinum, og verkefnið er að bera kennsl á það. Leiðabreytingar geta ekki losað port.

Fimm skref í þessari röð: endurtaktu villuna, listaðu hlustendurna, skildu wildcard, úthlutaðu verkinu og staðfestu síðan.

Skref 1: endurtaktu og lestu villuna

Ræstu dnsmasq í forgrunni með sömu stillingum og þjónustan notar, svo villan birtist í flugstöðinni þinni í stað loggs sem þú verður að giska á. Taktu eftir heimilisfangaflokknum og staðbundna heimilisfanginu í skilaboðunum. Binding við tiltekið heimilisfang og binding við wildcard eru mismunandi bilun með mismunandi eigendum.

Geymdu nákvæman textann. Heimilisfang í notkun, heimildarbilun og vantar viðmót koma öll sem ræsibilun, og þau benda á þrjár mismunandi viðgerðir.

Skref 2: listaðu eigendurna

Listaðu sokkana fyrst. Sía á upprunaporti 53 sýnir bæði flutningslögin og ferlið sem á þá þegar þú hefur réttindi til að sjá það:

ss -lntup 'sport = :53'

Lestu úttakið í dálkum: flutningur, staðbundið heimilisfang, port, ferli. TCP-hlustandi og UDP-hlustandi eru aðskildir sokkar, svo að stöðva annan losar ekki hinn. Wildcard-heimilisfang nær yfir hvert viðmót, sem þýðir að VPN-heimilisfangið er þegar tekið þótt engin lína nefni það á nafn. Og nafn ferlisins segir þér hvort þetta er resolver sem dreifingin stýrir, gámur eða eitthvað sem fyrra tilraun lét keyra.

Skref 3: gildran í wildcard

Valkosturinn bind-interfaces ræður því hvort dnsmasq bindur wildcard-sokk eða einn sokk fyrir hvert stillt viðmót, eins og dnsmasq-handbókin lýsir. Án hans getur dnsmasq bundið wildcard og síðan síað beiðnir eftir viðmóti í staðinn, sem mistekst samstundis þegar annar daemon heldur wildcard. Linux bætir við bind-dynamic, sem sér um viðmót sem eru búin til eftir ræsingu, raunverulegt áhyggjuefni þegar VPN-viðmótið birtist aðeins við tengingu.

Þess vegna rekast tveir daemonar, sem báðir líta út fyrir að vera stilltir fyrir mismunandi viðmót, samt á. Áreksturinn er við sokkinn, ekki við áformið. Veldu bindunarhaminn af ásettu ráði og lestu skjalfesta hegðun fyrir þína útgáfu áður en þú breytir honum.

Skref 4: úthlutaðu verkinu

Ákveddu hvaða daemon svarar VPN-biðlendum og hver svarar hýsilnum. Einn resolver sem hlustar á gönguheimilisfanginu og sendir framvirkt upp er algengt fyrirkomulag; tveir resolverar sem hvor um sig gerir ráð fyrir að eiga port 53 er alls ekki fyrirkomulag.

Láttu síðan þá ákvörðun koma fram í stillingum hverrar þjónustu: hlustunarheimilisföng, viðmótssíur og framsending. Breyttu þeim í gegnum eiganda þjónustunnar, hvort sem það er dreifingareiningin, netstjórinn eða keyrsluumhverfi gáma, svo breytingin lifi endurræsingu af.

Skref 5: staðfestu sokkinn, síðan slóðina

Eftir endurræsinguna, staðfestu að tilætlaðir sokkar séu til áður en þú prófar biðlara. Daemon sem aldrei bindið getur ekki bjargast með leið, og bilun biðlara gagnvart rétt bundnum sokki er annað vandamál með aðra lagfæringu. Athugaðu síðan aðgengi frá biðlara í göngunni. Aðeins eftir það er þess virði að spyrja hvort nauðsynlegu nöfnin leysist.

Þrjár aðskildar niðurstöður til að halda aðskildum: sokkurinn er til, biðlarinn nær honum, svarið er rétt.

Hvað á ekki að gera

Ekki stöðva ókunnan resolver til að losa portið án þess að vita hvað er háð honum, því uppflettingar hýsilsins sjálfs eru það venjulega. Ekki afrita gamla uppskrift sem færir seinni daemoninn á opinbert hlustunarheimilisfang, þar sem það ræður sem aukaverkun hverjir mega spyrja þig. Og ekki bæta við framsendingu þegar bilunin var staðbundin.

Ef vélin er stýrð, skráðu eignarhaldsákvörðunina þar sem næsti stjórnandi finnur hana. Portárekstrar koma aftur í hvert sinn sem ímynd er endurbyggð.