Homelab-Umbau Teil 11: Der Weg von aussen herein

Worum es geht Link zu Überschrift

Nach Teil 10 steht die Segmentierung. Jedes Gerät liegt in seinem Netz, und zwischen den Netzen gilt, was ich erlaubt habe. Was fehlt, ist der Weg von aussen herein — damit ich in fremdem WLAN nicht darauf angewiesen bin, dass der Betreiber weiss, was er tut.

WireGuard ist dafür die naheliegende Wahl: wenige Zeilen Konfiguration, ein UDP-Port, keine Zertifikatsverwaltung. Der interessante Teil ist nicht die Einrichtung, sondern die Frage davor.

Ein VPN-Client ist auch nur ein Gerät in einem Netz. In welchem?

Deshalb kommt das erst jetzt. Vor Teil 9 und 10 hätte ich darauf keine Antwort gehabt, ausser „im Hauptnetz, wie alles andere auch" — und genau das wollte ich loswerden.

Die Frage, an der ich hängen geblieben bin Link zu Überschrift

Drei Clients: mein Laptop, mein Handy, und ein Zugang für einen Familienangehörigen. Bei zweien war die Antwort schnell da — beide brauchen nur den Ausgang ins Internet, keinen Zugriff nach innen.

Beim Laptop bin ich hängen geblieben. Der gehört gefühlt in mein Trusted-VLAN, da liegt er zu Hause ja auch. Und trotzdem war mir unwohl dabei.

Der Grund, den ich erst beim Aufschreiben sauber formulieren konnte: Der Laptop im Wohnzimmer und der Laptop im Hotel-WLAN sind nicht dasselbe Gerät. Physisch schon, im Sinne der Vertrauensfrage nicht. Zwischen den beiden Zuständen liegen zwei Wochen in fremden Netzen, ein Flughafen und die Möglichkeit, dass er unterwegs abhandenkommt. Wenn der Tunnel dieselben Rechte hat wie das Kabel im Wohnzimmer, dann ist er die Abkürzung an allem vorbei, was in Teil 10 entstanden ist.

Dazu kommt ein technisches Argument: Ein VPN-Client bekommt vom Tunnel eine Adresse, aber keinen VLAN-Tag. Um ihn wirklich in ein bestehendes VLAN zu legen, bräuchte es Bridging. Über Regeln so zu tun als ob, ist möglich — dann pflegt man aber zwei Regelwerke, die mit Sicherheit auseinanderlaufen.

Also bekommt der Tunnel ein eigenes Netz, 10.0.60.0/24, bewusst ausserhalb der VLAN-Nummerierung, weil er kein VLAN auf dem Switch ist. Und die Rechte werden nicht pro Netz vergeben, sondern pro Tunnel-Adresse:

Das geht, weil die Tunnel-Adresse fest an einen Schlüssel gebunden ist. Anders als eine MAC lässt sie sich nicht einfach behaupten — und genau darauf muss man beim Einrichten achten, dazu gleich mehr.

Der Endpunkt: eine Adresse, die sich alle zwei Jahre ändert Link zu Überschrift

Mein Anschluss hat eine feste Adresse, aber nur semi-fest — alle ein bis zwei Jahre wechselt sie. Selten genug, dass man es vergisst, oft genug, dass alle Client-Profile irgendwann ins Leere zeigen.

Ich hatte dafür schon eine Lösung, und die war ein gutes Beispiel dafür, wie Bastellösungen altern. Ein Skript auf dem Router rief eine URL auf meinem Webserver auf, mit der eigenen Adresse als Parameter. Ein zweites Skript fischte sie per grep aus dem Apache-Log und schrieb sie in eine Textdatei.

Zwei Probleme damit, und nur eines davon war mir bewusst:

Es funktionierte seit dem Umbau gar nicht mehr. Das Skript las die Adresse von sfp-wan auf dem Access Point. Der Port ist seit dem Rückbau von Router zu Switch der Trunk zur Firewall und trägt keine öffentliche Adresse mehr. Es lief weiter, es lieferte nur nichts.

Und eine Textdatei hilft WireGuard nicht. Im Client steht ein Endpoint, und der wird beim Verbindungsaufbau aufgelöst. Was man braucht, ist ein A-Record, der sich ändert — dann lösen die Clients bei einem fehlgeschlagenen Handshake selbst neu auf. Eine Datei, in der die richtige Adresse steht, muss ein Mensch ablesen und in drei Profile übertragen.

