Peg OpenVPN-klienter mod en Pi-hole-resolver på en anden vært

At sætte en Pi-hole-adresse ind i en OpenVPN-profil skaber ikke en vej til den, giver ikke tilladelse til at forespørge den og garanterer ikke, at klienten bruger den. Med Pi-hole på en separat LAN-maskine skal fire ting passe sammen: ruten fra klienten, videresendelsen fra gatewayen, returvejen til poolen og modtagelsespolitikken på Pi-hole selv. Hver fejl ser forskellig ud i en log. At gennemgå dem i den rækkefølge er hurtigere end at rette den sidste først. Den sædvanlige genvej, at åbne rekursion for enhver oprindelse, bytter et lille problem for et permanent et.

Hvad den pushede DNS-indstilling gør, og hvad den ikke gør

Serveren annoncerer en resolver med direktivet nedenfor, forudsat at 192.168.50.53 er Pi-hole-værten. Klienten modtager indstillingen og, afhængigt af platform og resolverintegration , anvender den på tunnelgrænsefladen eller ignorerer den til fordel for en lokal stub. Rutelinjen betyder lige så meget som DNS-linjen, for en resolver som klienten ikke kan nå, er slet ingen resolver. Intet af dette er synligt 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"

At modtage en indstilling er ikke det samme som at bruge den. En Linux-klient med en resolvermanager accepterer måske den pushede server og sender kun bestemte domæner til den; en klient, der selv styrer DNS, kan overskrive indstillingen helt. Pushede ruter er også begrænsede på nogle platforme, hvilket efterlader resolveren unåelig, selv om indstillingen blev accepteret. Kontrollér på klienten, hvilken server der svarer, og ikke på serveren, hvad der blev sendt.

Indstillingen siger heller intet om serversiden. DNS-trafik skal stadig rejse fra klienten til gatewayen og fra gatewayen til Pi-hole, før nogen indstilling betyder noget. En manglende rute og en afvist forespørgsel ser ens ud fra klienten, så bekræft først videresendelsen på gatewayen.

Returvejen fra Pi-hole til poolen

Hvis klientens kildeadresse bevares, svarer Pi-hole til en adresse inde i VPN-poolen. Dets egen routingtabel ved sandsynligvis intet om den pool, så svaret går til dets standardgateway og forsvinder. Forespørgselsloggen viser en anmodning uden et matchende svar, hvilket er let at fejltolke som et firewallproblem.

Giv LAN-routeren en statisk rute til poolen med OpenVPN-gatewayen som næste hop, eller oversæt kilden på gatewayen, før der videresendes til Pi-hole. Den første holder hver klients adresser synlige i Pi-holes forespørgselslog. Den anden fjerner kravet om en returrute, men får hver forespørgsel til at se ud, som om den kom fra gatewayen. Ingen af dem er forkerte; de besvarer forskellige spørgsmål.

Hvis rapportering eller politik per klient betyder noget, er den statiske rute den bedre handel. Hvis LAN'et administreres af en anden, og der ikke er nogen rute til rådighed, er oversættelse den pragmatiske mulighed, med tabet af klientidentitet skrevet ned. Notér, hvilken du valgte, for hvert senere logspørgsmål afhænger af det.

Pi-holes lyttetilstand for rutede klienter

Rullemenuen for grænsefladernes lytteadfærd på indstillingssiden under DNS afgør, hvilke kilder Pi-hole svarer. Den strengeste indstilling accepterer kun klienter på direkte tilsluttede netværk; den indstilling, der tillader enheder højst ét hop væk, udvider det til undernet bag en tilstødende router, og sådan ser en rutet VPN-klient ud. Pakken ankommer godt nok på LAN-grænsefladen, men dens kildeadresse tilhører et andet undernet. Det er en politikafvisning og ikke en routingfejl, og forskellen betyder noget, når du læser logs.

Pi-holes lyttevejledning skelner lokalt tilsluttede kilder fra rutede oprindelser, og ankomstgrænsefladen er ikke testen. Vælg en tilstand, der tillader VPN-poolen uden at tillade hele internettet, og par den med en firewallregel, der kun accepterer DNS fra poolen.

At åbne rekursion for alle oprindelser for at få den første forespørgsel til at virke er den forkerte reparation. Det gør en privat resolver til en åben en, og rettelsen er en afgrænset tilladelse i stedet for en global.

Kobl svaret til forespørgselsloggen

Spørg klienten, kontrollér derefter serveren, og sammenlign de to. På en systemd-resolved-klient rapporterer kommandoerne nedenfor, hvilken resolver der producerede et svar, og hvilke servere der er konfigureret per link. Brug et navn, som kun Pi-hole kender, for en direkte forespørgsel til Pi-hole-adressen beviser nåbarhed og ikke konfiguration.

resolvectl query intranet.example.lan
resolvectl dns

Det forventede svar navngiver 192.168.50.53 som server og returnerer en adresse, som kun den resolver ville kende. Se derefter på Pi-holes eget billede: pihole -t følger forespørgselsloggen live, og hver linje bærer kildeadressen. Er kilden klientens tunneladresse, er poolruten intakt. Er det gatewayens LAN-adresse, er kildeoversættelse i spil, og klientens egen adresse vil aldrig dukke op.

Hvis der slet ikke vises noget i loggen, nåede forespørgslen aldrig Pi-hole, og videresendelsen på gatewayen er det næste, der skal kontrolleres. Hvis forespørgslen vises, og der ikke kommer et svar tilbage, er returvejen problemet, altså det forrige afsnit. At opdele fejlen på den måde forhindrer, at en routingfejl forveksles med en firewallregel.

Kontrollér gatewayens videresendelsesregel

Gatewayen skal videresende klientens DNS-pakker mod Pi-hole, og reglen, der gør det, er værd at læse i stedet for at antage. Kommandoerne nedenfor viser de regler, der rører port 53, med tællere, på en nftables-vært og på en iptables-vært. En regel, der findes, men viser nul match, er signalet om, at trafik bliver kasseret, før den oversættes.

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

Læs tællerne, ikke bare reglerne. En regel, der aldrig matcher, betyder, at pakken forlader via en anden grænseflade, eller at klienten aldrig sendte den. En regel, der matcher ved hver forespørgsel, betyder, at videresendelsen virker, og at problemet ligger længere fremme på vejen.

Uanset hvilket værktøj værten bruger, hold kontrollen snæver: poolen som kilde, port 53 som destination og Pi-hole som det eneste tilladte mål. En bred videresendelsesregel, der også tillader port 80, er et andet problem, der venter på at ske.