Pi-hotspot med Pi-hole och VPN: ge varje tjänst en egen uppgift

En telefon ansluter till Pi:ns hotspot, får en adress och sidan fungerar fortfarande inte. Pi:n kör en hotspot-hjälp, Pi-hole och en VPN-klient, och var och en tror sig äga en del av vägen. De flesta av dessa byggen misslyckas inte för att en komponent är trasig, utan för att två komponenter gör samma jobb. Tilldela en ägare per funktion innan du justerar någon av dem.

Tilldela en ägare per funktion

Här spelar fyra funktioner roll, och var och en behöver exakt en ägare. Tabellen nedan anger funktionen, en fungerande ägare och vad som går fel när två tjänster gör anspråk på den.

Överlappningen kommer oftast ett paket i taget. Hotspot-hjälpen installerar sin egen dnsmasq-instans, Pi-hole vill ha port 53 och VPN-klienten lägger till rutter. Varje steg verkar rimligt för sig, och tillsammans ger de en maskin där den andra tjänsten som startar tyst ändrar den förstas beteende.

Skriv ner ägarna innan du aktiverar något annat. En kort tabell i byggnoteringarna hindrar en senare installation från att ta över en funktion som redan hade en ägare.

Välj ett intervall och håll det borta från tunneln

Välj hotspotens intervall, Pi:ns adress i det, DHCP-poolen och den resolver som klienterna får. Håll det intervallet skilt från uppströms-LAN:et och från VPN-tunnelns intervall, eftersom överlappande subnät gör ett routingproblem till ett adressöversättningsprojekt. Ett intervall som överlappar tunneln gör Pi:n till en oavsiktlig router mellan två identiska prefix. Skriv intervallet och poolen i hotspotens konfiguration i stället för att lämna dem till ett standardvärde.

Om NetworkManagers delade läge äger hotspoten, inspektera den effektiva anslutningen innan du lägger till en DHCP-server. Det delade läget startar sina egna hjälpprogram och aktiverar vidarebefordran, så det är redan ägare till adressplanen för det gränssnittet. Att lägga till en andra server bara för att den finns skapar konkurrerande erbjudanden i stället för redundans.

Bestäm om IPv6 medvetet. Routerannonser och DHCPv6 kommer i många uppsättningar från en annan hjälp än DHCPv4, och att lämna IPv6 på medan VPN-policyn bara täcker IPv4 ger klienterna en väg som kringgår tunneln. Antingen planerar du IPv6-sidan eller inaktiverar den på hotspotens gränssnitt med en skriftlig anledning.

Vem som faktiskt svarar på port 53

Lista varje process som lyssnar på port 53 innan du ändrar en konfiguration. På en Pi som kör en lokal resolver-stub, Pi-hole och en delningshjälp är lyssnarlistan den enda tillförlitliga kartan över vem som svarar på frågor:

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

Pi-holes gränssnittsguide förklarar att ett mottagningsläge som begränsas till ett gränssnitt fortfarande kan använda en wildcard-socket och kasta ankomster någon annanstans. Det är inte samma sak som att binda bara valda gränssnitt, vilket är upplägget som är avsett när en annan DNS-tjänst måste dela maskinen.

Två processer kan normalt inte binda samma adress och port, även om SO_REUSEPORT kan få en delad bindning att lyckas; även då kan en wildcard-lyssnare ta ankomster som var avsedda för den snävare tjänsten. Välj det dokumenterade läget för den roll du vill ha och starta om tjänsterna i avsedd ordning.

Håll Pi-holes administrationssida utanför hotspotnätet. Klienter behöver en resolver, inte webbgränssnittet eller API:et som kan ändra resolverns konfiguration.

Två DNS-ben, en policy var

En klientfråga färdas från telefonen till Pi:n, och en separat fråga färdas från Pi:n till dess uppströms-resolver. En routingregel som matchar vidarebefordrad hotspottrafik gäller inte automatiskt för det andra benet, eftersom Pi:n genererar den trafiken lokalt. Om VPN:en ska bära DNS behöver den lokala vägen sin egen policy.

Se upp för en loop. Att peka Pi-holes upstream mot en adress som Pi:n själv betjänar, direkt eller via en port-forward, ger frågor som cirklar tills de tidsutlöper. Ge den en riktig upstream eller en villkorad forwarder för de domäner den inte kan svara på.

Bestäm vad som händer när tunneln faller. Att falla tillbaka på den lokala resolvern håller surfandet igång men kan läcka namn utanför VPN:en; att blockera håller policyn intakt och gör avbrottet till ett synligt fel. Båda valen är försvarbara, men de måste väljas i stället för att ärvas från ett standardvärde.

Bevisa vägen och beteendet vid avbrott

Testa i lager: klienten får en adress, klienten löser ett namn via Pi:n, Pi:n löser via den avsedda upstreamen, och ett program slutför en begäran. En lyckad ping säger inget om DNS, och en lyckad uppslagning säger inget om vidarebefordran.

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

Stoppa sedan tunneln och upprepa. Det avsedda beteendet bör dyka upp inom några sekunder, inte efter en manuell omstart av Pi-hole eller hotspot-tjänsten. Kontrollera klientens resolverinställning under avbrottet, eftersom en sekundär offentlig resolver fortsätter svara även när policyn förväntade sig ett fel.

Håll en ägare för vidarebefordran och NAT och verifiera den från en klient, inte från Pi:n själv. En begäran som lämnar Pi:n med framgång kan ändå slängas på vägen tillbaka, och klienten är den enda platsen där hela vägen syns.