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

dnsmasq izlazi s pogreškom da je adresa već u upotrebi, a zapisnik imenuje port umjesto krivca. Na stroju na kojem radi i VPN, prvi je refleks okriviti potisnute rute, no neuspjeh vezivanja nastupa prije nego ijedan klijent pošalje upit. Nešto već drži socket, a zadaća je to prepoznati. Promjene ruta ne mogu osloboditi port.

Pet koraka, ovim redom: reproducirajte pogrešku, popišite listenere, shvatite wildcard, dodijelite zadaću pa provjerite.

Korak 1: reproducirajte i pročitajte pogrešku

Pokrenite dnsmasq u prednjem planu s istom konfiguracijom koju rabi usluga, kako bi se pogreška pojavila u vašem terminalu, a ne u zapisniku koji morate nagađati. Zabilježite obitelj adresa i lokalnu adresu iz poruke. Vezivanje na određenu adresu i vezivanje na wildcard dvije su različite pogreške s različitim vlasnicima.

Sačuvajte točan tekst. Adresa u upotrebi, neuspjeh dopuštenja i nedostajuće sučelje dolaze svi kao neuspjeh pokretanja i upućuju na tri različita popravka.

Korak 2: popišite vlasnike

Najprije popišite socketove. Filtar na izvorni port 53 pokazuje oba prijenosa i proces koji ga drži kada imate ovlasti to vidjeti:

ss -lntup 'sport = :53'

Čitajte izlaz po stupcima: prijenos, lokalna adresa, port, proces. TCP listener i UDP listener odvojeni su socketovi, pa zaustavljanje jednoga ne oslobađa drugi. Wildcard adresa pokriva svako sučelje, što znači da je VPN adresa već zauzeta iako je nijedan redak ne navodi imenom. A ime procesa kaže je li riječ o resolveru kojim upravlja distribucija, o kontejneru ili o nečemu što je prethodni pokus ostavio pokrenuto.

Korak 3: zamka wildcarda

Opcija bind-interfaces mijenja to veže li dnsmasq wildcard socket ili po jedan socket za svako konfigurirano sučelje, kako opisuje priručnik za dnsmasq. Bez nje dnsmasq može vezati wildcard i umjesto toga filtrirati zahtjeve po sučelju, što odmah pada kada wildcard drži drugi démon. Linux dodaje bind-dynamic koji obrađuje sučelja stvorena nakon pokretanja, stvarna briga kada se VPN sučelje pojavi tek pri povezivanju.

Zato se dva démona koja oba izgledaju konfigurirana za različita sučelja ipak sudaraju. Sukob je na socketu, ne u namjeri. Odaberite način vezivanja svjesno i pročitajte dokumentirano ponašanje za svoju inačicu prije nego ga promijenite.

Korak 4: dodijelite zadaću

Odlučite koji démon odgovara VPN klijentima, a koji domaćinu. 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 tu odluku izrazite u konfiguraciji svake usluge: adrese slušanja, filtri sučelja i prosljeđivanje. Mijenjajte ih kroz vlasnika usluge, bio to distribucijski unit, mrežni upravitelj ili kontejnersko okruženje, da promjena preživi ponovno pokretanje.

Korak 5: provjerite socket pa put

Nakon ponovnog pokretanja potvrdite da namjeravani socketovi postoje prije ispitivanja 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 ishoda koje treba držati odvojenima: socket postoji, klijent ga doseže, odgovor je točan.

Što ne činiti

Ne zaustavljajte nepoznati resolver da biste oslobodili port, a da ne znate što o njemu ovisi, jer vlastita pretraživanja domaćina obično ovise. Ne preslikavajte stari recept koji premješta drugi démon na javnu adresu slušanja, jer to kao nuspojava odlučuje kome se smije obratiti. I ne dodajte prosljeđivanje kada je neuspjeh bio lokalan.

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