Зашто 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 поново појави. Упит који ради само до следећег рестарта није завршена промена.