Usmjeravanje OpenVPN klijenata na Pi-hole rezolver na drugom hostu

Upisivanje Pi-hole adrese u OpenVPN profil ne stvara put do nje, ne daje dozvolu da se ona pita i ne garantuje da će je klijent koristiti. Kada je Pi-hole na odvojenoj LAN mašini, četiri stvari moraju se poklopiti: ruta od klijenta, prosljeđivanje s gatewaya, povratni put do poola i politika prijema na samom Pi-holeu. Svaki kvar izgleda drugačije u dnevniku. Prolazak kroz njih tim redom brži je od popravljanja posljednjeg prvo. Uobičajena prečica, otvaranje rekurzije za svaki izvor, mijenja mali problem za trajni.

Šta gurnuta DNS opcija radi, a šta ne

Server objavljuje rezolver direktivom ispod, pretpostavljajući da je 192.168.50.53 Pi-hole host. Klijent prima opciju i, zavisno od platforme i integracije rezolvera , primjenjuje je na interfejs tunela ili je ignoriše u korist lokalnog stub-a. Linija rute je važna koliko i DNS linija, jer rezolver do kojeg klijent ne stiže nije nikakav rezolver. Ništa od ovoga se ne vidi sa strane servera.

server 10.90.0.0 255.255.255.0
push "dhcp-option DNS 192.168.50.53"
push "route 192.168.50.0 255.255.255.0"

Primiti opciju nije isto što i koristiti je. Linux klijent s menadžerom rezolvera može prihvatiti gurnuti server i slati mu samo određene domene; klijent koji sam upravlja DNS-om može potpuno prepisati postavku. Gurnute rute su također ograničene na nekim platformama, što ostavlja rezolver nedostupnim iako je opcija prihvaćena. Provjeravajte na klijentu koji server odgovara, a ne na serveru šta je poslano.

Opcija također ne govori ništa o strani servera. DNS saobraćaj ipak mora proći od klijenta do gatewaya i od gatewaya do Pi-holea prije nego što bilo koja opcija počne nešto značiti. Ruta koja nedostaje i odbijen upit izgledaju isto sa strane klijenta, zato prvo potvrdite prosljeđivanje na gatewayu.

Povratni put od Pi-holea do poola

Ako se adresa izvora klijenta sačuva, Pi-hole odgovara na adresu unutar VPN poola. Njegova vlastita tabela rutiranja vjerovatno ne zna ništa o tom poolu, pa odgovor ide na njegov podrazumijevani gateway i nestaje. Dnevnik upita pokazuje zahtjev bez odgovarajućeg odgovora, što je lako pogrešno protumačiti kao problem zaštitnog zida.

Dajte LAN ruteru statičku rutu za pool s OpenVPN gatewayem kao sljedećim skokom ili prevedite izvor na gatewayu prije prosljeđivanja ka Pi-holeu. Prvo ostavlja adrese svakog klijenta vidljivim u dnevniku upita Pi-holea. Drugo uklanja zahtjev za povratnom rutom, ali čini da svaki upit izgleda kao da dolazi s gatewaya. Nijedno nije pogrešno; ona odgovaraju na različita pitanja.

Ako su izvještaji ili politika po klijentu važni, statička ruta je bolja razmjena. Ako LAN-om upravlja neko drugi i ruta nije dostupna, prevođenje je pragmatična opcija, sa zabilježenim gubitkom identiteta klijenta. Zabilježite koju ste izabrali, jer svako kasnije pitanje o dnevnicima zavisi od toga.

Režim slušanja Pi-holea za rutirane klijente

Padajuća lista ponašanja slušanja interfejsa na stranici postavki u odjeljku DNS odlučuje kojim izvorima Pi-hole odgovara. Najstroža opcija prihvata samo klijente u direktno povezanim mrežama; opcija koja dozvoljava uređaje najviše jedan skok dalje proširuje to na podmreže iza susjednog rutera, a tako izgleda rutirani VPN klijent. Paket zaista stiže na LAN interfejs, ali njegova adresa izvora pripada drugoj podmreži. To je odbijanje po politici, a ne kvar rutiranja, i razlika je važna kada čitate dnevnike.

Pi-hole vodič za slušanje razdvaja lokalno povezane izvore od rutiranih porijekla i interfejs dolaska nije kriterij. Izaberite režim koji dozvoljava VPN pool bez dozvole cijelog interneta, a zatim ga uparite s pravilom zaštitnog zida koje prihvata DNS samo iz poola.

Otvaranje rekurzije za sve izvore da bi prvi upit proradio je pogrešna popravka. Pretvara privatni rezolver u otvoreni, a popravka je ograničena dozvola, a ne globalna.

Uparite odgovor s dnevnikom upita

Pitajte klijenta, zatim provjerite server i uporedite oba. Na systemd-resolved klijentu komande ispod pokazuju koji je rezolver dao odgovor i koji su serveri postavljeni po vezi. Koristite ime koje zna samo Pi-hole, jer direktan upit na Pi-hole adresu dokazuje dostupnost, a ne konfiguraciju.

resolvectl query intranet.example.lan
resolvectl dns

Očekivani odgovor imenuje 192.168.50.53 kao server i vraća adresu koju bi znao samo taj rezolver. Zatim pogledajte vlastiti prikaz Pi-holea: pihole -t prati dnevnik upita uživo i svaka linija nosi adresu izvora. Ako je izvor tunelska adresa klijenta, ruta poola je netaknuta. Ako je to LAN adresa gatewaya, u igri je prevođenje izvora i vlastita adresa klijenta nikada se neće pojaviti.

Ako se u dnevniku uopšte ništa ne pojavi, upit nikada nije stigao do Pi-holea i sljedeće što treba provjeriti je prosljeđivanje na gatewayu. Ako se upit pojavi a odgovor se ne vrati, problem je povratni put, odnosno prethodni odjeljak. Ovakvo razdvajanje kvara sprječava da se greška rutiranja zamijeni za pravilo zaštitnog zida.

Provjerite pravilo prosljeđivanja gatewaya

Gateway mora proslijediti DNS pakete klijenta ka Pi-holeu, a pravilo koje to radi vrijedi pročitati umjesto pretpostaviti. Komande ispod navode pravila koja dodiruju port 53 s brojačima, na nftables hostu i na iptables hostu. Pravilo koje postoji ali pokazuje nula poklapanja je signal da se saobraćaj odbacuje prije nego što se prevede.

sudo nft list ruleset | grep -A3 'dport 53'
sudo iptables -t nat -L POSTROUTING -n -v | grep 53

Čitajte brojače, ne samo pravila. Pravilo koje se nikada ne poklapa znači da paket izlazi kroz drugi interfejs ili da ga klijent nikada nije poslao. Pravilo koje se poklapa pri svakom upitu znači da prosljeđivanje radi i da je problem dalje na putu.

Koji god alat host koristio, držite provjeru uskom: pool kao izvor, port 53 kao odredište i Pi-hole kao jedini dozvoljeni cilj. Široko pravilo prosljeđivanja koje dozvoljava i port 80 je drugi problem koji samo čeka da se dogodi.