Pek OpenVPN-klientar mot ein Pi-hole-resolver på ein annan vert

Å setje ei Pi-hole-adresse inn i ein OpenVPN-profil lagar ikkje ein veg til ho, gir ikkje løyve til å spørje ho og garanterer ikkje at klienten brukar ho. Når Pi-hole står på ein separat LAN-maskin, må fire ting stemme: vegen frå klienten, vidaresendinga frå porten, returvegen til bassenget og mottakspolitikken på Pi-hole sjølv. Kvar feil ser ulik ut i ein logg. Å gå gjennom dei i den rekkjefølgja er raskare enn å rette den siste først. Den vanlege snarvegen, å opne rekursjon for kvar opphav, byter eit lite problem mot eit varig.

Kva det pushte DNS-valet gjer og ikkje gjer

Tenaren annonserer ein resolver med direktivet nedanfor, føresett at 192.168.50.53 er Pi-hole-verten. Klienten tek imot valet og, avhengig av plattform og resolverintegrasjon , brukar det på tunellgrensesnittet eller ignorerer det til føremon for ein lokal stub. Rutelinja er like viktig som DNS-linja, for ein resolver klienten ikkje når er ingen resolver i det heile. Ingenting av dette er synleg frå tenarsida.

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"

Å ta imot eit val er ikkje det same som å bruke det. Ein Linux-klient med ein resolverhandsamar kan godta den pushte tenaren og berre sende visse domene til han; ein klient som styrer DNS sjølv kan skrive over innstillinga heilt. Pushte ruter er også avgrensa på nokre plattformer, noko som let resolvaren vere utilgjengeleg sjølv om valet vart godteke. Sjekk på klienten kva tenar som svarar, ikkje på tenaren kva som vart sendt.

Valet seier heller ingenting om tenarsida. DNS-trafikk må framleis reise frå klienten til porten og frå porten til Pi-hole før noko val tyder noko. Ein manglande veg og ei avvist spørjing ser like ut frå klienten, så stadfest vidaresendinga på porten først.

Returvegen frå Pi-hole til bassenget

Viss kjeldeadressa til klienten vert halden, svarar Pi-hole til ei adresse inne i VPN-bassenget. Rutetabellen hans veit truleg ingenting om det bassenget, så svaret går til standardporten og forsvinn. Spørjeloggen viser ei førespurnad utan eit svar som passar, noko som er lett å mistolke som eit brannmurproblem.

Gi LAN-rutaren ein statisk veg for bassenget med OpenVPN-porten som neste hopp, eller omset kjelda på porten før vidaresending til Pi-hole. Den første held adressene til kvar klient synlege i spørjeloggen til Pi-hole. Den andre fjernar kravet om returveg, men får kvar spørjing til å sjå ut som ho kom frå porten. Ingen av dei er feil; dei svarar på ulike spørsmål.

Viss rapportering eller politikk per klient er viktig, er den statiske vegen den betre byttehandelen. Viss LANet vert styrt av nokon andre og ingen veg er tilgjengeleg, er omsetjing det pragmatiske valet, med tapet av klientidentitet skrive ned. Skriv opp kva du valde, for kvar seinare loggspørjing er avhengig av det.

Lyttemodusen til Pi-hole for rutelagde klientar

Rullemenyen for lytteåtferda til grensesnitta på innstillingssida under DNS avgjer kva kjelder Pi-hole svarar. Det strengaste valet godtek berre klientar på direkte tilkopla nettverk; valet som let einingar vere høgst eitt hopp unna, utvidar det til subnett bak ein tilstøytande ruter, og ein rutelagd VPN-klient ser nett slik ut. Pakka kjem verkeleg til LAN-grensesnittet, men kjeldeadressa hennar høyrer til eit anna subnett. Dette er ei avvising etter politikk og ikkje ein rutefeil, og skilnaden er viktig når du les loggar.

Lytteguiden til Pi-hole skil lokalt tilkopla kjelder frå rutelagde opphav, og kome-grensesnittet er ikkje målestokken. Vel ein modus som tillèt VPN-bassenget utan å tillate heile internettet, og køyr han saman med ein brannmurregel som tek imot DNS berre frå bassenget.

Å opne rekursjon for alle opphav for at den første spørjinga skal fungere er den gale reparasjonen. Det gjer ein privat resolver om til ein open, og rettinga er eit avgrensa løyve, ikkje eit globalt.

Få svaret til å passe med spørjeloggen

Spør klienten, sjekk så tenaren og samanlikn dei to. På ein systemd-resolved-klient rapporterer kommandoane nedanfor kva resolver som laga eit svar og kva tenarar som er sette opp per lenkje. Bruk eit namn som berre Pi-hole kjenner, for ei direkte spørjing til Pi-hole-adressa provar tilgjenge, ikkje oppsett.

resolvectl query intranet.example.lan
resolvectl dns

Det venta svaret nemner 192.168.50.53 som tenar og gjev attende ei adresse som berre den resolvaren ville kjenne. Sjå så på visinga til Pi-hole sjølv: pihole -t følgjer spørjeloggen direkte, og kvar linje ber kjeldeadressa. Viss kjelda er tunelladressa til klienten, er vegen til bassenget heil. Viss det er LAN-adressa til porten, er kjeldeomsetjing i gang og den eigne adressa til klienten vil aldri dukke opp.

Viss ingenting dukkar opp i loggen, nådde spørjinga aldri Pi-hole og det neste som må sjekkast er vidaresendinga på porten. Viss spørjinga dukkar opp og ingen svar kjem attende, er problemet returvegen, det vil seie den førre seksjonen. Å dele feilen slik hindrar at ein rutefeil vert teken for ein brannmurregel.

Sjekk vidaresendingsregelen til porten

Porten må sende DNS-pakkane til klienten vidare mot Pi-hole, og regelen som gjer det er verdt å lese i staden for å gå ut frå. Kommandoane nedanfor listar reglane som rører port 53 med teljarar, på ein nftables-vert og på ein iptables-vert. Ein regel som finst men viser null treff, er signalet om at trafikk vert kasta før han vert omsett.

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

Les teljarane, ikkje berre reglane. Ein regel som aldri passar, tyder at pakka går ut gjennom eit anna grensesnitt, eller at klienten aldri sende ho. Ein regel som passar på kvar spørjing, tyder at vidaresendinga fungerer og at problemet er lenger framme på vegen.

Kva verktøy verten enn brukar, hald sjekken trong: bassenget som kjelde, port 53 som mål og Pi-hole som det einaste tillatne målet. Ein brei vidaresendingsregel som også tillèt port 80, er eit anna problem som ventar på å skje.