+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

[ИСПРАВЛЕНО] Порт UDP 53 недоступен для Docker Pi-hole в непривилегированном LXC, Proxmox Виртуальная Среда

LexD

Guest

23.10.2025 11:52:00

Ребята, пытаюсь перейти с LXD на Proxmox, но столкнулся с проблемами.

Настройка:
Proxmox VE хост
Ubuntu 24.04
непривилегированный LXC-контейнер, в котором запущен Docker

Docker-стек: Pi-hole + Unbound + Gravity Sync + Nebula
Режим сети Docker: host
Сеть LXC: мост (vmbr0)

Вторичный IP Pi-hole: 192.168.50.160
Основной Pi-hole: работает нативно в непривилегированном контейнере LXD на другом хосте — всё идеально

Проблема:
DNS-трафик (UDP/53) не проходит, когда Pi-hole запускается внутри Docker в непривилегированном LXC.

Изнутри LXC на Proxmox (хоста Docker-контейнера):
dig @192.168.50.160 google.com — таймаут
nslookup google.com 192.168.50.160 — таймаут
nslookup pi.hole 192.168.50.160 — работает

С Proxmox хоста:
nslookup pi.hole 192.168.50.160 — работает
dig @192.168.50.160 pi.hole — работает
dig @192.168.50.160 google.com — таймаут

С LAN-клиентов:
nc -vuz 192.168.50.160 53 — успешно (UDP порт открыт)

Но запросы DNS с LAN по-прежнему таймаутятся.

Наблюдения:
Веб-интерфейс Pi-hole доступен из LAN, значит с TCP всё в порядке.
tcpdump показывает, что DNS-запросы уходят с Proxmox хоста, но UDP-ответы не возвращаются из контейнера.
Внутри LXC видны только локальные DNS-запросы, внешние к нему не доходят.

Возможная причина:
Входящий UDP-трафик к Docker-сервисам внутри непривилегированных LXC-контейнеров полностью не проходит, даже при --network=host. Похоже, AppArmor или ограничения неймспейсов блокируют обработку UDP-ответов для Docker-контейнеров с host-сетью, что затрагивает конкретно DNS.

Вопросы:
Это известное ограничение Docker с --network=host внутри непривилегированных LXC на Proxmox?
Есть ли способ разрешить UDP (особенно порт 53), не делая LXC привилегированным — например, через профиль AppArmor, lxc.apparmor.profile или дополнительные capabilities?
Безопасно ли обойти эту проблему, переключив Pi-hole на macvlan или отдельную сетевую мостовую сеть?

hans66

Guest

12.11.2025 20:35:00

Нашёл решение? У меня два pihole в LXC на pve с keepalived. При первоначальном запуске всё работает, но если выключить мастер, то резервный берёт на себя управление, однако порт 53 (udp и tcp) заблокирован, а вот порты 80 и 22 работают без проблем. Перезапуск мастера возвращает контроль мастеру, но часто всё равно нет подключения к порту 53. При этом я могу делать DNS-запросы с мастера на резервный и наоборот... или с любого LAN-клиента на pihole, но не через виртуальный IP. Значит, проблема где-то между виртуальным IP и pihole... пока без идей. У меня нет Nebula sync. Спасибо, Hans.

Johannes S

Guest

12.11.2025 21:13:00

Похоже, что порт 53 блокируется файрволом, вы уверены, что ваш провайдер, роутер или вы сами его не заблокировали? К тому же есть отличный (хоть и немного старый) туториал от @Dunuin на форуме о том, как настроить Pi-hole вместе с unbound в Debian LXC без докера: Тема «Pi-hole LXC с gravity-sync?» от 21 мая 2022.

Привет! Сейчас у меня работают два Pi-hole на двух Debian 11 ВМ, но я хотел бы заменить ВМ на LXC и добавить gravity-sync, чтобы не делать все админские задачи дважды в обоих веб-интерфейсах Pi-hole. А ещё хотелось бы добавить unbound для рекурсивного DNS разрешения в каждый LXC, как описано здесь. Если я правильно помню, видел темы, где люди запускали Pi-hole в LXC, так что, думаю, это должно работать.

Изучая документацию gravity-sync 4.x, я увидел такие строки:

Dunuin
Ответов: 32
Форум: Proxmox VE: установка и настройка

Обратите внимание, что не всё из этого актуально (некоторые вещи поменялись с последними версиями Pi-hole, nebula-sync уже не работает, но gravity-sync должен быть в порядке), но для рабочей настройки этого должно хватить. По крайней мере, у меня так и было, с небольшими правками, учитывающими изменения в Pi-hole, Proxmox VE и Debian за последние годы.

hans66

Guest

13.11.2025 20:30:00

Спасибо за ответ. Дело не в провайдере. Я проверяю из оболочки pve, с виртуальной машины на pve и с ноутбука-клиента — все в одной локальной сети. Запросы к двум инстансам pihole работают нормально, а запросы на виртуальный IP из keepalived не проходят (только для порта 53, а 22 и 80 продолжают работать). Я видел еще несколько таких же случаев, но решения пока нет.

Johannes S Guest	#5 0 13.11.2025 20:46:00 У тебя вообще получается получить виртуальный IP на одном из pihole? Если нет, я бы заподозрил, что с твоей конфигурацией keepalived что-то не так.

hans66

Guest

14.11.2025 20:50:00

Я могу пинговать виртуальный IP, могу подключиться по SSH к виртуальному IP (и получить ожидаемый экземпляр pihole — мастер или резервный), могу зайти на страницу администрирования pihole... Единственное, что не работает — это порт 53. Я также принудительно переключил DNS-запросы на TCP (по умолчанию UDP), но и это не помогло.

