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 жиі кездесетін құрылым; әрқайсысы 53-портқа ие деп ойлайтын екі resolver мүлде құрылым емес.

Содан кейін бұл шешімді әр қызметтің өз конфигурациясында білдіріңіз: тыңдау мекенжайлары, интерфейс сүзгілері және жіберу. Оларды қызметтің иесі арқылы өзгертіңіз, дистрибутив бірлігі, желі менеджері немесе контейнер орындау ортасы болсын, өзгеріс қайта іске қосудан кейін де қалсын.

5-қадам: сокетті, содан кейін жолды тексеру

Қайта іске қосқаннан кейін клиентті сынамас бұрын көзделген сокеттердің бар екенін растаңыз. Ешқашан байламаған демонды маршрутпен құтқару мүмкін емес, ал дұрыс байланған сокетке қатысты клиент сәтсіздігі басқа шешімі бар басқа мәселе. Содан кейін туннельдегі клиенттен қолжетімділікті тексеріңіз. Тек содан кейін қажетті атаулар шешіле ме деп сұрауға тұрарлық.

Бөлек ұстау керек үш нәтиже: сокет бар, клиент оған жетеді, жауап дұрыс.

Не істеуге болмайды

Портты босату үшін оған не тәуелді екенін білмей, таныс емес resolver-ді тоқтатпаңыз, өйткені хосттың өз іздеулері әдетте оған тәуелді. Екінші демонды жария тыңдау мекенжайына көшіретін ескі рецептіні көшірмеңіз, өйткені бұл жанама әсер ретінде кімнің сізге сұраныс жібере алатынын шешеді. Ал қате жергілікті болғанда жіберуді қоспаңыз.

Егер машина басқарылатын болса, меншік шешімін келесі әкімші табатын жерге жазыңыз. Порт қақтығыстары бейне қайта құрылған сайын қайта оралады.