OpenVPN-kliensek átirányítása egy másik hoszton futó Pi-hole-feloldóra

Ha egy Pi-hole-címet beírunk egy OpenVPN-profilba, az nem hoz létre útvonalat hozzá, nem ad engedélyt a lekérdezésére, és nem garantálja, hogy a kliens használni fogja. Ha a Pi-hole külön LAN-gépen fut, négy dolognak kell egyeznie: a kliens felőli útvonalnak, az átjáró továbbításának, a visszaútnak a pool felé és a Pi-hole saját fogadási szabályának. Minden hiba máshogy néz ki egy naplóban. Ezeket ebben a sorrendben végigvenni gyorsabb, mint a legutolsót javítani először. A szokásos rövidítés, hogy minden forrásnak megnyitjuk a rekurziót, egy kis problémát cserél egy állandóra.

Mit tesz és mit nem tesz a pusholt DNS-beállítás

A szerver az alábbi direktívával hirdet feloldót, feltételezve, hogy 192.168.50.53 a Pi-hole hosztja. A kliens megkapja a beállítást és, platformjától és feloldó-integrációjától függően , alkalmazza a tunnel interfészre, vagy figyelmen kívül hagyja egy helyi stub javára. Az útvonal-sor ugyanolyan fontos, mint a DNS-sor, mert az a feloldó, amelyet a kliens nem ér el, egyáltalán nem feloldó. Mindebből semmi sem látszik a szerver oldaláról.

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"

Beállítást kapni nem ugyanaz, mint használni. Egy Linux-kliens feloldókezelővel elfogadhatja a pusholt szervert, és csak bizonyos domaineket küldhet neki; egy kliens, amely maga kezeli a DNS-t, teljesen felülírhatja a beállítást. A pusholt útvonalak bizonyos platformokon korlátozottak is, ami elérhetetlenné teszi a feloldót, pedig a beállítást elfogadták. A kliensen ellenőrizd, melyik szerver válaszol, és ne a szerveren, mit küldtek.

A beállítás a szerver oldaláról sem mond semmit. A DNS-forgalomnak továbbra is a klienstől az átjáróig, majd az átjárótól a Pi-hole-ig kell jutnia, mielőtt bármely beállítás számítana. A hiányzó útvonal és az elutasított lekérdezés a kliens felől egyformán néz ki, ezért először az átjáró továbbítását igazold.

A visszaút a Pi-hole-tól a poolig

Ha a kliens forráscíme megmarad, a Pi-hole a VPN-poolon belüli címre válaszol. A saját útvonaltáblája valószínűleg semmit sem tud erről a poolról, így a válasz az alapértelmezett átjárójára megy és eltűnik. A lekérdezési napló egy kérést mutat, amelyhez nincs illeszkedő válasz, amit könnyű tűzfalproblémának vélni.

Adj a LAN-routernek statikus útvonalat a poolhoz az OpenVPN-átjáróval következő ugrásként, vagy fordítsd le a forrást az átjárón, mielőtt a Pi-hole felé továbbítanál. Az első láthatóan tartja a kliensenkénti címeket a Pi-hole lekérdezési naplójában. A második megszünteti a visszaút követelményét, de minden lekérdezés úgy néz ki, mintha az átjárótól jönne. Egyik sem hibás; más-más kérdésre válaszolnak.

Ha a kliensenkénti jelentés vagy szabály fontos, a statikus útvonal a jobb üzlet. Ha a LAN-t más kezeli, és útvonal nem áll rendelkezésre, a fordítás a pragmatikus megoldás, a kliens identitásának elvesztését feljegyezve. Jegyezd fel, melyiket választottad, mert minden későbbi naplókérdés ettől függ.

A Pi-hole figyelési módja útvonalazott kliensekhez

Az interfészek figyelési viselkedését kiválasztó legördülő menü a DNS alatti beállítások oldalon dönti el, mely forrásoknak válaszol a Pi-hole. A legszigorúbb beállítás csak a közvetlenül csatlakozó hálózatok klienseit fogadja el; a legfeljebb egy ugrásra lévő eszközöket engedő beállítás kiterjeszti ezt egy szomszédos router mögötti alhálózatokra, és pontosan így néz ki egy útvonalazott VPN-kliens. A csomag megérkezik a LAN-interfészre, de a forráscíme más alhálózathoz tartozik. Ez szabályelutasítás, nem útvonalazási hiba, és a különbség számít a naplók olvasásakor.

A Pi-hole figyelési útmutatója szétválasztja a helyben csatlakozó forrásokat az útvonalazott eredettől, és nem az érkezési interfész a kritérium. Válassz olyan módot, amely engedi a VPN-poolt anélkül, hogy az egész internetet engedné, majd párosítsd egy tűzfalszabállyal, amely csak a poolból fogad DNS-t.

A rekurzió minden forrásra való megnyitása, hogy az első lekérdezés működjön, rossz javítás. Nyilvános feloldót csinál egy privátból, és a megoldás egy szűk hatókörű engedély, nem egy globális.

A válasz és a lekérdezési napló összevetése

Kérdezd meg a klienst, aztán ellenőrizd a szervert, és vesd össze a kettőt. Egy systemd-resolved kliensen az alábbi parancsok megmondják, melyik feloldó adott választ, és mely szerverek vannak kapcsolatonként beállítva. Használj olyan nevet, amelyet csak a Pi-hole ismer, mert a Pi-hole címére küldött közvetlen lekérdezés az elérhetőséget bizonyítja, nem a konfigurációt.

resolvectl query intranet.example.lan
resolvectl dns

A várt válasz 192.168.50.53-at nevezi meg szerverként, és olyan címet ad vissza, amelyet csak az a feloldó ismerne. Aztán nézd meg a Pi-hole saját nézetét: pihole -t élőben követi a lekérdezési naplót, és minden sor hordozza a forráscímet. Ha a forrás a kliens tunnel-címe, a pool útvonala sértetlen. Ha az átjáró LAN-címe, forrásfordítás van játékban, és a kliens saját címe soha nem fog megjelenni.

Ha semmi sem jelenik meg a naplóban, a lekérdezés soha nem érte el a Pi-hole-t, és a következő ellenőrizendő dolog az átjáró továbbítása. Ha a lekérdezés megjelenik, de válasz nem jön vissza, a visszaút a probléma, vagyis az előző szakasz. A hiba ilyen felosztása megakadályozza, hogy egy útvonalazási hibát tűzfalszabálynak nézzünk.

Az átjáró továbbítási szabályának ellenőrzése

Az átjárónak a Pi-hole felé kell továbbítania a kliens DNS-csomagjait, és az ezt végző szabályt érdemes elolvasni, nem feltételezni. Az alábbi parancsok az 53-as portot érintő szabályokat listázzák számlálókkal, egy nftables-hoszten és egy iptables-hoszten. Egy szabály, amely létezik, de nulla találatot mutat, annak a jele, hogy a forgalmat még a fordítás előtt eldobják.

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

A számlálókat olvasd, ne csak a szabályokat. Az a szabály, amely soha nem illeszkedik, azt jelenti, hogy a csomag más interfészen távozik, vagy a kliens soha nem küldte el. Az a szabály, amely minden lekérdezésnél illeszkedik, azt jelenti, hogy a továbbítás működik, és a probléma az útvonalon tovább van.

Bármelyik eszközt használja is a hoszt, tartsd szűken az ellenőrzést: a pool mint forrás, az 53-as port mint cél, és a Pi-hole mint egyetlen engedélyezett cél. Egy széles továbbítási szabály, amely a 80-as portot is engedi, egy másik probléma, amely csak vár arra, hogy megtörténjen.