Null offene Ports – und ich komme trotzdem von überall ran

Der Moment, in dem mir die Portfreigaben-Liste zu lang wurde

Nach der Sache mit Authentik aus der letzten Ausgabe stand zwar ein Login für alles — aber meine Fritzbox hatte immer noch eine Portfreigaben-Liste, die aussah wie eine Einladung. Nextcloud auf 443 weitergeleitet, ein zweiter Dienst auf einem Custom-Port, weil der erste schon belegt war, dazu ein SSH-Port, den ich „nur kurz” für einen Notfall geöffnet und dann vergessen hatte, wieder zu schließen. Jede offene Portfreigabe ist eine Wette: Ich wette, dass der Dienst dahinter immer aktuell gepatcht ist, dass es keine Zero-Day-Lücke gibt, und dass ich nie einen Tippfehler in der Firewall-Regel mache. Drei Wetten, die ich nicht mehr eingehen wollte. Die Konsequenz: Portfreigaben komplett raus, und stattdessen ein einziger Weg nach drinnen — verschlüsselt, und zwar über WireGuard.

Was ich gebaut habe

Die Grundidee ist simpel und deshalb auch die Stärke: Der Router hat nach außen genau einen einzigen offenen Port — UDP für WireGuard, sonst nichts. Kein Port für Nextcloud, keiner für den Reverse Proxy, keiner für irgendeinen Dienst. Wer auf mein Homelab zugreifen will, baut zuerst einen WireGuard-Tunnel zum Router auf und ist danach — netzwerktechnisch — im selben Netz wie ein Gerät, das zu Hause am Router hängt. Der Reverse Proxy aus Ausgabe 1 (samt Authentik davor) ist danach ganz normal über die interne Adresse erreichbar, aber eben nur über den Tunnel, nie direkt aus dem Internet.

Jedes Gerät — Laptop, Handy, das Tablet meiner Partnerin — bekommt ein eigenes Schlüsselpaar und einen eigenen Eintrag in der WireGuard-Konfiguration des Routers, keine geteilten Zugangsdaten. Fällt ein Gerät weg (verloren, verkauft), lösche ich genau diesen einen Eintrag, der Rest bleibt unberührt. Das ist derselbe Gedanke wie bei Authentik: nicht ein gemeinsames Geheimnis für alle, sondern ein individueller Schlüssel pro Zugang, der sich einzeln entziehen lässt.

Was schiefging (zwei echte Fehler)

Fehler 1: Ich hatte aus Versehen einen Full-Tunnel gebaut — und mein Handy-Internet ging kaputt. Beim ersten Einrichten der Client-Config auf dem Handy habe ich die AllowedIPs einfach auf 0.0.0.0/0 gesetzt, weil das in der ersten Anleitung, die ich gefunden hatte, so stand. Das bedeutet: nicht nur der Traffic zu meinem Homelab, sondern jeglicher Internet-Traffic des Handys lief ab sofort durch den Tunnel zu meinem Router zu Hause — und von dort erst wieder raus ins Internet. Unterwegs, auf mobilen Daten, war das Ergebnis: spürbar langsameres Surfen, weil jede Anfrage einen Umweg über meine Wohnung machte, und ein Akku, der doppelt so schnell leer war, weil der Tunnel dauerhaft aktiv blieb, auch für Dinge, die mit dem Homelab nichts zu tun hatten. Ich habe zwei Tage gebraucht, um zu merken, dass „das Handy-Internet ist neuerdings lahm” und „ich habe gestern WireGuard eingerichtet” derselbe Vorfall waren. Learning: AllowedIPs ist die Stellschraube zwischen Split-Tunnel (nur der Traffic zum Homelab-Netz läuft durch den Tunnel) und Full-Tunnel (wirklich alles). Für den täglichen Zugriff aufs Homelab will man fast immer Split-Tunnel — nur das eigene Subnetz eintragen, nicht 0.0.0.0/0.

Fehler 2: Der Tunnel zeigte „verbunden” an — und trotzdem kam kein einziges Datenpaket durch. Unterwegs im Mobilfunknetz (hinter dem Carrier-NAT, das die meisten deutschen Mobilfunkanbieter nutzen) baute WireGuard den Handshake zwar sauber auf, aber nach ein paar Minuten Inaktivität war die Verbindung nach außen effektiv tot — die App zeigte weiterhin „aktiv”, aber kein Ping, kein Seitenaufruf kam mehr durch. Kein Fehler, keine Meldung, einfach Stille. Ich habe erst gedacht, der Router hätte ein Problem, dann den DNS-Server verdächtigt, bis ich auf ein Detail gestoßen bin, das in den ersten Anleitungen, die ich gelesen hatte, fast nie erwähnt wird: Mobilfunk-NAT vergisst offene Verbindungen viel schneller als ein normaler Heimrouter, und WireGuard schickt ohne Zusatzeinstellung von sich aus keine Pakete, um die Verbindung „warmzuhalten”, wenn gerade nichts zu übertragen ist. Learning: PersistentKeepalive auf einen niedrigen Wert (üblich: 25 Sekunden) setzen, wenn der Client hinter NAT sitzt — vor allem bei Mobilfunk. Das schickt in Ruhephasen ein winziges Paket, damit die NAT-Zuordnung offenbleibt und der Tunnel wirklich durchgehend erreichbar ist, nicht nur „laut Anzeige verbunden”.

Schritt-für-Schritt-Essenz

So sieht das Setup heute aus, ohne die zwei Abende Fehlersuche von oben:

Take-away & Teaser

Der eigentliche Unterschied zu vorher ist nicht „schneller” oder „bequemer” — er ist unsichtbar, und das ist der Punkt. Nach außen zeigt mein Homelab heute keinen einzigen Dienst-Port mehr, nur einen einzigen verschlüsselten Tunnel-Endpunkt. Ein Portscan von außen findet nichts, an dem er sich versuchen könnte, außer WireGuard selbst — und das spricht nur mit Geräten, die den richtigen Schlüssel haben.

Nächste Woche geht es um den Dienst, der mich am meisten Zeit gekostet hat, gemessen an dem, was auf der Verpackung stand: Nextcloud statt Fremd-Cloud. Was der Umstieg wirklich kostet — nicht in Euro, sondern in den Abenden, die niemand vorher erwähnt.

Wenn du gerade selbst an offenen Ports sitzt, die dir keine Ruhe lassen: Antworte einfach auf diese Mail — ich lese mit.

Bis Dienstag,

Määäx · Souveränes Homelab