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

Pi-hole v6 prima DNS upit na portu 53 i zatim odlučuje sme li se odgovoriti na paket koji je stigao. Na WireGuard hostu ta druga odluka je obično razlog zašto klijent dobije istek vremena dok rješavač izgleda zdravo iz LAN-a. Port je otvoren, FTL radi, a ipak se ništa ne vraća sa 10.90.0.1. Tri stvari djeluju zajedno prije nego odgovor izađe: dns.interface, dns.listeningMode i vatrozid ispred obojega.

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 interfejsa i izvora prije odgovora. Zato fraza "port sluša" dokazuje vrlo malo o klijentu tunela.

Čitajte konfiguraciju koja radi, 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 objavljivanje 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 podrazumijevana mrež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 sa rutiranjem sa 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 ulanč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 i nije njegov sinonim. Cijena se pojavljuje pri podizanju: ako wg0 nije podignut kada FTL startuje, možda nema adrese za vezivanje, a rješavač 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 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, sa 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 rješavača kroz tunel.

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

Provjerite odgovor i odbijanje

Sa VPN klijenta, pitajte adresu rješavača 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. Istek vremena klijenta bez zapisa u dnevniku ukazuje na vatrozid ili filter interfejsa; zapis bez odgovora ukazuje na razrješavanje na uzvodnoj strani.

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