Drejtimi i klientëve OpenVPN te një resolver Pi-hole në një host tjetër

Vendosja e një adrese Pi-hole në një profil OpenVPN nuk krijon një rrugë drejt saj, nuk jep leje për ta pyetur dhe nuk garanton që klienti ta përdorë. Kur Pi-hole është në një makinë të veçantë të LAN-it, katër gjëra duhet të përputhen: rruga nga klienti, përcjellja nga gateway-i, rruga e kthimit drejt pishinës dhe politika e pritjes në vetë Pi-hole. Çdo dështim duket ndryshe në një regjistër. Kalimi nëpër to në këtë rend është më i shpejtë sesa rregullimi i të fundit i pari. Shkurtorja e zakonshme, hapja e rekursionit për çdo origjinë, shkëmben një problem të vogël me një të përhershëm.

Çfarë bën dhe çfarë nuk bën opsioni DNS i shtyrë

Serveri shpall një resolver me direktivën më poshtë, duke supozuar se 192.168.50.53 është hosti Pi-hole. Klienti e merr opsionin dhe, në varësi të platformës dhe integrimit të resolverit , e zbaton në ndërfaqen e tunelit ose e injoron në favor të një stub-i lokal. Rreshti i rrugës ka po aq rëndësi sa rreshti DNS, sepse një resolver ku klienti nuk arrin nuk është fare resolver. Asgjë nga kjo nuk shihet nga ana e serverit.

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"

Marrja e një opsioni nuk është njësoj si përdorimi i tij. Një klient Linux me një menaxher resolver mund të pranojë serverin e shtyrë dhe t'i dërgojë vetëm disa domene; një klient që e menaxhon vetë DNS-në mund ta mbishkruajë plotësisht cilësimin. Rrugët e shtyra janë gjithashtu të kufizuara në disa platforma, gjë që e lë resolverin të paarritshëm edhe pse opsioni u pranua. Kontrolloni në klient cili server përgjigjet, jo në server çfarë u dërgua.

Opsioni gjithashtu nuk thotë asgjë për anën e serverit. Trafiku DNS duhet përsëri të udhëtojë nga klienti te gateway-i dhe nga gateway-i te Pi-hole përpara se çdo opsion të ketë rëndësi. Një rrugë që mungon dhe një kërkesë e refuzuar duken njësoj nga klienti, prandaj së pari konfirmoni përcjelljen në gateway.

Rruga e kthimit nga Pi-hole drejt pishinës

Nëse adresa burimore e klientit ruhet, Pi-hole përgjigjet në një adresë brenda pishinës VPN. Tabela e vet e rrugëtimit ndoshta nuk di asgjë për atë pishinë, kështu që përgjigjja shkon te gateway-i i saj i parazgjedhur dhe zhduket. Regjistri i kërkesave tregon një kërkesë pa përgjigje përputhëse, gjë që është e lehtë të keqinterpretohet si problem i firewall-it.

Jepini ruterit të LAN-it një rrugë statike për pishinën me gateway-in OpenVPN si hopin tjetër, ose përktheni burimin në gateway përpara se të përcillni te Pi-hole. E para i mban adresat e secilit klient të dukshme në regjistrin e kërkesave të Pi-hole. E dyta heq kërkesën për rrugë kthimi, por e bën çdo kërkesë të duket sikur vjen nga gateway-i. Asnjëra nuk është e gabuar; ato përgjigjen pyetjeve të ndryshme.

Nëse raportimi ose politika për çdo klient ka rëndësi, rruga statike është shkëmbimi më i mirë. Nëse LAN-in e menaxhon dikush tjetër dhe nuk ka rrugë të disponueshme, përkthimi është opsioni pragmatik, me humbjen e identitetit të klientit të shënuar. Shënoni cilën zgjodhët, sepse çdo pyetje e mëvonshme për regjistrat varet nga ajo.

Mënyra e dëgjimit e Pi-hole për klientët e rrugëtuar

