Miért hagyja figyelmen kívül a Pi-hole v6 a WireGuard-kliensek DNS-kéréseit

A Pi-hole v6 DNS-kérést fogad az 53-as porton, majd eldönti, hogy a megérkezett csomagra adható-e válasz. WireGuard-gazdagépen ez a második döntés általában az oka annak, hogy a kliens időtúllépést kap, miközben a feloldó a LAN felől egészségesnek látszik. A port nyitva van, az FTL fut, és mégsem jön vissza semmi a 10.90.0.1-ről. Három dolog hat egymásra, mielőtt a válasz elindul: dns.interface, dns.listeningMode és a mindkettő előtti tűzfal.

A hallgató socket nem dönti el, ki kap választ

Az FTL UDP- és TCP-figyelőket nyit az 53-as porton. Az alapértelmezett konfigurációban a socket gyakran wildcard, ezért a ss -lunp | grep :53 a 0.0.0.0:53 és a [::]:53 címet mutatja, függetlenül attól, hogy kiszolgálnak-e VPN-klienseket. A wildcard socket elfogadja a csomagot, majd az FTL a válasz előtt alkalmazza az interfész- és forrásszabályait. Ezért a „a port hallgat” kifejezés nagyon keveset bizonyít egy alagút-kliensről.

A futó konfigurációt olvassa, ne azt a fájlt, amelyet aktívnak gondol. pihole-FTL --config dns.interface és pihole-FTL --config dns.listeningMode kiírja a tényleges értékeket, és ezek eltérhetnek a gazdagép fájljától, ha a beállítás egy konténer, egy környezeti változó vagy egy telepítéskezelő tulajdonában van. A Pi-hole FTL konfigurációs referenciája felsorolja a módokat, és hogy melyik támaszkodik az interfészre.

A LOCAL azt kérdezi, melyik alhálózat, a SINGLE azt, melyik interfész

A LOCAL, az alapértelmezett, azokra a kérésekre válaszol, amelyek forráscíme a gazdagép valamelyik interfészén beállított alhálózatba tartozik. Egy egyszerű wg0 a 10.90.0.1/24 hálózattal átmegy ezen a teszten, mert a 10.90.0.2-es kliens az alagút alhálózatán belül van. Egy távoli peer túloldalán átirányított kliens, vagy egy másik előtagban NAT mögé rejtett kliens nem megy át rajta, pedig a csomag megérkezett a wg0-ra, és nem jelenik meg kérés a naplóban.

A SINGLE megváltoztatja a kérdést. Elfogadja azokat a kéréseket, amelyek a dns.interface alatt megnevezett interfészre érkeznek, a loopbacket is beleértve, és figyelmen kívül hagyja a forrás-alhálózatot. Ez az a mód, amely túlél egy láncolt vagy irányított VPN-topológiát. Állítsa be a két kulcsot együtt, mert a megnevezett interfész nélküli mód nem teljes utasítás:

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

A BIND megváltoztatja a socketet, és ennek ára van

A BIND nem szűri a wildcard socketet; az 53-as portot csak a megnevezett interfészen létező címekhez köti, így a kernel elutasítja a máshova érkező csomagokat. Szigorúbb a SINGLE-nál, és nem a szinonimája. Az ár a rendszerindításnál mutatkozik: ha a wg0 nem áll fel, amikor az FTL elindul, lehet, hogy nincs cím, amihez kötni, és a feloldó figyelő nélkül futhat, amíg az interfész meg nem jelenik és az FTL újra nem indul.

Akkor válassza a BIND-et, ha Ön irányítja az indítási sorrendet, például egy WireGuard-interfész után sorolt systemd-egységgel, és ha azt szeretné, hogy a kernel eldobja a kóbor csomagokat, mielőtt az FTL látná őket. Akkor válassza a SINGLE-t, ha az alagút jön-megy, vagy ha az interfészt egy olyan eszköz hozza létre, amely az FTL után indul.

A tűzfal a második kapu

A helyes FTL-mód is elbukik, ha a gazdagép tűzfala eldobja az 53-as portot a wg0-n. Engedje át a VPN-forrástartományt mindkét protokollon, és tartsa zárva az internet felőli oldalt. Az nftablesben, a meglévő input lánccal az inet filter táblában, a szabályok így néznek ki:

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

Adjon hozzá megfelelő IPv6-szabályokat, ha az alagút IPv6-ot szállít, és tegye őket a lánc drop-szabálya elé. Ha a gazdagép ufw-t vagy firewalld-t használ, ugyanazt az egyezést abban a kezelőben fejezze ki, ne keverje az eszközöket. Ne továbbítsa az 53-as portot az internetes útválasztóról; a klienseknek az alagúton át kell elérniük a feloldó VPN-címét.

Két útvonal külön marad. A kliensek kérései az FTL-nél végződnek. Az FTL saját felfelé irányuló lekérdezései a gazdagép útválasztási táblázata szerint lépnek ki, amely használhatja vagy nem használhatja az alagutat, ezért az a feloldó, amely válaszol, de semmi hasznosat nem ad vissza, felfelé irányuló probléma. A webes admin és az API a saját portjain hallgat, és saját korlátozásra van szükségük.

Ellenőrizze a választ és az elutasítást

VPN-kliensről kérdezze le a feloldó címét mindkét protokollon: dig @10.90.0.1 example.com és dig +tcp @10.90.0.1 example.com. Ezután nézze meg a kérésnaplót az adminfelületen, hogy megbizonyosodjon róla, az FTL rögzítette a kérést. A naplóbejegyzés nélküli kliens-időtúllépés a tűzfalra vagy az interfészszűrőre utal; a válasz nélküli naplóbejegyzés a felfelé irányuló feloldásra.

Tesztelje a negatív útvonalat egy a VPN-en kívüli gazdagépről. dig @10.90.0.1 example.com időtúllépéssel kellene végződnie, és a ss -lunp a feloldón nem mutathatja az 53-as portot nyilvános címhez kötve. Indítsa újra egyszer a szolgáltatást, majd indítsa újra a gazdagépet, és erősítse meg, hogy a feloldó továbbra is válaszol, miután a wg0 újra megjelenik. Egy kérés, amely csak a következő újraindításig működik, nem befejezett változtatás.