Kein offener Port: wie mein Handy Paperless erreicht

Angenommen, die Waschmaschine streikt kurz vor Ende der Garantie. Ich stehe im Baumarkt an der Servicetheke, und die erste Frage kommt, wie sie immer kommt: Haben Sie die Rechnung dabei? Auf Papier natürlich nicht. Ich tippe paperless.home.example ins Handy, und eine Sekunde später ist sie da, aus meinem Dokumentenarchiv zu Hause.

Für die Person hinter der Theke ist das einfach ein Handy mit einer Rechnung darauf. Für mich steckt darin die Frage, um die es in diesem Teil geht. Mein Router zu Hause lässt von außen niemanden herein, es gibt dort keine offene Tür, im Jargon keinen offenen Port. Wie kommt die Anfrage aus dem Baumarkt trotzdem bis nach Hause? Und wer kann unterwegs mitlesen?

Kurz zur Orientierung: In Teil 1 habe ich mein Homelab als Haus beschrieben. Auf einem einzigen Rechner, pve1, laufen viele virtuelle Maschinen, kurz VMs, also abgeschottete Rechner im Rechner, und jeder Dienst wohnt in seiner eigenen. Dieser Teil kümmert sich um Haustür, Klingelschild und Empfang, auf der Karte Netz & Zugriff. Den Weg dorthin bin ich in Teil 1 schon einmal im Schnelldurchlauf gegangen. Diesmal gehen wir langsam, Station für Station, und am Ende steht eine Messung, die zeigt, ob „alles verschlüsselt“ wirklich stimmt.

Ein Netz über dem Netz

Die erste Station sieht man nie. Mein Handy hängt im Mobilfunk oder in irgendeinem WLAN, meine Server stehen hinter der Fritz!Box zu Hause, und dazwischen liegt das Internet. Damit beide trotzdem miteinander reden können, als stünden sie im selben Raum, gibt es NetBird.

NetBird legt ein privates Netz über das Internet, ein sogenanntes Overlay-Netz. Am einfachsten stellt man es sich als System privater Tunnel vor, durch die nur meine eigenen Geräte fahren dürfen. Die Tunnel baut eine Technik namens WireGuard. Sie verschlüsselt jede Verbindung zwischen zwei Geräten mit deren eigenen Schlüsseln, und wer von außen zuschaut, sieht nur Zeichensalat. Jedes Gerät in diesem Netz heißt Peer und bekommt darin eine eigene Adresse, seine NetBird-Adresse. Mein Handy ist ein Peer, ebenso mein Laptop, pve1 und jede VM, in der ein Dienst läuft.

Damit sich die Peers finden, braucht es einen Vermittler, den NetBird-Server. Ihn betreibe ich selbst, auf einem kleinen gemieteten Server beim Hosting-Anbieter Hetzner. Er ist der einzige Teil mit offenen Türen, und seine Rolle ist bescheiden. Er weiß, wer dazugehört und wer mit wem reden darf, und hilft zwei Peers, einander zu finden. Den Tunnel selbst bauen beide Seiten von innen nach außen auf, deshalb muss der Router zu Hause keine Tür öffnen. Finden sie keinen direkten Weg, reicht ein Relay, eine Art Umsteigebahnhof auf demselben Server, die Daten weiter, verschlüsselt, wie sie sind.

Das Bild zeigt diese Aufteilung. Oben steht der NetBird-Server, der nur verteilt, wer wen erreichen darf. Darunter das Handy unterwegs, in der Mitte mein Zuhause hinter der Fritz!Box und ganz unten der Backup-Server, der ebenfalls bei Hetzner steht.

Wer mit wem reden darf

Die Kästen im Bild tragen Namen wie mobile oder lan-servers. Das sind Gruppen, und über sie regelt NetBird, wer mit wem reden darf. Ich komme mit vier aus:

Einsortieren muss ich neue Dienste nicht. Wenn eine neue VM zum ersten Mal eingerichtet wird, tritt sie mit einem Setup-Key bei, einem Einmal-Schlüssel, der sie automatisch in die richtige Gruppe steckt, und dazu in eine DNS-Gruppe, zu der wir gleich kommen.

