Wêrom Pi-hole v6 DNS-query’s fan WireGuard-klanten negearret

Pi-hole v6 ûntfangt in DNS-query op poarte 53 en beslút dan oft it pakket dat oankaam beantwurde wurde mei. Op in WireGuard-host is dy twadde beslissing meastentiids de reden wêrom’t in klant in time-out krijt wylst de resolver fan ’e LAN ôf sûn liket. De poarte is iepen, FTL rint, en dochs komt der neat werom fan 10.90.0.1. Trije dingen wurkje gear foardat in antwurd fuortgiet: dns.interface, dns.listeningMode en de firewall foar beide.

De harkende socket beslút net wa’t in antwurd krijt

FTL iepenet UDP- en TCP-harkers op poarte 53. Yn ’e standertkonfiguraasje is de socket faak wildcard, dus ss -lunp | grep :53 lit 0.0.0.0:53 en [::]:53 sjen, oft VPN-klanten no betsjinne wurde of net. In wildcard-socket akseptearret it pakket, en dan past FTL syn ynterface- en boarneregels ta foardat er antwurdet. Dêrom bewiist "de poarte harket" hiel lyts bytsje oer in tunnelklant.

Lês de rinnende konfiguraasje ynstee fan it bestân dat jo aktyf achtsje. pihole-FTL --config dns.interface en pihole-FTL --config dns.listeningMode printsje de effektive wearden, en dy kinne fan it hostbestân ôfwike as in kontener, omjouwingsfariabele of útrôljingsbehearder de ynstelling besit. De Pi-hole FTL-konfiguraasjereferinsje listet de modi en hokker dêrfan op ’e ynterface steld is.

LOCAL freget hokker subnet, SINGLE freget hokker ynterface

LOCAL, de standert, antwurdet queries wêrfan’t it boarneadres by in subnet heart dat op ien fan ’e ynterfaces fan ’e host konfigurearre is. In ienfâldige wg0 mei 10.90.0.1/24 slagget foar dy test, om’t de klant op 10.90.0.2 binnen it tunnelsubnet sit. In rûte klant oan ’e oare kant fan in pear, of ien dy’t efter NAT yn in oar prefiks ferskûle is, slagget der net foar, sels net as it pakket op wg0 oankaam, en der ferskynt gjin query yn it logboek.

SINGLE feroaret de fraach. It akseptearret queries dy’t oankomme op ’e ynterface neamd yn dns.interface, mei loopback derby, en negearret it boarnesubnet. Dat is de modus dy’t in keatling- of rûte-VPN-topology oerlibbet. Set beide kaaien tagelyk, om’t in modus sûnder neamde ynterface gjin folsleine ynstruksje is:

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

BIND feroaret de socket, en dat hat in priis

BIND filteret gjin wildcard-socket; it bynt poarte 53 allinnich oan adressen dy’t op ’e neamde ynterface besteane, sadat de kernel pakketten wegeret dy’t earne oars oankomme. It is stranger as SINGLE en gjin synonym dêrfan. De priis blykt by it opstarten: as wg0 net omheech is as FTL start, is der miskien gjin adres om oan te bynjen, en kin de resolver sûnder harker rinne oant de ynterface ferskynt en FTL op ’e nij start.

Kies BIND as jo de opstartfolchoarder behearskje, bygelyks in systemd-ienheid dy’t nei de WireGuard-ynterface oardere is, en as jo wolle dat de kernel dyfge pakketten ferpletteret foardat FTL se sjocht. Kies SINGLE as de tunnel komt en giet, of as de ynterface makke wurdt troch in helpmiddel dat nei FTL start.

De firewall is de twadde poarte

In korrekte FTL-modus mislearret noch altyd as de firewall fan ’e host poarte 53 op wg0 ferpletteret. Lit it VPN-boarneberik foar beide protokollen troch en hâld de ynternetkant ticht. Yn nftables, mei de besteande input-ketting yn ’e tabel inet filter, sjogge de regels der sa út:

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

Foegje oerienkommende IPv6-regels ta as de tunnel IPv6 ferfiert, en set se foar it drop-belied fan ’e ketting. As de host ufw of firewalld brûkt, uterje deselde oerienkomst yn dy behearder ynstee fan helpmiddels te mingen. Stjoer poarte 53 net troch fan ’e ynternetrouter; klanten moatte it VPN-adres fan ’e resolver fia de tunnel berikke.

Twa paden bliuwe skieden. Queries fan klanten einigje by FTL. FTL syn eigen upstream-syktochten gean fuort neffens de rûtetabel fan ’e host, dy’t de tunnel brûke kin of net, dus in resolver dy’t antwurdet mar neat nuttich weromjout is in upstream-probleem. De webbehearder en API harkje op har eigen poarten en hawwe har eigen beheining nedich.

Ferifiearje it antwurd en de wegering

Freegje fan in VPN-klant it resolveradres oer beide protokollen: dig @10.90.0.1 example.com en dig +tcp @10.90.0.1 example.com. Besjoch dan it querylogboek yn ’e behearderynterface om te befêstigjen dat FTL de query registrearre hat. In time-out fan ’e klant sûnder logboekoantekening wiist op ’e firewall of it ynterfacefilter; in oantekening sûnder antwurd wiist op upstream-oplossing.

Test it negative paad fan in host bûten it VPN. dig @10.90.0.1 example.com soe ferrinne moatte, en ss -lunp op ’e resolver soe poarte 53 net bûn oan in iepenbier adres sjen litte moatte. Start de tsjinst ien kear op ’e nij, start dan de host op ’e nij en befêstigje dat de resolver noch antwurdet as wg0 wer ferskynt. In query dy’t allinnich oant de folgjende werstart wurket, is gjin ôfmakke feroaring.