Pi-hole-k ez ditu iragarkiak blokeatzen VPN-a konektatu ondoren: bost egiaztapen

Iragarkiak oraindik agertzen dira bezero batean, Pi-hole-k osasuntsu dagoela dio, eta tunela martxan dago, beraz, sena bezero horren trafikoa Pi-tik bideratzea da. Bihurgune okerra da hori. Iragazketak galderak behar ditu, ez paketeak, eta kontsultak ISP-ren ebazpenera joaten zaizkion bezeroa iragazi gabe geratzen da, bere trafikoa edonora joan arren. Egin zerrenda hau ordenan eta gelditu huts egiten duen lehen pausuan, geroagoko pausu batek ezer esan ezin dizulako aurrekoa hondatuta dagoen bitartean.

1. Irakurri bezeroak benetan erabiltzen duen ebazpena

Galdetu bezeroari, ez bideratzaileari. Linux-en resolvectl status-ek esteka bakoitzeko DNS zerbitzariak eta zein estekak irabazten duen inprimatzen du; /etc/resolv.conf bakarrik, normalean, 127.0.0.53-ra seinalatzen duen stub bat da. Windows-en ipconfig /all-ek DHCP-k emandako zerbitzariak zerrendatzen ditu egokitzaile bakoitzeko, eta macOS-en scutil --dns-ek gauza bera erakusten du esparruka. Erantzuna Pi-hole-ren helbidea ez bada, esleipen arazoa daukazu eta 2 pausua da hori non dagoen.

Bi gauzak sistema-ebazpena gainditzen dute behar bezala ezarrita egon arren. DNS seguru propioa duten nabigatzaileek (Chrome-ren “Use secure DNS”, Firefox-en network.trr.mode) HTTPS bidez bidaltzen dituzte kontsultak ebazpen publiko batera eta ez dute 53 portua inoiz irekitzen. Eta bezeroan bertan dagoen VPN bezero batek DNS zerbitzari bat instala dezake bere tunel interfazean ~. bideratze-domeinuarekin, eta horrek esteka hori izen guztietarako autoritatezko egiten du.

Probatu aplikazioek hartzen duten bidea, ez arazketa-tresnak hartzen duena. resolvectl query example.com-ek zein estekak erantzun duen erakusten du, eta getent hosts example.com aplikazio batek egiten duen NSS bide beretik doa; macOS-en dscacheutil -q host -a name example.com-ek scutil --dns-ek zerrendatzen dituen esparruko ebazpenak irakurtzen ditu. dig soil batek ez du hori egiten: /etc/resolv.conf irakurtzen du eta estekako hautapena saltatzen du, beraz Pi-hole-tik erantzun dezake aplikazio bakoitzak bultzatutako ebazpena erabiltzen duen bitartean, eta hori da hain zuzen zerrenda hau existitzen den hutsegitea. Gorde dig @192.168.1.53 zerbitzari jakin bat probatzeko.

2. Egiaztatu nork banatzen duen erantzuna

Esleipena DHCPri erantzuten dion edozerengandik dator. dnsmasq-en lerro bakarra da, dhcp-option=6,192.168.1.53; bideratzaile baten web interfazean LAN DHCP ataleko DNS eremua da. Bezeroek berritu behar dute ikusi aurretik. Egunak martxan egon den gailu batek alokairu zaharra oraindik gordetzen du, eta eskuz idatzitako ebazpena duen gailu batek betiko gordetzen du. Berritu proba-bezero batean hedapena suposatu beharrean.

IPv6 da ahaztu ohi den erdia. Bideratzailearen iragarkiek beren DNS zerbitzaria eraman dezakete (RDNSS), eta OpenWrt-en hori odhcpd-ren ra_dns aukera da; IPv6 nahiago duen bezeroak zerbitzari hori erabiltzen du, oraintxe ezarri duzun DHCPv4 aukera erabili gabe geratzen den bitartean. IPv6 DNS zerbitzatzeko prest ez bazaude, garbitu DNS iragarkia soilik: ra_dns odhcpd-en, edo RDNSS aukera bideratzailearen iragarkiei erantzuten dien edozertan. Iragarki osoa desaktibatzeak LAN-etik IPv6 helbideratzea ere kentzen du, eta hori egin nahi zenuena baino askoz aldaketa handiagoa da, DNS aukera soilik garbitzeak helbideratzea osorik mantentzen duen bitartean eta falta den RDNSS pakete-kapturan ikusgai egiten du.

3. Frogatu kontsulta Pi-hole-ra iristen dela

