Pi-hole plus VPN auf einem Pi: Wird das Betriebssystem noch unterstützt?

Auf einer kombinierten Pi-hole- und VPN-Box werden zwei Dinge verwechselt: die installierte Distributionsfamilie und das Release samt Architektur, die die Komponenten tatsächlich unterstützen. Ein Board, das ein Image bootet, belegt, dass der Kernel läuft; es belegt nicht, dass Pi-holes FTL-Binärdatei und Ihr VPN-Installer denselben Userspace ansprechen. Der eigentliche Test ist eine vierfache Überschneidung aus Board-Unterstützung, Release-Zweig, Paketarchitektur und einem Upgrade-Pfad, den Sie selbst fahren können. Verlieren Sie eines dieser vier Beine, läuft das Gerät diese Woche und lässt Sie beim nächsten Sicherheitsupdate hängen.

Der Release-Zweig bestimmt die Unterstützung, nicht der Familienname

Fragen Sie, gegen welches Release das Projekt noch testet, und schreiben Sie die Antwort als Versionsstring statt als Debian auf. Pi-holes Seite mit den Voraussetzungen führt unterstützte Betriebssysteme und vorgebaute FTL-Architekturen als zwei getrennte Anforderungen auf, begrenzt die Unterstützung auf Releases, die die Distribution selbst noch pflegt, und warnt, dass Varianten oder ungewöhnliche Konfigurationen selbst innerhalb der unterstützten Liste scheitern können. Diese Formulierung ist wichtig: Eine unterstützte Familie deckt nicht jedes ihrer Mitglieder ab.

Ein altes Image, das auf Ihrem Pi noch bootet, ist kein Beleg für Unterstützung. Das Board ist in Ordnung, der Paketindex ist veraltet, und die Diskrepanz zeigt sich später, wenn ein Installer eine Abhängigkeit zieht, die das Release nicht mehr erfüllen kann.

Die VPN-Seite hat mehr Teile, jedes mit seinem eigenen Fenster: Der Tunnel-Daemon, der Installationshelfer, der seine Konfiguration schreibt, die Client-App des Anbieters und das Integrationspaket der Distribution sind vier getrennte Projekte. Ein Installer, der Ihre Distribution erkennt, und ein Installer, der einen Dienst erzeugt, den das Release am Laufen halten kann, sind verschiedene Aussagen. Sehen Sie in der eigenen Plattformliste des Daemons nach und prüfen Sie dann, ob der Helfer, den Sie ausführen wollen, seit jenem Release angefasst wurde. Wo ein Projekt Unterstützung nur bis zu einem benannten Release zusagt, behandeln Sie das nächste als ungetestet, bis Sie es selbst gebootet haben.

Passen Sie das Binärziel an den Userspace an, den Sie haben

Die Architektur ist der leisere Fehler. Ein 64-Bit-Kernel mit einem 32-Bit-Userland ist auf mehreren Boards eine reale, unterstützte Kombination, und er führt eine 32-Bit-FTL-Binärdatei ohne Murren aus, bis zu dem Moment, in dem Sie etwas installieren, das nur für arm64 veröffentlicht wird. Drucken Sie beide Hälften aus, bevor Sie ein Image wählen, und legen Sie die Ausgabe zu Ihren Notizen.

uname -m
dpkg --print-architecture
grep -E '^(PRETTY_NAME|VERSION_ID)=' /etc/os-release
apt-cache policy pihole-ftl

Wenn diese beiden Architekturzeilen nicht übereinstimmen, sind Sie auf einem gemischten Setup: für Pi-hole allein machbar, fragil, sobald ein zweiter Dienst native Bibliotheken will. Ein sauberes 64-Bit-Image neu zu flashen ist meist schneller, als die Toolchain neu zu bauen, die die Diskrepanz erzeugt hat.

Board-Marketing klärt das auch nicht. Speichergröße und CPU-Modell sagen nichts darüber, gegen welche libc Ihre Pakete linken, entscheiden Sie also nach den ausgedruckten Werten, nie nach der Produktseite.

Eine Box, zwei Dienste, ein Eigentümer des Netzwerks

