Pi-hotspot met Pi-hole en VPN: geef elke dienst een eigen taak

Een telefoon maakt verbinding met de hotspot van de Pi, krijgt een adres en de pagina werkt nog steeds niet. De Pi draait een hotspot-hulp, Pi-hole en een VPN-client, en elk daarvan denkt een deel van het pad te bezitten. De meeste van deze opstellingen mislukken niet omdat een component stuk is, maar omdat twee componenten hetzelfde werk doen. Wijs één eigenaar per functie aan voordat je er een afstelt.

Wijs één eigenaar per functie aan

Hier tellen vier functies, en elk heeft precies één eigenaar nodig. De tabel hieronder noemt de functie, een werkbare eigenaar en wat er misgaat wanneer twee diensten er aanspraak op maken.

De overlap komt meestal één pakket tegelijk. De hotspot-hulp installeert zijn eigen dnsmasq-instantie, Pi-hole wil poort 53 en de VPN-client voegt routes toe. Elke stap lijkt op zichzelf redelijk, en samen leveren ze een machine op waarin de tweede dienst die start stilletjes het gedrag van de eerste verandert.

Schrijf de eigenaren op voordat je iets anders inschakelt. Een korte tabel in de build-notities voorkomt dat een latere installatie een functie overneemt die al een eigenaar had.

Kies één bereik en houd het buiten de tunnel

Kies het hotspot-bereik, het adres van de Pi daarin, de DHCP-pool en de resolver die clients krijgen. Houd dat bereik gescheiden van de upstream-LAN en van het bereik van de VPN-tunnel, want overlappende subnetten maken van een routeringsprobleem een adresvertaalproject. Een bereik dat de tunnel overlapt maakt de Pi een onbedoelde router tussen twee identieke prefixen. Schrijf het bereik en de pool in de hotspot-configuratie in plaats van ze aan een standaardwaarde over te laten.

Als de gedeelde modus van NetworkManager de hotspot beheert, inspecteer dan de effectieve verbinding voordat je een DHCP-server toevoegt. De gedeelde modus start zijn eigen hulpprogramma's en schakelt doorsturing in, dus is hij al de eigenaar van het adresplan voor die interface. Een tweede server toevoegen omdat hij beschikbaar is, levert concurrerende aanbiedingen op in plaats van redundantie.

Beslis bewust over IPv6. Routeradvertenties en DHCPv6 komen in veel opstellingen van een andere hulp dan DHCPv4, en IPv6 aan laten staan terwijl het VPN-beleid alleen IPv4 dekt, geeft clients een pad dat de tunnel omzeilt. Plan de IPv6-kant of schakel die uit op de hotspot-interface, met een opgeschreven reden.

Wie antwoordt er werkelijk op poort 53

Som elk proces op dat op poort 53 luistert voordat je een configuratie wijzigt. Op een Pi met een lokale resolver-stub, Pi-hole en een deel-hulp is de luisteraarslijst de enige betrouwbare kaart van wie queries beantwoordt:

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

De interfacegids van Pi-hole legt uit dat een ontvangstmodus die tot één interface beperkt is, nog steeds een wildcard-socket kan gebruiken en aankomsten elders kan weggooien. Dat is niet hetzelfde als alleen geselecteerde interfaces binden, de opzet die bedoeld is wanneer een andere DNS-dienst de machine moet delen.

Twee processen kunnen normaal niet hetzelfde adres en dezelfde poort binden, hoewel SO_REUSEPORT een gedeelde bind kan laten slagen; zelfs dan kan een wildcard-listener aankomsten overnemen die voor de nauwere dienst bedoeld waren. Kies de gedocumenteerde modus voor de rol die je wilt en herstart de diensten in de bedoelde volgorde.

Houd de beheerpagina van Pi-hole buiten het hotspot-netwerk. Clients hebben een resolver nodig, niet de webinterface of API die de configuratie van de resolver kan wijzigen.

Twee DNS-benen, elk één beleid

Een query van een client reist van de telefoon naar de Pi, en een aparte query reist van de Pi naar zijn upstream-resolver. Een routeringsregel die overeenkomt met doorgestuurd hotspot-verkeer geldt niet automatisch voor het tweede been, omdat de Pi dat verkeer lokaal genereert. Als de VPN DNS moet vervoeren, heeft het lokale pad zijn eigen beleid nodig.

Let op een loop. De upstream van Pi-hole richten op een adres dat de Pi zelf dient, direct of via een port-forward, levert queries op die rondcirkelen tot ze verlopen. Geef hem een echte upstream of een conditionele forwarder voor de domeinen die hij niet kan beantwoorden.

Beslis wat er gebeurt als de tunnel wegvalt. Terugvallen op de lokale resolver houdt browsen in leven maar kan namen buiten de VPN laten lekken; blokkeren houdt het beleid intact en maakt van de storing een zichtbare fout. Beide keuzes zijn verdedigbaar, maar ze moeten gekozen worden in plaats van geërfd uit een standaardwaarde.

Bewijs het pad en het gedrag bij uitval

Test in lagen: de client krijgt een adres, de client lost een naam op via de Pi, de Pi lost op via de bedoelde upstream, en een applicatie rondt een verzoek af. Een geslaagde ping zegt niets over DNS, en een geslaagde lookup zegt niets over doorsturing.

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 dan de tunnel en herhaal. Het bedoelde gedrag moet binnen enkele seconden verschijnen, niet na een handmatige herstart van Pi-hole of de hotspot-dienst. Controleer de resolver-instelling van de client tijdens de storing, want een secundaire publieke resolver blijft antwoorden ook wanneer het beleid een fout verwachtte.

Houd één eigenaar voor doorsturing en NAT en verifieer die vanaf een client, niet vanaf de Pi zelf. Een verzoek dat de Pi met succes verlaat kan op de terugweg alsnog worden weggegooid, en de client is de enige plek waar het hele pad zichtbaar is.