dnsmasq ne može vezati port 53: pronađite socket koji ga drži

dnsmasq izlazi s greškom da je adresa već u upotrebi, a zapis imenuje port umjesto krivca. Na računaru na kojem radi i VPN, prva reakcija je kriviti potisnute rute, ali neuspjeh vezivanja nastaje prije nego bilo koji klijent pošalje upit. Nešto već drži socket, a zadatak je identificirati to. Promjene ruta ne mogu osloboditi port.

Pet koraka ovim redom: reproducirajte grešku, izlistajte listenere, razumite wildcard, dodijelite zadatak, pa provjerite.

Korak 1: reproducirajte i pročitajte grešku

Pokrenite dnsmasq u prvom planu s istom konfiguracijom koju koristi servis, kako bi se greška pojavila u vašem terminalu umjesto u zapisu koji morate nagađati. Obratite pažnju na porodicu adresa i lokalnu adresu u poruci. Vezivanje na konkretnu adresu i vezivanje na wildcard su različiti neuspjesi s različitim vlasnicima.

Sačuvajte tačan tekst. Adresa u upotrebi, neuspjeh dozvole i nedostajući interfejs svi dolaze kao neuspjeh pokretanja, a upućuju na tri različita popravka.

Korak 2: izlistajte vlasnike

Prvo izlistajte socketove. Filter na izvorni port 53 prikazuje oba transporta i proces vlasnik kada imate privilegiju da to vidite:

ss -lntup 'sport = :53'

Čitajte izlaz po kolonama: transport, lokalna adresa, port, proces. TCP listener i UDP listener su odvojeni socketovi, pa zaustavljanje jednog ne oslobađa drugi. Wildcard adresa pokriva svaki interfejs, što znači da je VPN adresa već zauzeta iako je nijedan red ne imenuje. A ime procesa vam kaže je li to resolverom upravljan od strane distribucije, kontejner ili nešto što je ostavio pokrenut raniji eksperiment.

Korak 3: zamka wildcard adrese

Opcija bind-interfaces mijenja to da li dnsmasq veže wildcard socket ili po jedan socket za svaki konfigurirani interfejs, kako opisuje referenca za dnsmasq. Bez nje dnsmasq može vezati wildcard i umjesto toga filtrirati zahtjeve po interfejsu, što odmah pada kada drugi démon drži wildcard. Linux dodaje bind-dynamic, koji obrađuje interfejse stvorene nakon pokretanja, stvarna briga kada se VPN interfejs pojavi samo pri povezivanju.

Zato se dva démona koja oba izgledaju konfigurirana za različite interfejse ipak sudaraju. Sukob je na socketu, ne u namjeri. Odaberite način vezivanja namjerno i pročitajte dokumentirano ponašanje za svoju verziju prije nego ga promijenite.

Korak 4: dodijelite zadatak

Odlučite koji démon odgovara VPN klijentima, a koji hostu. Jedan resolver koji sluša na adresi tunela i prosljeđuje prema izvoru uobičajen je raspored; dva resolvera od kojih svaki pretpostavlja da posjeduje port 53 nije nikakav raspored.

Zatim izrazite tu odluku u konfiguraciji svakog servisa: adrese slušanja, filteri interfejsa i prosljeđivanje. Mijenjajte ih kroz vlasnika servisa, bio to distribucijski unit, mrežni menadžer ili kontejnerski runtime, kako bi promjena preživjela restart.

Korak 5: provjerite socket, pa putanju

Nakon restarta potvrdite da namjeravani socketovi postoje prije testiranja klijenta. Démon koji se nikada nije vezao ne može se spasiti rutom, a neuspjeh klijenta prema ispravno vezanom socketu drugi je problem s drugim rješenjem. Zatim provjerite dostupnost s klijenta na tunelu. Tek nakon toga vrijedi pitati razrješavaju li se potrebna imena.

Tri odvojena rezultata koje treba držati razdvojenim: socket postoji, klijent ga doseže, odgovor je tačan.

Šta ne treba raditi

Ne zaustavljajte nepoznati resolver da biste oslobodili port bez znanja o tome šta o njemu zavisi, jer vlastita pretraživanja hosta obično zavise. Ne kopirajte stari recept koji premješta drugi démon na javnu adresu za slušanje, jer to kao nuspojava odlučuje ko vam smije upućivati upite. I ne dodajte prosljeđivanje kada je neuspjeh bio lokalan.

Ako se računarom upravlja, zabilježite odluku o vlasništvu tamo gdje će je naći sljedeći administrator. Sukobi portova se vraćaju kad god se slika ponovo izgradi.