Die Ablösung war unspektakulär: Das Plugin os-ddclient auf der Firewall, ein API-Token beim DNS-Anbieter, ein Subdomain-Record mit kurzer Gültigkeit. Die Firewall kennt ihre öffentliche Adresse selbst, also entfällt der ganze Umweg über Logfile und Fremdserver.

Die Lehre: Nicht die Bastellösung war das Problem, sondern dass sie still kaputtgegangen ist. Ein Skript, das nichts mehr findet und trotzdem mit Status 0 endet, meldet sich nie.

Ein Feld, zwei Bedeutungen Link zu Überschrift

Bevor es um Fehler geht, das eine Konzept, das man verstanden haben muss.

Der häufigste Stolperstein bei WireGuard, und er steht in beiden Konfigurationen unter demselben Namen.

Auf der Firewall ist AllowedIPs die Zuordnung von Schlüssel zu Adresse. Steht dort 10.0.60.4/32, akzeptiert WireGuard von diesem Schlüssel ausschliesslich Pakete mit genau dieser Absenderadresse. Trägt man dort grosszügig ein ganzes Netz ein, könnte sich ein Peer als ein anderer ausgeben — und alle Regeln, die auf einer einzelnen Tunnel-IP stehen, sind wertlos.

Im Client-Profil bedeutet dasselbe Feld etwas völlig anderes, nämlich welchen Verkehr der Client durch den Tunnel schickt. 0.0.0.0/0 heisst: alles. Das ist der Full-Tunnel, und den will ich hier, weil der ganze Zweck ist, dem fremden WLAN nicht trauen zu müssen.

Man kann beide Seiten korrekt konfigurieren, ohne den Unterschied zu kennen. Bis man anfängt, Regeln pro Client zu bauen — dann hängt deren Wirksamkeit an der Serverseite dieses Felds.

Was schiefging Link zu Überschrift

Vier Dinge, und drei davon hatten dasselbe Symptom.

Der Schalter, der zweimal existiert Link zu Überschrift

Instanz angelegt, drei Peers angelegt, Peers der Instanz zugewiesen, gespeichert, appliziert. Im Status: nichts. wg show ohne Ausgabe, das Interface existierte gar nicht.

Der Grund stand unten auf derselben Seite: ein globales Enable WireGuard, das unabhängig davon ist, ob die Instanz aktiviert ist. Zwei Häkchen mit demselben Namen auf zwei Ebenen, und das obere hatte ich gesetzt.

Das Interface, das keins ist Link zu Überschrift

Auch nach dem Aktivieren kann man keine Firewall-Regel bauen. Der Tunnel existiert zwar, aber nicht als Interface im Sinne der Firewall — dafür muss er unter Interfaces → Assignments zugewiesen werden. Erst danach gibt es einen Reiter unter Firewall → Rules.

Beim Zuweisen zwei Stolperfallen: Die IPv4-Konfiguration bleibt auf None, weil die Tunnel-Adresse von WireGuard selbst verwaltet wird — trägt man sie hier nochmal ein, hat man zwei Interfaces im selben Subnetz. Und Block private networks muss aus bleiben, denn der Tunnel trägt ausschliesslich private Adressen.

Der Schlüssel, den ich nicht nachgezogen habe Link zu Überschrift

Der interessanteste Fehler, weil er sich als Netzwerkproblem verkleidet hat.

Handy über Mobilfunk verbunden, DNS-Name löste korrekt auf, Port stimmte. Am Client: gesendet ein paar Kilobyte, empfangen null. Auf der Firewall bei allen drei Peers: null empfangen.

Der Mitschnitt am WAN zeigte die Pakete ankommen. Der Trefferzähler der WAN-Regel zählte. Und wg show blieb bei null.

Die Ursache: Die Public Keys der Clients hatte ich aus der alten Konfiguration übernommen — die stimmten. Den Public Key des Servers hatte ich nicht nachgezogen. Der wurde beim Anlegen der Instanz neu erzeugt, in den Client-Profilen stand noch der vom alten Router.

Das Handy verschlüsselte den Handshake also für einen Empfänger, den es nicht gibt. WireGuard konnte das Paket nicht entschlüsseln und hat es kommentarlos verworfen — kein Log, kein Zähler, keine Fehlermeldung.

