Zašto Pi-hole v6 ignoriše DNS upite klijenata WireGuarda

Pi-hole v6 prima DNS upit na portu 53 i zatim odlučuje da li je paketu koji je stigao dozvoljeno da bude odgovoren. Na WireGuard hostu to drugo odlučivanje obično je razlog zašto klijent dobija tajmaut dok rezolver izgleda zdravo sa LAN-a. Port je otvoren, FTL radi, a ipak ništa ne dolazi natrag sa 10.90.0.1. Tri stvari međusobno djeluju prije nego što odgovor izađe: dns.interface, dns.listeningMode i vatrozid ispred oba.

Slušajući socket ne odlučuje ko dobija odgovor

FTL otvara UDP i TCP slušaoce na portu 53. U podrazumijevanoj konfiguraciji socket je često wildcard, pa ss -lunp | grep :53 pokazuje 0.0.0.0:53 i [::]:53 bez obzira na to poslužuju li se VPN klijenti. Wildcard socket prihvata paket, a zatim FTL primjenjuje svoja pravila za interfejs i izvor prije nego što odgovori. Zato fraza "port sluša" dokazuje vrlo malo o klijentu iz tunela.

Čitajte konfiguraciju koja je u pogonu, a ne datoteku za koju mislite da je aktivna. pihole-FTL --config dns.interface i pihole-FTL --config dns.listeningMode ispisuju stvarne vrijednosti i mogu se razlikovati od datoteke hosta kada kontejner, varijabla okruženja ili menadžer za isporuku posjeduje to podešavanje. Referenca za konfiguraciju Pi-hole FTL-a navodi režime i koji od njih zavisi od interfejsa.

LOCAL pita koja je podmreža, SINGLE pita koji je interfejs

LOCAL, podrazumijevani režim, odgovara na upite čija adresa izvora pripada podmreži konfigurisanoj na jednom od interfejsa hosta. Jednostavan wg0 sa 10.90.0.1/24 prolazi taj test jer klijent na 10.90.0.2 sjedi unutar podmreže tunela. Klijent s rutiranjem s druge strane peera, ili onaj skriven iza NAT-a u drugom prefiksu, ne prolazi ga iako je paket stigao na wg0, i nijedan upit se ne pojavljuje u dnevniku.

SINGLE mijenja pitanje. Prihvata upite koji stižu na interfejs nazvan u dns.interface, uključujući loopback, i ignoriše izvornu podmrežu. To je režim koji preživljava lančanu ili rutiranu VPN topologiju. Postavite oba ključa zajedno, jer režim bez imenovanog interfejsa nije potpuna instrukcija:

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

BIND mijenja socket i to ima cijenu

BIND ne filtrira wildcard socket; veže port 53 samo na adrese koje postoje na imenovanom interfejsu, pa kernel odbija pakete koji stižu drugdje. Stroži je od SINGLE-a i nije njegov sinonim. Cijena se pojavljuje pri podizanju: ako wg0 nije podignut kada FTL startuje, možda nema adrese za vezivanje, a rezolver može raditi bez slušaoca dok se interfejs ne pojavi i FTL ponovo ne pokrene.

Izaberite BIND kada kontrolišete redoslijed pokretanja, na primjer systemd jedinicu poredanu nakon WireGuard interfejsa, i kada želite da kernel odbaci zalutale pakete prije nego što ih FTL vidi. Izaberite SINGLE kada tunel dolazi i odlazi, ili kada interfejs stvara alat koji startuje nakon FTL-a.

Vatrozid je druga kapija

Ispravan FTL režim i dalje pada ako vatrozid hosta odbacuje port 53 na wg0. Propustite VPN raspon izvora za oba protokola i držite internet stranu zatvorenom. U nftables-u, s postojećim input lancem u tabeli inet filter, pravila izgledaju ovako:

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

Dodajte odgovarajuća IPv6 pravila ako tunel nosi IPv6 i stavite ih prije politike odbacivanja lanca. Ako host koristi ufw ili firewalld, izrazite isto podudaranje u tom menadžeru umjesto miješanja alata. Ne prosljeđujte port 53 sa internet rutera; klijenti treba da dosegnu VPN adresu rezolvera kroz tunel.

Dvije putanje ostaju odvojene. Upiti klijenata završavaju na FTL-u. Vlastiti FTL upiti prema upstreamu izlaze prema tabeli rutiranja hosta, koja može ili ne mora koristiti tunel, pa je rezolver koji odgovara ali ne vraća ništa korisno problem na upstream strani. Web administracija i API slušaju na vlastitim portovima i trebaju vlastito ograničenje.

Provjerite odgovor i odbijanje

Sa VPN klijenta, pitajte adresu rezolvera preko oba protokola: dig @10.90.0.1 example.com i dig +tcp @10.90.0.1 example.com. Zatim provjerite dnevnik upita u administrativnom interfejsu da potvrdite da je FTL zabilježio upit. Tajmaut klijenta bez zapisa u dnevniku ukazuje na vatrozid ili filter interfejsa; zapis bez odgovora ukazuje na razrješavanje na upstreamu.

Testirajte negativnu putanju s hosta izvan VPN-a. dig @10.90.0.1 example.com treba da istekne, a ss -lunp na rezolveru ne treba da pokaže port 53 vezan za javnu adresu. Ponovo pokrenite servis jednom, zatim ponovo podignite host i potvrdite da rezolver još odgovara nakon što se wg0 ponovo pojavi. Upit koji radi samo do sljedećeg restarta nije završena promjena.