Zwei Bewohner von lan-infra verdienen noch einen Satz. Das NetBird-Gateway ist ein Übergang, über den das Handy auch Geräte im Heimnetz erreicht, die selbst kein Peer sind. Unterwegs dient es außerdem als Exit-Node, also als Ausgang, über den mein ganzer Internetverkehr erst nach Hause und von dort weiter geht. Der Raspberry Pi, ein kleiner Computer im Scheckkartenformat, ist die Reserve dafür.

Ein Name, eine Adresse

Das Handy ist jetzt im privaten Netz. Mit paperless.home.example allein kann es aber noch nichts anfangen, denn Rechner finden sich über Adressen, nicht über Namen. Die Übersetzung übernimmt ein DNS-Server, das Telefonbuch des Netzes. Bei mir ist das AdGuard Home in der VM dns-01, ein DNS-Server, der nebenbei Werbung und Tracker herausfiltert.

Woher weiß das Handy, dass es AdGuard fragen soll? Das sagt ihm NetBird. Alle Peers in der DNS-Gruppe bekommen eine Regel, die im Kern lautet: Frag AdGuard. Als zweiter Eintrag steht dort eine Kopie von AdGuard auf dem Pi, damit Namen auch dann aufgelöst werden, wenn dns-01 gerade neu startet.

Was AdGuard dann antwortet, ist fast langweilig. Für meine Dienste gibt es genau einen Eintrag, eine Platzhalter-Regel, im Jargon Wildcard. Jeder Name, der auf .home.example endet, zeigt auf dieselbe NetBird-Adresse, nämlich die der VM proxy-01, um die es im nächsten Abschnitt geht. Ob ich nach Paperless, Nextcloud oder Immich frage, die Antwort ist immer dieselbe. Für einen neuen Dienst muss ich am Telefonbuch deshalb nichts ändern.

Eine Regel dazu habe ich mir allerdings hart erarbeitet.

Aus der Praxis: Vor dem Umzug hatte ich die Regel „Frag AdGuard“ an die Gruppe All verteilt, also an alle Peers. Sie traf auch Peers, die AdGuard gar nicht erreichen konnten. NetBird trägt in dem Fall nur seinen eigenen Resolver ein, ohne Rückfall, und der betroffene Rechner stand ohne Namensauflösung da. Seitdem gehört jeder Peer genau einer DNS-Gruppe an, und die AdGuard-Rechner selbst fragen einen öffentlichen DNS-Server.

Der Proxy

Alle Namen führen also zur selben Adresse. Dort steht der Reverse Proxy, kurz Proxy. Er arbeitet wie der Empfang in einem Bürohaus. Jeder Besucher meldet sich dort, der Empfang liest auf dem Zettel, zu wem er will, und bringt ihn hin. Genauso nimmt der Proxy jede Anfrage an, erkennt am Namen den Dienst und reicht sie an die richtige VM weiter. Bei mir ist das das Programm Nginx Proxy Manager in der VM proxy-01, und es ist der einzige Eingang.

Die VMs dahinter trägt der Proxy immer mit ihrer NetBird-Adresse ein, nie mit ihrem Namen. Das hat zwei Gründe. Der eine ist, dass dadurch auch das Stück vom Proxy zum Dienst durch einen WireGuard-Tunnel läuft; darauf komme ich beim Messen zurück. Der andere ist eine schlechte Erfahrung mit einem anderen Proxy. Dort hatten Namen als Ziel zu sporadischen Fehlerseiten mit der Nummer 502 geführt, weil der Proxy den Namen mal in eine unerreichbare IPv6-Adresse und mal gar nicht übersetzte.

Das Schloss im Browser

Zwischen Handy und Proxy spricht der Browser HTTPS, die verschlüsselte Sprache von Webseiten, die man am Schloss in der Adresszeile erkennt. Ohne Schloss würde mein Auftritt an der Servicetheke mit einer Warnmeldung beginnen.

