Waarom Pi-hole v6 DNS-query’s van WireGuard-clients negeert

Pi-hole v6 ontvangt een DNS-query op poort 53 en beslist daarna of het aangekomen pakket beantwoord mag worden. Op een WireGuard-host is die tweede beslissing meestal de reden waarom een client een time-out krijgt terwijl de resolver er vanaf het LAN gezond uitziet. De poort is open, FTL draait, en toch komt er niets terug van 10.90.0.1. Drie dingen werken samen voordat een antwoord vertrekt: dns.interface, dns.listeningMode en de firewall voor beide.

De luisterende socket beslist niet wie een antwoord krijgt

FTL opent UDP- en TCP-listeners op poort 53. In de standaardconfiguratie is de socket vaak wildcard, dus ss -lunp | grep :53 toont 0.0.0.0:53 en [::]:53, of VPN-clients nu wel of niet worden bediend. Een wildcard-socket neemt het pakket aan, waarna FTL zijn interface- en bronregels toepast voordat het antwoordt. Daarom bewijst "de poort luistert" heel weinig over een tunnelclient.

Lees de draaiende configuratie in plaats van het bestand dat u actief denkt. pihole-FTL --config dns.interface en pihole-FTL --config dns.listeningMode drukken de effectieve waarden af, en die kunnen afwijken van het bestand van de host wanneer een container, omgevingsvariabele of deploymentmanager de instelling bezit. De Pi-hole FTL-configuratiereferentie noemt de modi en welke daarvan op de interface is gebaseerd.

LOCAL vraagt welk subnet, SINGLE vraagt welke interface

LOCAL, de standaard, beantwoordt query’s waarvan het bronadres bij een subnet hoort dat op een van de interfaces van de host is geconfigureerd. Een eenvoudige wg0 met 10.90.0.1/24 slaagt voor die test, omdat de client op 10.90.0.2 binnen het subnet van de tunnel zit. Een gerouteerde client aan de andere kant van een peer, of een die achter NAT in een andere prefix verborgen zit, slaagt er niet voor, ook al kwam het pakket binnen op wg0, en er verschijnt geen query in het log.

SINGLE verandert de vraag. Het accepteert query’s die binnenkomen op de interface die in dns.interface wordt genoemd, met loopback inbegrepen, en negeert het bronsubnet. Dat is de modus die een geketende of gerouteerde VPN-topologie overleeft. Stel beide sleutels samen in, want een modus zonder genoemde interface is geen volledige instructie:

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

BIND verandert de socket, en dat heeft een prijs

BIND filtert geen wildcard-socket; het bindt poort 53 alleen aan adressen die op de genoemde interface bestaan, zodat de kernel pakketten weigert die elders binnenkomen. Het is strenger dan SINGLE en geen synoniem ervan. De prijs blijkt bij het opstarten: als wg0 niet actief is wanneer FTL start, is er misschien geen adres om aan te binden, en kan de resolver zonder listener draaien tot de interface verschijnt en FTL opnieuw start.

Kies BIND wanneer u de opstartvolgorde beheert, bijvoorbeeld een systemd-unit die na de WireGuard-interface is geordend, en wanneer u wilt dat de kernel verdwaalde pakketten weggooit voordat FTL ze ziet. Kies SINGLE wanneer de tunnel komt en gaat, of wanneer de interface wordt gemaakt door een hulpmiddel dat na FTL start.

De firewall is de tweede poort

Een correcte FTL-modus faalt nog steeds als de firewall van de host poort 53 op wg0 weggooit. Sta het VPN-bronbereik toe voor beide protocollen en houd de internetkant gesloten. In nftables, met de bestaande input-keten in de tabel inet filter, zien de regels er zo uit:

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

Voeg overeenkomende IPv6-regels toe als de tunnel IPv6 vervoert, en plaats ze vóór het drop-beleid van de keten. Gebruikt de host ufw of firewalld, druk dan dezelfde overeenkomst in die beheerder uit in plaats van hulpmiddelen te mengen. Stuur poort 53 niet door vanaf de internetrouter; clients moeten het VPN-adres van de resolver via de tunnel bereiken.

Twee paden blijven gescheiden. Query’s van clients eindigen bij FTL. De eigen upstream-zoekopdrachten van FTL verlaten het systeem volgens de routetabel van de host, die de tunnel wel of niet gebruikt, dus een resolver die antwoordt maar niets bruikbaars teruggeeft is een upstream-probleem. De webbeheerder en de API luisteren op hun eigen poorten en hebben hun eigen beperking nodig.

Controleer het antwoord en de weigering

Vraag vanaf een VPN-client het adres van de resolver op via beide protocollen: dig @10.90.0.1 example.com en dig +tcp @10.90.0.1 example.com. Controleer daarna het querylog in de beheerinterface om te bevestigen dat FTL de query heeft vastgelegd. Een time-out van de client zonder logregel wijst op de firewall of het interfacefilter; een logregel zonder antwoord wijst op upstream-resolutie.

Test het negatieve pad vanaf een host buiten de VPN. dig @10.90.0.1 example.com hoort te verlopen, en ss -lunp op de resolver hoort poort 53 niet gebonden aan een openbaar adres te tonen. Herstart de dienst één keer, herstart daarna de host en bevestig dat de resolver nog steeds antwoordt wanneer wg0 weer verschijnt. Een query die alleen tot de volgende herstart werkt, is geen afgeronde wijziging.