Dirigir els clients OpenVPN a un resolutor Pi-hole en un altre host

Posar una adreça de Pi-hole en un perfil d'OpenVPN no crea un camí cap a ella, no concedeix permís per consultar-la ni garanteix que el client la faci servir. Quan Pi-hole és en una màquina LAN separada, quatre coses s'han d'alinear: la ruta des del client, el reenviament des de la passarel·la, el camí de tornada al pool i la política de recepció al mateix Pi-hole. Cada fallada té un aspecte diferent en un registre. Tractar-les en aquest ordre és més ràpid que arreglar l'última primer. La drecera habitual, obrir la recursió a tots els orígens, canvia un problema petit per un de permanent.

Què fa i què no fa l'opció DNS empenyuda

El servidor anuncia un resolutor amb la directiva de sota, suposant que 192.168.50.53 és l'host de Pi-hole. El client rep l'opció i, segons la seva plataforma i la integració del resolutor , l'aplica a la interfície del túnel o l'ignora en favor d'un stub local. La línia de ruta importa tant com la línia DNS, perquè un resolutor al qual el client no arriba no és cap resolutor. Res d'això no és visible des del costat del servidor.

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"

Rebre una opció no és el mateix que fer-la servir. Un client Linux amb un gestor de resolutors pot acceptar el servidor empès i enviar-l'hi només certs dominis; un client que gestiona el DNS per si mateix pot sobreescriure el paràmetre del tot. Les rutes empenyudes també estan restringides en algunes plataformes, cosa que deixa el resolutor inabastable encara que l'opció s'hagi acceptat. Comprova al client quin servidor respon, no al servidor què s'ha enviat.

L'opció tampoc diu res sobre el costat del servidor. El trànsit DNS encara ha de viatjar del client a la passarel·la i de la passarel·la a Pi-hole abans que qualsevol opció importi. Una ruta que falta i una consulta rebutjada es veuen iguals des del client, així que confirma primer el reenviament a la passarel·la.

El camí de tornada de Pi-hole al pool

Si es conserva l'adreça d'origen del client, Pi-hole respon a una adreça dins del pool VPN. La seva pròpia taula de rutes probablement no sap res d'aquest pool, així que la resposta va a la seva passarel·la per defecte i desapareix. El registre de consultes mostra una petició sense resposta corresponent, cosa fàcil de malinterpretar com un problema de tallafocs.

Dona al router de la LAN una ruta estàtica per al pool amb la passarel·la OpenVPN com a salt següent, o tradueix l'origen a la passarel·la abans de reenviar a Pi-hole. La primera manté les adreces de cada client visibles al registre de consultes de Pi-hole. La segona elimina el requisit de ruta de tornada però fa que cada consulta sembli venir de la passarel·la. Cap de les dues no és incorrecta; responen preguntes diferents.

Si importen els informes o les polítiques per client, la ruta estàtica és el millor intercanvi. Si la LAN la gestiona una altra persona i no hi ha ruta disponible, la traducció és l'opció pragmàtica, amb la pèrdua de la identitat del client documentada. Anota quina has triat, perquè cada pregunta posterior sobre registres en depèn.

El mode d'escolta de Pi-hole per a clients encaminats

La llista desplegable del comportament d'escolta de les interfícies, a la pàgina d'ajustos sota DNS, decideix a quins orígens respon Pi-hole. L'opció més estricta només accepta clients en xarxes connectades directament; l'opció que permet dispositius a un salt com a màxim ho estén a les subxarxes darrere d'un router adjacent, i així és exactament com es veu un client VPN encaminat. El paquet arriba de fet a la interfície LAN, però la seva adreça d'origen pertany a una altra subxarxa. Això és un refús de política i no una fallada d'encaminament, i la diferència importa quan llegeixes registres.

La guia d' escolta de Pi-hole separa els orígens connectats localment dels orígens encaminats, i la interfície d'arribada no és el criteri. Tria un mode que permeti el pool VPN sense permetre tot internet, i després combina'l amb una regla de tallafocs que accepti DNS només des del pool.

Obrir la recursió a tots els orígens perquè funcioni la primera consulta és la reparació incorrecta. Converteix un resolutor privat en un d'obert, i la correcció és un permís limitat, no global.

Fes coincidir la resposta amb el registre de consultes

Pregunta al client, després comprova el servidor i compara els dos. En un client amb systemd-resolved les ordres de sota informen quin resolutor ha produït una resposta i quins servidors estan configurats per enllaç. Fes servir un nom que només conegui Pi-hole, perquè una consulta directa a l'adreça de Pi-hole demostra abastabilitat, no configuració.

resolvectl query intranet.example.lan
resolvectl dns

La resposta esperada nomena 192.168.50.53 com a servidor i retorna una adreça que només aquell resolutor coneixeria. Després mira la vista del mateix Pi-hole: pihole -t segueix el registre de consultes en directe, i cada línia porta l'adreça d'origen. Si l'origen és l'adreça del túnel del client, la ruta del pool és intacta. Si és l'adreça LAN de la passarel·la, hi ha traducció d'origen i l'adreça del mateix client no apareixerà mai.

Si no apareix res al registre, la consulta no ha arribat mai a Pi-hole i el següent que cal comprovar és el reenviament a la passarel·la. Si la consulta apareix i no torna cap resposta, el problema és el camí de tornada, és a dir, la secció anterior. Dividir la fallada d'aquesta manera evita que un error d'encaminament es confongui amb una regla de tallafocs.

Comprova la regla de reenviament de la passarel·la

La passarel·la ha de reenviar els paquets DNS del client cap a Pi-hole, i la regla que ho fa mereix ser llegida en lloc de suposada. Les ordres de sota llisten les regles que toquen el port 53 amb comptadors, en un host nftables i en un host iptables. Una regla que existeix però mostra zero coincidències és el senyal que el trànsit es descarta abans de traduir-se.

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

Llegeix els comptadors, no només les regles. Una regla que no coincideix mai significa que el paquet surt per una altra interfície, o que el client no l'ha enviat mai. Una regla que coincideix en cada consulta significa que el reenviament funciona i que el problema és més endavant a la ruta.

Sigui quina sigui l'eina que faci servir l'host, mantén la comprovació estreta: el pool com a origen, el port 53 com a destinació i Pi-hole com a únic objectiu permès. Una regla de reenviament àmplia que també permeti el port 80 és un altre problema que espera a passar.