Pi-Hotspot mat Pi-hole an VPN: gitt all Service eng Aufgab

En Telefon verbënnt sech mam Hotspot vum Pi, kritt eng Adress, an d'Säit schläit nach ëmmer fehl. De Pi bedreift eng Hotspot-Hëllef, Pi-hole an e VPN-Client, an all eenzele mengt, en Deel vum Wee ze besëtzen. Déi meeschte vun dëse Konfiguratioune schléien net fehl, well eng Komponent futti ass, mä well zwou Komponenten déiselwecht Aarbecht maachen. Gitt engem Besëtzer pro Funktioun, ier Dir eng vun hinnen ajustéiert.

Gitt engem Besëtzer pro Funktioun

Hei zielen véier Funktiounen, an all brauch genee ee Besëtzer. D'Tabelle hei drënner nennt d'Funktioun, en tragbare Besëtzer a wat schief geet, wann zwou Servicer se beusproochen.

D'Iwwerlappung kënnt meeschtens ee Pakett gläichzäiteg. D'Hotspot-Hëllef installéiert hir eegen dnsmasq-Instanz, Pi-hole wëllt Port 53, an de VPN-Client setzt Routen derbäi. All Schrëtt schéngt eleng raisonnabel, an zesummen ergi se eng Maschinn, an där den zweete Service, deen ufänkt, still d'Verhalen vum éischten ännert.

Schreift d'Besëtzer op, ier Dir eppes anescht aschalt. Eng kuerz Tabell an de Build-Notizen verhënnert, datt eng méi spéit Installatioun eng Funktioun iwwerhëlt, déi schonn e Besëtzer hat.

Wielt eng Range a haalt se vum Tunnel ewech

Wielt d'Hotspot-Range, d'Adress vum Pi doran, den DHCP-Pool an den Resolver, deen d'Cliente kréien. Haalt déi Range getrennt vum Upstream-LAN a vun der Range vum VPN-Tunnel, well iwwerlappend Subnetzer aus engem Routingproblem en Adress-Iwwersetzungsprojet maachen. Eng Range, déi den Tunnel iwwerlappt, mécht de Pi zu engem zoufällege Router tëscht zwou identesche Prefixen. Schreift d'Range an de Pool an d'Hotspot-Konfiguratioun, amplaz se op enger Standardwäert ze loossen.

Wann de Shared-Modus vum NetworkManager den Hotspot besëtzt, iwwerpréift déi effektiv Verbindung, ier Dir en DHCP-Server dobäisetzt. De Shared-Modus start seng eege Hëllefen an aktivéiert d'Weiderleedung, also ass en schonn de Besëtzer vum Adressplang fir déi Interface. En zweeten Server dobäisetzen, well en disponibel ass, schaaft konkurréierend Offeren amplaz Redundanz.

Entscheet bewosst iwwer IPv6. Router-Advertisements an DHCPv6 kommen a ville Konfiguratiounen vun enger anerer Hëllef wéi DHCPv4, an IPv6 un ze loossen, während d'VPN-Politik nëmmen IPv4 deckt, gëtt de Cliente e Wee, deen den Tunnel ëmgeet. Entweder plangt Dir d'IPv6-Säit oder Dir deaktivéiert se op der Hotspot-Interface mat engem schrëftlechen Grond.

Wien äntwert tatsächlech op Port 53

Lëscht all Prozess op, deen op Port 53 lauschtert, ier Dir eng Konfiguratioun ännert. Op engem Pi mat engem lokale Resolver-Stub, Pi-hole an enger Deele-Hëllef ass d'Lauschterer-Lëscht déi eenzeg zouverlässeg Kaart dovun, wien Ufroen äntwert:

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

Den Interface-Guide vu Pi-hole erkläert, datt en Empfangsmodus, deen op eng Interface limitéiert ass, nach ëmmer e Wildcard-Socket ka benotzen an Uschëss aneschtwou verwerfen. Dat ass net datselwecht wéi nëmme gewielten Interfacen ze binden, wat d'Arrangement ass, dat geduecht ass, wann en aneren DNS-Service d'Maschinn deele muss.

Zwee Prozesser kënnen normalerweis net déiselwecht Adress an dee selwechte Port binden, obwuel SO_REUSEPORT e gedeelte Bind ka geléngen; och dann ka en Wildcard-Lauschterer Uschëss huelen, déi fir dee méi enke Service geduecht waren. Wielt de dokumentéierte Modus fir d'Roll, déi Dir wëllt, an startet d'Servicer an der geduechter Reihenfolg nei.

Haalt d'Administratiounssäit vu Pi-hole aus dem Hotspot-Netzwierk. D'Cliente brauchen e Resolver, net d'Webinterface oder d'API, déi d'Konfiguratioun vum Resolver ännere kann.

Zwou DNS-Sträcken, jee eng Politik

Eng Ufro vun engem Client reest vum Telefon zum Pi, an eng separat Ufro reest vum Pi zu sengem Upstream-Resolver. Eng Routing-Regel, déi op weidergeleet Hotspot-Traffic passt, gëllt net automatesch fir déi zweet Streck, well de Pi deen Traffic lokal generéiert. Wann d'VPN DNS soll droen, brauch de lokale Wee seng eege Politik.

Passt op eng Schleif op. De Pi-hole-Upstream op eng Adress ze riichten, déi de Pi selwer servéiert, direkt oder iwwer e Port-Forward, produzéiert Ufroen, déi am Krees lafen, bis se oflafe loossen. Gitt him en echte Upstream oder e bedingte Forwarder fir d'Domänen, déi en net ka beäntweren.

Entscheet, wat geschitt, wann den Tunnel fält. Op de lokale Resolver zréckzegräifen hält d'Browsen lieweg, kann awer Nimm baussent der VPN lecken; blockéieren hält d'Politik intakt an mécht aus dem Ausfall e sichtbaren Fehler. Béid Wiel sinn defendéierbar, mä se musse gewielt ginn, amplaz vun engem Standardwäert geierft ze ginn.

Beweist de Wee an d'Verhalen beim Ausfall

Testet a Schichten: de Client kritt eng Adress, de Client léist en Numm iwwer de Pi op, de Pi léist iwwer den geduechten Upstream op, an eng Applikatioun fäerdeg en Ufro. En erfollegräiche Ping seet näischt iwwer DNS, an en erfollegräiche Lookup seet näischt iwwer d'Weiderleedung.

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

Stoppt dann den Tunnel a widderhëlt. Dat geduecht Verhalen soll bannent e puer Sekonne erschéngen, net no engem manuelle Neistart vu Pi-hole oder dem Hotspot-Service. Kontrolléiert d'Resolver-Astellung vum Client während dem Ausfall, well en zweeten ëffentleche Resolver weider äntwert, och wann d'Politik e Fehler erwaart huet.

Haalt ee Besëtzer fir Weiderleedung an NAT a verifizéiert en vun engem Client, net vum Pi selwer. Eng Ufro, déi de Pi erfollegräich verléisst, kann um Réckwee nach ëmmer verworf ginn, an de Client ass déi eenzeg Plaz, wou de ganze Wee sichtbar ass.