Zergatik uzten dituen Pi-hole v6-k alde batera WireGuard bezeroen DNS kontsultak

Pi-hole v6-k DNS kontsulta bat jasotzen du 53 portuan eta gero erabakitzen du iritsitako paketeari erantzutea baimenduta dagoen. WireGuard ostalari batean bigarren erabaki hori izaten da bezeroak denbora-muga jasotzeko arrazoia, resolverra LAN-etik osasuntsu ikusten den bitartean. Portua irekita dago, FTL martxan dago, eta hala ere ez da ezer itzultzen 10.90.0.1-tik. Erantzun bat irten aurretik hiru gauza elkarreragiten dute: dns.interface, dns.listeningMode eta bien aurrean dagoen suebakia.

Entzuteko socket-ak ez du erabakitzen nork jasotzen duen erantzuna

FTL-k UDP eta TCP entzuleak irekitzen ditu 53 portuan. Leheneratzeko konfigurazioan socket-a wildcard izaten da sarritan, beraz ss -lunp | grep :53 erakusten du 0.0.0.0:53 eta [::]:53, VPN bezeroei zerbitzatzen zaien ala ez. Wildcard socket-ak paketea onartzen du, eta gero FTL-k bere interfaze eta iturri arauak aplikatzen ditu erantzun aurretik. Horregatik "portua entzuten ari da" esaldiak oso gutxi frogatzen du tunel bezero bati buruz.

Irakurri martxan dagoen konfigurazioa aktibo uste duzun fitxategiaren ordez. pihole-FTL --config dns.interface eta pihole-FTL --config dns.listeningMode balio eraginkorrak inprimatzen dituzte, eta ostalariaren fitxategitik desberdin daitezke edukiontzi, ingurune-aldagai edo hedapen-kudeatzaile bat ezarpenaren jabe denean. Pi-hole FTL konfigurazio erreferentzia moduak zerrendatzen ditu eta horietako zein den interfazearen mende.

LOCAL-ek zein azpisare galdetzen du, SINGLE-k zein interfaze

LOCAL, lehenetsia, iturburu-helbidea ostalariaren interfazeetako batean konfiguratutako azpisare batekoa duten kontsultei erantzuten die. 10.90.0.1/24 duen wg0 sinple bat proba hori gainditzen du, 10.90.0.2-ko bezeroa tunelaren azpisarearen barruan dagoelako. Pare baten bestaldeko bezero bideratua, edo beste prefijo batean NAT atzean ezkutatuta dagoena, ez da gainditzen, paketea wg0-ra iritsi den arren, eta ez da kontsultarik agertzen erregistroan.

SINGLE-k galdera aldatzen du. Onartzen ditu dns.interface gakoan izendatutako interfazera iristen diren kontsultak, loopback barne, eta iturburu-azpisarea ez du kontuan hartzen. Hori da VPN topologia kateatu edo bideratu bat jasaten duen modua. Ezarri bi gakoak elkarrekin, gako izendatutako interfazerik gabeko modua ez baita jarraibide osoa:

sudo pihole-FTL --config dns.interface "wg0"
sudo pihole-FTL --config dns.listeningMode "SINGLE"

BIND-k socket-a aldatzen du, eta horrek kostua du

BIND-k ez du wildcard socket-ik iragazten; 53 portua izendatutako interfazean dauden helbideetara soilik lotzen du, beraz kernelak beste leku batera iristen diren paketeak ukatzen ditu. SINGLE baino zorrotzagoa da eta ez da haren sinonimo. Kostua abioan agertzen da: FTL hastean wg0 martxan ez badago, baliteke lotzeko helbiderik ez egotea, eta resolverra entzulerik gabe ibili daiteke interfazea agertu eta FTL berrabiarazi arte.

Aukeratu BIND abio-ordena kontrolatzen duzunean, adibidez WireGuard interfazearen ondoren ordenatutako systemd unitate bat, eta kernelak pakete galduak bota ditzan nahi duzunean FTL-k ikusi aurretik. Aukeratu SINGLE tunela etorri eta joaten denean, edo interfazea FTL ondoren hasten den tresna batek sortzen duenean.

Suebakia da bigarren atea

FTL modu zuzen batek huts egiten du oraindik ostalariaren suebakiak wg0-n 53 portua botatzen badu. Onartu VPN iturburu-tartea bi protokoloetarako eta mantendu Internet aldea itxita. nftables-en, inet filter taulako input katea existitzen denean, arauak horrela ikusten dira:

sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 udp dport 53 accept
sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 tcp dport 53 accept

Gehitu bat datozen IPv6 arauak tunelak IPv6 garraiatzen badu, eta jarri katearen drop politika aurretik. Ostalariak ufw edo firewalld erabiltzen badu, adierazi bat-etortze bera kudeatzaile horretan tresnak nahastu beharrean. Ez birbidali 53 portua Internet bideratzailetik; bezeroek resolverraren VPN helbidera tunelaren bidez iritsi behar dute.

Bi bide bereiziak diraute. Bezeroen kontsultak FTL-n amaitzen dira. FTL-ren upstream bilaketek ostalariaren bideratze-taularen arabera irteten dira, eta horrek tunela erabil dezake edo ez, beraz erantzuten duen baina ezer erabilgarririk itzultzen ez duen resolver bat upstream arazoa da. Web administrazioa eta API-a beren portuetan entzuten dute eta beren murrizketa behar dute.

Egiaztatu erantzuna eta ukapena

VPN bezero batetik, galdetu resolverraren helbidea bi protokoloen bidez: dig @10.90.0.1 example.com eta dig +tcp @10.90.0.1 example.com. Gero begiratu kontsulten erregistroa administrazio interfazean, FTL-k kontsulta erregistratu duela baieztatzeko. Bezeroaren denbora-muga erregistro-sarrerarik gabe suebakira edo interfaze-iragazkira bideratzen du; erantzunik gabeko erregistro-sarrera upstream ebazpenera.

Probatu bide negatiboa VPN-tik kanpoko ostalari batetik. dig @10.90.0.1 example.com iraungi beharko luke, eta ss -lunp resolverrean ez luke 53 portua helbide publiko bati lotuta erakutsi behar. Berrabiarazi zerbitzua behin, gero berrabiarazi ostalaria eta egiaztatu resolverrak oraindik erantzuten duela wg0 berriro agertzen denean. Hurrengo berrabiaraztea arte soilik funtzionatzen duen kontsulta ez da amaitutako aldaketa.