Защо 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. Собствените upstream заявки на FTL излизат според таблицата за маршрутизация на хоста, която може да използва тунела или не, затова резолвер, който отговаря, но не връща нищо полезно, е проблем на upstream. Уеб администрацията и API слушат на собствени портове и се нуждаят от собствено ограничение.

Проверете отговора и отказа

От VPN клиент заявете адреса на резолвера по двата протокола: dig @10.90.0.1 example.com и dig +tcp @10.90.0.1 example.com. След това проверете журнала на заявките в административния интерфейс, за да потвърдите, че FTL е записал заявката. Изчакване на клиента без запис в журнала сочи към защитната стена или филтъра на интерфейса; запис без отговор сочи към разрешаване на upstream.

Тествайте отрицателния път от хост извън VPN. dig @10.90.0.1 example.com трябва да изтече, а ss -lunp на резолвера не трябва да показва порт 53, свързан с публичен адрес. Рестартирайте услугата веднъж, после рестартирайте хоста и потвърдете, че резолверът все още отговаря, след като wg0 се появи отново. Заявка, която работи само до следващото рестартиране, не е завършена промяна.