Homelab-Neuaufbau: Der Masterplan für ein sauberes Heimnetz
Wer die letzten Beiträge hier verfolgt hat – Cloudflare Tunnel und zuletzt Split-Horizon im Homelab – hat's vielleicht schon geahnt: Das waren keine zufälligen Bastelabende. Das waren Vorab-Tests.
Denn ich baue mein komplettes Heimnetz neu auf. Nicht „ein bisschen umstecken", sondern richtig: sauber, durchdacht, reproduzierbar. Weg von „historisch gewachsen" – hin zu einem Konzept, das ich in einem halben Jahr noch verstehe.
In diesem Artikel nehme ich dich mit durch den Plan: was ich vorhabe, warum ich mich für welche Lösung entschieden habe – und ganz ehrlich auch, wo ich selbst noch nicht weiter bin (Stichwort Firewall, dazu unten mehr).
Das Zielbild in einem Satz
Die Fritzbox macht nur noch das, was sie wirklich gut kann: Internet-Router, WLAN und VPN. Alles andere wandert auf dedizierte Maschinen:
- Netzwerk-Server – das Gehirn: DNS, DHCP, Ad-Filter, Reverse-Proxy und der Cloudflare-Tunnel.
- App-Server – hostet die eigentlichen Dienste (dieses Ghost hier und was sonst noch so läuft).
- NAS – Windows-Domänencontroller und Dateiserver in einem.
Drei klare Rollen statt „ein Gerät macht irgendwie alles". Das ist der ganze Trick.
Die Entscheidungen – und das Warum
Die Fritzbox wird entmachtet
Klingt hart, ist aber der Kern. Die FB ist ein solider Router, aber ein mittelmäßiger DNS- und DHCP-Server. Beides nehme ich ihr weg. Sie bleibt Gateway, WLAN-Access-Point und WireGuard-Endpunkt – Schluss. Je weniger sie macht, desto weniger kann sie mir kaputtmachen.
DNS + DHCP: alles in AdGuard
Statt DNS und DHCP auf zwei Systeme zu verteilen, macht AdGuard Home beides in einem Dienst – auf dem Netzwerk-Server. Ein Ort für alles: netzwerkweites Ad-Blocking, die Split-Horizon-Rewrites, die Weiterleitung an den Domänencontroller und die IP-Vergabe. Eine GUI, ein Backup, ein Kopf, in dem das Wissen liegt.
Der kritische Moment beim Umbau ist genau dieser Schwenk: Erst muss AdGuard als DNS getestet laufen, dann als DHCP – und erst dann wird der Fritzbox-DHCP abgeschaltet. Solange der noch an ist, gibt's einen Weg zurück. Diese Reihenfolge ist kein Detail, die ist überlebenswichtig.
Ein Name, zwei Wege: Split-Horizon (aber ohne Wildcard)
Der gleiche Name – z. B. dienst.s3nf-net.com – löst zuhause auf die interne IP auf und unterwegs über Cloudflare. Zuhause bleibt der Traffic im LAN (volle Geschwindigkeit), von außen kommt er sicher durch den Tunnel. Beides mit gültigem Zertifikat, ohne Warnungen.
Wichtig dabei: kein Wildcard-Rewrite, sonst verschluckt man sich die eigene E-Mail (mail., MX, SPF, DKIM …). Jeder Dienst bekommt seinen einzelnen Eintrag. Wie das genau funktioniert und warum, habe ich im Split-Horizon-Artikel ausführlich aufgeschrieben – das ist quasi das Herzstück dieses ganzen Plans.
Ein Reverse-Proxy für innen UND außen
Genau eine Stelle terminiert TLS und routet nach Hostname: der Nginx Proxy Manager auf dem Netzwerk-Server. Egal ob die Anfrage aus dem LAN kommt oder aus dem Cloudflare-Tunnel – sie landet am selben Proxy, mit demselben Wildcard-Zertifikat. Eine Konfiguration, ein Zertifikat, keine doppelte Pflege. Neuer Dienst? Ein Proxy-Host, fertig.
Fernzugriff: WireGuard bleibt auf der Fritzbox
Das VPN wandert bewusst nicht auf den Server, sondern bleibt am Gateway. Warum? Resilienz. Wenn die Server mal aus sind – Wartung, Stromausfall, kaputtgebastelt – komme ich per WireGuard trotzdem noch ins Netz, um zu reparieren. Ein VPN, das nur läuft, wenn der Rest läuft, ist im Ernstfall wertlos. Und der schöne Nebeneffekt: per VPN bin ich netzwerktechnisch zuhause – interne Namen, interne-only Dienste, Ad-Blocking inklusive.
Flaches Netz mit System
Ein flaches /16-Netz, logisch über das dritte Oktett gegliedert (Infrastruktur, Clients, Drucker, DHCP-Pool …). Das ist Konvention, keine Isolation – bewusst so. Echte, getrennte VLANs bräuchten Routing zwischen den Segmenten, und das kann die Fritzbox schlicht nicht. Also bleibt es flach, aber ordentlich sortiert. Das Schema ist vorwärtskompatibel: Wenn irgendwann eine richtige Firewall mit Routing kommt, wird aus jedem Block bei Bedarf ein echtes VLAN.
Windows-Domäne ohne Windows-Server
Auf dem NAS läuft der Synology Directory Server – ein Samba-basiertes Active Directory. Damit gibt's echten Domain-Join für die Windows-Rechner, zentrale Anmeldung und automatische Home-Laufwerke. Ganz ohne Windows-Server-Lizenz. Für ein Homelab genau die richtige Nummer – mit der ehrlichen Einschränkung, dass Gruppenrichtlinien nicht ganz so mächtig sind wie beim echten Microsoft-DC.
Die offene Baustelle: die Firewall
Und jetzt der ehrliche Teil. Alles oben ist entschieden und größtenteils schon getestet. Ein Puzzleteil fehlt aber noch – und da bin ich mir selbst noch nicht einig: die Firewall.
Aktuell ist die Fritzbox das Einzige, was zwischen meinem Netz und dem Internet steht. Für den Hausgebrauch okay, aber „okay" ist mir zu wenig. Meine Tendenz: eine pfSense möglichst früh in der Kette – zwischen Router und erstem Switch – damit alles, was Richtung Internet geht, wenigstens durch eine echte Sicherheits-Instanz läuft statt nur durch die FB.
Nur: die genaue Idee fehlt mir noch. Transparente Bridge oder geroutet? Wie spielt das mit dem bestehenden Gateway zusammen, ohne mir ein Double-NAT einzufangen? Wo genau ziehe ich die Grenze zwischen „FB macht Internet" und „pfSense macht Sicherheit"? Da denke ich noch drüber nach – und genau deshalb steht die Firewall in diesem Plan bewusst als offene Frage und nicht als fertige Antwort.
Wenn du sowas schon gebaut hast: Ich bin für Erfahrungen und Meinungen absolut offen. Immer her damit.
Fazit & Ausblick
Das ist der Plan. Die Vorab-Tests haben funktioniert, das Konzept steht – jetzt kommt der eigentliche Umbau, Phase für Phase: DNS/DHCP-Schwenk, Reverse-Proxy, Tunnel, die Dienste, die Domäne, das VPN. Und irgendwann eben die Firewall.
Ich nehme dich hier mit – die einzelnen Schritte werden nach und nach eigene Artikel. Aus „historisch gewachsen" wird endlich „durchdacht".
Plan steht. Jetzt wird gebaut.