Чому Pi-hole v6 ігнорує DNS-запити клієнтів WireGuard

Pi-hole v6 приймає DNS-запит на порту 53 і потім вирішує, чи можна відповісти на пакет, що надійшов. На хості WireGuard це друге рішення зазвичай і є причиною, чому клієнт отримує тайм-аут, тоді як резолвер виглядає здоровим з LAN. Порт відкритий, FTL працює, але з 10.90.0.1 нічого не повертається. Перш ніж відповідь вийде, взаємодіють три речі: dns.interface, dns.listeningMode і міжмережевий екран перед обома.

Слухаючий сокет не вирішує, хто отримає відповідь

FTL відкриває UDP- і TCP-прослуховувачі на порту 53. У типовій конфігурації сокет часто wildcard, тому ss -lunp | grep :53 показує 0.0.0.0:53 і [::]:53 незалежно від того, чи обслуговуються клієнти VPN. Wildcard-сокет приймає пакет, потім FTL застосовує свої правила інтерфейсу та джерела, перш ніж відповісти. Тому фраза «порт слухає» доводить дуже мало про клієнта тунелю.

Читайте робочу конфігурацію, а не файл, який ви вважаєте активним. pihole-FTL --config dns.interface і pihole-FTL --config dns.listeningMode друкують фактичні значення, і вони можуть відрізнятися від файлу хоста, коли налаштуванням володіє контейнер, змінна середовища або менеджер розгортання. Довідник з конфігурації Pi-hole FTL перелічує режими та те, який із них спирається на інтерфейс.

LOCAL питає про підмережу, SINGLE — про інтерфейс

LOCAL, типовий режим, відповідає на запити, адреса джерела яких належить підмережі, налаштованій на одному з інтерфейсів хоста. Простий wg0 з 10.90.0.1/24 проходить цю перевірку, бо клієнт на 10.90.0.2 перебуває всередині підмережі тунелю. Клієнт із маршрутизацією з іншого боку піра, або клієнт, прихований за NAT в іншому префіксі, її не проходить, хоча пакет надійшов на wg0, і в журналі не з'являється жодного запиту.

SINGLE змінює запитання. Він приймає запити, що надходять на інтерфейс, названий у dns.interface, включно з loopback, і ігнорує підмережу джерела. Це режим, який виживає в ланцюговій або маршрутизованій топології VPN. Задайте обидва ключі разом, бо режим без названого інтерфейсу не є повною інструкцією:

sudo pihole-FTL --config dns.interface "wg0"
sudo pihole-FTL --config dns.listeningMode "SINGLE"

BIND змінює сокет, і це має ціну

BIND не фільтрує wildcard-сокет; він прив'язує порт 53 лише до адрес, які існують на названому інтерфейсі, тому ядро відкидає пакети, що надходять в інше місце. Він суворіший за SINGLE і не є його синонімом. Ціна проявляється під час завантаження: якщо wg0 не піднято, коли FTL стартує, може не бути адреси для прив'язки, і резолвер може працювати без прослуховувача, доки інтерфейс не з'явиться і FTL не перезапуститься.

Виберіть BIND, коли ви контролюєте порядок запуску, наприклад модуль systemd, упорядкований після інтерфейсу WireGuard, і коли хочете, щоб ядро відкидало заблукалі пакети до того, як їх побачить FTL. Виберіть SINGLE, коли тунель з'являється і зникає, або коли інтерфейс створює інструмент, що запускається після FTL.

Міжмережевий екран — другі ворота

Правильний режим FTL усе одно не спрацює, якщо міжмережевий екран хоста відкидає порт 53 на wg0. Дозвольте діапазон джерел VPN для обох протоколів і тримайте інтернет-бік закритим. У nftables, з наявним ланцюгом input у таблиці inet filter, правила виглядають так:

sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 udp dport 53 accept
sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 tcp dport 53 accept

Додайте відповідні правила IPv6, якщо тунель несе IPv6, і поставте їх перед політикою відкидання ланцюга. Якщо хост використовує ufw або firewalld, виразіть ту саму відповідність у цьому менеджері, а не змішуйте інструменти. Не пересилайте порт 53 з інтернет-маршрутизатора; клієнти мають досягати VPN-адреси резолвера через тунель.

Два шляхи залишаються окремими. Запити клієнтів завершуються на FTL. Власні запити FTL до вищого рівня виходять згідно з таблицею маршрутизації хоста, яка може використовувати тунель або ні, тому резолвер, що відповідає, але не повертає нічого корисного, — це проблема вищого рівня. Веб-адміністрування та API слухають на власних портах і потребують власного обмеження.

Перевірте відповідь і відмову

З клієнта VPN запитайте адресу резолвера обома протоколами: dig @10.90.0.1 example.com і dig +tcp @10.90.0.1 example.com. Потім перевірте журнал запитів в інтерфейсі адміністратора, щоб підтвердити, що FTL записав запит. Тайм-аут клієнта без запису в журналі вказує на міжмережевий екран або фільтр інтерфейсу; запис без відповіді вказує на розв'язання на вищому рівні.

Перевірте негативний шлях з хоста поза VPN. dig @10.90.0.1 example.com має завершитися тайм-аутом, а ss -lunp на резолвері не має показувати порт 53, прив'язаний до публічної адреси. Перезапустіть службу один раз, потім перезавантажте хост і переконайтеся, що резолвер досі відповідає після появи wg0. Запит, який працює лише до наступного перезавантаження, — не завершена зміна.