Per què Pi-hole v6 ignora les consultes DNS dels clients de WireGuard

Pi-hole v6 rep una consulta DNS al port 53 i després decideix si el paquet que ha arribat es pot respondre. En un amfitrió WireGuard, aquesta segona decisió és normalment la raó per la qual un client rep un temps d’espera mentre el resolutor sembla sa des de la LAN. El port és obert, l’FTL s’executa, i tot i així no torna res des de 10.90.0.1. Tres coses interactuen abans que surti una resposta: dns.interface, dns.listeningMode i el tallafoc davant de tots dos.

El sòcol d’escolta no decideix qui rep una resposta

L’FTL obre oients UDP i TCP al port 53. En la configuració per defecte el sòcol sovint és wildcard, així que ss -lunp | grep :53 mostra 0.0.0.0:53 i [::]:53 tant si es serveixen clients VPN com si no. Un sòcol wildcard accepta el paquet i després l’FTL aplica les seves regles d’interfície i d’origen abans de respondre. Per això "el port està escoltant" demostra molt poc sobre un client de túnel.

Llegeix la configuració en execució en lloc del fitxer que creus actiu. pihole-FTL --config dns.interface i pihole-FTL --config dns.listeningMode imprimeixen els valors efectius, i poden diferir del fitxer de l’amfitrió quan un contenidor, una variable d’entorn o un gestor de desplegament posseeix el paràmetre. La Referència de configuració de Pi-hole FTL llista els modes i quin d’ells depèn de la interfície.

LOCAL pregunta quina subxarxa, SINGLE pregunta quina interfície

LOCAL, el mode per defecte, respon les consultes l’adreça d’origen de les quals pertany a una subxarxa configurada en una de les interfícies de l’amfitrió. Un wg0 senzill amb 10.90.0.1/24 supera aquesta prova, perquè el client de 10.90.0.2 és dins de la subxarxa del túnel. Un client encaminat a l’altre costat d’un parell, o un d’amagat darrere de NAT en un prefix diferent, no la supera tot i que el paquet ha arribat a wg0, i no apareix cap consulta al registre.

SINGLE canvia la pregunta. Accepta les consultes que arriben a la interfície indicada per dns.interface, amb loopback inclòs, i ignora la subxarxa d’origen. Aquest és el mode que sobreviu a una topologia VPN encadenada o encaminada. Defineix les dues claus juntes, perquè un mode sense interfície indicada no és una instrucció completa:

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

BIND canvia el sòcol, i això té un cost

BIND no filtra un sòcol wildcard; enllaça el port 53 només a les adreces que existeixen a la interfície indicada, de manera que el nucli rebutja els paquets que arriben a qualsevol altre lloc. És més estricte que SINGLE i no és un sinònim. El cost apareix a l’arrencada: si wg0 no està aixecat quan l’FTL comença, pot no haver-hi cap adreça per enllaçar i el resolutor pot funcionar sense oient fins que la interfície aparegui i l’FTL es reiniciï.

Tria BIND quan controlis l’ordre d’arrencada, per exemple una unitat de systemd ordenada després de la interfície WireGuard, i quan vulguis que el nucli descarti els paquets esgarriats abans que l’FTL els vegi. Tria SINGLE quan el túnel va i ve, o quan la interfície la crea una eina que arrenca després de l’FTL.

El tallafoc és la segona porta

Un mode d’FTL correcte encara falla si el tallafoc de l’amfitrió descarta el port 53 a wg0. Admet el rang d’origen VPN per a tots dos protocols i mantén el costat d’Internet tancat. A nftables, amb la cadena input existent a la taula inet filter, les regles són així:

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

Afegeix regles IPv6 coincidents si el túnel transporta IPv6, i posa-les abans de la política de descart de la cadena. Si l’amfitrió fa servir ufw o firewalld, expressa la mateixa coincidència en aquell gestor en lloc de barrejar eines. No reenviïs el port 53 del router d’Internet; els clients haurien d’arribar a l’adreça VPN del resolutor a través del túnel.

Dos camins es mantenen separats. Les consultes dels clients acaben a l’FTL. Les cerques pròpies de l’FTL cap a l’upstream surten segons la taula d’encaminament de l’amfitrió, que pot usar el túnel o no, així que un resolutor que respon però no retorna res útil és un problema d’upstream. L’administració web i l’API escolten en ports propis i necessiten la seva pròpia restricció.

Verifica la resposta i el rebuig

Des d’un client VPN, consulta l’adreça del resolutor pels dos protocols: dig @10.90.0.1 example.com i dig +tcp @10.90.0.1 example.com. Després revisa el registre de consultes a la interfície d’administració per confirmar que l’FTL ha registrat la consulta. Un temps d’espera del client sense cap entrada al registre apunta al tallafoc o al filtre d’interfície; una entrada al registre sense resposta apunta a la resolució upstream.

Prova el camí negatiu des d’un amfitrió fora de la VPN. dig @10.90.0.1 example.com hauria d’esgotar-se, i ss -lunp al resolutor no hauria de mostrar el port 53 enllaçat a una adreça pública. Reinicia el servei un cop, després reinicia l’amfitrió i confirma que el resolutor encara respon quan wg0 reapareix. Una consulta que només funciona fins al proper reinici no és un canvi acabat.