hindi ma-bind ng dnsmasq ang port 53: hanapin ang socket na humahawak nito

nagtatapos ang dnsmasq sa error na ginagamit na ang address, at pinapangalanan ng log ang port sa halip na ang salarin. Sa isang makina na nagpapatakbo rin ng VPN, ang unang reaksyon ay sisihin ang mga itinulak na ruta, ngunit nangyayari ang pagkabigo ng bind bago pa magpadala ng query ang sinumang kliyente. May bagay nang humahawak sa socket, at ang gawain ay tukuyin iyon. Hindi kayang magpalaya ng port ang mga pagbabago sa ruta.

Limang hakbang, sa ganitong pagkakasunod-sunod: ulitin ang error, ilista ang mga tagapakinig, unawain ang wildcard, italaga ang gawain, pagkatapos ay i-verify.

Hakbang 1: ulitin at basahin ang error

Simulan ang dnsmasq sa harapan gamit ang parehong configuration na ginagamit ng serbisyo, upang lumitaw ang error sa iyong terminal sa halip na sa isang log na kailangan mong hulaan. Pansinin ang pamilya ng address at ang lokal na address sa mensahe. Ang bind sa isang partikular na address at ang bind sa wildcard ay magkaibang pagkabigo na may magkaibang may-ari.

Itago ang eksaktong teksto. Address na ginagamit, pagkabigo sa pahintulot at nawawalang interface ay dumarating lahat bilang pagkabigo sa pagsisimula, at tumuturo sila sa tatlong magkaibang pag-aayos.

Hakbang 2: ilista ang mga may-ari

Ilista muna ang mga socket. Ang filter sa source port 53 ay nagpapakita ng dalawang transport at ng prosesong may-ari kapag may pribilehiyo kang makita ito:

ss -lntup 'sport = :53'

Basahin ang output sa mga hanay: transport, lokal na address, port, proseso. Ang tagapakinig ng TCP at tagapakinig ng UDP ay magkaibang socket, kaya ang paghinto sa isa ay hindi nagpapalaya sa isa. Sinasaklaw ng wildcard address ang bawat interface, ibig sabihin ang address ng VPN ay nakuha na kahit walang linyang nagpapangalan dito. At ang pangalan ng proseso ay nagsasabi kung ito ay resolver na pinamamahalaan ng distribusyon, container, o isang bagay na iniwan ng naunang eksperimento na tumatakbo.

Hakbang 3: ang bitag ng wildcard

Binabago ng opsyong bind-interfaces kung ang dnsmasq ay nagbibind ng wildcard socket o isang socket bawat naka-configure na interface, gaya ng inilalarawan ng sanggunian ng dnsmasq. Kung wala ito, maaaring i-bind ng dnsmasq ang wildcard at salain ang mga kahilingan ayon sa interface sa halip, na agad nabigo kapag may ibang daemon na humahawak sa wildcard. Nagdaragdag ang Linux ng bind-dynamic, na humahawak sa mga interface na nilikha pagkatapos ng pagsisimula, tunay na alalahanin kapag ang interface ng VPN ay lumilitaw lamang kapag kumokonekta.

Kaya naman nagbabanggaan pa rin ang dalawang daemon na parehong mukhang naka-configure para sa magkaibang interface. Ang salungatan ay sa socket, hindi sa layunin. Piliin ang mode ng bind nang sadya at basahin ang dokumentadong pag-uugali para sa iyong bersyon bago ito baguhin.

Hakbang 4: italaga ang gawain

Magpasya kung aling daemon ang sumasagot sa mga kliyente ng VPN at alin sa host. Isang resolver na nakikinig sa address ng tunnel at nagpapasa pataas ay karaniwang kaayusan; dalawang resolver na ang bawat isa ay ipinapalagay na pagmamay-ari nito ang port 53 ay hindi kaayusan.

Pagkatapos ay ipahayag ang pasyang iyon sa configuration ng bawat serbisyo: mga address ng pakikinig, mga filter ng interface at pagpapasa. Baguhin ang mga ito sa pamamagitan ng may-ari ng serbisyo, maging ito ang yunit ng distribusyon, ang tagapamahala ng network o ang runtime ng container, upang mabuhay ang pagbabago pagkatapos ng restart.

Hakbang 5: i-verify ang socket, pagkatapos ang landas

Pagkatapos ng restart, kumpirmahin na umiiral ang mga inilaan na socket bago subukan ang isang kliyente. Ang daemon na hindi kailanman nagbind ay hindi maililigtas ng isang ruta, at ang pagkabigo ng kliyente laban sa isang socket na wastong nakabind ay ibang problema na may ibang solusyon. Pagkatapos ay suriin ang maabot mula sa isang kliyente sa tunnel. Pagkatapos lamang niyon sulit itanong kung nareresolba ang mga kinakailangang pangalan.

Tatlong magkaibang resulta na dapat ihiwalay: umiiral ang socket, naaabot ito ng kliyente, tama ang sagot.

Ang hindi dapat gawin

Huwag ihinto ang isang hindi kilalang resolver upang palayain ang port nang hindi alam kung ano ang nakasalalay dito, dahil ang sariling mga paghahanap ng host ay karaniwang nakasalalay. Huwag kopyahin ang lumang resipe na naglilipat sa ikalawang daemon sa isang pampublikong address ng pakikinig, dahil ito bilang side effect ay nagpapasya kung sino ang maaaring magtanong sa iyo. At huwag magdagdag ng pagpapasa kapag lokal ang pagkabigo.

Kung ang makina ay pinamamahalaan, itala ang pasya sa pagmamay-ari kung saan ito mahahanap ng susunod na administrador. Bumabalik ang mga salungatan ng port sa tuwing muling itinatayo ang isang image.