Pi-hotspot med Pi-hole og VPN: giv hver tjeneste en opgave

En telefon opretter forbindelse til Pi'ens hotspot, får en adresse, og siden fejler stadig. Pi'en kører en hotspot-hjælper, Pi-hole og en VPN-klient, og hver af dem tror, at den ejer en del af vejen. De fleste af disse opsætninger fejler ikke, fordi en komponent er i stykker, men fordi to komponenter udfører det samme arbejde. Tildel én ejer per funktion, før du justerer nogen af dem.

Tildel én ejer per funktion

Fire funktioner er vigtige her, og hver især kræver præcis én ejer. Tabellen nedenfor angiver funktionen, en brugbar ejer og hvad der går galt, når to tjenester gør krav på den.

Overlapningen kommer normalt én pakke ad gangen. Hotspot-hjælperen installerer sin egen dnsmasq-instans, Pi-hole vil have port 53, og VPN-klienten tilføjer ruter. Hvert skridt virker fornuftigt alene, og sammen skaber de en maskine, hvor den anden tjeneste, der starter, stille ændrer den førstes adfærd.

Skriv ejerne ned, før du aktiverer noget andet. En kort tabel i byggenoterne forhindrer en senere installation i at overtage en funktion, der allerede havde en ejer.

Vælg ét interval og hold det væk fra tunnelen

Vælg hotspot-intervallet, Pi'ens adresse i det, DHCP-puljen og den resolver, klienterne får. Hold det interval adskilt fra det overordnede LAN og fra VPN-tunnelens interval, fordi overlappende subnets gør et routingproblem til et adresseoversættelsesprojekt. Et interval, der overlapper tunnelen, gør Pi'en til en utilsigtet router mellem to identiske præfikser. Skriv intervallet og puljen ind i hotspot-konfigurationen i stedet for at overlade dem til en standardværdi.

Hvis NetworkManagers delte tilstand ejer hotspottet, skal du undersøge den effektive forbindelse, før du tilføjer en DHCP-server. Delt tilstand starter sine egne hjælpere og aktiverer videresendelse, så den er allerede ejer af adresseplanen for det interface. At tilføje en anden server, fordi den er tilgængelig, skaber konkurrerende tilbud i stedet for redundans.

Beslut IPv6 med vilje. Routerannonceringer og DHCPv6 kommer i mange opsætninger fra en anden hjælper end DHCPv4, og hvis IPv6 forbliver slået til, mens VPN-politikken kun dækker IPv4, får klienterne en vej uden om tunnelen. Planlæg enten IPv6-siden, eller slå den fra på hotspot-interfacet med en skriftlig begrundelse.

Hvem svarer faktisk på port 53

List hver proces, der lytter på port 53, før du ændrer en konfiguration. På en Pi, der kører en lokal resolver-stub, Pi-hole og en delingshjælper, er lytterlisten det eneste pålidelige kort over, hvem der svarer på forespørgsler:

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

Pi-holes interfaceguide forklarer, at en modtagelsestilstand begrænset til ét interface stadig kan bruge en wildcard-socket og kassere ankomster andre steder. Det er ikke det samme som kun at binde udvalgte interfaces, hvilket er den ordning, der er tilsigtet, når en anden DNS-tjeneste skal dele maskinen.

To processer kan normalt ikke binde samme adresse og port, selvom SO_REUSEPORT kan få en delt binding til at lykkes; selv da kan en wildcard-lytter tage ankomster beregnet til den smallere tjeneste. Vælg den dokumenterede tilstand til den rolle, du ønsker, og genstart tjenesterne i den tilsigtede rækkefølge.

Hold Pi-holes administrationsside væk fra hotspot-netværket. Klienter har brug for en resolver, ikke webinterfacet eller API'en, der kan ændre resolverens konfiguration.

To DNS-ben, en politik hver

En klientforespørgsel rejser fra telefonen til Pi'en, og en separat forespørgsel rejser fra Pi'en til dens overordnede resolver. En routingregel, der matcher videresendt hotspot-trafik, gælder ikke automatisk for det andet ben, fordi Pi'en genererer den trafik lokalt. Hvis VPN'en skal bære DNS, har den lokale vej brug for sin egen politik.

Hold øje med en løkke. At pege Pi-holes overordnede resolver mod en adresse, som Pi'en selv betjener, direkte eller via en portvideresendelse, giver forespørgsler, der cirkler, indtil de timeout'er. Giv den en rigtig overordnet resolver eller en betinget forwarder til de domæner, den ikke kan svare på.

Beslut, hvad der sker, når tunnelen falder. At falde tilbage til den lokale resolver holder browsing i live, men kan lække navne uden for VPN'en; blokering holder politikken intakt og gør afbrydelsen til en synlig fejl. Begge valg er forsvarlige, men det skal vælges i stedet for at arves fra en standardværdi.

Bevis vejen og adfærden ved afbrydelse

Test i lag: klienten får en adresse, klienten opløser et navn gennem Pi'en, Pi'en opløser gennem den tilsigtede overordnede resolver, og et program fuldfører en anmodning. En vellykket ping siger intet om DNS, og et vellykket opslag siger intet om videresendelse.

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

Stop derefter tunnelen, og gentag. Den tilsigtede adfærd bør vise sig inden for få sekunder, ikke efter en manuel genstart af Pi-hole eller hotspot-tjenesten. Kontrollér klientens resolverindstilling under afbrydelsen, fordi en sekundær offentlig resolver fortsætter med at svare, selv når politikken forventede fejl.

Hold én ejer til videresendelse og NAT, og verificér det fra en klient, ikke fra Pi'en selv. En anmodning, der forlader Pi'en med succes, kan stadig blive droppet på vejen tilbage, og klienten er det eneste sted, hvor hele vejen er synlig.