Lista rënëse e sjelljes së dëgjimit të ndërfaqeve, në faqen e cilësimeve nën DNS, vendos se cilave burime u përgjigjet Pi-hole. Opsioni më i rreptë pranon vetëm klientë në rrjete të lidhura drejtpërdrejt; opsioni që lejon pajisjet më së shumti një hop larg e zgjeron atë në nënrrjete pas një ruteri fqinj, dhe pikërisht kështu duket një klient VPN i rrugëtuar. Paketa vërtet mbërrin në ndërfaqen LAN, por adresa e saj burimore i përket një nënrrjeti tjetër. Ky është një refuzim politikash, jo një dështim rrugëtimi, dhe dallimi ka rëndësi kur lexoni regjistra.

Udhëzuesi i Pi-hole për dëgjimin i ndan burimet e lidhura lokalisht nga origjinat e rrugëtuara, dhe ndërfaqja e mbërritjes nuk është kriteri. Zgjidhni një mënyrë që lejon pishinën VPN pa lejuar të gjithë internetin, pastaj bashkojeni me një rregull firewall që pranon DNS vetëm nga pishina.

Hapja e rekursionit për të gjitha origjinat që kërkesa e parë të funksionojë është rregullimi i gabuar. E kthen një resolver privat në një të hapur, dhe zgjidhja është një leje e kufizuar, jo një globale.

Përputhni përgjigjen me regjistrin e kërkesave

Pyetni klientin, pastaj kontrolloni serverin dhe krahasoni të dyja. Në një klient systemd-resolved, komandat më poshtë raportojnë cili resolver prodhoi një përgjigje dhe cilët serverë janë konfiguruar për çdo lidhje. Përdorni një emër që e di vetëm Pi-hole, sepse një kërkesë e drejtpërdrejtë në adresën e Pi-hole provon arritshmërinë, jo konfigurimin.

resolvectl query intranet.example.lan
resolvectl dns

Përgjigjja e pritur emërton 192.168.50.53 si server dhe kthen një adresë që vetëm ai resolver do ta dinte. Pastaj shikoni pamjen e vetë Pi-hole: pihole -t ndjek regjistrin e kërkesave drejtpërdrejt, dhe çdo rresht mban adresën burimore. Nëse burimi është adresa e tunelit të klientit, rruga e pishinës është e paprekur. Nëse është adresa LAN e gateway-it, përkthimi i burimit është në lojë dhe adresa e vetë klientit nuk do të shfaqet kurrë.

Nëse në regjistër nuk shfaqet fare asgjë, kërkesa nuk arriti kurrë te Pi-hole dhe gjëja tjetër për të kontrolluar është përcjellja në gateway. Nëse kërkesa shfaqet dhe nuk kthehet asnjë përgjigje, problemi është rruga e kthimit, pra seksioni i mëparshëm. Ndarja e dështimit në këtë mënyrë pengon një gabim rrugëtimi të ngatërrohet me një rregull firewall.

Kontrolloni rregullin e përcjelljes së gateway-it

Gateway-i duhet t'i përcjellë paketat DNS të klientit drejt Pi-hole, dhe rregulli që e bën këtë ia vlen të lexohet, jo të supozohet. Komandat më poshtë listojnë rregullat që prekin portën 53 me numërues, në një host nftables dhe në një host iptables. Një rregull që ekziston por tregon zero përputhje është sinjali se trafiku po hidhet para se të përkthehet.

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

Lexoni numëruesit, jo vetëm rregullat. Një rregull që nuk përputhet kurrë do të thotë se paketa del nga një ndërfaqe tjetër, ose se klienti nuk e dërgoi kurrë. Një rregull që përputhet në çdo kërkesë do të thotë se përcjellja funksionon dhe problemi është më tej në rrugë.

Cilido mjet që përdor hosti, mbajeni kontrollin të ngushtë: pishina si burim, porta 53 si destinacion dhe Pi-hole si i vetmi objektiv i lejuar. Një rregull i gjerë përcjelljeje që lejon edhe portën 80 është një problem tjetër që pret të ndodhë.