De ce Pi-hole v6 ignoră interogările DNS de la clienții WireGuard

Pi-hole v6 primește o interogare DNS pe portul 53 și apoi decide dacă pachetul sosit poate primi răspuns. Pe un host WireGuard, a doua decizie este de obicei motivul pentru care un client primește timeout în timp ce resolverul pare sănătos din LAN. Portul este deschis, FTL rulează, și totuși nimic nu se întoarce de la 10.90.0.1. Trei lucruri interacționează înainte ca un răspuns să plece: dns.interface, dns.listeningMode și paravanul din fața ambelor.

Socketul de ascultare nu decide cine primește răspuns

FTL deschide ascultători UDP și TCP pe portul 53. În configurația implicită socketul este adesea wildcard, așa că ss -lunp | grep :53 arată 0.0.0.0:53 și [::]:53 indiferent dacă se deservesc sau nu clienți VPN. Un socket wildcard acceptă pachetul, apoi FTL aplică regulile sale de interfață și sursă înainte de a răspunde. De aceea "portul ascultă" demonstrează foarte puțin despre un client de tunel.

Citiți configurația aflată în execuție, nu fișierul pe care îl credeți activ. pihole-FTL --config dns.interface și pihole-FTL --config dns.listeningMode afișează valorile efective, iar acestea pot diferi de fișierul gazdei când un container, o variabilă de mediu sau un manager de implementare deține setarea. Referința de configurare Pi-hole FTL enumeră modurile și care dintre ele se bazează pe interfață.

LOCAL întreabă ce subrețea, SINGLE întreabă ce interfață

LOCAL, modul implicit, răspunde interogărilor a căror adresă sursă aparține unei subrețele configurate pe una dintre interfețele gazdei. Un wg0 simplu cu 10.90.0.1/24 trece acest test, pentru că clientul de la 10.90.0.2 se află în subrețeaua tunelului. Un client rutat de cealaltă parte a unui peer, sau unul ascuns în spatele NAT într-un alt prefix, nu îl trece, deși pachetul a ajuns pe wg0, și nicio interogare nu apare în jurnal.

SINGLE schimbă întrebarea. Acceptă interogările care sosesc pe interfața numită în dns.interface, inclusiv loopback, și ignoră subrețeaua sursă. Acesta este modul care supraviețuiește unei topologii VPN înlănțuite sau rutate. Setați ambele chei împreună, pentru că un mod fără interfață numită nu este o instrucțiune completă:

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

BIND schimbă socketul, iar asta are un cost

BIND nu filtrează un socket wildcard; leagă portul 53 doar de adresele care există pe interfața numită, așa că nucleul refuză pachetele care sosesc în altă parte. Este mai strict decât SINGLE și nu este sinonimul lui. Costul apare la pornire: dacă wg0 nu este activă când pornește FTL, poate să nu existe adresă de legat, iar resolverul poate rula fără ascultător până când interfața apare și FTL repornește.

Alegeți BIND când controlați ordinea de pornire, de exemplu o unitate systemd ordonată după interfața WireGuard, și când vreți ca nucleul să arunce pachetele rătăcite înainte ca FTL să le vadă. Alegeți SINGLE când tunelul vine și pleacă, sau când interfața este creată de un instrument care pornește după FTL.

Paravanul este a doua poartă

Un mod FTL corect tot eșuează dacă paravanul gazdei aruncă portul 53 pe wg0. Permiteți intervalul sursă VPN pentru ambele protocoale și țineți partea de internet închisă. În nftables, cu lanțul input existent în tabela inet filter, regulile arată așa:

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

Adăugați reguli IPv6 corespunzătoare dacă tunelul transportă IPv6, și puneți-le înaintea politicii de aruncare a lanțului. Dacă gazda folosește ufw sau firewalld, exprimați aceeași potrivire în acel manager în loc să amestecați instrumente. Nu forwardați portul 53 din routerul de internet; clienții trebuie să ajungă la adresa VPN a resolverului prin tunel.

Două căi rămân separate. Interogările clienților se termină la FTL. Căutările proprii ale FTL către upstream ies conform tabelului de rutare al gazdei, care poate sau nu să folosească tunelul, deci un resolver care răspunde dar nu întoarce nimic util este o problemă de upstream. Administrarea web și API-ul ascultă pe porturi proprii și au nevoie de propria restricție.

Verificați răspunsul și refuzul

De pe un client VPN, interogați adresa resolverului prin ambele protocoale: dig @10.90.0.1 example.com și dig +tcp @10.90.0.1 example.com. Apoi verificați jurnalul de interogări din interfața de administrare pentru a confirma că FTL a înregistrat interogarea. Un timeout al clientului fără intrare în jurnal indică paravanul sau filtrul de interfață; o intrare fără răspuns indică rezolvarea upstream.

Testați calea negativă de pe o gazdă din afara VPN-ului. dig @10.90.0.1 example.com ar trebui să expire, iar ss -lunp pe resolver nu ar trebui să arate portul 53 legat de o adresă publică. Reporniți serviciul o dată, apoi reporniți gazda și confirmați că resolverul încă răspunde când wg0 reapare. O interogare care funcționează doar până la următoarea repornire nu este o schimbare terminată.