Pi-tik egindako kontsulta batek ez du ezer frogatzen sare-bideaz. Exekutatu bezerotik eta irakurri erantzun-kodea:

dig @192.168.1.53 example.com
dig @192.168.1.53 doubleclick.net

Denbora-mugak iragazketara edo ibilbide batera seinalatzen du; REFUSED-ek sarbide-arau batera; SERVFAIL-ek Pi-hole-ren atzean dagoen goi-ebazpenera; kontsulta-erregistroan inoiz agertzen ez den erantzun zuzen batek bezeroak beste zerbait galdetu duela esan nahi du. Egiaztatu UDP eta TCP 53, erantzun handiak eta ebazpen batzuk TCP-ra erortzen baitira, eta argitaratu biak Pi-hole edukiontzi batean exekutatzen denean. UDP soilik estaltzen duen mapaketak tarteka hutsegiteak sortzen ditu, pakete-galeraren itxura dutenak.

Ondoren Pi-hole-ren entzute-moduak erabakitzen du ea batere erantzuten duen. Tokiko bakarrik moduan dnsmasq-k zuzeneko azpisare batean ez dauden iturburuetako kontsultak ez ikusi egiten ditu, eta hain zuzen horrela ikusten da beste bideratzaile baten atzean dagoen edo tunel bidez iristen den bezero bat: bezeroak denbora agortzen du eta kontsulta ez da inoiz erregistrora iristen. REFUSED gisa agertzen den kontsulta bat sarbide-zerrenda edo suebaki-arau batek baztertu zuen. Jatorri guztiak baimentzea da ohiko konponbidea, 53 portua zure azpisareetara mugatzen duen suebaki-arau batekin batera.

4. Egiaztatu tunelak erantzuna ordezkatu edo irentsi duen

Hau da bi sintomak ezkutatzen diren kasua. Bideratzailea bera VPN bezeroa denean, bultzatutako DNS aukera batek LAN ezarpena gaindi dezake tunela igotzen den unean: OpenVPN zerbitzariek dhcp-option DNS bultzatzen dute, eta WireGuard profilek beren DNS sarrera daramate. Irakurri bideratzailearen ebazpen eraginkorra tunela martxan dagoela, ez aurretik, eta ez ikusi LAN orrialdeak dioena.

Beste akatsa irisgarritasuna da, ez ordezkapena. Tunelaren aurrizki baimenduek zure LAN azpisarea barne hartzen badute, bideratzaileak 192.168.1.53-rako kontsultak tunelera bidaltzen dituen ibilbidea du, eta beste aldeak ez du itzultzeko ibilbiderik: kontsulten denbora agortzen da tunela osasuntsu egon arren. Alderantzizkoa gertatzen da Pi-hole tunelak eramaten ez duen azpisare batean dagoenean. Alderatu helbidea tunelaren aurrizki baimenduekin eta bideratzailearen ibilbide-taularekin DNS berriro ukitu aurretik.

Aukeratu konponbide bat, ez biak. Edo mantendu tunela DNS-tik urrun — OpenVPN-en pull-filter ignore “dhcp-option DNS” eta WireGuard-en AllowedIPs-en LAN aurrizkirik gabe —, edo onartu bultzatutako ebazpena eta utzi bertan behera tokiko iragazketa bideratzaile horren atzean dauden bezeroentzat. Edozer aukeratzen duzula ere, idatzi profilaren ondoan, hurrengo pertsona editatzera datorrenak bestela ustekabean erabakia alderantzikatuko baitu.

5. Errepikatu proba berriro konektatu ondoren

Egin kontsulta bezero batetik, egiaztatu bezero hori Pi-hole-ren erregistroan agertzen dela, gero blokeatu beharko litzatekeen domeinu bat ebatzi eta egiaztatu benetako erantzunaren ordez blokeo-erantzuna jasotzen duzula. Berriro konektatu tunela eta exekutatu bi kontsulta berak, hurrengo konexiora arte soilik irauten duen ebazpen-ezarpena geruza okerrean aplikatutako konponbide baten ohiko emaitza baita.

Utzi tunelaren mende ez dagoen bigarren ebazpen-bide bat, Pi-hole-ren etendurak iragazi gabeko nabigaziora behera egin dezan, batere nabigaziorik ez egon beharrean. Mantendu aurreko DHCP eta ebazpen balioak proba bitan gainditu arte; afarian etxeko internet hausten duen aldaketak askoz zailagoa du arazketa minutu batean atzera dezakezun aldaketa batek baino.