dnsmasq nemůže svázat port 53: najděte socket, který ho drží

dnsmasq skončí s chybou, že adresa je již používána, a log uvádí port místo viníka. Na stroji, kde běží i VPN, je prvním reflexem vinit pushované routy, ale selhání bind nastane dřív, než kterýkoli klient pošle dotaz. Něco už socket drží a úkolem je to identifikovat. Změny rout port neuvolní.

Pět kroků v tomto pořadí: reprodukujte chybu, vypište naslouchající procesy, pochopte wildcard, přidělte úlohu a pak ověřte.

Krok 1: reprodukujte a přečtěte chybu

Spusťte dnsmasq na popředí se stejnou konfigurací, jakou používá služba, aby se chyba objevila ve vašem terminálu místo v logu, který musíte hádat. Všimněte si adresní rodiny a lokální adresy ve zprávě. Bind na konkrétní adresu a bind na wildcard jsou různá selhání s různými vlastníky.

Zachovejte přesný text. Adresa v použití, selhání oprávnění a chybějící rozhraní přicházejí všechny jako selhání startu a ukazují na tři různé opravy.

Krok 2: vypište vlastníky

Nejprve vypište sockety. Filtr na zdrojový port 53 ukáže oba transporty i vlastnící proces, když máte oprávnění to vidět:

ss -lntup 'sport = :53'

Čtěte výstup po sloupcích: transport, lokální adresa, port, proces. TCP listener a UDP listener jsou oddělené sockety, takže zastavení jednoho neuvolní druhý. Wildcard adresa pokrývá každé rozhraní, což znamená, že VPN adresa je už obsazená, i když ji žádný řádek nejmenuje. A název procesu vám řekne, zda jde o resolver spravovaný distribucí, kontejner nebo něco, co nechal běžet předchozí experiment.

Krok 3: past wildcard adresy

Volba bind-interfaces mění, zda dnsmasq sváže wildcard socket, nebo jeden socket pro každé nakonfigurované rozhraní, jak popisuje referenční příručka dnsmasq. Bez ní může dnsmasq svázat wildcard a požadavky filtrovat podle rozhraní, což okamžitě selže, když wildcard drží jiný démon. Linux přidává bind-dynamic, který zvládá rozhraní vytvořená po startu, což je skutečný problém, když se VPN rozhraní objeví až při připojení.

Proto se dva démoni, kteří oba vypadají nakonfigurovaní pro různá rozhraní, přesto srazí. Konflikt je na socketu, ne v záměru. Zvolte režim bind vědomě a před změnou si přečtěte dokumentované chování pro svou verzi.

Krok 4: přidělte úlohu

Rozhodněte, který démon odpovídá VPN klientům a který hostiteli. Jeden resolver, který naslouchá na adrese tunelu a přeposílá výš je běžné uspořádání; dva resolvery, z nichž každý předpokládá, že vlastní port 53, není uspořádání vůbec.

Pak toto rozhodnutí vyjádřete v konfiguraci každé služby: adresy pro naslouchání, filtry rozhraní a přeposílání. Měňte je prostřednictvím vlastníka služby, ať je to distribuční unit, správce sítě nebo runtime kontejnerů, aby změna přežila restart.

Krok 5: ověřte socket, pak cestu

Po restartu potvrďte, že zamýšlené sockety existují, než otestujete klienta. Démon, který se nikdy nesvázal, nemůže být zachráněn routou, a selhání klienta proti správně svázanému socketu je jiný problém s jinou opravou. Pak zkontrolujte dostupnost z klienta v tunelu. Teprve potom má smysl ptát se, zda se požadovaná jména překládají.

Tři oddělené výsledky, které je třeba držet od sebe: socket existuje, klient se k němu dostane, odpověď je správná.

Co nedělat

Nezastavujte neznámý resolver, abyste uvolnili port, aniž byste věděli, co na něm závisí, protože vlastní dotazy hostitele na něm obvykle závisí. Neopisujte starý recept, který přesouvá druhého démona na veřejnou adresu pro naslouchání, protože to jako vedlejší efekt určuje, kdo se vás smí dotazovat. A nepřidávejte přeposílání, když selhání bylo lokální.

Pokud je stroj spravovaný, zaznamenejte rozhodnutí o vlastnictví tam, kde ho najde příští administrátor. Konflikty portů se vracejí pokaždé, když se image znovu sestaví.