Pi-hotspot med Pi-hole og VPN: gje kvar teneste ei eiga oppgåve

Ein telefon koplar seg til hotspoten på Pi-en, får ei adresse, og sida fungerer framleis ikkje. Pi-en køyrer ein hotspot-hjelpar, Pi-hole og ein VPN-klient, og kvar av dei trur dei eig ein del av vegen. Dei fleste av desse bygga mislukkast ikkje fordi ein komponent er øydelagd, men fordi to komponentar gjer same jobben. Tildel éin eigar per funksjon før du justerer nokon av dei.

Tildel éin eigar per funksjon

Her tel fire funksjonar, og kvar treng nøyaktig éin eigar. Tabellen nedanfor namngir funksjonen, ein brukbar eigar og kva som går gale når to tenester gjer krav på han.

Overlappen kjem vanlegvis éin pakke om gongen. Hotspot-hjelparen installerer sin eigen dnsmasq-instans, Pi-hole vil ha port 53, og VPN-klienten legg til ruter. Kvart steg verkar rimeleg åleine, og saman gir dei ein maskin der den andre tenesta som startar stille endrar åtferda til den første.

Skriv ned eigarane før du slår på noko anna. Ein kort tabell i byggnotata hindrar ein seinare installasjon i å ta over ein funksjon som allereie hadde ein eigar.

Vel eitt område og hald det unna tunnelen

Vel hotspot-området, adressa til Pi-en i det, DHCP-poolen og resolveren klientane får. Hald det området skilt frå oppstraums-LAN-et og frå området til VPN-tunnelen, fordi overlappande subnett gjer eit ruteproblem til eit adresseomsetjingsprosjekt. Eit område som overlappar tunnelen gjer Pi-en til ein utilsikta ruter mellom to identiske prefiks. Skriv området og poolen inn i hotspot-konfigurasjonen i staden for å overlate dei til ein standardverdi.

Viss den delte modusen til NetworkManager eig hotspoten, inspiser den effektive tilkoplinga før du legg til ein DHCP-server. Den delte modusen startar sine eigne hjelparar og slår på videresending, så han er allereie eigar av adresseplanen for det grensesnittet. Å leggje til ein ekstra server fordi han er tilgjengeleg skapar konkurrerande tilbod i staden for redundans.

Avgjer IPv6 medvite. Ruterannonsar og DHCPv6 kjem i mange oppsett frå ein annan hjelpar enn DHCPv4, og å la IPv6 stå på medan VPN-policyen berre dekkjer IPv4 gir klientane ein veg som omgår tunnelen. Anten planlegg du IPv6-sida eller deaktiverer ho på hotspot-grensesnittet med ein skriftleg grunn.

Kven som faktisk svarar på port 53

List kvar prosess som lyttar på port 53 før du endrar ein konfigurasjon. På ein Pi som køyrer ein lokal resolver-stub, Pi-hole og ein delingshjelpar, er lyttarlista det einaste pålitelege kartet over kven som svarar på spurnader:

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

Pi-holes grensesnittguide forklarar at ein mottaksmodus avgrensa til eitt grensesnitt framleis kan bruke ein wildcard-socket og kaste ankomstar andre stader. Det er ikkje det same som å binde berre valde grensesnitt, som er oppsettet meint når ei anna DNS-teneste må dele maskinen.

To prosessar kan normalt ikkje binde same adresse og port, sjølv om SO_REUSEPORT kan få ei delt binding til å lukkast; sjølv då kan ein wildcard-lyttar ta ankomstar som var meint for den smalare tenesta. Vel den dokumenterte modusen for rolla du vil ha, og start tenestene på nytt i tiltenkt rekkjefølgje.

Hald administrasjonssida til Pi-hole utanfor hotspot-nettet. Klientar treng ein resolver, ikkje webgrensesnittet eller API-et som kan endre konfigurasjonen til resolveren.

To DNS-bein, éin policy kvar

Ein klientførespurnad reiser frå telefonen til Pi-en, og ein separat førespurnad reiser frå Pi-en til oppstraums-resolveren sin. Ein ruteregel som passar med videresendt hotspot-trafikk gjeld ikkje automatisk for det andre beinet, fordi Pi-en genererer den trafikken lokalt. Viss VPN-en skal bere DNS, treng den lokale vegen sin eigen policy.

Sjå opp for ei løkke. Å peike upstreamen til Pi-hole mot ei adresse Pi-en sjølv tener, direkte eller via ein port-forward, gir førespurnader som sirkar til dei går ut på tid. Gje han ein ekte upstream eller ein vilkårsforwardar for domena han ikkje kan svare på.

Avgjer kva som skjer når tunnelen fell. Å falle tilbake på den lokale resolveren held surfing i live, men kan lekke namn utanfor VPN-en; å blokkere held policyen intakt og gjer avbrotet til ein synleg feil. Begge vala er forsvarlege, men dei må veljast i staden for å arvast frå ein standardverdi.

Prov vegen og åtferda ved avbrot

Test i lag: klienten får ei adresse, klienten slår opp eit namn via Pi-en, Pi-en slår opp via den tiltenkte upstreamen, og eit program fullfører ein førespurnad. Ein vellukka ping seier ingenting om DNS, og eit vellukka oppslag seier 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.1

Stopp deretter tunnelen og gjer om. Den tiltenkte åtferda bør dukke opp innan nokre sekund, ikkje etter ein manuell omstart av Pi-hole eller hotspot-tenesta. Kontroller resolverinnstillinga til klienten under avbrotet, fordi ein sekundær offentleg resolver held fram med å svare sjølv når policyen venta ein feil.

Hald éin eigar for videresending og NAT, og verifiser han frå ein klient, ikkje frå Pi-en sjølv. Ein førespurnad som forlèt Pi-en med hell kan framleis bli forkasta på vegen tilbake, og klienten er det einaste staden der heile vegen er synleg.