Zašto Pi-hole v6 ignorira DNS upite klijenata WireGuarda

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

Priključnica za slušanje ne odlučuje tko dobiva odgovor

FTL otvara UDP i TCP slušače na portu 53. U zadanom se sastavljanju priključnica često ponaša kao wildcard, pa ss -lunp | grep :53 pokazuje 0.0.0.0:53 i [::]:53 neovisno o tome poslužuju li se VPN klijenti. Wildcard priključnica prihvaća paket, a zatim FTL primjenjuje svoja pravila sučelja i izvora prije nego odgovori. Zato izraz "port sluša" dokazuje vrlo malo o klijentu iz tunela.

Čitajte sastavljanje koje 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 računala kada kontejner, varijabla okoline ili upravitelj implementacije posjeduje tu postavku. Referenca za sastavljanje Pi-hole FTL-a navodi načine i koji od njih ovisi o sučelju.

LOCAL pita koja je podmreža, SINGLE pita koje je sučelje

LOCAL, zadani način, odgovara na upite čija izvorna adresa pripada podmreži postavljenoj na jednom od sučelja računala. Jednostavan wg0 s 10.90.0.1/24 prolazi taj test jer klijent na 10.90.0.2 sjedi unutar podmreže tunela. Klijent s usmjeravanjem s druge strane para, ili onaj skriven iza NAT-a u drugom prefiksu, ne prolazi ga iako je paket stigao na wg0, i nijedan se upit ne pojavljuje u zapisniku.

SINGLE mijenja pitanje. Prihvaća upite koji stižu na sučelje navedeno u dns.interface, uključujući loopback, i zanemaruje izvornu podmrežu. To je način koji preživljava ulančanu ili usmjerenu VPN topologiju. Postavite oba ključa zajedno, jer način bez navedenog sučelja nije potpuna uputa:

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

BIND mijenja priključnicu i to ima cijenu

BIND ne filtrira wildcard priključnicu; veže port 53 samo na adrese koje postoje na navedenom sučelju, pa jezgra odbija pakete koji stižu drugamo. Stroži je od SINGLE-a i nije njegov sinonim. Cijena se pokazuje pri podizanju: ako wg0 nije podignut kada FTL kreće, možda nema adrese za vezanje, a rješavač može raditi bez slušača dok se sučelje ne pojavi i FTL ponovno ne pokrene.

Odaberite BIND kada kontrolirate redoslijed pokretanja, primjerice systemd jedinicu poredanu nakon WireGuard sučelja, i kada želite da jezgra odbaci zalutale pakete prije nego ih FTL vidi. Odaberite SINGLE kada tunel dolazi i odlazi, ili kada sučelje stvara alat koji kreće nakon FTL-a.

Vatrozid su druga vrata

Ispravan FTL način ipak pada ako vatrozid računala odbacuje port 53 na wg0. Propustite VPN raspon izvora za oba protokola i držite internetsku stranu zatvorenom. U nftablesu, s postojećim input lancem u tablici 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 računalo koristi ufw ili firewalld, izrazite isto podudaranje u tom upravitelju umjesto miješanja alata. Ne prosljeđujte port 53 s internetskog usmjerivača; klijenti trebaju dosegnuti VPN adresu rješavača kroz tunel.

Dvije putanje ostaju odvojene. Upiti klijenata završavaju na FTL-u. Vlastiti FTL upiti prema uzvodnom poslužitelju izlaze prema tablici usmjeravanja računala, 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

S 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 zapisnik upita u administrativnom sučelju da potvrdite da je FTL zabilježio upit. Istek vremena klijenta bez zapisa u zapisniku upućuje na vatrozid ili filtar sučelja; zapis bez odgovora upućuje na uzvodno rješavanje.

Isprobajte negativnu putanju s računala izvan VPN-a. dig @10.90.0.1 example.com trebao bi isteći, a ss -lunp na rješavaču ne bi trebao pokazati port 53 vezan uz javnu adresu. Ponovno pokrenite uslugu jednom, zatim ponovno podignite računalo i potvrdite da rješavač još odgovara nakon što se wg0 ponovno pojavi. Upit koji radi samo do sljedećeg ponovnog pokretanja nije dovršena promjena.