Por que Pi-hole v6 ignora as consultas DNS dos clientes de WireGuard

Pi-hole v6 recibe unha consulta DNS no porto 53 e despois decide se o paquete que chegou pode ser respondido. Nun host WireGuard esa segunda decisión adoita ser a razón pola que un cliente recibe un tempo de espera mentres o resolvedor parece san desde a LAN. O porto está aberto, FTL está en execución, e aínda así non volve nada desde 10.90.0.1. Tres cousas interactúan antes de que saia unha resposta: dns.interface, dns.listeningMode e a devasadoira diante de ambos.

O socket de escoita non decide quen recibe unha resposta

FTL abre escoitas UDP e TCP no porto 53. Na configuración predeterminada o socket adoita ser wildcard, así que ss -lunp | grep :53 mostra 0.0.0.0:53 e [::]:53 tanto se se atenden clientes VPN como se non. Un socket wildcard acepta o paquete e despois FTL aplica as súas regras de interface e de orixe antes de responder. Por iso "o porto está escoitando" demostra moi pouco sobre un cliente de túnel.

Le a configuración en execución en lugar do ficheiro que cres activo. pihole-FTL --config dns.interface e pihole-FTL --config dns.listeningMode imprimen os valores efectivos, e poden diferir do ficheiro do host cando un contedor, unha variable de contorno ou un xestor de despregue é dono do axuste. A Referencia de configuración de Pi-hole FTL enumera os modos e cal deles depende da interface.

LOCAL pregunta que subrede, SINGLE pregunta que interface

LOCAL, o modo predeterminado, responde consultas cuxo enderezo de orixe pertence a unha subrede configurada nunha das interfaces do host. Un wg0 sinxelo con 10.90.0.1/24 pasa esa proba, porque o cliente en 10.90.0.2 está dentro da subrede do túnel. Un cliente encamiñado no outro lado dun par, ou un oculto tras NAT noutro prefixo, non a pasa aínda que o paquete chegou por wg0, e non aparece ningunha consulta no rexistro.

SINGLE cambia a pregunta. Acepta as consultas que chegan pola interface indicada en dns.interface, con loopback incluído, e ignora a subrede de orixe. Ese é o modo que sobrevive a unha topoloxía VPN encadeada ou encamiñada. Define as dúas claves xuntas, porque un modo sen interface indicada non é unha instrución completa:

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

BIND cambia o socket, e iso ten un custo

BIND non filtra un socket wildcard; liga o porto 53 só aos enderezos que existen na interface indicada, así que o núcleo rexeita os paquetes que chegan a outro sitio. É máis estrito que SINGLE e non é un sinónimo. O custo aparece ao arrincar: se wg0 non está levantada cando FTL comeza, pode que non haxa enderezo ao que ligar e o resolvedor pode funcionar sen escoita ata que a interface apareza e FTL se reinicie.

Escolle BIND cando controles a orde de arrinque, por exemplo unha unidade de systemd ordenada despois da interface WireGuard, e cando queiras que o núcleo descarte os paquetes perdidos antes de que FTL os vexa. Escolle SINGLE cando o túnel vai e vén, ou cando a interface a crea unha ferramenta que arrinca despois de FTL.

A devasadoira é a segunda porta

Un modo de FTL correcto segue fallando se a devasadoira do host descarta o porto 53 en wg0. Admite o rango de orixe da VPN para ambos protocolos e mantén pechado o lado de Internet. En nftables, coa cadea input existente na táboa inet filter, as regras vense así:

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

Engade regras IPv6 equivalentes se o túnel transporta IPv6, e pona antes da política de descarte da cadea. Se o host usa ufw ou firewalld, expresa a mesma coincidencia nese xestor en vez de mesturar ferramentas. Non reenvíes o porto 53 desde o router de Internet; os clientes deben alcanzar o enderezo VPN do resolvedor a través do túnel.

Dúas rutas permanecen separadas. As consultas dos clientes terminan en FTL. As buscas propias de FTL cara ao upstream saen segundo a táboa de encamiñamento do host, que pode usar o túnel ou non, así que un resolvedor que responde pero non devolve nada útil é un problema de upstream. A administración web e a API escoitan nos seus propios portos e necesitan a súa propia restrición.

Verifica a resposta e o rexeitamento

Desde un cliente VPN, consulta o enderezo do resolvedor por ambos protocolos: dig @10.90.0.1 example.com e dig +tcp @10.90.0.1 example.com. Despois revisa o rexistro de consultas na interface de administración para confirmar que FTL rexistrou a consulta. Un tempo de espera do cliente sen entrada no rexistro apunta á devasadoira ou ao filtro de interface; unha entrada sen resposta apunta á resolución upstream.

Proba a ruta negativa desde un host fóra da VPN. dig @10.90.0.1 example.com debería esgotarse, e ss -lunp no resolvedor non debería mostrar o porto 53 ligado a un enderezo público. Reinicia o servizo unha vez, despois reinicia o host e confirma que o resolvedor segue respondendo cando wg0 reaparece. Unha consulta que só funciona ata o seguinte reinicio non é un cambio rematado.