dnsmasq ne more vezati vrat 53: poiščite vtičnico, ki jih drži

dnsmasq se konča z napako, da je naslov že v uporabi, dnevnik pa navede vrata namesto krivca. Na stroju, kjer teče tudi VPN, je prvi odziv kriviti potisnjene poti, vendar se napaka bind zgodi, preden kateri koli odjemalec pošlje poizvedbo. Nekaj že drži vtičnico, naloga pa je to prepoznati. Spremembe poti ne morejo sprostiti vrat.

Pet korakov v tem vrstnem redu: ponovite napako, naštejte poslušalce, razumejte wildcard, dodelite nalogo in nato preverite.

Korak 1: ponoviti in prebrati napako

Zaženite dnsmasq v ospredju z enako konfiguracijo, kot jo uporablja storitev, da se napaka pojavi v vašem terminalu namesto v dnevniku, ki ga morate ugibati. Bodite pozorni na družino naslovov in lokalni naslov v sporočilu. Vezava na določen naslov in vezava na wildcard sta različni napaki z različnimi lastniki.

Shranite natančno besedilo. Naslov v uporabi, napaka dovoljenja in manjkajoč vmesnik pridejo vsi kot napaka zagona in kažejo na tri različna popravila.

Korak 2: našteti lastnike

Najprej naštejte vtičnice. Filter na izvornih vratih 53 prikaže oba prenosa in proces, ki ju ima v lasti, ko imate pravico to videti:

ss -lntup 'sport = :53'

Berite izpis po stolpcih: prenos, lokalni naslov, vrata, proces. Poslušalec TCP in poslušalec UDP sta ločeni vtičnici, zato zaustavitev enega ne sprosti drugega. Naslov wildcard pokriva vsak vmesnik, kar pomeni, da je naslov VPN že zaseden, tudi če ga nobena vrstica ne imenuje. In ime procesa vam pove, ali je to resolver, ki ga upravlja distribucija, vsebnik ali nekaj, kar je pustil teči prejšnji poskus.

Korak 3: past wildcard

Možnost bind-interfaces spremeni, ali dnsmasq veže vtičnico wildcard ali po eno vtičnico za vsak konfiguriran vmesnik, kot opisuje referenca dnsmasq. Brez nje lahko dnsmasq veže wildcard in zahteve filtrira po vmesniku, kar takoj spodleti, ko wildcard drži drug demon. Linux doda bind-dynamic, ki obravnava vmesnike, ustvarjene po zagonu, resnična skrb, ko se vmesnik VPN pojavi šele ob povezavi.

Zato se dva demona, ki oba izgledata konfigurirana za različne vmesnike, vseeno zaletita. Spopad je pri vtičnici, ne pri nameri. Način vezave izberite zavestno in pred spremembo preberite dokumentirano vedenje za svojo različico.

Korak 4: dodeliti nalogo

Odločite, kateri demon odgovarja odjemalcem VPN in kateri gostitelju. En resolver, ki posluša na naslovu tunela in posreduje navzgor je običajna ureditev; dva resolverja, od katerih vsak domneva, da ima v lasti vrata 53, ni nobena ureditev.

Nato to odločitev izrazite v konfiguraciji vsake storitve: naslovi poslušanja, filtri vmesnikov in posredovanje. Spreminjajte jih prek lastnika storitve, naj bo to distribucijska enota, upravitelj omrežja ali izvajalno okolje vsebnikov, da sprememba preživi ponovni zagon.

Korak 5: preveriti vtičnico, nato pot

Po ponovnem zagonu potrdite, da predvidene vtičnice obstajajo, preden preizkusite odjemalca. Demona, ki se nikoli ni vezal, ne more rešiti pot, napaka odjemalca proti pravilno vezani vtičnici pa je druga težava z drugim popravkom. Nato preverite dosegljivost z odjemalca v tunelu. Šele nato se je vredno vprašati, ali se zahtevana imena razrešujejo.

Trije ločeni izidi, ki jih je treba ločevati: vtičnica obstaja, odjemalec jo doseže, odgovor je pravilen.

Česa ne storiti

Ne ustavljajte neznanega resolverja, da bi sprostili vrata, ne da bi vedeli, kaj je od njega odvisno, ker so lastne poizvedbe gostitelja običajno odvisne. Ne kopirajte starega recepta, ki premakne drugega demona na javni naslov poslušanja, saj to kot stranski učinek odloči, kdo vas sme poizvedovati. In ne dodajajte posredovanja, ko je bila napaka lokalna.

Če se stroj upravlja, zabeležite odločitev o lastništvu tam, kjer jo bo našel naslednji skrbnik. Spori glede vrat se vrnejo vsakič, ko se slika znova zgradi.