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, — гэта зусім не схема.

Затым выразіце гэтае рашэнне ў канфігурацыі кожнай службы: адрасы праслухоўвання, фільтры інтэрфейсаў і перасылка. Змяняйце іх праз уласніка службы, ці гэта модуль дыстрыбутыва, сеткавы менеджар ці асяроддзе выканання кантэйнераў, каб змена перажыла перазапуск.

Крок 5: праверце сокет, затым шлях

Пасля перазапуску пераканайцеся, што патрэбныя сокеты існуюць, перш чым тэставаць кліента. Дэман, які так і не прывязаўся, не выратуе маршрут, а збой кліента супраць правільна прывязанага сокета — іншая праблема з іншым рашэннем. Затым праверце дасяжнасць з кліента ў тунелі. Толькі пасля гэтага варта пытацца, ці развязваюцца патрэбныя імёны.

Тры асобныя вынікі, якія трэба не змешваць: сокет існуе, кліент да яго даходзіць, адказ правільны.

Чаго не рабіць

Не спыняйце незнаёмы resolver, каб вызваліць порт, не ведаючы, што ад яго залежыць, бо ўласныя запыты хоста звычайна залежаць. Не капіруйце стары рэцэпт, які пераносіць другі дэман на публічны адрас праслухоўвання, бо гэта як пабочны эфект вырашае, хто можа рабіць вам запыты. І не дадавайце перасылку, калі збой быў лакальным.

Калі машына кіруемая, запішыце рашэнне пра ўласнасць там, дзе яго знойдзе наступны адміністратар. Канфлікты партоў вяртаюцца кожны раз, калі вобраз збіраецца нанова.