Novirzīt OpenVPN klientus uz Pi-hole atrisinātāju citā resursdatorā

Pi-hole adreses ievietošana OpenVPN profilā neizveido ceļu uz to, nedod atļauju to vaicāt un negarantē, ka klients to izmantos. Kad Pi-hole atrodas atsevišķā LAN mašīnā, četrām lietām jāsakrīt: ceļam no klienta, pāradresācijai no vārtejas, atgriešanās ceļam uz baseinu un uztveršanas politikai pašā Pi-hole. Katra kļūme izskatās citādi žurnālā. To apstrāde šādā secībā ir ātrāka nekā pēdējās labošana vispirms. Parastais saīsinājums, rekursijas atvēršana visiem avotiem, apmaina mazu problēmu pret pastāvīgu.

Ko uzspiests DNS variants dara un ko ne

Serveris paziņo atrisinātāju ar zemāk norādīto direktīvu, pieņemot, ka 192.168.50.53 ir Pi-hole resursdators. Klients saņem variantu un, atkarībā no platformas un atrisinātāja integrācijas , piemēro to tuneļa saskarnei vai ignorē to par labu vietējam stub. Maršruta rinda ir tikpat svarīga kā DNS rinda, jo atrisinātājs, kuram klients nevar piekļūt, nemaz nav atrisinātājs. Nekas no tā nav redzams no servera puses.

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"

Variantu saņemt nav tas pats, kas to izmantot. Linux klients ar atrisinātāja pārvaldnieku var pieņemt uzspiesto serveri un sūtīt tam tikai noteiktus domēnus; klients, kas pārvalda DNS pats, var pilnībā pārrakstīt iestatījumu. Uzspiestie maršruti arī ir ierobežoti dažās platformās, kas atstāj atrisinātāju nesasniedzamu pat pēc varianta pieņemšanas. Pārbaudi klientā, kurš serveris atbild, nevis serverī, kas tika nosūtīts.

Variants arī neko nepasaka par servera pusi. DNS trafikam joprojām jāceļo no klienta uz vārteju un no vārtejas uz Pi-hole, pirms jebkurš variants kļūst nozīmīgs. Trūkstošs maršruts un noraidīts vaicājums no klienta puses izskatās vienādi, tāpēc vispirms apstiprini pāradresāciju uz vārtejas.

Atgriešanās ceļš no Pi-hole uz baseinu

Ja klienta avota adrese tiek saglabāta, Pi-hole atbild uz adresi VPN baseinā. Tā paša maršrutēšanas tabula, visticamāk, neko nezina par šo baseinu, tāpēc atbilde aiziet uz tās noklusējuma vārteju un pazūd. Vaicājumu žurnāls rāda pieprasījumu bez atbilstošas atbildes, ko viegli pārprast kā ugunsmūra problēmu.

Dod LAN maršrutētājam statisku maršrutu uz baseinu ar OpenVPN vārteju kā nākamo lēcienu, vai pārtulko avotu uz vārtejas pirms pāradresācijas uz Pi-hole. Pirmais saglabā katra klienta adreses redzamas Pi-hole vaicājumu žurnālā. Otrais novērš atgriešanās maršruta prasību, bet liek katram vaicājumam izskatīties kā nākušam no vārtejas. Neviens nav nepareizs; tie atbild uz dažādiem jautājumiem.

Ja svarīga ir atskaitīšana vai politika katram klientam, statiskais maršruts ir labākais maiņas darījums. Ja LAN pārvalda kāds cits un maršruts nav pieejams, tulkošana ir pragmatiskais variants, ar klienta identitātes zudumu pierakstītu. Pieraksti, kuru izvēlējies, jo katrs vēlākais žurnāla jautājums no tā ir atkarīgs.

Pi-hole klausīšanās režīms maršrutētiem klientiem

