Hvers vegna Pi-hole v6 hunsar DNS-fyrirspurnir frá WireGuard-biðlurum
Pi-hole v6 ákveður hvaða VPN-biðlarar fá DNS út frá tenginu og hlustunarham, ekki portinu einu saman. Stilltu bæði og prófaðu svo höfnuðu leiðina.
Pi-hole v6 tekur á móti DNS-fyrirspurn á porti 53 og ákveður síðan hvort svara megi pakkanum sem barst. Á WireGuard-vél er þessi seinni ákvörðun yfirleitt ástæðan fyrir því að biðlari fær tímanak, á meðan leysirinn virðist heilbrigður frá LAN. Portið er opið, FTL er í gangi, en samt kemur ekkert til baka frá 10.90.0.1. Þrír hlutir vinna saman áður en svar fer út: dns.interface, dns.listeningMode og eldveggurinn fyrir framan bæði.
Hlustunarsokkurinn ákveður ekki hver fær svar
FTL opnar UDP- og TCP-hlustara á porti 53. Í sjálfgefinni uppsetningu er sokkurinn oft wildcard, svo ss -lunp | grep :53 sýnir 0.0.0.0:53 og [::]:53 hvort sem VPN-biðlarar eru þjónaðir eða ekki. Wildcard-sokkur tekur við pakkanum, og þá beitir FTL tengi- og upprunareglum sínum áður en hann svarar. Þess vegna sannar setningin „portið hlustar“ mjög litlu um göngubiðlara.
Lestu uppsetninguna sem er í gangi í stað skráarinnar sem þú telur virka. pihole-FTL --config dns.interface og pihole-FTL --config dns.listeningMode prenta raunverulegu gildin, og þau geta verið frábrugðin skrá vélarinnar þegar gámur, umhverfisbreyta eða dreifingarstjóri á stillinguna. Uppsetningarviðmið Pi-hole FTL telur upp hamina og hver þeirra byggir á tenginu.
LOCAL spyr hvaða undirnet, SINGLE spyr hvaða tengi
LOCAL, sjálfgefni hamurinn, svarar fyrirspurnum þar sem upprunavistfangið tilheyrir undirneti sem er stillt á einu af tengjum vélarinnar. Einfalt wg0 með 10.90.0.1/24 stenst þá prófun, því biðlarinn á 10.90.0.2 situr innan undirnets gangsins. Biðlari með leið hinum megin við jafningja, eða einn falinn bak við NAT í öðru forskeyti, stenst hana ekki þótt pakkinn hafi komið á wg0, og engin fyrirspurn birtist í skránni.
SINGLE breytir spurningunni. Hann tekur við fyrirspurnum sem berast á tengið sem nefnt er í dns.interface, með loopback innifalinn, og hunsar upprunanetið. Þetta er hamurinn sem lifir af keðjutengda eða leiðrætta VPN-topologíu. Stilltu báða lyklana saman, því hamur án nefnds tengis er ekki fullkomin leiðbeining:
sudo pihole-FTL --config dns.interface "wg0"
sudo pihole-FTL --config dns.listeningMode "SINGLE"BIND breytir sokkinum, og það hefur kostnað í för með sér
BIND síar ekki wildcard-sokk; hann bindur port 53 aðeins við vistföng sem eru til á nefnda tenginu, svo kjarninn hafnar pökkum sem berast annars staðar. Hann er strangari en SINGLE og ekki samheiti. Kostnaðurinn kemur fram við ræsingu: ef wg0 er ekki uppi þegar FTL byrjar, er kannski ekkert vistfang til að binda, og leysirinn getur gengið án hlustara þar til tengið birtist og FTL ræsir sig aftur.
Veldu BIND þegar þú stjórnar ræsingarröðinni, til dæmis systemd-einingu sem er raðað eftir WireGuard-tenginu, og þegar þú vilt að kjarninn hendi villtum pökkum áður en FTL sér þá. Veldu SINGLE þegar gangurinn kemur og fer, eða þegar tengið er búið til af tóli sem byrjar eftir FTL.
Eldveggurinn er annað hliðið
Réttur FTL-hamur bregst samt ef eldveggur vélarinnar hendir porti 53 á wg0. Leyfðu VPN-upprunasviðið fyrir bæði samskiptareglur og hafðu netmegin lokað. Í nftables, með fyrirliggjandi input-keðju í inet filter-töflunni, líta reglurnar svona út:
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 acceptBættu við samsvarandi IPv6-reglum ef gangurinn flytur IPv6, og settu þær á undan drop-stefnu keðjunnar. Ef vélin notar ufw eða firewalld, tjáðu sömu samsvörun í þeim stjóra í stað þess að blanda tólum. Framsendu ekki port 53 frá netbeininum; biðlarar eiga að ná VPN-vistfangi leysisins gegnum ganginn.
Tvær leiðir haldast aðskildar. Fyrirspurnir biðlara enda í FTL. Uppstreymisleitir FTL sjálfs fara út samkvæmt leiðatöflu vélarinnar, sem kann að nota ganginn eða ekki, svo leysir sem svarar en skilar engu gagnlegu er uppstreymisvandamál. Vefstjórnunin og API hlusta á eigin portum og þurfa eigin takmörkun.
Staðfestu svarið og höfnunina
Frá VPN-biðlara, spurðu að vistfangi leysisins yfir báðar samskiptareglur: dig @10.90.0.1 example.com og dig +tcp @10.90.0.1 example.com. Athugaðu svo fyrirspurnaskrána í stjórnviðmótinu til að staðfesta að FTL skráði fyrirspurnina. Tímanak biðlara án færslu í skrá bendir á eldvegginn eða tengisíuna; færsla án svars bendir á uppstreymisleysingu.
Prófaðu neikvæðu leiðina frá vél utan VPN. dig @10.90.0.1 example.com ætti að renna út, og ss -lunp á leysinum ætti ekki að sýna port 53 bundið almenningsvistfangi. Endurræstu þjónustuna einu sinni, endurræstu svo vélina og staðfestu að leysirinn svari enn þegar wg0 birtist aftur. Fyrirspurn sem virkar aðeins þar til næsta endurræsing er ekki lokið breyting.