Pek OpenVPN-klienter mot en Pi-hole-resolver på en annen vert

Å sette en Pi-hole-adresse inn i en OpenVPN-profil lager ikke en vei til den, gir ikke tillatelse til å spørre den og garanterer ikke at klienten bruker den. Med Pi-hole på en separat LAN-maskin må fire ting stemme: ruten fra klienten, videresendingen fra gatewayen, returveien til poolen og mottakspolicyen på Pi-hole selv. Hver feil ser ulik ut i en logg. Å gå gjennom dem i den rekkefølgen er raskere enn å rette den siste først. Den vanlige snarveien, å åpne rekursjon for enhver opprinnelse, bytter et lite problem mot et permanent.

Hva det pushede DNS-alternativet gjør og ikke gjør

Serveren annonserer en resolver med direktivet nedenfor, forutsatt at 192.168.50.53 er Pi-hole-verten. Klienten mottar alternativet og, avhengig av plattform og resolverintegrasjon , bruker det på tunnelgrensesnittet eller ignorerer det til fordel for en lokal stub. Rutelinjen betyr like mye som DNS-linjen, for en resolver klienten ikke når er ingen resolver i det hele tatt. Ingenting av dette er synlig fra serversiden.

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"

Å motta et alternativ er ikke det samme som å bruke det. En Linux-klient med en resolverbehandler kan godta den pushede serveren og sende bare visse domener til den; en klient som styrer DNS selv kan overskrive innstillingen helt. Pushede ruter er også begrenset på enkelte plattformer, noe som gjør resolveren utilgjengelig selv om alternativet ble godtatt. Sjekk på klienten hvilken server som svarer, ikke på serveren hva som ble sendt.

Alternativet sier heller ingenting om serversiden. DNS-trafikk må fortsatt reise fra klienten til gatewayen og fra gatewayen til Pi-hole før noe alternativ betyr noe. En manglende rute og en avvist spørring ser like ut fra klienten, så bekreft videresendingen på gatewayen først.

Returveien fra Pi-hole til poolen

Hvis klientens kildeadresse bevares, svarer Pi-hole til en adresse inne i VPN-poolen. Dens egen rutetabell vet sannsynligvis ingenting om den poolen, så svaret går til standardgatewayen og forsvinner. Spørringsloggen viser en forespørsel uten et samsvarende svar, noe som er lett å mistolke som et brannmurproblem.

Gi LAN-ruteren en statisk rute for poolen med OpenVPN-gatewayen som neste hopp, eller oversett kilden på gatewayen før videresending til Pi-hole. Den første holder hver klients adresser synlige i Pi-holes spørringslogg. Den andre fjerner kravet om returrute, men får hver spørring til å se ut som den kom fra gatewayen. Ingen av dem er feil; de svarer på ulike spørsmål.

Hvis rapportering eller policy per klient betyr noe, er den statiske ruten den bedre handelen. Hvis LANet administreres av noen andre og ingen rute er tilgjengelig, er oversettelse det pragmatiske alternativet, med tapet av klientidentitet skrevet ned. Noter hvilken du valgte, for hvert senere loggspørsmål avhenger av det.

Pi-holes lyttemodus for rutede klienter

Rullegardinmenyen for grensesnittenes lyttatferd på innstillingssiden under DNS avgjør hvilke kilder Pi-hole svarer. Det strengeste alternativet godtar bare klienter på direkte tilkoblede nettverk; alternativet som tillater enheter høyst ett hopp unna, utvider det til subnett bak en tilstøtende ruter, og det er nettopp hvordan en rutet VPN-klient ser ut. Pakken ankommer riktignok på LAN-grensesnittet, men kildeadressen tilhører et annet subnett. Det er en policyavvisning og ikke en rutefeil, og forskjellen betyr noe når du leser logger.

Pi-holes lytteveiledning skiller lokalt tilkoblede kilder fra rutede opprinnelser, og ankomstgrensesnittet er ikke testen. Velg en modus som tillater VPN-poolen uten å tillate hele internett, og koble den til en brannmurregel som bare godtar DNS fra poolen.

Å åpne rekursjon for alle opprinnelser for å få den første spørringen til å virke er den gale reparasjonen. Det gjør en privat resolver til en åpen en, og rettelsen er en avgrenset tillatelse i stedet for en global.

Koble svaret til spørringsloggen

Spør klienten, sjekk deretter serveren og sammenlign de to. På en systemd-resolved-klient rapporterer kommandoene nedenfor hvilken resolver som produserte et svar, og hvilke servere som er konfigurert per lenke. Bruk et navn som bare Pi-hole kjenner, for en direkte spørring til Pi-hole-adressen beviser nåbarhet og ikke konfigurasjon.

resolvectl query intranet.example.lan
resolvectl dns

Det forventede svaret navngir 192.168.50.53 som server og returnerer en adresse som bare den resolveren ville kjenne. Se deretter på Pi-holes eget bilde: pihole -t følger spørringsloggen live, og hver linje bærer kildeadressen. Er kilden klientens tunneladresse, er poolruten intakt. Er det gatewayens LAN-adresse, er kildeoversettelse i spill, og klientens egen adresse vil aldri dukke opp.

Hvis ingenting vises i loggen i det hele tatt, nådde spørringen aldri Pi-hole, og videresendingen på gatewayen er det neste som skal sjekkes. Hvis spørringen vises og ingen svar kommer tilbake, er returveien problemet, altså forrige avsnitt. Å dele opp feilen på denne måten hindrer at en rutefeil blir forvekslet med en brannmurregel.

Sjekk gatewayens videresendingsregel

Gatewayen må videresende klientens DNS-pakker mot Pi-hole, og regelen som gjør det er verdt å lese i stedet for å anta. Kommandoene nedenfor lister reglene som berører port 53 med tellere, på en nftables-vert og på en iptables-vert. En regel som finnes men viser null treff, er signalet om at trafikk blir forkastet før den oversettes.

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

Les tellerne, ikke bare reglene. En regel som aldri treffer, betyr at pakken forlater via et annet grensesnitt, eller at klienten aldri sendte den. En regel som treffer på hver spørring, betyr at videresendingen virker og at problemet ligger lenger fremme på veien.

Uansett hvilket verktøy verten bruker, hold kontrollen smal: poolen som kilde, port 53 som mål og Pi-hole som eneste tillatte mål. En bred videresendingsregel som også tillater port 80, er et annet problem som venter på å skje.