Pi hotspot s Pi-hole a VPN: prideľte každej službe vlastnú úlohu

Telefón sa pripojí k hotspotu Pi, dostane adresu a stránka stále zlyháva. Pi spúšťa pomocníka pre hotspot, Pi-hole a VPN klienta a každý z nich si myslí, že vlastní časť cesty. Väčšina týchto zostavení zlyháva nie preto, že je komponent pokazený, ale preto, že dve komponenty robia tú istú prácu. Priraďte jedného vlastníka na funkciu, skôr než ktorýkoľvek z nich naladíte.

Priraďte jedného vlastníka na funkciu

Dôležité sú tu štyri funkcie a každá potrebuje presne jedného vlastníka. Tabuľka nižšie uvádza funkciu, použiteľného vlastníka a čo sa pokazí, keď si ju nárokujú dve služby.

Prekrytie zvyčajne prichádza jeden balík po druhom. Pomocník pre hotspot nainštaluje vlastnú inštanciu dnsmasq, Pi-hole chce port 53 a VPN klient pridáva trasy. Každý krok vyzerá rozumne sám o sebe a spolu vytvárajú stroj, v ktorom druhá spustená služba potichu mení správanie prvej.

Zapíšte si vlastníkov, skôr než zapnete čokoľvek iné. Krátka tabuľka v poznámkach k zostaveniu zabráni neskoršej inštalácii prevziať funkciu, ktorá už mala vlastníka.

Vyberte jeden rozsah a držte ho mimo tunela

Vyberte rozsah hotspotu, adresu Pi v ňom, DHCP pool a resolver, ktorý klienti dostanú. Držte ten rozsah oddelene od upstream LAN a od rozsahu VPN tunela, pretože prekrývajúce sa podsiete menia problém smerovania na projekt prekladu adries. Rozsah, ktorý sa prekrýva s tunelom, robí z Pi náhodného smerovača medzi dvoma identickými prefixmi. Zapíšte rozsah a pool do konfigurácie hotspotu namiesto toho, aby ste ich nechali na predvolenej hodnote.

Ak hotspot vlastní zdieľaný režim NetworkManageru, pred pridaním DHCP servera preskúmajte efektívne pripojenie. Zdieľaný režim spúšťa vlastných pomocníkov a zapína preposielanie, takže už je vlastníkom plánu adries pre to rozhranie. Pridanie druhého servera preto, že je dostupný, vytvára konkurenčné ponuky namiesto redundancie.

O IPv6 rozhodnite zámerne. Inzeráty smerovača a DHCPv6 v mnohých zostaveniach pochádzajú z iného pomocníka ako DHCPv4, a ak necháte IPv6 zapnuté, kým pravidlo VPN pokrýva len IPv4, klienti dostanú cestu, ktorá obchádza tunel. Buď IPv6 stranu naplánujte, alebo ju na rozhraní hotspotu vypnite s písomným dôvodom.

Kto v skutočnosti odpovedá na porte 53

Pred zmenou konfigurácie vypíšte každý proces, ktorý počúva na porte 53. Na Pi, ktoré spúšťa lokálny resolver stub, Pi-hole a pomocníka pre zdieľanie, je zoznam poslucháčov jediná spoľahlivá mapa toho, kto odpovedá na dopyty:

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

Príručka k rozhraniam Pi-hole vysvetľuje, že režim príjmu obmedzený na jedno rozhranie môže stále používať wildcard socket a zahadzovať príchody inde. To nie je to isté ako viazanie len vybraných rozhraní, čo je usporiadanie zamýšľané vtedy, keď sa o stroj musí deliť iná DNS služba.

Dva procesy zvyčajne nemôžu viazať rovnakú adresu a port, hoci SO_REUSEPORT môže spôsobiť, že zdieľané viazanie uspeje; aj potom môže wildcard poslucháč prevziať príchody určené užšej službe. Vyberte dokumentovaný režim pre rolu, ktorú chcete, a reštartujte služby v zamýšľanom poradí.

Držte administračnú stránku Pi-hole mimo hotspot siete. Klienti potrebujú resolver, nie webové rozhranie alebo API, ktoré môže zmeniť konfiguráciu resolvera.

Dve DNS vetvy, každá s vlastným pravidlom

Dopyt klienta putuje z telefónu na Pi a samostatný dopyt putuje z Pi na jeho upstream resolver. Pravidlo smerovania, ktoré zodpovedá preposielanej prevádzke hotspotu, sa automaticky nevzťahuje na druhú vetvu, pretože Pi túto prevádzku generuje lokálne. Ak má VPN prenášať DNS, lokálna cesta potrebuje vlastné pravidlo.

Dávajte pozor na slučku. Nasmerovanie upstreamu Pi-hole na adresu, ktorú obsluhuje samotné Pi, priamo alebo cez port-forward, vytvára dopyty, ktoré krúžia, kým nevyprší čas. Dajte mu skutočný upstream alebo podmienený forwarder pre domény, na ktoré nevie odpovedať.

Rozhodnite, čo sa stane, keď tunel spadne. Návrat na lokálny resolver udrží prehliadanie živé, ale môže uniknúť mená mimo VPN; blokovanie udrží pravidlo nedotknuté a premení výpadok na viditeľnú chybu. Obe voľby sú obhájiteľné, ale musia sa vybrať, nie zdediť z predvolenej hodnoty.

Dokážte cestu a správanie pri výpadku

Testujte po vrstvách: klient dostane adresu, klient preloží meno cez Pi, Pi preloží cez zamýšľaný upstream a aplikácia dokončí požiadavku. Úspešný ping nehovorí nič o DNS a úspešné vyhľadanie nehovorí nič o preposielaní.

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 zopakujte. Zamýšľané správanie by sa malo objaviť v priebehu niekoľkých sekúnd, nie po ručnom reštarte Pi-hole alebo služby hotspotu. Počas výpadku skontrolujte nastavenie resolvera na klientovi, pretože sekundárny verejný resolver bude odpovedať ďalej, aj keď pravidlo očakávalo zlyhanie.

Zachovajte jedného vlastníka pre preposielanie a NAT a overte ho z klienta, nie z Pi samotného. Požiadavka, ktorá z Pi úspešne odíde, môže byť na spiatočnej ceste stále zahodená, a klient je jediné miesto, kde je vidieť celú cestu.