Die Regel an der falschen Stelle Link zu Überschrift

Zum Schluss der Fehler aus Teil 10, in neuem Gewand. Über den Tunnel wollte ich auch fernsehen können; dafür gibt es bei mir einen kleinen Dienst, der den IPTV-Multicast in einen normalen HTTP-Stream übersetzt.

Die Regel dafür war angelegt und der Zugriff wurde trotzdem geblockt. Sie stand unter der Block-Regel gegen private Netze — und das Ziel ist eine private Adresse. Hochgeschoben, und es lief.

Immerhin: Gesehen habe ich es sofort, weil die Block-Regel loggt. Das ist der Haken, den ich in Teil 10 gesetzt habe und der sich hier zum ersten Mal ausgezahlt hat.

Der Merksatz Link zu Überschrift

WireGuard schweigt bei jedem Fehler gleich. Falscher Schlüssel, falscher Endpunkt, geblocktes Paket, Dienst nicht gestartet — das Symptom ist immer, dass nichts passiert. Es gibt kein „Verbindung abgelehnt" und keine Fehlermeldung im Log.

Das ist eine Design-Entscheidung des Protokolls, keine Nachlässigkeit: WireGuard antwortet grundsätzlich nicht auf Pakete, die es nicht zuordnen kann. Von aussen sieht der Port geschlossen aus, und ein Scanner erfährt nicht, dass dort etwas lauscht.

Für die Fehlersuche heisst das: Raten funktioniert nicht, weil alle Ursachen gleich aussehen. Man prüft von aussen nach innen und schaut, wo die Kette abreisst.

Vier Schritte, vier mögliche Ursachen. Bei mir riss die Kette zwischen 2 und 3 — die Firewall zählte Treffer, WireGuard nicht.

Genau diese Kombination war der Schlüsselfehler: Der Paketfilter sieht das Paket und lässt es durch, der Dienst kann es nicht entschlüsseln. Wer nur „es geht nicht" hat, würde an dieser Stelle vermutlich weiter an den Firewall-Regeln drehen.

Wo ich jetzt stehe Link zu Überschrift

Der Tunnel läuft, Handy getestet über Mobilfunk. Full-Tunnel, DNS über die eigene Firewall, IPTV funktioniert. Handy und der Zugang für den Angehörigen kommen ins Internet und an nichts Internes — dieselbe Vierer-Kette wie in Teil 10, nur mit einer Regel für einen einzelnen Host dazwischen.

Von aussen ist genau ein UDP-Port offen, und der antwortet nur auf Pakete mit gültiger Signatur.

Offen ist zweierlei:

Der Laptop. Er wird morgen eingerichtet. Die Regel für ihn steht momentan noch breit, aber mit Logging — dieselbe Methode wie beim Receiver in Teil 10: einmal alles machen, was man unterwegs typischerweise tut, dann aus dem Log die echten Ziele und Ports ablesen und eng fassen. Das ist ehrlicher, als jetzt zu raten, welche Ports die Verwaltungsoberflächen tatsächlich brauchen.

Der Notfallzugang bleibt aussen vor. Mein Access Point hat neben seiner regulären Adresse ein Recovery-Interface in einem eigenen Subnetz ohne Verbindung zum Rest — der Notausgang nach zwei Aussperrungen aus Teil 3. Über den Tunnel ist der nicht erreichbar, und das soll auch so bleiben. Heisst aber: Wenn ich mich aussperre, hilft mir das VPN nicht. Dafür braucht es weiterhin ein Kabel und Anwesenheit.

Und ein Randbefund fürs Protokoll: Meine IPTV-Senderliste enthält noch Adressen aus der Zeit vor dem Umbau. Über den Tunnel läuft jeder dieser Einträge in ein Timeout, bevor der Player den nächsten probiert. Aufräumen steht an.

Nächster Schritt Link zu Überschrift

Mit dem Tunnel ist die Netzarbeit fürs Erste zusammen. Was danach kommt, ist eine andere Ebene: Identität. Bisher hat jeder Dienst seine eigene Benutzerverwaltung, und das skaliert genauso schlecht wie ein flaches Netz.

Teil einer Serie über den Umbau meines Heimnetzes. Stand: September 2026. Fragen, Korrekturen und eigene Erfahrungen gerne in die Kommentare.