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: проверить сокет, затем путь

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

Три отдельных результата, которые нужно держать врозь: сокет существует, клиент до него доходит, ответ верен.

Чего не делать

Не останавливайте незнакомый резолвер, чтобы освободить порт, не зная, что от него зависит, потому что собственные запросы хоста обычно зависят. Не копируйте старый рецепт, который переносит второй демон на публичный адрес прослушивания, поскольку это как побочный эффект решает, кто может вас опрашивать. И не добавляйте пересылку, когда сбой был локальным.

Если машиной управляют, запишите решение о владении там, где его найдёт следующий администратор. Конфликты портов возвращаются каждый раз, когда образ пересобирается.