Saskarņu klausīšanās uzvedības nolaižamā izvēlne lapā ar iestatījumiem sadaļā DNS nosaka, kuriem avotiem Pi-hole atbild. Stingrākais variants pieņem tikai klientus tieši pievienotos tīklos; variants, kas pieļauj ierīces ne tālāk kā vienu lēcienu, paplašina to uz apakštīkliem aiz blakus maršrutētāja, un maršrutēts VPN klients izskatās tieši tā. Pakete patiešām nonāk LAN saskarnē, bet tās avota adrese pieder citam apakštīklam. Tā ir politikas atteikšana, nevis maršrutēšanas kļūme, un atšķirība ir svarīga, lasot žurnālus.

Pi-hole klausīšanās rokasgrāmata atdala lokāli pievienotos avotus no maršrutētās izcelsmes, un ierašanās saskarne nav kritērijs. Izvēlies režīmu, kas pieļauj VPN baseinu, nepieļaujot visu internetu, un pēc tam sapāro to ar ugunsmūra noteikumu, kas pieņem DNS tikai no baseina.

Rekursijas atvēršana visiem avotiem, lai pirmais vaicājums darbotos, ir nepareizs labojums. Tas pārvērš privātu atrisinātāju atvērtā, un labojums ir ierobežota atļauja, nevis globāla.

Saskaņo atbildi ar vaicājumu žurnālu

Pajautā klientam, pēc tam pārbaudi serveri un salīdzini abus. systemd-resolved klientā zemāk esošās komandas ziņo, kurš atrisinātājs radīja atbildi un kuri serveri ir konfigurēti katram savienojumam. Izmanto nosaukumu, ko zina tikai Pi-hole, jo tiešs vaicājums uz Pi-hole adresi pierāda sasniedzamību, nevis konfigurāciju.

resolvectl query intranet.example.lan
resolvectl dns

Gaidītā atbilde nosauc 192.168.50.53 kā serveri un atgriež adresi, ko zinātu tikai šis atrisinātājs. Pēc tam apskati paša Pi-hole skatu: pihole -t seko vaicājumu žurnālam tiešraidē, un katra rinda nes avota adresi. Ja avots ir klienta tuneļa adrese, baseina maršruts ir neskarts. Ja tā ir vārtejas LAN adrese, notiek avota tulkošana un klienta paša adrese nekad neparādīsies.

Ja žurnālā neparādās nekas, vaicājums nekad nav sasniedzis Pi-hole, un nākamais pārbaudāmais ir pāradresācija uz vārtejas. Ja vaicājums parādās, bet atbilde neatgriežas, problēma ir atgriešanās ceļā, tas ir, iepriekšējā sadaļā. Šāda kļūmes sadalīšana neļauj maršrutēšanas kļūdu noturēt par ugunsmūra noteikumu.

Pārbaudi vārtejas pāradresācijas noteikumu

Vārtejai ir jāpāradresē klienta DNS paketes uz Pi-hole, un noteikums, kas to dara, ir pelnījis lasīšanu, nevis pieņēmumu. Zemāk esošās komandas uzskaita noteikumus, kas skar portu 53, ar skaitītājiem, nftables resursdatorā un iptables resursdatorā. Noteikums, kas pastāv, bet rāda nulli sakritību, ir signāls, ka trafiks tiek izmests pirms tulkošanas.

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

Lasi skaitītājus, ne tikai noteikumus. Noteikums, kas nekad nesakrīt, nozīmē, ka pakete iziet pa citu saskarni vai klients to nekad nav nosūtījis. Noteikums, kas sakrīt katrā vaicājumā, nozīmē, ka pāradresācija darbojas un problēma ir tālāk ceļā.

Lai kādu rīku resursdators izmantotu, turi pārbaudi šauru: baseins kā avots, ports 53 kā galamērķis un Pi-hole kā vienīgais atļautais mērķis. Plats pāradresācijas noteikums, kas pieļauj arī portu 80, ir cita problēma, kas gaida notikšanu.