Johannes S

Guest

14.11.2025 21:00:00

Было бы здорово, если бы ты мог сделать тесты nslookup и dig, которые делал LexD, и выложить результаты здесь. Тебе нужно заменить IP на свой виртуальный IP и IP-адреса контейнеров pihole (чтобы мы понимали, связана ли проблема с виртуальным IP, одним или обоими LXC-контейнерами).

hans66

Guest

14.11.2025 21:43:00

LXC pihole1 = 192.168.1.253
LXC pihole2 = 192.168.1.252
Виртуальный IP = 192.168.1.251

Тесты с оболочки Debian VM на PVE (и те же результаты при выполнении напрямую с PVE хоста)
dig @192.168.1.253 google.com
; <<>> DiG 9.18.41-1~deb12u1-Debian <<>> @192.168.1.253 google.com
; (1 сервер найден)
;; глобальные опции: +cmd
;; Получен ответ:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43901
;; флаги: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
<удалено, успешно>

dig @192.168.1.252 google.com
; <<>> DiG 9.18.41-1~deb12u1-Debian <<>> @192.168.1.252 google.com
; (1 сервер найден)
;; глобальные опции: +cmd
;; Получен ответ:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9107
;; флаги: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
<удалено, успешно>

dig @192.168.1.251 google.com
;; ошибка связи с 192.168.1.251#53: соединение отказано
;; ошибка связи с 192.168.1.251#53: соединение отказано
;; ошибка связи с 192.168.1.251#53: соединение отказано
; <<>> DiG 9.18.41-1~deb12u1-Debian <<>> @192.168.1.251 google.com
; (1 сервер найден)
;; глобальные опции: +cmd
;; серверы недоступны

ssh 192.168.1.251
Введите пароль для ключа '/home/user/.ssh/id_ed25519':

telnet 192.168.1.251 80
Подключение к 192.168.1.251...
Подключено к 192.168.1.251.
Символ выхода ^].
HTTP/1.0 400 Bad Request
Cache-Control: no-cache, no-store, must-revalidate, private, max-age=0
Expires: 0
Pragma: no-cache
X-DNS-Prefetch-Control: off
Content-Security-Policy: default-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:;
X-Frame-Options: DENY
<удалено>

nslookup google.com 192.168.1.251
;; ошибка связи с 192.168.1.251#53: соединение отказано

Тесты с LXC pihole1 на PVE
dig @192.168.1.251 google.com
;; ошибка связи с 192.168.1.251#53: соединение отказано
;; ошибка связи с 192.168.1.251#53: соединение отказано
;; ошибка связи с 192.168.1.251#53: соединение отказано

dig @192.168.1.252 google.com
; <<>> DiG 9.18.41-1~deb12u1-Debian <<>> @192.168.1.252 google.com
; (1 сервер найден)
;; глобальные опции: +cmd
;; Получен ответ:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 519
;; флаги: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

telnet 192.168.1.251 22
Подключение к 192.168.1.251...
Подключено к 192.168.1.251.
Символ выхода ^].
SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u7

nslookup google.com 192.168.1.251
;; ошибка связи с 192.168.1.251#53: соединение отказано

Johannes S

Guest

14.11.2025 22:55:00

Спасибо, включали ли вы внутренний файрвол Proxmox? Можете, пожалуйста, прислать вывод этих команд:
Code:
pve-firewall status
iptables-save
iptables -L

И, пожалуйста, пришлите содержимое этих файлов:
cat /etc/pve/firewall/cluster.fw
cat /etc/pve/nodes/node-name/host.fw

Мне кажется, что файрвол блокирует DNS, так как ваше описание очень похоже на документацию по умолчанию для правил: https://pve-node2.private.jstarosta...-pve-firewall.html#pve_firewall_default_rules

hans66 Guest	#10 0 15.11.2025 14:02:00 Привет! Ниже информация, которую ты просил. Я никак не могу в этом разобраться. Виртуальный IP keepalived работает для ssh, http и icmp (ping). Поскольку ssh и http — это TCP-соединения, а DNS по умолчанию использует UDP, я попробовал сделать TCP-запрос к DNS — проблема та же, проверял из оболочки pve: dig +tcp @192.168.1.251 google.com ;; Connection to 192.168.1.251#53(192.168.1.251) for google.com failed: connection refused. Другие данные: sudo pve-firewall status Статус: отключен/запущен sudo iptables-save # Generated by iptables-save v1.8.9 on Sat Nov 15 10:26:27 2025 raw :PREROUTING ACCEPT [23962824:4555531404] :OUTPUT ACCEPT [1943079:852407336] COMMIT # Completed on Sat Nov 15 10:26:27 2025 # Generated by iptables-save v1.8.9 on Sat Nov 15 10:26:27 2025 filter :INPUT ACCEPT [3864163:1558667868] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [1943079:852407336] COMMIT # Completed on Sat Nov 15 10:26:27 2025 sudo iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination sudo cat /etc/pve/firewall/cluster.fw cat: /etc/pve/firewall/cluster.fw: No such file or directory (папка firewall пуста) sudo cat /etc/pve/nodes/pve/host.fw cat: /etc/pve/nodes/pve/host.fw: No such file or directory (node-name=pve, в папке pve нет host.fw) Я перезагружал pve-ноду и оба LXC-контейнера. В общем, я немного в тупике, что происходит. Спасибо за любые советы!

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры