Usmeritev odjemalcev OpenVPN na resolver Pi-hole na drugem gostitelju

Vpis naslova Pi-hole v profil OpenVPN ne ustvari poti do njega, ne podeli dovoljenja za poizvedovanje po njem in ne zagotovi, da ga bo odjemalec uporabil. Ko je Pi-hole na ločenem računalniku v omrežju LAN, se morajo ujemati štiri stvari: pot od odjemalca, posredovanje s prehoda, povratna pot do bazena in politika sprejemanja na samem Pi-holu. Vsaka napaka je v dnevniku videti drugače. Če jih obdelate v tem vrstnem redu, ste hitreje gotovi, kot če najprej popravite zadnjo. Običajna bližnjica, odpiranje rekurzije za vsak vir, zamenja majhno težavo za trajno.

Kaj potisnjena možnost DNS naredi in česa ne

Strežnik oglašuje resolver z direktivo spodaj, ob predpostavki, da je 192.168.50.53 gostitelj Pi-hole. Odjemalec prejme možnost in jo, odvisno od platforme in integracije resolverja , uporabi na vmesniku tunela ali pa jo zavrže v korist lokalnega stub-a. Vrstica poti je enako pomembna kot vrstica DNS, saj resolver, do katerega odjemalec ne seže, ni noben resolver. Nič od tega ni vidno s strani strežnika.

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"

Prejeti možnost ni isto kot jo uporabljati. Odjemalec Linuxa z upraviteljem resolverja lahko potisnjeni strežnik sprejme in mu pošilja le določene domene; odjemalec, ki sam upravlja DNS, lahko nastavitev povsem prepiše. Potisnjene poti so na nekaterih platformah tudi omejene, zato resolver ostane nedosegljiv, čeprav je bila možnost sprejeta. Preverite na odjemalcu, kateri strežnik odgovarja, ne na strežniku, kaj je bilo poslano.

Možnost tudi ne pove ničesar o strani strežnika. Promet DNS mora še vedno potovati od odjemalca do prehoda in od prehoda do Pi-hola, preden katera koli možnost kaj pomeni. Manjkajoča pot in zavrnjena poizvedba sta z vidika odjemalca videti enako, zato najprej potrdite posredovanje na prehodu.

Povratna pot od Pi-hola do bazena

Če se naslov vira odjemalca ohrani, Pi-hole odgovori na naslov znotraj bazena VPN. Njegova lastna usmerjevalna tabela verjetno ne ve ničesar o tem bazenu, zato odgovor odide na njegov privzeti prehod in izgine. Dnevnik poizvedb pokaže zahtevo brez ustreznega odgovora, kar zlahka napačno razumemo kot težavo požarnega zidu.

Usmerjevalniku v omrežju LAN dajte statično pot za bazen s prehodom OpenVPN kot naslednjim skokom ali prevedite vir na prehodu, preden posredujete proti Pi-holu. Prva rešitev ohrani naslove vsakega odjemalca vidne v dnevniku poizvedb Pi-hola. Druga odpravi zahtevo po povratni poti, a vsako poizvedbo naredi videti, kot da prihaja s prehoda. Nobena ni napačna; odgovarjata na različni vprašanji.

Če sta pomembna poročanje ali politika po odjemalcu, je statična pot boljša izmenjava. Če omrežje LAN upravlja nekdo drug in pot ni na voljo, je prevajanje pragmatična možnost, z izgubo identitete odjemalca zapisano. Zabeležite, katero ste izbrali, ker je vsako poznejše vprašanje o dnevnikih odvisno od tega.

Način poslušanja Pi-hola za usmerjene odjemalce

Spustni seznam vedenja poslušanja vmesnikov na strani z nastavitvami v razdelku DNS odloča, katerim virom Pi-hole odgovarja. Najstrožja možnost sprejme le odjemalce v neposredno povezanih omrežjih; možnost, ki dovoljuje naprave največ en skok stran, to razširi na podomrežja za sosednjim usmerjevalnikom, in prav tako je videti usmerjen odjemalec VPN. Paket res prispe na vmesnik LAN, vendar njegov naslov vira pripada drugemu podomrežju. To je zavrnitev zaradi politike, ne napaka usmerjanja, in razlika je pomembna, ko berete dnevnike.

Vodnik Pi-hola za poslušanje ločuje lokalno povezane vire od usmerjenih izvorov, vmesnik prihoda pa ni merilo. Izberite način, ki dovoljuje bazen VPN, ne da bi dovolil ves internet, nato pa ga povežite s pravilom požarnega zidu, ki sprejema DNS le iz bazena.

Odpiranje rekurzije za vse izvore, da bi prva poizvedba delovala, je napačno popravilo. Zasebni resolver spremeni v odprtega, popravek pa je omejeno dovoljenje, ne globalno.

Ujemite odgovor z dnevnikom poizvedb

Vprašajte odjemalca, nato preverite strežnik in primerjajte oba. Na odjemalcu systemd-resolved spodnji ukazi povedo, kateri resolver je ustvaril odgovor in kateri strežniki so nastavljeni na povezavo. Uporabite ime, ki ga pozna le Pi-hole, ker neposredna poizvedba na naslov Pi-hola dokazuje dosegljivost, ne konfiguracije.

resolvectl query intranet.example.lan
resolvectl dns

Pričakovani odgovor navaja 192.168.50.53 kot strežnik in vrne naslov, ki bi ga poznal le ta resolver. Nato poglejte pogled Pi-hola samega: pihole -t spremlja dnevnik poizvedb v živo in vsaka vrstica nosi naslov vira. Če je vir naslov tunela odjemalca, je pot bazena nedotaknjena. Če je to naslov LAN prehoda, je v igri prevajanje vira in lastni naslov odjemalca se ne bo nikoli pojavil.

Če se v dnevniku ne pojavi nič, poizvedba ni nikoli dosegla Pi-hola in naslednja stvar za preverjanje je posredovanje na prehodu. Če se poizvedba pojavi in odgovora ni nazaj, je težava povratna pot, torej prejšnji razdelek. Takšna razdelitev napake prepreči, da bi napako usmerjanja zamenjali za pravilo požarnega zidu.

Preverite pravilo posredovanja prehoda

Prehod mora posredovati pakete DNS odjemalca proti Pi-holu, in pravilo, ki to počne, si velja prebrati, ne pa domnevati. Spodnji ukazi naštejejo pravila, ki se dotikajo vrat 53, s števci, na gostitelju nftables in na gostitelju iptables. Pravilo, ki obstaja, a kaže nič zadetkov, je znak, da se promet zavrže, preden se prevede.

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

Berite števce, ne le pravil. Pravilo, ki se nikoli ne ujame, pomeni, da paket odide skozi drug vmesnik ali da ga odjemalec ni nikoli poslal. Pravilo, ki se ujame pri vsaki poizvedbi, pomeni, da posredovanje deluje in da je težava dlje na poti.

Katero koli orodje gostitelj uporablja, naj bo preverjanje ozko: bazen kot vir, vrata 53 kot cilj in Pi-hole kot edini dovoljeni cilj. Široko pravilo posredovanja, ki dovoli tudi vrata 80, je druga težava, ki le čaka, da se zgodi.