Hotspot na Pi s Pi-hole a VPN: každé službě přiřaďte úlohu

Telefon se připojí k hotspotu Pi, dostane adresu, a stránka přesto selže. Na Pi běží pomocník hotspotu, Pi-hole a klient VPN a každý z nich věří, že vlastní část cesty. Většina takových sestavení selhává ne proto, že je komponenta rozbitá, ale proto, že dva komponenty dělají stejnou práci. Než začnete kteroukoli z nich ladit, přiřaďte každé funkci jednoho vlastníka.

Přiřaďte každé funkci jednoho vlastníka

Záleží zde na čtyřech funkcích a každá potřebuje právě jednoho vlastníka. Tabulka níže uvádí funkci, schůdného vlastníka a co se pokazí, když si ji nárokují dvě služby.

Překryv obvykle přichází jeden balíček po druhém. Pomocník hotspotu nainstaluje vlastní instanci dnsmasq, Pi-hole chce port 53 a klient VPN přidává trasy. Každý krok sám o sobě vypadá rozumně, ale dohromady vytvářejí stroj, kde druhá spuštěná služba tiše mění chování první.

Napište si vlastníky, než zapnete cokoli dalšího. Krátká tabulka v poznámkách ke stavbě zabrání pozdější instalaci převzít funkci, která už vlastníka měla.

Vyberte jeden rozsah a držte ho dál od tunelu

Vyberte rozsah hotspotu, adresu Pi v něm, fond DHCP a resolver, který klienti dostávají. Držte tento rozsah odděleně od nadřazené LAN i od rozsahu tunelu VPN, protože překrývající se podsítě mění problém směrování v projekt překladu adres. Rozsah, který se překrývá s tunelem, dělá z Pi náhodný router mezi dvěma shodnými prefixy. Zapište rozsah a fond do konfigurace hotspotu, místo abyste je nechali na výchozí hodnotě.

Pokud hotspot vlastní sdílený režim NetworkManageru, před přidáním serveru DHCP prozkoumejte efektivní připojení. Sdílený režim spouští vlastní pomocníky a zapíná předávání, takže už je vlastníkem plánu adres pro toto rozhraní. Přidání druhého serveru jen proto, že je k dispozici, vytváří konkurenční nabídky, nikoli redundanci.

O IPv6 rozhodněte vědomě. Oznámení routeru a DHCPv6 v mnoha sestavách přicházejí od jiného pomocníka než DHCPv4, a pokud necháte IPv6 zapnuté, zatímco politika VPN pokrývá jen IPv4, dáváte klientům cestu, která obchází tunel. Buď stranu IPv6 naplánujte, nebo ji na rozhraní hotspotu vypněte s písemným důvodem.

Kdo na portu 53 skutečně odpovídá

Před změnou konfigurace vypište každý proces, který naslouchá na portu 53. Na Pi, kde běží místní resolver stub, Pi-hole a pomocník pro sdílení, je seznam posluchačů jediná spolehlivá mapa toho, kdo odpovídá na dotazy:

sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip route

Průvodce rozhraními Pi-hole vysvětluje, že režim příjmu omezený na jedno rozhraní může přesto používat univerzální socket a zahazovat příchody jinde. To není totéž jako vázání jen na vybraná rozhraní, což je uspořádání zamýšlené tehdy, když se o stroj musí dělit jiná služba DNS.

Dva procesy obvykle nemohou vázat stejnou adresu a port, i když SO_REUSEPORT může sdílené vázání nechat uspět; ani pak může univerzální posluchač převzít příchody určené užší službě. Vyberte dokumentovaný režim pro roli, kterou chcete, a restartujte služby v zamýšleném pořadí.

Držte administrační stránku Pi-hole mimo síť hotspotu. Klienti potřebují resolver, ne webové rozhraní nebo API, které může změnit konfiguraci resolveru.

Dvě DNS nohy, každá s vlastní politikou

Dotaz klienta putuje z telefonu na Pi a samostatný dotaz putuje z Pi na jeho nadřazený resolver. Pravidlo směrování, které odpovídá předávanému provozu hotspotu, se automaticky nevztahuje na druhou nohu, protože Pi tento provoz vytváří lokálně. Pokud má VPN přenášet DNS, potřebuje lokální cesta vlastní politiku.

Pozor na smyčku. Nasměrování nadřazeného resolveru Pi-hole na adresu, kterou obsluhuje samotné Pi, přímo nebo přes přesměrování portu, vytváří dotazy, které krouží, dokud nevyprší. Dejte mu skutečný nadřazený resolver nebo podmíněný forwarder pro domény, na které nedokáže odpovědět.

Rozhodněte, co se stane, když tunel spadne. Návrat k místnímu resolveru udrží prohlížení při životě, ale může unikat jména mimo VPN; blokování zachová politiku a promění výpadek ve viditelnou chybu. Každá volba je obhajitelná, ale musí být zvolena, ne zděděna z výchozí hodnoty.

Dokažte cestu a chování při výpadku

Testujte po vrstvách: klient dostane adresu, klient přeloží jméno přes Pi, Pi přeloží přes zamýšlený nadřazený resolver a aplikace dokončí požadavek. Úspěšný ping nic neříká o DNS a úspěšné vyhledání nic neříká o předávání.

dig @192.168.70.1 example.com
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
ip -4 route get 1.1.1.1

Potom tunel zastavte a opakujte. Zamýšlené chování se má objevit během několika sekund, ne po ručním restartu Pi-hole nebo služby hotspotu. Během výpadku zkontrolujte nastavení resolveru klienta, protože sekundární veřejný resolver bude dál odpovídat, i když politika očekávala selhání.

Držte jednoho vlastníka pro předávání a NAT a ověřujte ho z klienta, ne z Pi samotného. Požadavek, který Pi úspěšně opustí, může být přesto na zpáteční cestě zahozen, a klient je jediné místo, kde je celá cesta vidět.