dnsmasq не може да веже порт 53: пронађите сокет који га држи

dnsmasq излази са грешком да је адреса већ у употреби, а запис именује порт уместо кривца. На рачунару на којем ради и VPN, први одраз је кривити гурнуте руте, али неуспех везивања настаје пре него што било који клијент пошаље упит. Нешто већ држи сокет, а задатак је то препознати. Промене рута не могу ослободити порт.

Пет корака овим редом: репродукујте грешку, излистајте слушаоце, разумите wildcard, доделите задатак, па проверите.

Корак 1: репродукујте и прочитајте грешку

Покрените dnsmasq у предњем плану са истом конфигурацијом коју користи услуга, како би се грешка појавила у вашем терминалу, а не у запису који морате нагађати. Обратите пажњу на породицу адреса и локалну адресу у поруци. Везивање на одређену адресу и везивање на wildcard две су различите грешке са различитим власницима.

Сачувајте тачан текст. Адреса у употреби, неуспех дозволе и недостајући интерфејс сви долазе као неуспех покретања и упућују на три различита поправка.

Корак 2: излистајте власнике

Најпре излистајте сокетове. Филтер на изворни порт 53 приказује оба преноса и процес који га држи када имате овлашћење да то видите:

ss -lntup 'sport = :53'

Читајте излаз по колонама: пренос, локална адреса, порт, процес. TCP слушалац и UDP слушалац су одвојени сокетови, па заустављање једног не ослобађа други. Wildcard адреса покрива сваки интерфејс, што значи да је VPN адреса већ заузета иако је ниједан ред не наводи именом. А име процеса вам каже да ли је реч о resolver-у којим управља дистрибуција, о контејнеру или о нечему што је претходни експеримент оставио покренуто.

Корак 3: замка wildcard-а

Опција bind-interfaces мења то везује ли dnsmasq wildcard сокет или по један сокет за сваки конфигурисани интерфејс, како описује приручник за dnsmasq. Без ње dnsmasq може везати wildcard и уместо тога филтрирати захтеве по интерфејсу, што одмах пада када wildcard држи други демон. Linux додаје bind-dynamic који обрађује интерфејсе створене након покретања, стварна брига када се VPN интерфејс појави тек при повезивању.

Зато се два демона која оба изгледају конфигурисана за различите интерфејсе ипак сударају. Сукоб је на сокету, не у намери. Одаберите начин везивања свесно и прочитајте документовано понашање за своју верзију пре него што га промените.

Корак 4: доделите задатак

Одлучите који демон одговара VPN клијентима, а који домаћину. Један resolver који слуша на адреси тунела и прослеђује према извору је уобичајен распоред; два resolver-а од којих сваки претпоставља да поседује порт 53 није никакав распоред.

Затим ту одлуку изразите у конфигурацији сваке услуге: адресе слушања, филтери интерфејса и прослеђивање. Мењајте их кроз власника услуге, био то дистрибуцијски unit, мрежни менаџер или контејнерско окружење, да промена преживи поновно покретање.

Корак 5: проверите сокет, па пут

Након поновног покретања потврдите да намеравани сокетови постоје пре испитивања клијента. Демон који се никада није везао не може се спасити рутом, а неуспех клијента према исправно везаном сокету други је проблем са другим решењем. Затим проверите доступност са клијента на тунелу. Тек након тога вреди питати разрешавају ли се потребна имена.

Три одвојена исхода које треба држати одвојенима: сокет постоји, клијент га достиже, одговор је тачан.

Шта не чинити

Не заустављајте непознати resolver да бисте ослободили порт, а да не знате шта о њему зависи, јер сопствене претраге домаћина обично зависе. Не пресликавајте стари рецепт који премешта други демон на јавну адресу слушања, јер то као нуспојава одлучује коме се сме обратити. И не додајте прослеђивање када је неуспех био локалан.

Ако се рачунаром управља, забележите одлуку о власништву тамо где ће је наћи следећи администратор. Сукоби портова се враћају кад год се слика поново изгради.