Pi-Hotspot mit Pi-hole und VPN: Jeder Dienst bekommt eine Aufgabe

Ein Telefon verbindet sich mit dem Hotspot des Pi, erhält eine Adresse, und die Seite lädt trotzdem nicht. Auf dem Pi laufen ein Hotspot-Helfer, Pi-hole und ein VPN-Client, und jeder glaubt, einen Teil des Weges zu besitzen. Die meisten dieser Aufbauten scheitern nicht, weil eine Komponente defekt ist, sondern weil zwei Komponenten dieselbe Aufgabe erledigen. Weisen Sie jeder Funktion genau einen Eigentümer zu, bevor Sie eine davon abstimmen.

Weisen Sie jeder Funktion einen Eigentümer zu

Vier Funktionen sind hier wichtig, und jede braucht genau einen Eigentümer. Die folgende Tabelle nennt die Funktion, einen brauchbaren Eigentümer und was schiefgeht, wenn zwei Dienste sie beanspruchen.

Die Überschneidung kommt meistens ein Paket nach dem anderen. Der Hotspot-Helfer installiert seine eigene dnsmasq-Instanz, Pi-hole will Port 53, und der VPN-Client fügt Routen hinzu. Jeder Schritt wirkt für sich vernünftig, und zusammen erzeugen sie eine Maschine, auf der der zweite startende Dienst das Verhalten des ersten still verändert.

Schreiben Sie die Eigentümer auf, bevor Sie etwas anderes aktivieren. Eine kurze Tabelle in den Build-Notizen verhindert, dass eine spätere Installation eine Funktion übernimmt, die bereits einen Eigentümer hatte.

Wählen Sie einen Bereich und halten Sie ihn vom Tunnel fern

Wählen Sie den Hotspot-Bereich, die Adresse des Pi darin, den DHCP-Pool und den Resolver, den die Clients erhalten. Halten Sie diesen Bereich vom übergeordneten LAN und vom VPN-Tunnelbereich getrennt, denn überlappende Subnetze machen aus einem Routingproblem ein Adressübersetzungsprojekt. Ein Bereich, der den Tunnel überlappt, macht den Pi zu einem versehentlichen Router zwischen zwei identischen Präfixen. Schreiben Sie Bereich und Pool in die Hotspot-Konfiguration, statt sie einer Vorgabe zu überlassen.

Wenn der geteilte Modus von NetworkManager den Hotspot besitzt, prüfen Sie die effektive Verbindung, bevor Sie einen DHCP-Server hinzufügen. Der geteilte Modus startet eigene Helfer und aktiviert die Weiterleitung, ist also bereits Eigentümer des Adressplans für diese Schnittstelle. Einen zweiten Server hinzuzufügen, weil er verfügbar ist, erzeugt konkurrierende Angebote statt Redundanz.

Entscheiden Sie bewusst über IPv6. Router-Ankündigungen und DHCPv6 kommen in vielen Aufbauten von einem anderen Helfer als DHCPv4, und wenn IPv6 eingeschaltet bleibt, während die VPN-Richtlinie nur IPv4 abdeckt, erhalten Clients einen Weg am Tunnel vorbei. Planen Sie entweder die IPv6-Seite, oder deaktivieren Sie sie an der Hotspot-Schnittstelle mit einer schriftlichen Begründung.

Wer tatsächlich auf Port 53 antwortet

Listen Sie jeden Prozess auf, der auf Port 53 lauscht, bevor Sie eine Konfiguration ändern. Auf einem Pi, der einen lokalen Resolver-Stub, Pi-hole und einen Freigabe-Helfer ausführt, ist die Lauscherliste die einzige verlässliche Karte dafür, wer Anfragen beantwortet:

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

Die Schnittstellenanleitung von Pi-hole erklärt, dass ein auf eine Schnittstelle beschränkter Empfangsmodus trotzdem einen Wildcard-Socket nutzen und Ankünfte anderswo verwerfen kann. Das ist nicht dasselbe wie das Binden nur an ausgewählte Schnittstellen, und genau diese Anordnung ist gemeint, wenn ein anderer DNS-Dienst die Maschine mitnutzen muss.

Zwei Prozesse können normalerweise nicht dieselbe Adresse und denselben Port binden, obwohl SO_REUSEPORT ein gemeinsames Binden gelingen lassen kann; selbst dann kann ein Wildcard-Listener Ankünfte übernehmen, die für den engeren Dienst bestimmt waren. Wählen Sie den dokumentierten Modus für die gewünschte Rolle und starten Sie die Dienste in der vorgesehenen Reihenfolge neu.

Halten Sie die Verwaltungsseite von Pi-hole aus dem Hotspot-Netz heraus. Clients brauchen einen Resolver, nicht die Weboberfläche oder API, die die Konfiguration des Resolvers ändern kann.

Zwei DNS-Beine, je eine Richtlinie

Eine Client-Anfrage reist vom Telefon zum Pi, und eine separate Anfrage reist vom Pi zu seinem übergeordneten Resolver. Eine Routingregel, die weitergeleiteten Hotspot-Verkehr trifft, gilt nicht automatisch für das zweite Bein, weil der Pi diesen Verkehr lokal erzeugt. Wenn das VPN DNS tragen soll, braucht der lokale Weg seine eigene Richtlinie.

Achten Sie auf eine Schleife. Den übergeordneten Resolver von Pi-hole auf eine Adresse zu zeigen, die der Pi selbst bedient, direkt oder über eine Portweiterleitung, erzeugt Anfragen, die kreisen, bis sie ablaufen. Geben Sie ihm einen echten übergeordneten Resolver oder einen bedingten Forwarder für die Domains, die er nicht beantworten kann.

Entscheiden Sie, was passiert, wenn der Tunnel ausfällt. Der Rückfall auf den lokalen Resolver hält das Surfen am Leben, kann aber Namen außerhalb des VPN preisgeben; Blockieren hält die Richtlinie intakt und macht den Ausfall zu einem sichtbaren Fehler. Beide Wahlmöglichkeiten sind vertretbar, aber sie muss gewählt und nicht von einer Vorgabe geerbt werden.

Beweisen Sie den Weg und das Verhalten beim Ausfall

Testen Sie in Schichten: Der Client erhält eine Adresse, der Client löst einen Namen über den Pi auf, der Pi löst über den vorgesehenen übergeordneten Resolver auf, und eine Anwendung schließt eine Anfrage ab. Ein erfolgreicher Ping sagt nichts über DNS, und eine erfolgreiche Abfrage sagt nichts über die Weiterleitung.

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

Stoppen Sie dann den Tunnel und wiederholen Sie den Test. Das vorgesehene Verhalten sollte innerhalb weniger Sekunden erscheinen, nicht erst nach einem manuellen Neustart von Pi-hole oder des Hotspot-Dienstes. Prüfen Sie während des Ausfalls die Resolver-Einstellung des Clients, denn ein sekundärer öffentlicher Resolver antwortet weiter, selbst wenn die Richtlinie einen Fehler erwartete.

Halten Sie einen Eigentümer für Weiterleitung und NAT und prüfen Sie ihn von einem Client aus, nicht vom Pi selbst. Eine Anfrage, die den Pi erfolgreich verlässt, kann auf dem Rückweg trotzdem verworfen werden, und der Client ist der einzige Ort, an dem der ganze Weg sichtbar ist.