Legen Sie fest, wem Adressierung, Resolver und Tunnel gehören, bevor das erste Paket hinaufgeht, sonst beanspruchen zwei Dienste dieselbe Aufgabe, und keiner gewinnt sauber. Geben Sie dem Pi eine statische Adresse außerhalb des DHCP-Pools Ihres Routers und halten Sie den Tunnel in einem eigenen Subnetz: 192.168.50.10 für den Pi und 10.42.0.0/24 für den Tunnel ist eine machbare Aufteilung, und die Zahlen selbst sind beliebig, solange sie nicht mit dem kollidieren, was Ihr Router bereits bedient. Notieren Sie dann, welche Komponente auf Port 53 antwortet, welche DHCP verteilt, falls Sie es nutzen, und welche die Standardroute besitzt, solange der Tunnel steht. Auf einem Headless-Image gehört die letzte Aufgabe NetworkManager oder systemd-networkd, und einen Anbieter-Client zu installieren, der auch die Resolver-Konfiguration umschreibt, ist der Weg, auf dem Leute mit einem lebenden Tunnel und totem DNS enden.

Die Box zu teilen ist in Ordnung. Eine Rolle zu teilen nicht. Pi-hole will der einzige Listener auf Port 53 sein, und der VPN-Daemon will seine eigene DNS-Einstellung an die Clients schieben, also wählen Sie, welchem der beiden die Clients trauen sollen, und konfigurieren Sie den anderen so, dass er aus dem Weg bleibt.

Halten Sie den Verwaltungsweg vom Tunnel fern, wo Sie können. Wenn Resolver und Tunnel gemeinsam ausfallen, wollen Sie SSH weiterhin auf der LAN-Adresse erreichen, und das heißt, der Verwaltungsdienst darf von keinem der beiden abhängen.

Machen Sie das nächste Upgrade zu einem Teil der Wahl

Ein Release, das Sie nicht upgraden können, ist eine Unterstützungsobergrenze, die Sie bereits akzeptiert haben. Testen Sie die Upgrade-Mechanik auf einer Ersatzkarte, bevor das Gerät das DNS Ihres Haushalts trägt, und lesen Sie, was die Projekte über das Springen zwischen Zweigen sagen, statt anzunehmen, ein Paket-Upgrade reiche.

sudo apt update
apt-mark showhold
sudo apt full-upgrade
pihole -up

Zurückgehaltene Pakete sind der übliche Grund, warum ein Upgrade erfolgreich aussieht und nichts ändert. Lösen Sie die Holds bewusst, eines nach dem anderen, und notieren Sie, welcher Dienst die Fixierung brauchte.

Exportieren Sie vor dem Sprung die Pi-hole-Konfiguration, die statischen Leases und alle Tunnelprofile und bestätigen Sie, dass Sie sie auf einem frischen Image wiederherstellen können. Testen Sie nach dem Sprung gewöhnliches Client-DNS, die private Ressource hinter dem Tunnel, eine Wiederverbindung und jede Weiterleitungsregel am Gateway. Eine Box, die bootet und auf ping antwortet, hat fast nichts bestanden.

Wenn kein einzelnes Release zu beiden Diensten passt

Manchmal ist die Überschneidung leer: Der VPN-Helfer ist auf ein neueres Release umgezogen als das Pi-hole-Paket, das Sie installieren können, oder das Hersteller-Image des Boards hinkt beiden hinterher. Trennen Sie in diesem Fall die Rollen, statt Release-Metadaten zu bearbeiten, um einen Installer zufriedenzustellen. Zwei kleine Geräte oder ein Gerät plus ein Container für den zweiten Dienst kosten weniger als ein Gerät, dessen Unterstützungsgeschichte auf einer Lüge beruht.

Die Version zu fälschen ist die eine Abkürzung, die Sie rundweg ablehnen sollten. Paketmanager vertrauen dem, was die Release-Datei sagt, also beschert Ihnen eine gefälschte Kennung eine Installation, bei deren Fehlersuche Ihnen keines der beiden Projekte hilft.

Wenn zwei aktuelle Releases alles erfüllen, wählen Sie das, dessen Upgrade-Notizen Sie ohne Raten befolgen können, und hören Sie auf zu suchen. Dann notieren Sie Version, Architektur, Dienst-Eigentümer und Wiederherstellungsschritt an einer Stelle, denn die nächste Person, die die SD-Karte anfasst, braucht alle vier.