Für das Schloss braucht der Proxy ein Zertifikat, eine Art Ausweis, der dem Browser beweist, dass er mit dem richtigen Server spricht. Diesen Ausweis stellt Let’s Encrypt aus, eine kostenlose Ausweisstelle fürs Web. Ich habe einen einzigen für alle Namen unter *.home.example, ein sogenanntes Wildcard-Zertifikat.

Bevor Let’s Encrypt einen Ausweis ausstellt, prüft es, ob mir die Domain wirklich gehört. Die übliche Prüfung klopft dazu von außen an meinen Server, und genau das geht hier nicht. Bei der zweiten Variante, der DNS-01-Prüfung, lege ich stattdessen einen Prüfeintrag im öffentlichen Telefonbuch meiner Domain an, das bei Hetzner liegt. Dafür reicht ein API-Token, ein Schlüssel, mit dem ein Programm dort Einträge ändern darf. Kein Server muss dafür erreichbar sein.

Damit sind alle Stationen beisammen. Das Bild zeigt den ganzen Weg aus dem Baumarkt als Abfolge. Oben stehen die Beteiligten, und die Pfeile folgen der Zeit von oben nach unten.

Zwei Türen

Bis zum Proxy kommt nur, wer ein Peer im privaten Netz ist. Das ist die erste Tür. Die zweite ist die Anmeldung beim Dienst selbst. Für Nextcloud und Immich übernimmt das Authentik in der VM auth-01. Authentik ist ein Single Sign-on, also eine zentrale Anmeldung, ähnlich wie „Mit Google anmelden“, nur bei mir zu Hause. Die Dienste fragen es über ein Standardverfahren namens OpenID Connect. Pro Dienst gibt es eine Gruppe, und nur deren Mitglieder dürfen sich anmelden.

Die Einrichtung klicke ich nicht in der Oberfläche zusammen. Das erledigt ein kleines Python-Skript über die Programmierschnittstelle von Authentik, und ein neuer Dienst ist damit nur ein Eintrag in einer Liste. Ganz glatt lief das nicht. Seit Authentik 2026.x gibt es ein Feld grant_types, das festlegt, auf welche Arten sich ein Dienst anmelden darf. Setzt das Skript es nicht, bleibt es leer, und jede Anmeldung scheitert mit einer nichtssagenden Meldung. Außerdem muss Authentik dem Adressbereich von NetBird als Proxy vertrauen. Sonst schreibt es in seine Absenderangabe für die Dienste, den Issuer, http statt https, und die Dienste lehnen sie ab.

Und im eigenen Heimnetz? Nachgemessen

Damit sind wir bei der zweiten Frage vom Anfang, wer mitlesen kann. Unterwegs ist das schnell beantwortet, zwischen Handy und Proxy liegt der WireGuard-Tunnel. Interessanter ist das Stück, das man gern vergisst, zwischen den Diensten zu Hause im Heimnetz, im Jargon LAN.

Weil der Proxy jeden Dienst über dessen NetBird-Adresse anspricht, läuft auch dieser Verkehr durch WireGuard-Tunnel, selbst wenn beide VMs auf demselben Rechner stehen. Einen Umweg kostet das nicht, denn zwei Peers im selben Netz finden sich direkt. NetBird zeigt das auf Nachfrage an (gekürzt):

paperless-01.peers.<netbird-domain>:
  Connection type: P2P
  ICE candidate (Local/Remote): host/host

P2P mit host/host heißt, dass die Daten direkt durchs Heimnetz gehen und nicht über den Umsteigebahnhof im Internet. Verschlüsselt sein sollten sie trotzdem. Behaupten lässt sich das leicht, also habe ich nachgemessen.

