Miksi Pi-hole v6 jättää WireGuard-asiakkaiden DNS-kyselyt huomiotta

Pi-hole v6 vastaanottaa DNS-kyselyn portissa 53 ja päättää sitten, saako saapunut paketti vastauksen. WireGuard-isännässä tämä toinen päätös on yleensä syy siihen, miksi asiakas saa aikakatkaisun, vaikka resolveri näyttää LANista terveeltä. Portti on auki, FTL on käynnissä, ja silti 10.90.0.1:stä ei tule mitään takaisin. Kolme asiaa vaikuttaa toisiinsa ennen kuin vastaus lähtee: dns.interface, dns.listeningMode ja palomuuri molempien edessä.

Kuunteleva socket ei päätä, kuka vastauksen saa

FTL avaa UDP- ja TCP-kuuntelijat porttiin 53. Oletusasetuksissa socket on usein wildcard, joten ss -lunp | grep :53 näyttää osoitteet 0.0.0.0:53 ja [::]:53 riippumatta siitä, palvellaanko VPN-asiakkaita. Wildcard-socket hyväksyy paketin, ja sitten FTL soveltaa rajapinta- ja lähdesääntönsä ennen vastaamista. Siksi lause "portti kuuntelee" todistaa tunneliasiakkaasta hyvin vähän.

Lue käynnissä oleva kokoonpano sen sijaan, että luottaisit tiedostoon, jonka uskot olevan aktiivinen. pihole-FTL --config dns.interface ja pihole-FTL --config dns.listeningMode tulostavat tehokkaat arvot, ja ne voivat poiketa isännän tiedostosta, kun kontti, ympäristömuuttuja tai käyttöönottotyökalu omistaa asetuksen. Pi-hole FTL:n kokoonpanoviite luettelee tilat ja sen, mikä niistä perustuu rajapintaan.

LOCAL kysyy aliverkkoa, SINGLE kysyy rajapintaa

LOCAL, oletus, vastaa kyselyihin, joiden lähdeosoite kuuluu johonkin isännän rajapinnoista määritettyyn aliverkkoon. Yksinkertainen wg0 aliverkolla 10.90.0.1/24 läpäisee testin, koska osoitteessa 10.90.0.2 oleva asiakas on tunnelin aliverkon sisällä. Reititetty asiakas vertaislaitteen toisella puolella, tai toiseen etuliitteeseen NATin taakse piilotettu asiakas, ei läpäise sitä, vaikka paketti saapui wg0:lle, eikä lokiin ilmesty yhtään kyselyä.

SINGLE muuttaa kysymystä. Se hyväksyy kyselyt, jotka saapuvat rajapintaan, jonka asetus dns.interface nimeää, loopback mukaan lukien, ja jättää lähde-aliverkon huomiotta. Tämä on tila, joka kestää ketjutettua tai reititettyä VPN-topologiaa. Aseta molemmat avaimet yhdessä, koska tila ilman nimettyä rajapintaa ei ole täydellinen ohje:

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

BIND muuttaa socketin, ja sillä on hintansa

BIND ei suodata wildcard-socketia; se sitoo portin 53 vain osoitteisiin, jotka ovat olemassa nimetylle rajapinnalle, joten ydin hylkää paketit, jotka saapuvat muualle. Se on tiukempi kuin SINGLE eikä sen synonyymi. Hinta näkyy käynnistyksessä: jos wg0 ei ole ylhäällä, kun FTL käynnistyy, sidottavaa osoitetta ei ehkä ole, ja resolveri voi toimia ilman kuuntelijaa, kunnes rajapinta ilmestyy ja FTL käynnistyy uudelleen.

Valitse BIND, kun hallitset käynnistysjärjestystä, esimerkiksi systemd-yksikkö, joka on järjestetty WireGuard-rajapinnan jälkeen, ja kun haluat ytimen pudottavan harhailevat paketit ennen kuin FTL näkee ne. Valitse SINGLE, kun tunneli tulee ja menee, tai kun rajapinnan luo työkalu, joka käynnistyy FTL:n jälkeen.

Palomuuri on toinen portti

Oikea FTL-tila epäonnistuu silti, jos isännän palomuuri pudottaa portin 53 wg0:lla. Salli VPN-lähdevalikoima molemmille protokollille ja pidä internetsivu suljettuna. nftablesissa, kun inet filter -taulussa on olemassa oleva input-ketju, säännöt näyttävät tältä:

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

Lisää vastaavat IPv6-säännöt, jos tunneli kuljettaa IPv6:ta, ja laita ne ketjun drop-käytännön eteen. Jos isäntä käyttää ufw:ää tai firewalldia, ilmaise sama osuma siinä hallinnassa sen sijaan, että sekoittaisit työkaluja. Älä välitä porttia 53 internetreitittimestä; asiakkaiden pitäisi tavoittaa resolverin VPN-osoite tunnelin kautta.

Kaksi polkua pysyy erillään. Asiakkaiden kyselyt päättyvät FTL:ään. FTL:n omat ylöspäin suuntautuvat haut lähtevät isännän reititystaulukon mukaan, joka voi käyttää tunnelia tai olla käyttämättä, joten resolveri, joka vastaa mutta ei palauta mitään hyödyllistä, on ylöspäin suuntautuva ongelma. Verkkohallinta ja API kuuntelevat omissa porteissaan ja tarvitsevat oman rajoituksensa.

Varmista vastaus ja hylkäys

Kysy VPN-asiakkaasta resolverin osoitetta molemmilla protokollilla: dig @10.90.0.1 example.com ja dig +tcp @10.90.0.1 example.com. Tarkista sitten kyselyloki hallintaliittymästä ja varmista, että FTL kirjasi kyselyn. Asiakkaan aikakatkaisu ilman lokimerkintää viittaa palomuuriin tai rajapintasuodattimeen; lokimerkintä ilman vastausta viittaa ylöspäin suuntautuvaan ratkaisuun.

Testaa negatiivinen polku isännästä VPN:n ulkopuolelta. dig @10.90.0.1 example.com pitäisi aikakatkaista, ja ss -lunp resolverissa ei pitäisi näyttää porttia 53 sidottuna julkiseen osoitteeseen. Käynnistä palvelu kerran uudelleen, käynnistä sitten isäntä uudelleen ja varmista, että resolveri vastaa edelleen, kun wg0 ilmestyy uudelleen. Kysely, joka toimii vain seuraavaan uudelleenkäynnistykseen asti, ei ole valmis muutos.