Контейнер dnsmasq недоступен извне.

Содержание

Вопрос или проблема
Ответ или решение
DNSMasq Container Не Доступен Извне: Полный Анализ Проблемы
Контекст проблемы
Идентификация проблемы
Предложения по улучшению
Заключение

Вопрос или проблема

У меня есть VPS на CentOS 7, на котором работают несколько служб в контейнерах Docker. Все службы доступны через 127.0.0.1 и доступны через ZeroTier. Я направляю соединения с интерфейса ZeroTier (ZT) на localhost, чтобы получить доступ к своим службам, используя ::

sudo sysctl -w net.ipv4.conf.ztyxa6sxte.route_localnet=1
sudo iptables -t nat -A PREROUTING -i ztyxa6sxte -j DNAT --to-destination 127.0.0.1

Это отлично работает для всех служб — кроме dnsmasq. Я использую образ jpillora/dnsmasq с простым веб-интерфейсом. Мой docker-compose.yml:

services:
  dns:
    container_name: dns
    restart: unless-stopped
    image: jpillora/dnsmasq
    volumes:
      - /etc/dnsmasq/dnsmasq.conf:/etc/dnsmasq.conf
    ports:
      - "127.0.0.1:53:53"
      - "127.0.0.1:53:53/udp"
      - "127.0.0.1:5380:8080"
    environment:
      - HTTP_USER=
      - HTTP_PASS=

Несмотря на то, что конфигурация портов такая же, как у других служб, ни dnsmasq (порт 53), ни его веб-интерфейс (порт 5380) не доступны через интерфейс ZT — только локально с VPS.

Я попробовал:

другие образы – изменений нет
открытие на 0.0.0.0 и подключение через публичный IP VPS – то же самое
netstat показывает, что порты связаны с правильным IP и находятся в состоянии “прослушивания”
SELinux и firewalld отключены
политика iptables – ACCEPT, если нужно, я могу предоставить вывод.
SSH обратный туннель для порта 5380 сработал, я мог получать доступ к localhost:5380 с моего ПК.

Мне кажется, что я упускаю что-то очевидное, но не могу понять. Мне нужна свежая перспектива, пожалуйста, помогите мне выбраться из этого круга.

Проблема с WebUI

Наблюдая за интерфейсом ZT на своем сервере с помощью tcpdump, я заметил, что запросы к WebUI на порту 5380 проходят нормально, и ответы отправляются обратно. Проблема оказалась связанной с основной аутентификацией. Я тестировал доступность с помощью Chrome, который больше не поддерживает основную аутентификацию.

Что меня сбило с толку, так это то, что обратный туннель работал и показывал диалог для входа. Мое предположение, что Chrome позволяет основную аутентификацию при доступе к localhost, но игнорирует ее для внешних адресов. Переход на другой браузер решил проблему — WebUI работает нормально везде.

Проблема с DNS

Когда я впервые настроил это и протестировал <my.domain> в браузере, я не получил ответа. После этого я тестировал только с помощью nslookup на моем ПК с Windows. Тут есть подводный камень: ZeroTier использует NRPT (Таблица политик разрешения имен) для DNS на Windows, но nslookup ее не учитывает.

Я подключился к сети ZT с моего телефона, и DNS работал прекрасно. Затем я снова протестировал из браузера на своем ПК, и там тоже все работало.

Во время этого времени в конфигурацию не вносились изменения, но сервер был перезагружен один раз, возможно, это помогло.

Ответ или решение

DNSMasq Container Не Доступен Извне: Полный Анализ Проблемы

В данной статье рассматривается проблема с доступом к контейнеру dnsmasq, работающему на CentOS 7 в окружении Docker. Несмотря на корректные настройки и конфигурации, доступ к контейнеру стал возможен только локально, а это создает трудности в работе с другими сервисами. Давайте разберем каждую из проблем и возможные решения!

Контекст проблемы

Вы используете VPS на базе CentOS 7 с несколькими службами, организованными в контейнерах Docker. Все службы доступны через интерфейс ZeroTier (ZT). Подключение к ним осуществляется через маршрутизацию, перенаправляя запросы на 127.0.0.1 (localhost). Однако контейнер с dnsmasq не реагирует на запросы через ZT, в отличие от других сервисов. Основные параметры конфигурации вашего docker-compose.yml выглядят следующим образом:

services:
  dns:
    container_name: dns
    restart: unless-stopped
    image: jpillora/dnsmasq
    volumes:
      - /etc/dnsmasq/dnsmasq.conf:/etc/dnsmasq.conf
    ports:
      - "127.0.0.1:53:53"
      - "127.0.0.1:53:53/udp"
      - "127.0.0.1:5380:8080"
    environment:
      - HTTP_USER=<user>
      - HTTP_PASS=<pass>

Несмотря на аналогичные настройки портов с другими сервисами, dnsmasq остается недоступным с внешних интерфейсов.

Идентификация проблемы

Проблема с WebUI:
- Вы отметили, что при использовании Chrome не удается получить доступ к WebUI, несмотря на корректную маршрутизацию и настройки. Обсудим, как браузеры обрабатывают базовую аутентификацию: Chrome, возможно, не поддерживает ее для внешних адрессов так же, как для localhost.
- Решение: Попробуйте использовать другой браузер, как вы уже сделали. Это подтверждает, что проблема была связана именно с браузером.
Проблема с DNS:
- У вас возникли проблемы с доступом к DNS через Windows. Основная причина в том, что клиент ZeroTier использует NRPT (таблицу политик разрешения имен), который не определяется традиционными утилитами, такими как nslookup.
- Решение: Вы тестировали разрешение имени, и только при подключении к потребительскому устройству, такому как ваш телефон, запросы к DNS работали. Это говорит о том, что DNS-система функционирует корректно. Однако браузеры используют разные механизмы для DNS-разрешения, что иногда приводит к путанице.

Предложения по улучшению

Проверка конфигураций маршрутизации и iptables:
- Убедитесь, что вы правильно настроили правила NAT для контейнера dnsmasq. Возможно, какие-то дополнительные правила в iptables блокируют трафик, даже если основной policy установлен на ACCEPT. Используйте следующие команды для диагностики:
```
sudo iptables -t nat -L -n -v
sudo iptables -L -n -v
```
Настройки Docker:
- Попробуйте изменить параметры контейнера, используя 0.0.0.0 вместо 127.0.0.1 для портов в docker-compose.yml. Это позволит сделать сервис доступным извне.
- Пример:
```
ports:
- "0.0.0.0:53:53"
- "0.0.0.0:53:53/udp"
- "0.0.0.0:5380:8080"
```
Мониторинг трафика:
- Используйте tcpdump или другие сетевые инструменты для отображения трафика во время запроса. Это позволит вам увидеть, действительно ли пакеты отправляются, и правильно ли они обрабатываются.

Заключение

Ваш случай демонстрирует, как комплексные сетевые настройки могут быть причиной проблем с доступом к контейнерам Docker. Проводя исследования и тестируя различные решения, вы постепенно сможете определить корень проблемы и устранить его. Следуя предложенным рекомендациям и изменяя конфигурации, вы сможете успешно настроить доступ к вашему серверу DNS через ZeroTier, обеспечивая надежную работу всех ваших сервисов.

Если у вас остаются вопросы или проблемы, не стесняйтесь обращаться за дополнительной поддержкой!