Suuna OpenVPN kliendid teise hosti Pi-hole'i lahendajale

Pi-hole'i aadressi OpenVPN-profiili panemine ei loo sinna teed, ei anna õigust seda küsida ega taga, et klient seda kasutab. Kui Pi-hole on eraldi LAN-masinas, peavad neli asja kokku langema: tee kliendist, edasisaatmine lüüsist, tagasitee basseini ja vastuvõtupoliitika Pi-hole'is endas. Iga tõrge näeb logis erinev välja. Nende selles järjekorras käsitlemine on kiirem kui viimase esimesena parandamine. Tavaline otsetee, rekursiooni avamine kõigile allikatele, vahetab väikese probleemi püsiva vastu.

Mida lükatud DNS-valik teeb ja mida mitte

Server teavitab lahendajast alloleva direktiiviga, eeldades, et 192.168.50.53 on Pi-hole'i host. Klient saab valiku ja, sõltuvalt platvormist ja lahendaja integratsioonist , rakendab selle tunneliliidesele või jätab selle kohaliku stubi kasuks tähelepanuta. Marsruudirida on sama oluline kui DNS-rida, sest lahendaja, kelleni klient ei jõua, ei ole üldse lahendaja. Midagi sellest ei ole serveri poolelt näha.

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"

Valiku saamine ei ole sama mis selle kasutamine. Linuxi klient lahendajahalduriga võib lükatud serveri vastu võtta ja saata sinna ainult teatud domeene; klient, kes haldab DNS-i ise, võib seade täielikult üle kirjutada. Lükatud marsruudid on mõnel platvormil ka piiratud, mis jätab lahendaja kättesaamatuks ka siis, kui valik vastu võeti. Kontrolli kliendil, milline server vastab, mitte serveril, mida saadeti.

Valik ei ütle midagi ka serveri poole kohta. DNS-liiklus peab ikkagi liikuma kliendist lüüsini ja lüüsist Pi-hole'ini enne, kui ükskõik milline valik loeb. Puuduv marsruut ja tagasilükatud päring näevad kliendi poolt ühesugused välja, seega kinnita esmalt edasisaatmine lüüsil.

Tagasitee Pi-hole'ist basseini

Kui kliendi lähteaadress säilib, vastab Pi-hole VPN-basseini sees olevale aadressile. Selle enda marsruutimistabel ei tea tõenäoliselt sellest basseinist midagi, seega läheb vastus selle vaikimisi lüüsile ja kaob. Päringulogi näitab päringut ilma vastava vastuseta, mida on lihtne tulemüüriprobleemiks pidada.

Anna LAN-marsruuterile basseini jaoks staatiline marsruut, kus OpenVPN-lüüs on järgmine hüpe, või tõlgi lähteaddress lüüsil enne Pi-hole'ile edasisaatmist. Esimene hoiab iga kliendi aadressid Pi-hole'i päringulogis nähtavana. Teine kaotab tagasitee nõude, kuid paneb iga päringu näima lüüsilt tulevana. Kumbki ei ole vale; need vastavad erinevatele küsimustele.

Kui aruandlus või poliitika kliendi kohta on oluline, on staatiline marsruut parem vahetus. Kui LAN-i haldab keegi teine ja marsruuti pole saadaval, on tõlkimine pragmaatiline valik, kliendi identiteedi kadu kirja pandud. Pane kirja, millise valisid, sest iga hilisem logiküsimus sõltub sellest.

Pi-hole'i kuulamisrežiim marsruuditud klientidele

DNS-i all oleva seadete lehe liideste kuulamis käitumise rippmenüü otsustab, millistele allikatele Pi-hole vastab. Kõige rangem valik võtab vastu ainult otse ühendatud võrkude kliente; valik, mis lubab seadmeid kõige rohkem ühe hüppe kaugusel, laiendab selle külgneva marsruuteri taga olevatele alamvõrkudele ja marsruuditud VPN-klient näeb täpselt selline välja. Pakett jõuab tõesti LAN-liidesele, kuid selle lähteaadress kuulub teise alamvõrku. See on poliitiline keeldumine, mitte marsruutimise tõrge, ja erinevus on logisid lugedes oluline.

Pi-hole'i kuulamisjuhend eristab kohapeal ühendatud allikaid marsruuditud päritolust ning saabumisliides ei ole kriteerium. Vali režiim, mis lubab VPN-basseini ilma kogu internetti lubamata, ja seo see seejärel tulemüürireegliga, mis võtab DNS-i vastu ainult basseinist.

Rekursiooni avamine kõigile päritoludele, et esimene päring töötaks, on vale parandus. See muudab privaatse lahendaja avatuks ja parandus on piiratud luba, mitte globaalne.

Sovita vastus päringulogiga

Küsi kliendilt, seejärel kontrolli serverit ja võrdle mõlemat. systemd-resolved kliendil teatavad allolevad käsud, milline lahendaja vastuse tekitas ja millised serverid on iga lingi jaoks seadistatud. Kasuta nime, mida teab ainult Pi-hole, sest otsene päring Pi-hole'i aadressile tõestab kättesaadavust, mitte seadistust.

resolvectl query intranet.example.lan
resolvectl dns

Oodatav vastus nimetab 192.168.50.53 serverina ja tagastab aadressi, mida teaks ainult see lahendaja. Seejärel vaata Pi-hole'i enda vaadet: pihole -t jälgib päringulogi reaalajas ja iga rida kannab lähteaadressi. Kui allikas on kliendi tunneliaadress, on basseini marsruut terve. Kui see on lüüsi LAN-aadress, käib lähtekoha tõlkimine ja kliendi enda aadress ei ilmu kunagi.

Kui logis ei ilmu üldse midagi, ei jõudnud päring kunagi Pi-hole'ini ja järgmine kontrollitav asi on edasisaatmine lüüsil. Kui päring ilmub, kuid vastust ei tule tagasi, on probleem tagasitees, st eelmises jaotises. Tõrke selline jagamine hoiab ära marsruutimisvea pidamise tulemüürireegliks.

Kontrolli lüüsi edasisaatmisreeglit

Lüüs peab kliendi DNS-paketid Pi-hole'i suunas edasi saatma ja reeglit, mis seda teeb, tasub lugeda, mitte eeldada. Allolevad käsud loetlevad porti 53 puudutavad reeglid koos loenduritega, nftables-hostil ja iptables-hostil. Reegel, mis on olemas, kuid näitab null vastet, on märk, et liiklus visatakse enne tõlkimist ära.

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

Loe loendureid, mitte ainult reegleid. Reegel, mis kunagi ei vasta, tähendab, et pakett väljub teise liidese kaudu või et klient ei saatnud seda kunagi. Reegel, mis vastab igale päringule, tähendab, et edasisaatmine töötab ja probleem on tee peal kaugemal.

Ükskõik millist tööriista host kasutab, hoia kontroll kitsas: bassein allikana, port 53 sihtkohana ja Pi-hole ainsa lubatud sihtmärgina. Lai edasisaatmisreegel, mis lubab ka porti 80, on teine probleem, mis ootab juhtumist.