Direcționarea clienților OpenVPN către un resolver Pi-hole de pe alt host

Punerea unei adrese Pi-hole într-un profil OpenVPN nu creează o cale către ea, nu acordă permisiunea de a o interoga și nu garantează că clientul o folosește. Când Pi-hole rulează pe o mașină separată din LAN, patru lucruri trebuie să se alinieze: ruta de la client, redirecționarea de la gateway, calea de întoarcere către pool și politica de recepție pe Pi-hole însuși. Fiecare eșec arată diferit într-un jurnal. Parcurgerea lor în această ordine este mai rapidă decât repararea ultimului mai întâi. Scurtătura obișnuită, deschiderea recursiunii pentru orice origine, schimbă o problemă mică pe una permanentă.

Ce face și ce nu face opțiunea DNS împinsă

Serverul anunță un resolver cu directiva de mai jos, presupunând că 192.168.50.53 este hostul Pi-hole. Clientul primește opțiunea și, în funcție de platformă și de integrarea resolverului , o aplică interfeței tunelului sau o ignoră în favoarea unui stub local. Linia de rută contează la fel de mult ca linia DNS, pentru că un resolver la care clientul nu poate ajunge nu este deloc resolver. Nimic din toate acestea nu se vede din partea serverului.

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"

A primi o opțiune nu este același lucru cu a o folosi. Un client Linux cu un manager de resolver poate accepta serverul împins și poate trimite către el doar anumite domenii; un client care gestionează singur DNS-ul poate suprascrie complet setarea. Rutele împinse sunt și ele restricționate pe unele platforme, ceea ce lasă resolverul inaccesibil chiar dacă opțiunea a fost acceptată. Verifică pe client care server răspunde, nu pe server ce s-a trimis.

Opțiunea nu spune nimic nici despre partea serverului. Traficul DNS trebuie totuși să călătorească de la client la gateway și de la gateway la Pi-hole înainte ca vreo opțiune să conteze. O rută lipsă și o interogare refuzată arată la fel din partea clientului, așa că confirmă mai întâi redirecționarea pe gateway.

Calea de întoarcere de la Pi-hole la pool

Dacă adresa sursă a clientului este păstrată, Pi-hole răspunde către o adresă din interiorul pool-ului VPN. Propriul tabel de rutare probabil nu știe nimic despre acel pool, așa că răspunsul merge la gateway-ul său implicit și dispare. Jurnalul de interogări arată o cerere fără un răspuns potrivit, ceea ce este ușor de confundat cu o problemă de firewall.

Dă routerului din LAN o rută statică pentru pool cu gateway-ul OpenVPN ca următor hop, sau tradu adresa sursă pe gateway înainte de a redirecționa către Pi-hole. Prima păstrează adresele fiecărui client vizibile în jurnalul de interogări al Pi-hole. A doua elimină cerința rutei de întoarcere, dar face fiecare interogare să pară că vine de la gateway. Niciuna nu este greșită; răspund la întrebări diferite.

Dacă raportarea sau politica pe client contează, ruta statică este schimbul mai bun. Dacă LAN-ul este administrat de altcineva și nu există o rută disponibilă, traducerea este opțiunea pragmatică, cu pierderea identității clientului notată. Notează pe care ai ales-o, pentru că fiecare întrebare ulterioară despre jurnale depinde de ea.

Modul de ascultare al Pi-hole pentru clienții rutați

Lista derulantă pentru comportamentul de ascultare a interfețelor, din pagina de setări la secțiunea DNS, decide căror surse le răspunde Pi-hole. Opțiunea cea mai strictă acceptă doar clienți din rețele conectate direct; opțiunea care permite dispozitive la cel mult un hop distanță extinde asta la subrețelele din spatele unui router adiacent, iar așa arată un client VPN rutat. Pachetul ajunge într-adevăr pe interfața LAN, dar adresa sa sursă aparține altei subrețele. Este un refuz de politică, nu o defecțiune de rutare, iar diferența contează când citești jurnale.

Ghidul Pi-hole despre ascultare separă sursele conectate local de originile rutate, iar interfața de sosire nu este criteriul. Alege un mod care permite pool-ul VPN fără a permite întregul internet, apoi asociază-l cu o regulă de firewall care acceptă DNS doar din pool.

Deschiderea recursiunii pentru toate originile ca să funcționeze prima interogare este reparația greșită. Transformă un resolver privat într-unul deschis, iar corectarea este o permisiune restrânsă, nu una globală.

Potrivește răspunsul cu jurnalul de interogări

Întreabă clientul, apoi verifică serverul și compară cele două. Pe un client systemd-resolved, comenzile de mai jos raportează ce resolver a produs un răspuns și ce servere sunt configurate pe legătură. Folosește un nume pe care doar Pi-hole îl știe, pentru că o interogare directă la adresa Pi-hole dovedește accesibilitatea, nu configurația.

resolvectl query intranet.example.lan
resolvectl dns

Răspunsul așteptat numește 192.168.50.53 ca server și returnează o adresă pe care doar acel resolver ar cunoaște-o. Apoi uită-te la vederea proprie a Pi-hole: pihole -t urmărește jurnalul de interogări în direct, iar fiecare linie poartă adresa sursă. Dacă sursa este adresa de tunel a clientului, ruta pool-ului este intactă. Dacă este adresa LAN a gateway-ului, traducerea sursei este în joc și adresa proprie a clientului nu va apărea niciodată.

Dacă în jurnal nu apare nimic, interogarea nu a ajuns niciodată la Pi-hole, iar redirecționarea pe gateway este următorul lucru de verificat. Dacă interogarea apare și nu se întoarce niciun răspuns, problema este calea de întoarcere, adică secțiunea anterioară. Împărțirea eșecului în acest fel împiedică o eroare de rutare să fie confundată cu o regulă de firewall.

Verifică regula de redirecționare a gateway-ului

Gateway-ul trebuie să redirecționeze pachetele DNS ale clientului către Pi-hole, iar regula care face asta merită citită, nu presupusă. Comenzile de mai jos listează regulile care ating portul 53, cu contoare, pe un host nftables și pe un host iptables. O regulă care există dar arată zero potriviri este semnalul că traficul este aruncat înainte de a fi tradus.

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

Citește contoarele, nu doar regulile. O regulă care nu se potrivește niciodată înseamnă că pachetul pleacă pe altă interfață sau că clientul nu l-a trimis niciodată. O regulă care se potrivește la fiecare interogare înseamnă că redirecționarea funcționează și că problema este mai departe pe cale.

Indiferent de instrumentul folosit de host, ține verificarea îngustă: pool-ul ca sursă, portul 53 ca destinație și Pi-hole ca singura țintă permisă. O regulă largă de redirecționare care permite și portul 80 este o altă problemă care așteaptă să se întâmple.