dnsmasq не може зайняти порт 53: знайдіть сокет, який його тримає

dnsmasq завершується з помилкою, що адреса вже використовується, а журнал називає порт, а не винуватця. На машині, де також працює VPN, перша реакція звинувачувати просунуті маршрути, але помилка bind трапляється раніше, ніж будь-який клієнт надішле запит. Щось уже тримає сокет, і завдання визначити це. Зміни маршрутів не можуть звільнити порт.

П’ять кроків у такому порядку: відтворіть помилку, перелічіть слухачів, зрозумійте wildcard, призначте завдання, потім перевірте.

Крок 1: відтворити й прочитати помилку

Запустіть dnsmasq на передньому плані з тією самою конфігурацією, яку використовує служба, щоб помилка з’явилася у вашому терміналі, а не в журналі, який доводиться вгадувати. Зверніть увагу на родину адрес і локальну адресу в повідомленні. Прив язка до конкретної адреси й прив’язка до wildcard різні збої з різними власниками.

Збережіть точний текст. Зайнята адреса, відмова в дозволі й відсутній інтерфейс надходять усі як збій запуску, і вони вказують на три різні виправлення.

Крок 2: перелічити власників

Спочатку перелічіть сокети. Фільтр за портом джерела 53 показує обидва транспорти й процес-власник, коли у вас є право це бачити:

ss -lntup 'sport = :53'

Читайте вивід за стовпцями: транспорт, локальна адреса, порт, процес. Слухач TCP і слухач UDP окремі сокети, тому зупинка одного не звільняє інший. Адреса wildcard охоплює кожен інтерфейс, тобто адреса VPN уже зайнята, навіть якщо жоден рядок не називає її за іменем. А ім’я процесу підказує, чи це резолвер під керуванням дистрибутива, контейнер чи щось, що залишив працювати попередній експеримент.

Крок 3: пастка wildcard

Параметр bind-interfaces змінює, чи dnsmasq прив’язує wildcard-сокет, чи по одному сокету на кожен налаштований інтерфейс, як описує довідка з dnsmasq. Без нього dnsmasq може прив’язати wildcard і натомість фільтрувати запити за інтерфейсом, що одразу дає збій, коли wildcard тримає інший демон. Linux додає bind-dynamic, який обробляє інтерфейси, створені після запуску, реальна проблема, коли інтерфейс VPN з’являється лише під час підключення.

Тому два демони, які обидва виглядають налаштованими на різні інтерфейси, все одно стикаються. Конфлікт у сокеті, а не в намірі. Обирайте режим прив’язки свідомо й прочитайте документовану поведінку для своєї версії, перш ніж її змінити.

Крок 4: призначити завдання

Вирішіть, який демон відповідає клієнтам VPN, а який хосту. Один резолвер, що слухає на адресі тунелю й пересилає вгору звична схема; два резолвери, кожен з яких вважає, що володіє портом 53, це взагалі не схема.

Потім виразіть це рішення в конфігурації кожної служби: адреси прослуховування, фільтри інтерфейсів і пересилання. Змінюйте їх через власника служби, чи це юніт дистрибутива, мережевий менеджер або середовище виконання контейнерів, щоб зміна пережила перезапуск.

Крок 5: перевірити сокет, потім шлях

Після перезапуску переконайтеся, що потрібні сокети існують, перш ніж тестувати клієнта. Демона, який так і не прив’язався, не врятує маршрут, а збій клієнта проти правильно прив’язаного сокета інша проблема з іншим виправленням. Потім перевірте доступність з клієнта в тунелі. Лише після цього варто питати, чи розв язуються потрібні імена.

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

Чого не робити

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

Якщо машиною керують, запишіть рішення про володіння там, де його знайде наступний адміністратор. Конфлікти портів повертаються щоразу, коли образ перезбирається.