Waarom Pi-hole v6 DNS-navrae van WireGuard-kliënte ignoreer

Pi-hole v6 ontvang ’n DNS-navraag op poort 53 en besluit dan of die pakket wat aangekom het, beantwoord mag word. Op ’n WireGuard-gasheer is daardie tweede besluit gewoonlik die rede waarom ’n kliënt ’n tydsverloop kry terwyl die oplosser gesond lyk vanaf die LAN. Die poort is oop, FTL loop, en tog kom niks terug van 10.90.0.1 nie. Drie dinge werk saam voordat ’n antwoord vertrek: dns.interface, dns.listeningMode en die vuurmuur voor albei.

Die luisterende sokkel besluit nie wie ’n antwoord kry nie

FTL open UDP- en TCP-luisteraars op poort 53. In die verstekkonfigurasie is die sokkel dikwels ’n wildcard, so ss -lunp | grep :53 wys 0.0.0.0:53 en [::]:53 of VPN-kliënte bedien word of nie. ’n Wildcard-sokkel aanvaar die pakket, en dan pas FTL sy koppelvlak- en bronreëls toe voordat hy antwoord. Daarom bewys "die poort luister" baie min oor ’n tonnelkliënt.

Lees die lopende konfigurasie eerder as die lêer wat jy dink aktief is. pihole-FTL --config dns.interface en pihole-FTL --config dns.listeningMode druk die werklike waardes, en hulle kan van die gasheerlêer verskil wanneer ’n houer, omgewingsveranderlike of ontplooiingsbestuurder die instelling besit. Die Pi-hole FTL-konfigurasieverwysing lys die modusse en watter een op die koppelvlak staatmaak.

LOCAL vra watter subnet, SINGLE vra watter koppelvlak

LOCAL, die verstek, beantwoord navrae waarvan die bronadres aan ’n subnet behoort wat op een van die gasheer se koppelvlakke ingestel is. ’n Eenvoudige wg0 met 10.90.0.1/24 slaag daardie toets, want die kliënt by 10.90.0.2 sit binne die tonnel-subnet. ’n Kliënt met ’n roete aan die oorkant van ’n eweknie, of een wat agter NAT in ’n ander voorvoegsel versteek is, slaag dit nie, selfs al het die pakket op wg0 aangekom, en geen navraag verskyn in die log nie.

SINGLE verander die vraag. Dit aanvaar navrae wat op die koppelvlak aankom wat deur dns.interface genoem word, met terugvoerlus ingesluit, en ignoreer die bronsubnet. Dit is die modus wat ’n gekettingde of geroteerde VPN-topologie oorleef. Stel albei sleutels saam, want ’n modus sonder ’n genoemde koppelvlak is nie ’n volledige instruksie nie:

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

BIND verander die sokkel, en dit het ’n prys

BIND filter nie ’n wildcard-sokkel nie; dit bind poort 53 net aan adresse wat op die genoemde koppelvlak bestaan, so die kernel weier pakkette wat elders aankom. Dit is strenger as SINGLE en nie ’n sinoniem daarvoor nie. Die prys verskyn by die opstart: as wg0 nie op is wanneer FTL begin nie, is daar dalk geen adres om aan te bind nie, en die oplosser kan sonder ’n luisteraar loop totdat die koppelvlak verskyn en FTL herbegin.

Kies BIND wanneer jy die opstartorde beheer, byvoorbeeld ’n systemd-eenheid wat na die WireGuard-koppelvlak georden is, en wanneer jy wil hê die kernel moet verdwaalde pakkette laat val voordat FTL dit sien. Kies SINGLE wanneer die tonnel kom en gaan, of wanneer die koppelvlak deur ’n program geskep word wat ná FTL begin.

Die vuurmuur is die tweede hek

’n Korrekte FTL-modus misluk steeds as die gasheer se vuurmuur poort 53 op wg0 laat val. Laat die VPN-bronreeks vir albei protokolle deur en hou die internetkant toe. In nftables, met die bestaande input-ketting in die inet-filtertabel, lyk die reëls so:

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 ooreenstemmende IPv6-reëls by as die tonnel IPv6 dra, en plaas hulle voor die ketting se drop-beleid. As die gasheer ufw of firewalld gebruik, druk dieselfde passing in daardie bestuurder uit eerder as om gereedskap te meng. Moenie poort 53 vanaf die internetroeteerder deurstuur nie; kliënte moet die oplosser se VPN-adres deur die tonnel bereik.

Twee paaie bly apart. Kliëntnavrae eindig by FTL. FTL se eie opstroom-navrae vertrek volgens die gasheer se roetetabel, wat die tonnel mag gebruik of nie, so ’n oplosser wat antwoord maar niks bruikbaars teruggee, is ’n opstroomprobleem. Die webadmin en API luister op hulle eie poorte en het hulle eie beperking nodig.

Verifieer die antwoord en die weiering

Vanaf ’n VPN-kliënt, vra die oplosseradres oor albei protokolle: dig @10.90.0.1 example.com en dig +tcp @10.90.0.1 example.com. Kyk dan na die navraaglog in die admin-koppelvlak om te bevestig dat FTL die navraag aangeteken het. ’n Kliënt-tydsverloop sonder ’n loginskrywing dui op die vuurmuur of die koppelvlakfilter; ’n loginskrywing sonder antwoord dui op opstroom-resolusie.

Toets die negatiewe pad vanaf ’n gasheer buite die VPN. dig @10.90.0.1 example.com behoort te verstryk, en ss -lunp op die oplosser behoort nie poort 53 aan ’n openbare adres gebind te wys nie. Herbegin die diens een keer, herbegin dan die gasheer en bevestig dat die oplosser steeds antwoord nadat wg0 weer verskyn. ’n Navraag wat net tot die volgende herbegin werk, is nie ’n afgeronde verandering nie.