dnsmasq nemôže zviazať port 53: nájdite socket, ktorý ho drží

dnsmasq skončí s chybou, že adresa sa už používa, a log uvádza port namiesto vinníka. Na stroji, kde beží aj VPN, je prvým reflexom viniť pushnuté trasy, ale zlyhanie bind nastane skôr, než ktorýkoľvek klient pošle dopyt. Niečo už socket drží a úlohou je to identifikovať. Zmeny trás port neuvoľnia.

Päť krokov v tomto poradí: reprodukujte chybu, vypíšte počúvajúce procesy, pochopte wildcard, pridelte úlohu a potom overte.

Krok 1: reprodukovať a prečítať chybu

Spustite dnsmasq na popredí s rovnakou konfiguráciou, akú používa služba, aby sa chyba objavila vo vašom termináli namiesto v logu, ktorý musíte hádať. Všimnite si adresnú rodinu a lokálnu adresu v správe. Bind na konkrétnu adresu a bind na wildcard sú rôzne zlyhania s rôznymi vlastníkmi.

Zachovajte presný text. Adresa v používaní, zlyhanie oprávnenia a chýbajúce rozhranie prichádzajú všetky ako zlyhanie štartu a ukazujú na tri rôzne opravy.

Krok 2: vypísať vlastníkov

Najprv vypíšte sockety. Filter na zdrojový port 53 ukáže oba transporty aj vlastniaci proces, keď máte oprávnenie to vidieť:

ss -lntup 'sport = :53'

Čítajte výstup po stĺpcoch: transport, lokálna adresa, port, proces. TCP listener a UDP listener sú oddelené sockety, takže zastavenie jedného neuvoľní druhý. Wildcard adresa pokrýva každé rozhranie, čo znamená, že VPN adresa je už obsadená, aj keď ju žiadny riadok neuvádza menom. A názov procesu vám povie, či ide o resolver spravovaný distribúciou, kontajner alebo niečo, čo nechal bežať predchádzajúci experiment.

Krok 3: pasca wildcard

Voľba bind-interfaces mení, či dnsmasq zviaže wildcard socket alebo jeden socket pre každé nakonfigurované rozhranie, ako opisuje referenčná príručka dnsmasq. Bez nej môže dnsmasq zviazať wildcard a požiadavky filtrovať podľa rozhrania, čo okamžite zlyhá, keď wildcard drží iný démon. Linux pridáva bind-dynamic, ktorý spracúva rozhrania vytvorené po štarte, čo je skutočná starosť, keď sa VPN rozhranie objaví až pri pripojení.

Preto sa dvaja démoni, ktorí obaja vyzerajú nakonfigurovaní pre rôzne rozhrania, napriek tomu zrazia. Konflikt je na sockete, nie v úmysle. Zvoľte režim bind vedome a pred zmenou si prečítajte dokumentované správanie pre svoju verziu.

Krok 4: prideliť úlohu

Rozhodnite, ktorý démon odpovedá VPN klientom a ktorý hostiteľovi. Jeden resolver, ktorý počúva na adrese tunela a preposiela vyššie je bežné usporiadanie; dva resolvery, z ktorých každý predpokladá, že vlastní port 53, nie je usporiadanie vôbec.

Potom toto rozhodnutie vyjadrite v konfigurácii každej služby: adresy na počúvanie, filtre rozhraní a preposielanie. Meňte ich prostredníctvom vlastníka služby, či je to distribučná jednotka, správca siete alebo runtime kontajnerov, aby zmena prežila reštart.

Krok 5: overiť socket, potom cestu

Po reštarte potvrďte, že zamýšľané sockety existujú, skôr než otestujete klienta. Démon, ktorý sa nikdy nezviazal, nemôže byť zachránený trasou, a zlyhanie klienta voči správne zviazanému socketu je iný problém s inou opravou. Potom skontrolujte dostupnosť z klienta v tuneli. Až potom má zmysel pýtať sa, či sa požadované mená prekladajú.

Tri oddelené výsledky, ktoré treba držať od seba: socket existuje, klient sa k nemu dostane, odpoveď je správna.

Čo nerobiť

Nezastavujte neznámy resolver, aby ste uvoľnili port, bez toho, aby ste vedeli, čo na ňom závisí, pretože vlastné dopyty hostiteľa na ňom zvyčajne závisia. Neopisujte starý recept, ktorý presúva druhého démona na verejnú adresu na počúvanie, keďže to ako vedľajší efekt určuje, kto sa vás smie dopytovať. A nepridávajte preposielanie, keď zlyhanie bolo lokálne.

Ak je stroj spravovaný, zaznamenajte rozhodnutie o vlastníctve tam, kde ho nájde nasledujúci administrátor. Konflikty portov sa vracajú zakaždým, keď sa image znova zostaví.