Daten reisen im Netz in kleinen Stücken, sogenannten Paketen, und auf jedem steht wie auf einem Briefumschlag, an welche Tür, also an welchen Port, es geht. Paperless nimmt Anfragen an Port 8000 an. Während der Proxy sechs Anfragen an Paperless schickte, habe ich auf pve1 an der Netzwerkleitung der Paperless-VM jedes Paket mitgeschrieben, einen sogenannten Mitschnitt. Gut 1.100 Pakete kamen in 14 Sekunden zusammen. Kein einziges trug Port 8000. Ich sah nur WireGuard-Pakete an Port 51820, also die verschlüsselten Tunnel.

Dass ich so etwas lieber messe als glaube, hat einen Grund. Einmal haben mir die Wegweiser in meinem Netz etwas anderes erzählt, als tatsächlich passierte.

Aus der Praxis: Im September war Paperless „manchmal nicht erreichbar“. Der Dienst lief durchgehend, die Routing-Tabellen, also die Wegweiser für Pakete, sahen bei jeder Prüfung richtig aus, und NetBird meldete nichts. Schuld war ein alter, fest eingetragener Weg auf der Fritz!Box in den Adressbereich von NetBird. Die Fritz!Box schickte ab und zu einen Hinweis für einzelne Ziele, im Jargon ICMP-Redirect, der sinngemäß sagt „nimm lieber diesen Weg“, und der Proxy folgte ihm. Für kurze Zeit ging dann genau eine Adresse am Tunnel vorbei. Weil sich der Proxy das in einem Zwischenspeicher merkte und nicht in der Tabelle, sah jede Prüfung sauber aus. Der alte Eintrag ist weg, und der Proxy ignoriert solche Hinweise jetzt.

Jeder Weg, einzeln

Der Mitschnitt deckt nur einen Weg ab. Für das ganze Bild habe ich jeden Weg aufgeschrieben, auf dem bei mir Daten unterwegs sind, und daneben, was sie schützt. Ein paar davon gehören zu späteren Teilen, etwa die Sicherungen bei Hetzner. Für jetzt zählt nur die Farbe. Grün heißt NetBird, blau heißt auf anderem Weg verschlüsselt, rot heißt unverschlüsselt.

Dieselben Wege noch einmal als Tabelle. TLS ist dabei dieselbe Verschlüsselung, die auch hinter dem Schloss im Browser steckt.

Die letzte Zeile ist die ehrliche Ausnahme. TrueNAS ist meine Dateiablage im Heimnetz, und NFS und SMB sind die Sprachen, in denen andere Geräte auf ihre Netzwerkordner zugreifen. TrueNAS ist noch kein NetBird-Peer. Der Eingangsordner, in den der Scanner für Paperless schreibt, die Ablage von Proxmox und die Sicherungen von Home Assistant hängen an seiner Adresse im Heimnetz, und wer dort mitschneidet, könnte gescannte Dokumente mitlesen. TrueNAS ins NetBird-Netz zu holen ist der nächste Schritt.

Zurück an der Servicetheke

Die Rechnung auf meinem Handy hat also einen gut bewachten Weg hinter sich. Den Tunnel hat der NetBird-Server nur vermittelt, das Telefonbuch antwortet für jeden Dienst gleich, und hinter dem Proxy mit seinem Ausweis geht es noch einmal durch einen Tunnel bis zur Paperless-VM. Unterwegs liest niemand mit, und zu Hause auch nicht, solange der Weg nicht über TrueNAS führt.

Was ich aus diesem Teil vor allem mitnehme, ist das Messen. „Alles verschlüsselt“ ist eine Behauptung, und ein Mitschnitt an der richtigen Stelle dauert eine Minute. Er bestätigt die Regel und zeigt auch die Ausnahme. Und wenn ein Fehler nur einzelne Ziele trifft und nur manchmal, schaue ich inzwischen zuerst in die Zwischenspeicher und erst dann in die Einstellungen.

Bleibt eine Frage, die mit Netzwerk gar nichts zu tun hat. Die Rechnung für die Waschmaschine war ja einmal ein Blatt Papier. Wie wird aus so einem Blatt ein Dokument, das ich im Baumarkt in einer Sekunde finde? Dem gehe ich in Teil 3 nach.