Pi-hotspot mei Pi-hole en VPN: jou elk tsjinst in eigen taak

In telefoan ferbynt him mei de hotspot fan 'e Pi, krijt in adres en de side wurket noch altyd net. De Pi draait in hotspot-helper, Pi-hole en in VPN-klant, en elk fan harren tinkt in part fan it paad te besitten. De measte fan dizze opstellings mislearje net omdat in komponint stikken is, mar omdat twa komponinten itselde wurk dogge. Jou ien eigner per funksje oan foardatst ien fan harren ôfstelst.

Jou ien eigner per funksje

Hjir telle fjouwer funksjes, en elk hat krekt ien eigner nedich. De tabel hjirûnder neamt de funksje, in wurkbere eigner en wat der misgiet as twa tsjinsten der oanspraak op meitsje.

De oerlaap komt meastentiids ien pakket tagelyk. De hotspot-helper ynstallearret syn eigen dnsmasq-eksimplaar, Pi-hole wol poarte 53 en de VPN-klant foeget rûtes ta. Elke stap liket op himsels ridlik, en tegearre leverje se in masine op wêryn't de twadde tsjinst dy't start stilwei it gedrach fan 'e earste feroaret.

Skriuw de eigners op foardatst wat oars ynskeakelest. In koarte tabel yn 'e build-notysjes foarkomt dat in lettere ynstallaasje in funksje oernimt dy't al in eigner hie.

Kies ien berik en hâld it bûten de tunnel

Kies it hotspot-berik, it adres fan 'e Pi dêryn, de DHCP-pool en de resolver dy't clients krije. Hâld dat berik apart fan 'e upstream-LAN en fan it berik fan 'e VPN-tunnel, want oerlaapjende subnetten meitsje fan in routeringsprobleem in adresfertaalprojekt. In berik dat de tunnel oerlaapet makket de Pi in ûnbedoelde router tusken twa identike prefixen. Skriuw it berik en de pool yn 'e hotspot-konfiguraasje yn stee fan se oan in standertwearde oer te litten.

As de dielde modus fan NetworkManager de hotspot besit, ynspektearje dan de effektive ferbining foardatst in DHCP-server tafoege. De dielde modus start syn eigen helpers en skeakelt foarstjoering yn, dus is hy al de eigner fan it adresplan foar dy interface. In twadde server tafoegje om't er beskikber is, leveret konkurrearjende oanbiedingen op yn stee fan redundantie.

Beslis bewust oer IPv6. Routeradvertinsjes en DHCPv6 komme yn in soad opstellings fan in oare helper as DHCPv4, en IPv6 oan litte wylst it VPN-belied allinne IPv4 dekt, jout clients in paad dat de tunnel omgiet. Plan de IPv6-kant of skeakel dy út op 'e hotspot-interface, mei in opskreaune reden.

Wa't antwurdet der wier op poarte 53

List elk proses op dat op poarte 53 harket foardatst in konfiguraasje feroarest. Op in Pi mei in lokale resolver-stub, Pi-hole en in diel-helper is de harkerlist de iennige betroubere kaart fan wa't queries beantwurdet:

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

De interfacegids fan Pi-hole leit út dat in ûntfangstmodus dy't ta ien interface beheind is, noch altyd in wildcard-socket brûke kin en oankomsten earne oars fuortsmite kin. Dat is net itselde as allinne selekteare interfaces bine, de opset dy't bedoeld is as in oare DNS-tsjinst de masine diele moat.

Twa prosessen kinne normaal net itselde adres en deselde poarte bine, hoewol't SO_REUSEPORT in dielde bind slagje litte kin; sels dan kin in wildcard-harker oankomsten oernimme dy't foar de nauwere tsjinst bedoeld wiene. Kies de dokumintearre modus foar de rol dy'tsto wolst en werstart de tsjinsten yn 'e bedoelde folchoarder.

Hâld de behearspagina fan Pi-hole bûten it hotspot-netwurk. Clients hawwe in resolver nedich, net de webinterface of API dy't de konfiguraasje fan 'e resolver feroarje kin.

Twa DNS-skinkels, elk ien belied

In query fan in client reizget fan 'e telefoan nei de Pi, en in aparte query reizget fan 'e Pi nei syn upstream-resolver. In routeringsregel dy't oerienkomt mei trochstjoerd hotspot-ferkear jildt net automatysk foar de twadde skinkel, om't de Pi dat ferkear lokaal generearret. As de VPN DNS drage moat, hat it lokale paad syn eigen belied nedich.

Let op in loop. De upstream fan Pi-hole rjochtsje op in adres dat de Pi sels tsjinnet, direkt of fia in port-forward, leveret queries op dy't rûngean oant se ferrinne. Jou him in echte upstream of in betingst-forwarder foar de domeinen dy't er net beantwurdzje kin.

Beslis wat der bart as de tunnel weifalt. Weromfalle op 'e lokale resolver hâldt browsen yn libben mar kin nammen bûten de VPN lekke; blokkearje hâldt it belied yntakt en makket fan 'e steuring in sichtbere flater. Beide karren binne ferdigenber, mar se moatte keazen wurde yn stee fan erfd út in standertwearde.

Bewiis it paad en it gedrach by útfal

Test yn lagen: de client krijt in adres, de client lost in namme op fia de Pi, de Pi lost op fia de bedoelde upstream, en in applikaasje rûnet in fersyk ôf. In slagge ping seit neat oer DNS, en in slagge lookup seit neat oer foarstjoering.

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 werhelje. It bedoelde gedrach moat binnen in pear sekonden ferskine, net nei in manuele werstart fan Pi-hole of de hotspot-tsjinst. Kontrolearje de resolver-ynstelling fan 'e client by de steuring, want in sekundêre publike resolver bliuwt antwurdzje sels as it belied in flater ferwachte.

Hâld ien eigner foar foarstjoering en NAT en ferifiearje dy fanôf in client, net fanôf de Pi sels. In fersyk dat de Pi mei súkses ferlit kin op 'e weromwei dochs noch weilitten wurde, en de client is it iennige plak dêr't it hiele paad sichtber is.