Direkti OpenVPN-klientojn al Pi-hole-resolvilo sur alia gastiganto

Meti Pi-hole-adreson en OpenVPN-profilo ne kreas vojon al ĝi, ne donas permeson demandi ĝin kaj ne garantias, ke la kliento uzos ĝin. Kiam Pi-hole estas sur aparta LAN-maŝino, kvar aferoj devas kongrui: la vojo de la kliento, la plusendado de la pordego, la revena vojo al la baseno kaj la akcepta politiko sur Pi-hole mem. Ĉiu malsukceso aspektas malsame en protokolo. Prilabori ilin en tiu ordo estas pli rapida ol ripari la lastan unue. La kutima fuŝsolvo, malfermi rikursadon por ĉiu origino, interŝanĝas malgrandan problemon kontraŭ daŭra.

Kion la puŝita DNS-opcio faras kaj kion ne

La servilo anoncas resolvilon per la suba direktivo, supozante ke 192.168.50.53 estas la Pi-hole-gastiganto. La kliento ricevas la opcion kaj, laŭ sia platformo kaj resolvila integriĝo , aplikas ĝin al la tunela interfaco aŭ ignoras ĝin favore al loka stub. La vojlinio same gravas kiel la DNS-linio, ĉar resolvilo, kiun la kliento ne atingas, tute ne estas resolvilo. Nenio el tio videblas de la servila flanko.

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"

Ricevi opcion ne samas kiel uzi ĝin. Linux-kliento kun resolvila administranto povas akcepti la puŝitan servilon kaj sendi al ĝi nur certajn domajnojn; kliento, kiu mem administras DNS, povas tute anstataŭigi la agordon. Puŝitaj vojoj ankaŭ estas limigitaj sur iuj platformoj, kio lasas la resolvilon neatingebla eĉ post kiam la opcio akceptiĝis. Kontrolu ĉe la kliento, kiu servilo respondas, ne ĉe la servilo, kion oni sendis.

La opcio ankaŭ diras nenion pri la servila flanko. DNS-trafiko ankoraŭ devas vojaĝi de la kliento al la pordego kaj de la pordego al Pi-hole antaŭ ol iu ajn opcio gravas. Mankanta vojo kaj rifuzita demando aspektas same de la klienta flanko, do unue konfirmu la plusendadon ĉe la pordego.

La revena vojo de Pi-hole al la baseno

Se la fonta adreso de la kliento konserviĝas, Pi-hole respondas al adreso ene de la VPN-baseno. Ĝia propra enkursiga tabelo verŝajne scias nenion pri tiu baseno, do la respondo iras al ĝia implicita pordego kaj malaperas. La demando-protokolo montras peton sen kongrua respondo, kio facile miskompreniĝas kiel fajromura problemo.

Donu al la LAN-enkursigilo senmovan vojon por la baseno kun la OpenVPN-pordego kiel la sekva salto, aŭ traduku la fonton ĉe la pordego antaŭ ol plusendi al Pi-hole. La unua tenas la adresojn de ĉiu kliento videblaj en la demando-protokolo de Pi-hole. La dua forigas la postulon pri revena vojo sed igas ĉiun demandon aspekti kvazaŭ ĝi venis de la pordego. Neniu estas malĝusta; ili respondas al malsamaj demandoj.

Se raportado aŭ politiko por kliento gravas, la senmova vojo estas la pli bona interŝanĝo. Se la LAN estas administrata de iu alia kaj vojo ne disponeblas, tradukado estas la pragmata opcio, kun la perdo de klienta identeco notita. Notu, kiun vi elektis, ĉar ĉiu posta protokola demando dependas de tio.

La aŭskulta reĝimo de Pi-hole por enkursigitaj klientoj

La falmenuo de la aŭskulta konduto de interfacoj sur la agorda paĝo sub DNS decidas, al kiuj fontoj Pi-hole respondas. La plej strikta opcio akceptas nur klientojn sur rekte konektitaj retoj; la opcio, kiu permesas aparatojn maksimume unu salton for, etendas tion al subretoj malantaŭ apuda enkursigilo, kaj enkursigita VPN-kliento aspektas ĝuste tiel. La paketo ja alvenas ĉe la LAN-interfaco, sed ĝia fonta adreso apartenas al alia subreto. Tio estas politika rifuzo, ne enkursiga fiasko, kaj la diferenco gravas kiam vi legas protokolojn.

La aŭskulta gvidilo de Pi-hole apartigas loke konektitajn fontojn disde enkursigitaj originoj, kaj la alvena interfaco ne estas la kriterio. Elektu reĝimon, kiu permesas la VPN-basenon sen permesi la tutan interreton, poste parigu ĝin kun fajromura regulo, kiu akceptas DNS nur el la baseno.

Malfermi rikursadon por ĉiuj originoj por ke la unua demando funkciu estas la malĝusta riparo. Ĝi igas privatan resolvilon malfermita, kaj la korekto estas limigita permeso, ne tutmonda.

Kongruigu la respondon kun la demando-protokolo

Demandu la klienton, poste kontrolu la servilon kaj komparu la du. Ĉe systemd-resolved-kliento la subaj komandoj raportas, kiu resolvilo produktis respondon kaj kiuj serviloj estas agorditaj por ĉiu ligo. Uzu nomon, kiun nur Pi-hole konas, ĉar rekta demando al la Pi-hole-adreso pruvas atingeblon, ne agordon.

resolvectl query intranet.example.lan
resolvectl dns

La atendata respondo nomas 192.168.50.53 kiel servilon kaj redonas adreson, kiun nur tiu resolvilo konus. Poste rigardu la vidon de Pi-hole mem: pihole -t sekvas la demando-protokolon vive, kaj ĉiu linio portas la fontan adreson. Se la fonto estas la tunela adreso de la kliento, la basena vojo estas sendifekta. Se ĝi estas la LAN-adreso de la pordego, fonta tradukado okazas kaj la propra adreso de la kliento neniam aperos.

Se nenio aperas en la protokolo, la demando neniam atingis Pi-hole kaj la sekva kontrolendaĵo estas la plusendado ĉe la pordego. Se la demando aperas sed neniu respondo revenas, la problemo estas la revena vojo, tio estas la antaŭa sekcio. Tiel dividi la fiaskon malhelpas enkursigan eraron esti prenita kiel fajromura regulo.

Kontrolu la plusendan regulon de la pordego

La pordego devas plusendi la DNS-paketojn de la kliento al Pi-hole, kaj la regulo, kiu tion faras, indas legiĝi anstataŭ supoziĝi. La subaj komandoj listigas la regulojn, kiuj tuŝas pordon 53 kun nombriloj, sur nftables-gastiganto kaj sur iptables-gastiganto. Regulo, kiu ekzistas sed montras nulan kongruon, estas la signalo, ke trafiko estas forĵetata antaŭ ol tradukiĝi.

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

Legu la nombrilojn, ne nur la regulojn. Regulo, kiu neniam kongruas, signifas ke la paketo eliras per alia interfaco, aŭ ke la kliento neniam sendis ĝin. Regulo, kiu kongruas ĉe ĉiu demando, signifas ke la plusendado funkcias kaj la problemo estas pli antaŭe sur la vojo.

Kiun ajn ilon la gastiganto uzas, tenu la kontrolon mallarĝa: la baseno kiel fonto, pordo 53 kiel celo kaj Pi-hole kiel la sola permesita celo. Larĝa plusenda regulo, kiu ankaŭ permesas pordon 80, estas alia problemo atendanta okazi.