Wys OpenVPN-kliënte na 'n Pi-hole-oplosser op 'n ander gasheer

Om 'n Pi-hole-adres in 'n OpenVPN-profiel te sit, skep nie 'n pad daarheen nie, gee nie toestemming om dit te bevra nie, en waarborg nie dat die kliënt dit sal gebruik nie. Wanneer Pi-hole op 'n aparte LAN-masjien staan, moet vier dinge in lyn kom: die roete van die kliënt, die deurvoering vanaf die grendel, die terugpad na die poel en die ontvangsbeleid op Pi-hole self. Elke fout lyk anders in 'n log. Om dit in daardie volgorde te hanteer is vinniger as om die laaste een eerste reg te maak. Die gewone kortpad, om rekursie vir elke bron oop te maak, ruil 'n klein probleem vir 'n permanente een.

Wat die gestoorde DNS-opsie doen en nie doen nie

Die bediener adverteer 'n oplosser met die richtlijn hieronder, met die aanname dat 192.168.50.53 die Pi-hole-gasheer is. Die kliënt ontvang die opsie en, afhangend van sy platform en oplosser-integrasie , pas dit op die tonnel-koppelvlak toe of ignoreer dit ten gunste van 'n plaaslike stomp. Die roetelyn is net so belangrik soos die DNS-lyn, want 'n oplosser wat die kliënt nie kan bereik nie is glad geen oplosser nie. Niks hiervan is van die bediener se kant sigbaar nie.

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"

Om 'n opsie te ontvang is nie dieselfde as om dit te gebruik nie. 'n Linux-kliënt met 'n oplosserbestuurder aanvaar dalk die gestoorde bediener en stuur net sekere domeine daarheen; 'n kliënt wat DNS self bestuur kan die instelling heeltemal oorskryf. Gestoorde roetes is ook op sommige platforms beperk, wat die oplosser onbereikbaar laat selfs nadat die opsie aanvaar is. Kontroleer op die kliënt watter bediener antwoord, nie op die bediener wat gestuur is nie.

Die opsie sê ook niks oor die bediener se kant nie. DNS-verkeer moet steeds van die kliënt na die grendel en van die grendel na Pi-hole beweeg voordat enige opsie saak maak. 'n Ontbrekende roete en 'n geweierde navraag lyk dieselfde van die kliënt af, so bevestig eers die deurvoering op die grendel.

Die terugpad van Pi-hole na die poel

As die kliënt se bronadres bewaar bly, antwoord Pi-hole na 'n adres binne die VPN-poel. Sy eie roetetabel weet waarskynlik niks van daardie poel nie, so die antwoord gaan na sy verstekgrendel en verdwyn. Die navraaglog wys 'n versoek sonder 'n ooreenstemmende antwoord, wat maklik as 'n brandmuurprobleem verkeerd gelees word.

Gee die LAN-roeteerder 'n statiese roete vir die poel met die OpenVPN-grendel as die volgende hop, of vertaal die bron op die grendel voordat dit na Pi-hole deurgevoer word. Die eerste hou elke kliënt se adres sigbaar in Pi-hole se navraaglog. Die tweede verwyder die vereiste van 'n terugroete maar laat elke navraag lyk asof dit van die grendel kom. Nie een is verkeerd nie; hulle beantwoord verskillende vrae.

As verslagdoening of beleid per kliënt saak maak, is die statiese roete die beter ruil. As die LAN deur iemand anders bestuur word en 'n roete nie beskikbaar is nie, is vertaling die pragmatiese opsie, met die verlies van kliëntidentiteit neergeskryf. Skryf neer watter een jy gekies het, want elke latere logvraag hang daarvan af.

Pi-hole se luistermodus vir geroteerde kliënte

Die aftreklys vir die luistergedrag van koppelvlakke op die instellingsbladsy onder DNS bepaal watter bronne Pi-hole antwoord. Die strengste opsie aanvaar net kliënte op direk gekoppelde netwerke; die opsie wat toelaat dat toestelle hoogstens een hop ver is, brei dit uit na subnetwerke agter 'n aangrensende roeteerder, en dit is presies hoe 'n geroteerde VPN-kliënt lyk. Die pakket kom wel by die LAN-koppelvlak aan, maar sy bronadres behoort aan 'n ander subnetwerk. Dit is 'n beleidsweiering en nie 'n roetefout nie, en die verskil maak saak wanneer jy logs lees.

Pi-hole se luistergids skei plaaslik gekoppelde bronne van geroteerde oorspronge, en die aankomskoppelvlak is nie die toets nie. Kies 'n modus wat die VPN-poel toelaat sonder om die hele internet toe te laat, en pas dit dan saam met 'n brandmuurreël toe wat DNS net uit die poel aanvaar.

Om rekursie vir alle oorspronge oop te maak sodat die eerste navraag werk, is die verkeerde herstelling. Dit verander 'n private oplosser in 'n oop een, en die regstelling is 'n beperkte toestemming, nie 'n globale nie.

Pas die antwoord by die navraaglog

Vra die kliënt, kyk dan na die bediener en vergelyk die twee. Op 'n systemd-resolved-kliënt rapporteer die opdragte hieronder watter oplosser 'n antwoord gelewer het en watter bedieners per skakel opgestel is. Gebruik 'n naam wat net Pi-hole ken, want 'n direkte navraag na die Pi-hole-adres bewys bereikbaarheid, nie opstelling nie.

resolvectl query intranet.example.lan
resolvectl dns

Die verwagte antwoord noem 192.168.50.53 as die bediener en gee 'n adres terug wat net daardie oplosser sou ken. Kyk dan na Pi-hole se eie aansig: pihole -t volg die navraaglog lewendig, en elke lyn dra die bronadres. As die bron die kliënt se tonneladres is, is die poelroete ongeskonde. As dit die grendel se LAN-adres is, is bronvertaling aan die werk en die kliënt se eie adres sal nooit verskyn nie.

As niks in die log verskyn nie, het die navraag nooit Pi-hole bereik nie en is die deurvoering op die grendel die volgende ding om na te kyk. As die navraag wel verskyn en geen antwoord kom terug nie, is die terugpad die probleem, dit wil sê die vorige afdeling. Om die fout so te verdeel verhoed dat 'n roetefout vir 'n brandmuurreël aangesien word.

Kontroleer die grendel se deurvoerreël

Die grendel moet die kliënt se DNS-pakkette na Pi-hole deurvoer, en die reël wat dit doen is werd om te lees eerder as om te aanvaar. Die opdragte hieronder lys die reëls wat poort 53 raak met tellers, op 'n nftables-gasheer en op 'n iptables-gasheer. 'n Reël wat bestaan maar nul treffers wys, is die sein dat verkeer weggegooi word voordat dit vertaal word.

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

Lees die tellers, nie net die reëls nie. 'n Reël wat nooit pas nie beteken die pakket verlaat deur 'n ander koppelvlak, of die kliënt het dit nooit gestuur nie. 'n Reël wat by elke navraag pas beteken die deurvoering werk en die probleem is verder langs die pad.

Watter gereedskap die gasheer ook gebruik, hou die kontrole nou: die poel as bron, poort 53 as bestemming en Pi-hole as die enigste toegelate teiken. 'n Breë deurvoerreël wat ook poort 80 toelaat, is 'n ander probleem wat wag om te gebeur.