by Da ich bereits mehrfach darauf angesprochen wurde und die Frage aufgetaucht ist, wie mein Netzwerk aussieht, wenn ich so unterschiedliche Tutorials veröffentliche, habe ich mich dazu entschieden, dieses Thema einmal aufzugreifen.
Dass mein Netzwerk nicht nur aus einem Internetrouter, ein bis zwei Computern und einer beliebigen Anzahl an Smartphones oder Tablets besteht, ist euch sicherlich schon aufgefallen.
Aber gehen wir das Ganze Schritt für Schritt durch. Ich werde diesen Beitrag zukünftig als Dokumentation nutzen, um selbst den Überblick zu behalten.
IP-Adressen und DNS-Namen teilweise verfälscht (ich muss ja nicht jedes Detail im Internet veröffentlichen)
Layer 1 bis 3
Zentral steht bei mir derzeit eine Fritzbox 6591 Cable, die sowohl mit dem Internet als auch mit dem Kabelanschluss verbunden ist (tatsächlich sind diese bei mir getrennt, da ich das Internet nicht (mehr) über den Kabel-TV-Anschluss bekomme).
Die Fritzbox bietet standardmäßig zwei interne Netzwerke an: das Standardnetzwerk mit der Adresse 192.168.178.0/24 und ein Gäste-LAN/WLAN mit der Adresse 192.168.189.0/24, das ich u.a. für IoT-Geräte nutze.
An anderen Standorten habe ich grundsätzlich OpenWRT-Router stehen, die entweder mit oder ohne SIM für Mobilfunk ausgestattet sind. So nutze ich für Reisen gerne den gl-inet Mudi, den ich dann beispielsweise mit dem Internetprovider des Hotels verbinde, sodass der eigene Router (Mudi) die von zu Hause bekannten WLAN-SSIDs (WLAN-Namen) ausstrahlt (eigener WLAN-Hotspot). So müssen alle meine mobilen Geräte nur zwei WLAN-Namen kennen: das Standard-WLAN und das IoT-WLAN – egal wo ich bin auf der Welt.
Des Weiteren habe ich den DHCP-Bereich auf der Fritzbox verkleinert (jetzt 192.168.30–192.168.178.199), da ich einen Bereich für statische IP-Adressen definieren wollte (für die diversen Serverdienste jetzt 192.168.178.2-29). Der Bereich ab 192.168.30.200 wird ja durch die Fritzbox für VPN-Endpunkte genutzt.
Das bringt mich auch gleich zum nächsten Punkt. Während ich früher IPSec mit IKEv1 genutzt habe, da die Fritzbox nichts anderes unterstützte, setze ich heutzutage voll und ganz auf Wireguard. Ich habe WireGuard an allen Standorten als Site-to-Site-VPN so konfiguriert, dass alle Standardgeräte (also nicht IoT) über ihre eigenen privaten IP-Adressen untereinander kommunizieren können – deshalb haben auch alle Standorte unterschiedliche private IP-Adressbereiche, was eine Grundvoraussetzung für IP-Routing bei Site-to-Site-VPN ist. So kann ich beispielsweise meinen Plex– oder Jellyfin-Server auch außerhalb von zu Hause über seine private IP-Adresse ansprechen und muss dessen Ports nicht über das Internet verfügbar machen. Das nutze ich beispielsweise, um das Kabel-TV, welches zu Hause an der Fritzbox anliegt, (für mich) überall verfügbar zu machen. Ich brauche also weder Waipu.tv noch Zattoo, um weltweit deutsches Fernsehen schauen zu können bzw. um TV-Aufnahmen zu planen oder abzuspielen.
Auch auf den mobilen Endgeräten habe ich einen WireGuard-Client installiert und konfiguriert – dann natürlich nicht als Site-to-Site-, sondern als Roadwarrior-VPN. Auch diese WireGuard-Tunnel sind 24/7 aktiv und ich bin permanent mit den Diensten zu Hause verbunden, ohne dass ich irgendwelche Ports Richtung Internet exponieren müsste.
Die einzigen beiden Ports, die die Fritzbox nach außen hin über Portweiterleitung verfügbar macht, sind HTTPS (443) und HTTP (80), wobei HTTP auf HTTPS umgeleitet wird.
Diese beiden Ports werden an den Reverse-Proxy (HAProxy) der Firewall weitergeleitet, der sich dann um die Authentifizierung, Berechtigungen und die passende Weiterleitung kümmert. Dazu war es notwendig, den Port, auf den die Fritzbox selbst hört (ebenfalls HTTPS), in der Konfiguration entsprechend anzupassen, sodass die WebGUI der Fritzbox jetzt auf einen anderen Port lauscht. Doch selbst diesen muss ich mir nicht merken, da ich aufgrund einer passenden internen DNS-Konfiguration mit der entsprechenden URL und dem Reverse Proxy automatisch umgeleitet werde.
Mit der passenden App (unter Android empfehle ich „WG Tunnel”) ist es auch möglich, auf dem mobilen Endgerät mehrere Wireguard-Verbindungen zu konfigurieren und dynamisch umzuschalten. Ich habe bereits erwähnt, dass ich den Roadwarrior-VPN 24/7 aktiviert habe. Dieser ist so konfiguriert, dass nur die IP-Adressen meiner lokalen Netzwerke (also die daheim und die drei bis vier externen Standorte) durch das VPN getunnelt werden. Alle anderen IP-Pakete werden direkt ins Internet geroutet (Stichwort Split-VPN), bis auf eine kleine Ausnahme: DNS-Anfragen werden bei aktiver WireGuard-Verbindung gemäß Konfiguration durch den Tunnel an meinen internen DNS-Server 192.168.178.2 zu Hause weitergeleitet. Bei Android und aktiver DNS-over-TLS-Einstellung in den Systemeinstellungen gehen diese systembedingt an meinen externen DNS-Server (in diesem Fall überstimmt das System die WireGuard-Konfiguration).
Sobald ich mich jedoch in einem nicht vertrauenswürdigen WLAN befinde – und das sind alle außer meinem Standard-WLAN – schaltet „WG Tunnel” automatisch auf den zweiten konfigurierten VPN-Tunnel. Alle IP-Pakete (ohne Ausnahme, da die Standardroute 0.0.0.0/0 gesetzt ist) werden dann durch den Tunnel geleitet und über die Fritzbox ins Internet geroutet. Der WLAN-Provider (Hotel-WLAN oder öffentlicher WLAN-Provider) sieht also ausschließlich verschlüsselten Datenverkehr, von der ersten DNS-Anfrage bis hin zum VoIP- oder HTTPS-Traffic.
Dank o2 und der im Mobilfunkvertrag enthaltenen Connect-Option verfüge ich über bis zu zehn SIM-/eSIM-Karten, die sich ein gemeinsames Datenvolumen teilen. Dies gibt mir unter anderem die Möglichkeit, alle Standorte als Redundanz auch über Mobilfunk anzubinden, falls der lokale Internetprovider einmal nicht verfügbar sein sollte.
WireGuard hat den charmanten Vorteil, dass auch bei wechselnden Internet-Gateways immer ein stabiler Tunnel gewährleistet ist.
DNS
Die Fritzbox unterstützt dynamisches DNS (DynDNS), aber ich nutze zusätzlich auch eine weitere Möglichkeit: DynDNS über duckdns.org. Das gibt mir die Möglichkeit, auf den internen Firewalls (derzeit OPNsense) über Let’s Encrypt eigene Zertifikate für die interne Nutzung im Homelab ausstellen zu lassen. DuckDNS ist ein kostenloser Dienst, der sich aber jederzeit über eine kleine Spende freut.
Darüber hinaus betreibe ich zwei DNS-Server: einen externen unter dns.kwellkorn.de auf einem VPS direkt im Internet und einen internen unter 192.168.178.2 – in beiden Fällen Adguard Home. Die DNS-Einstellungen innerhalb der Fritzbox habe ich so angepasst, dass als angefragter DNS-Server (wird auch als DHCP-Option verteilt) der interne DNS-Server angefragt wird. Dieser leitet die Anfragen nach passender Filterung (Werbung, Tracking, Malware, Gambling etc.) an den externen DNS-Server weiter – aber auch hier an den selbst betriebenen. Der externe Server hat grundsätzlich dieselben automatischen Filterregeln. Damit habe ich die Möglichkeit, beispielsweise bei Android in den Netzwerkeinstellungen einen DNS-over-TLS-DNS-Server einzutragen. Somit werden sämtliche DNS-Anfragen von Mobilfunkgeräten automatisch verschlüsselt durchgeführt und der jeweilige Internetprovider (Mobilfunk oder öffentliches WLAN) kann sie nicht mitsniffen. Der interne DNS-Server spart nicht nur Zeit beim Abfragen (durch Caching etc.), sondern ist auch notwendig, da interne DNS-Anfragen mit internen IP-Adressen beantwortet werden müssen. Es macht beispielsweise einen erheblichen Unterschied, ob ich mich im lokalen Netzwerk befinde und paperless.internally.duckdns.org auflöse – dann möchte ich als Antwort nicht die öffentliche IP-Adresse meiner Fritzbox, sondern die interne IP-Adresse erhalten. Somit vermeide ich, dass die IP-Pakete über die Fritzbox selbst geroutet werden, obwohl sie im lokalen Netz geswitcht werden könnten.
Die OpenWRT-Router an den Außenstandorten leiten DNS-Anfragen entweder grundsätzlich verschlüsselt an meinen selbst betriebenen externen DNS-Server per DNS-over-TLS weiter oder die neueren OpenWRT-Router mit ausreichender Performance haben Adguard Home bereits als Plugin vorinstalliert. In diesem Fall werden DNS-Anfragen direkt vor Ort gefiltert und es muss gar nicht erst der eigene externe DNS-Server angefragt werden. Letztendlich muss ja ohnehin irgendein Upstream-Server im Internet für DNS-Anfragen herhalten.
Du brauchst dir übrigens nicht die Mühe machen, meinen externen DNS-Server dns.kwellkorn.de bei dir als DNS-Server einzustellen. Du bekommst zwar DNS-Anfragen rudimentär beantwortet, aber in den Standard-Einstellungen gehe ich so restriktiv vor, dass du beispielsweise nicht einmal Instagram und Co. auflösen kannst. Ich erstelle für all meine Geräte entsprechende Clientregeln, um das volle Potenzial auszuschöpfen. Dieser Schritt war notwendig, da immer wieder versucht wurde, mittels DoS-Attacken auf dieselbe Adresse (z. B. pizzaseo.com) den Server anderweitig zu missbrauchen. Das wirst auch du schnell lernen, wenn du einen externen DNS-Server betreibst und die Logs regelmäßig kontrollierst.
IoT
Ich nutze an allen Standorten das Gäste-LAN/WLAN, um die IoT-Geräte ins Netzwerk zu bringen. Ich möchte derartige Geräte nicht in meinem Standard-Netzwerk haben. Leider kann man bei der Fritzbox im Gästemodus bei DHCP weder das Gateway noch den DNS-Server manuell ändern, sonst hätte ich die IoT-Geräte dort auch gerne hinter einer Firewall platziert (klar könnte ich einen eigenen DHCP-Server aufsetzen, aber da ist mir das zentrale Logging in der Fritzbox derzeit lieber). Dank ntopNG kann ich jedoch die entsprechende Schnittstelle im Gäste-Netzwerk dauerhaft überwachen und so nachvollziehen, mit welchen Servern die Geräte über welche Protokolle kommunizieren. Die OpenWRT-Router in den externen Netzwerken bieten da mehr Möglichkeiten. Dank der nProbe kann ich aber auch diese IoT-Geräte remote überwachen.
Monitoring
Da ich einen beruflichen Hintergrund im Netzwerk habe, liegt mir dieser Aspekt natürlich besonders am Herzen.
Das Netzwerk überwache ich auf der WAN-Seite mit ntopNG (das direkt an den Schnittstellen der Fritzbox snifft). Ich suche derzeit noch eine Möglichkeit, dasselbe auch mit SecurityOnion umzusetzen. LAN-seitig setze ich Suricata als IDS/IPS ein. Die Logfiles wandern grundsätzlich zu Wazuh, welches auch sämtliche virtuelle Maschinen und natürlich die Hosts und Clients überwacht.
Meine Hacking-Lab-Umgebung befindet sich in einem eigens abgesicherten Netzwerkbereich im Gästemodus hinter einer Firewall. Nur Kali hat ein Beinchen über die Firewall in dieses Netzwerk, sodass sich sämtliche Verbindungen in und aus diesem speziellen Netzwerkbereich heraus streng reglementieren lassen.
IT-Sicherheit
Ergänzend zum Monitoring möchte ich gleich das Thema IT-Sicherheit ansprechen. Was bringt es schließlich, ein System zu protokollieren, aber nicht auf Ereignisse zu reagieren oder gleich präventiv etwas zu tun?
Ich habe an diversen Stellen im Netzwerk Firewalls installiert, die die einzelnen Netzbereiche voneinander segmentieren. Dass auch die VMs mit konfigurierter Software-Firewall abgesichert sind, ist obligatorisch – Ansible macht das Ausrollen der Konfiguration unglaublich einfach. Dass meine Passwörter nicht trivial sind, muss ich nicht extra erwähnen (ich empfehle jedem einen entsprechenden Passwortmanager).
Daneben nutze ich wann immer möglich Passkeys bzw. eine 2-Faktor-Authentifizierung (2FA). SSH-Zugänge werden grundsätzlich mit Zertifikaten abgesichert und reine Passwort-bzw. direkte Root-Logins werden unterbunden. Fail2ban kümmert sich um den Rest.
Die Logs der exponierten Server lasse ich mir täglich per Logwatch zusenden. Alle anderen Logs gehen zum Wazuh-Server, der auch die VM-Hosts und -Guests scannt und die Ergebnisse visuell aufbereitet. Ein täglicher Blick darauf lohnt sich immer.
Hardware
Das ist bei mir gar nicht so spektakulär. Neben einer Fritzbox und diversen OpenWRT-Routern der Firma gl-inet.com besitze ich drei Intel-NUCs. Einer dient als Proxmox Virtual Environment (ich habe ihm noch ein paar RJ45-to-USB-Adapter gegönnt), einer als Proxmox-Backup-Server und einer als Desktop-PC – ich mag die kleinen Dinger. Alle drei stammen aus unterschiedlichen Generationen und verfügen durchweg über das Maximum an RAM. Damit sind sämtliche Performance-Fragen für mich gelöst – zumindest hatte ich noch nie wirklich Probleme damit.
Im Internet habe ich bei Netcup einen VPS angemietet. Für mich ist das eine absolute Preis-/Leistungsempfehlung für einen deutschen Provider mit Hosting in Deutschland und inzwischen auch Österreich.
Früher war mein Smart Home sehr Homematic-lastig. Inzwischen bin ich davon komplett weg und setze auf die Fritz!-Produkte, Nuki, Osram Lightify (Zigbee), Aqara und Google Home. Um die eine oder andere Zigbee-, DECT-, oder WLAN-Reichweite zu überbrücken nutze ich das Fritz!Gateway und Powerline- bzw. WLAN-Repeater (alles im Mesh)
Software
Ich bin ein großer Freund von Open-Source-Software und setze wann immer möglich auf derartige Produkte. Gerne unterstütze ich auch bei der Weiterentwicklung.
Während aus Bequemlichkeitsgründen die Desktop-PCs mit Windows 11 ausgestattet sind, laufen alle anderen Systeme mit Linux, wobei ich Debian ohne GUI bevorzuge.
Das kommt mir beim Einsatz von Proxmox natürlich sehr entgegen, da dieses ebenfalls auf Debian beruht.
DNS mache ich mit Adguard Home, wie ich bereits erwähnte. Das Monitoring erfolgt mit ntopNG, Suricata und Wazuh.
Für die Dokumentenverwaltung setze ich Paperless ein. Die Medienverwaltung – wobei sich das bei mir weitgehend auf Kabel-TV und die für mich weltweite Verfügbarkeit konzentriert – löse ich mit Plex oder Jellyfin (beide Lösungen haben ihre Vor- und Nachteile).
Home Assistant hat bei mir inzwischen Node-Red abgelöst, nachdem ich mich auch von Homematic (ohne IP) verabschiedet hatte.
Zur Umsetzung von Netzwerk-Labs setze ich auf GNS3 oder neu auf Cisco Modelling Labs 2. Für die Automatisierung setze ich voll und ganz auf Ansible – vom einfachen Update-/Upgrade-Prozess bis hin zur vollautomatischen Generierung virtueller Lab-Umgebungen für Schulungs- und Hacking-Zwecke.