Pi-hotspot med Pi-hole og VPN: gi hver tjeneste en egen oppgave
Bestem hvem som eier DHCP, DNS og pakkevideresending før du slår på tre hjelpere på én Pi. Doble eiere gir konkurrerende leases og resolver-løkker.
En telefon kobler seg til hotspoten på Pi-en, får en adresse, og siden fungerer fortsatt ikke. Pi-en kjører en hotspot-hjelper, Pi-hole og en VPN-klient, og hver av dem tror den eier en del av veien. De fleste av disse byggene mislykkes ikke fordi en komponent er ødelagt, men fordi to komponenter gjør samme jobb. Tildel én eier per funksjon før du justerer noen av dem.
Tildel én eier per funksjon
Her teller fire funksjoner, og hver trenger nøyaktig én eier. Tabellen nedenfor navngir funksjonen, en brukbar eier og hva som går galt når to tjenester gjør krav på den.
| Function | Workable owner | Duplicate-owner symptom |
|---|---|---|
| Client addresses | One DHCP server, such as the hotspot helper | Competing offers and changing leases |
| DNS reception | Pi-hole on port 53 | Bind failure or queries answered by the wrong process |
| Forwarding and NAT | One firewall manager | Double translation and broken return paths |
| VPN routing | One client configuration | Route flapping and traffic escaping outside the tunnel |
Overlappen kommer vanligvis ett pakke om gangen. Hotspot-hjelperen installerer sin egen dnsmasq-instans, Pi-hole vil ha port 53, og VPN-klienten legger til ruter. Hvert steg virker rimelig alene, og sammen gir de en maskin der den andre tjenesten som starter stille endrer oppførselen til den første.
Skriv ned eierne før du slår på noe annet. En kort tabell i byggenotatene hindrer en senere installasjon i å overta en funksjon som allerede hadde en eier.
Velg ett område og hold det unna tunnelen
Velg hotspot-området, adressen til Pi-en i det, DHCP-poolen og resolveren klientene får. Hold det området atskilt fra oppstrøms-LAN-et og fra VPN-tunnelens område, fordi overlappende subnett gjør et ruteproblem til et adresseoversettelsesprosjekt. Et område som overlapper tunnelen gjør Pi-en til en utilsiktet ruter mellom to identiske prefikser. Skriv området og poolen inn i hotspot-konfigurasjonen i stedet for å overlate dem til en standardverdi.
Hvis NetworkManagers delte modus eier hotspoten, inspiser den effektive tilkoblingen før du legger til en DHCP-server. Den delte modusen starter sine egne hjelpere og slår på videresending, så den er allerede eier av adresseplanen for det grensesnittet. Å legge til en ekstra server fordi den er tilgjengelig skaper konkurrerende tilbud i stedet for redundans.
Bestem IPv6 bevisst. Ruterannonser og DHCPv6 kommer i mange oppsett fra en annen hjelper enn DHCPv4, og å la IPv6 stå på mens VPN-policyen bare dekker IPv4 gir klientene en vei som omgår tunnelen. Enten planlegger du IPv6-siden eller deaktiverer den på hotspot-grensesnittet med en skriftlig begrunnelse.
Hvem som faktisk svarer på port 53
List hver prosess som lytter på port 53 før du endrer en konfigurasjon. På en Pi som kjører en lokal resolver-stub, Pi-hole og en delingshjelper, er lytterlisten det eneste pålitelige kartet over hvem som svarer på spørringer:
sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip routePi-holes grensesnittguide forklarer at en mottaksmodus begrenset til ett grensesnitt fortsatt kan bruke en wildcard-socket og forkaste ankomster andre steder. Det er ikke det samme som å binde bare valgte grensesnitt, som er oppsettet som er ment når en annen DNS-tjeneste må dele maskinen.
To prosesser kan normalt ikke binde samme adresse og port, selv om SO_REUSEPORT kan få en delt binding til å lykkes; selv da kan en wildcard-lytter ta ankomster som var ment for den smalere tjenesten. Velg den dokumenterte modusen for rollen du vil ha, og start tjenestene på nytt i tiltenkt rekkefølge.
Hold Pi-holes administrasjonsside utenfor hotspot-nettet. Klienter trenger en resolver, ikke webgrensesnittet eller API-et som kan endre resolverens konfigurasjon.
To DNS-ben, én policy hver
En klientforespørsel reiser fra telefonen til Pi-en, og en separat forespørsel reiser fra Pi-en til dens oppstrøms-resolver. En ruteregel som matcher videresendt hotspot-trafikk gjelder ikke automatisk for det andre benet, fordi Pi-en genererer den trafikken lokalt. Hvis VPN-en skal bære DNS, trenger den lokale veien sin egen policy.
Se opp for en løkke. Å peke Pi-holes upstream mot en adresse Pi-en selv betjener, direkte eller via en port-forward, gir forespørsler som sirkler til de går ut på tid. Gi den en ekte upstream eller en betinget forwarder for domenene den ikke kan svare på.
Bestem hva som skjer når tunnelen faller. Å falle tilbake på den lokale resolveren holder surfing i live, men kan lekke navn utenfor VPN-en; å blokkere holder policyen intakt og gjør avbruddet til en synlig feil. Begge valgene er forsvarlige, men de må velges i stedet for å arves fra en standardverdi.
Bevis veien og oppførselen ved avbrudd
Test i lag: klienten får en adresse, klienten slår opp et navn via Pi-en, Pi-en slår opp via den tiltenkte upstreamen, og et program fullfører en forespørsel. En vellykket ping sier ingenting om DNS, og et vellykket oppslag sier ingenting om videresending.
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.1Stopp deretter tunnelen og gjenta. Den tiltenkte oppførselen bør dukke opp innen noen sekunder, ikke etter en manuell omstart av Pi-hole eller hotspot-tjenesten. Kontroller klientens resolverinnstilling under avbruddet, fordi en sekundær offentlig resolver fortsetter å svare selv når policyen forventet en feil.
Hold én eier for videresending og NAT, og verifiser den fra en klient, ikke fra Pi-en selv. En forespørsel som forlater Pi-en med hell kan fortsatt bli forkastet på veien tilbake, og klienten er det eneste stedet der hele veien er synlig.