Small Office Architektur

Hinweis: Dieser Artikel ist auch im neuen Präsentationsmodus verfügbar!

In den meisten Fällen dreht es sich hier auf diesem Blog um Enterprise Architektur. Vor kurzem habe ich darüber hinaus die Unterschiede zwischen Small Office / Home Office, Small Medium Business und Enterprise Architektur aufgezeigt. Mit diesem Artikel möchte ich noch einen Schritt weiter gehen und eine konkrete Small Office Architektur aufzeigen. Die Motivation kommt aus der Frage, die mir wiederkehrend gestellt wurde: Wie sieht es bei dir zu Hause aus?

Ich sage gleich vorweg, dass diese Architektur für ein Einfamilienhaus ein wenig zu komplex ist. Ich benutze nicht nur Home-User-Technologie, sondern auch Technologien und Prinzipien, wie sie in Small Offices zum Einsatz kommen. Diese Architektur ist also keinesfalls eine Blaupause für jedwedes Heimnetzwerk, kann dagegen schon eine realistische Vorlage für ein kleines Büro sein. Wie bei jeder IT-Architektur gilt: Es kommt auf die Anforderungen an.

Netzwerkarchitektur

Bei der Netzwerkarchitektur nutze ich ein physisches Netzwerk, das hausintern auf einer Cat.7-Verkabelung basiert. Diese Verkabelung fahre ich aktuell mit 1 GBit/sec. Die Kabel könnten mehr leisten, allerdings benötige ich nicht mehr als 1 GBit/sec und daher sind alle meine Router und Switches auf diese Geschwindigkeit ausgelegt. “Über” dem physischen Netzwerk liegt eine virtuelle Netzwerkstruktur auf Basis von VLANs, die das physische Netzwerk segmentiert. Eine solche Struktur ist für einen Privathaushalt eher ungewöhnlich. Kleine Büros haben das schon vereinzelt und spätestens in einer SMB-IT ist diese Art der Netzwerksegmentierung Pflicht.

Physisches Netzwerk

Mein physisches Netzwerk ist wie ein Baum mit 2 Wurzeln aufgebaut. Wie bei jedem guten Baum in der Informatik sind die Wurzeln dabei oben. Das steuernde Zentrum ist ein  UniFi Cloud Gateway Ultra. Dieser stellt die beiden WAN-Verbindungen her und spannt die VLAN-Struktur auf.

WAN-Verbindungen

Ich nutze parallel 2 WAN-Verbindungen: einen Glasfaseranschluss und einen DSL-Anschluss. Den DSL-Anschluss (Telekom-Backbone, resellt über 1&1) habe ich schon sehr lange und er funktioniert ziemlich stabil. Der Glasfaseranschluss (Deutsche Glasfaser, zuerst direkt, heute ebenfalls resellt über 1&1) ist dagegen eine ziemliche Katastrophe. Wenn er funktioniert, dann ist er schnell, aber er ist leider nicht besonders zuverlässig. Am Anfang hatte er so oft Ausfälle, dass er realistisch nicht benutzbar war. Mit der Zeit wurde es etwas besser, aber er fällt immer noch gelegentlich aus. Da mir eine stabile Internetverbindung jedoch sehr wichtig ist, nutze ich die beschriebene Dual-WAN-Architektur mit DSL-Fallback. Sobald die Glasfaser ausfällt, springt die DSL-Leitung ein. Normalerweise merkt man davon im Netzwerk nichts.

Das physische Netzwerk

Router und Gateways

Der UniFi Cloud Gateway könnte die Verbindung zum DSL- und Glasfaseranschluss auch ohne die beiden vorgeschalteten FritzBoxen herstellen. Für dieses Szenario hatte ich am Glasfaseranschluss früher ein Modem der Deutschen Glasfaser und am DSL-Anschluss ein Draytek-Modem. Letztendlich habe ich mich dagegen entschieden und die beiden auf dem Bild eingezeichneten FritzBoxen als Router vorgeschaltet. Das hatte mehrere Gründe:

• Die FritzBoxen sind meine DECT-Basisstationen und stellen die Telefonie im Haus sicher.
• Sowohl der DSL- als auch der Glasfaseranschluss von 1&1 machen alle 24 Stunden eine Zwangstrennung. Damit kann der UniFi Cloud Gateway nicht so richtig gut umgehen. Es geht zwar, aber das ist Gebastel. Die FritzBoxen dagegen können das nativ sehr elegant.
• Die FritzBoxen sind beide in der Lage, den Internetzugang autark herzustellen und bilden damit nochmals einen Fallback, falls das UniFi-Netzwerk ausfallen sollte.

Notfall-Netzwerke

Switches

Direkt am Cloud Gateway angeschlossen, bilden meine beiden Core-Switches (auch UniFi) den Backbone meines Netzwerks. An zwei Stellen im Haus befinden sich besonders viele Netzwerkgeräte: im Keller, wo das primäre NAS, die meisten Netzwerkgeräte und die IoT-Gateways stehen. Und im Dachgeschoss, wo sich mein Büro mit den meisten Rechnern, dem sekundären NAS, dem Drucker und dem Scanner befindet. Aufgrund dieser Gegebenheiten sind genau dort die beiden Core-Switches lokalisiert, die den Rest des Netzwerks weiter aufspannen. Neben den kabelgebundenen Geräten sind an den Switches je 2 UniFi-Access-Points angeschlossen, die per PoE gespeist werden und das ganze Haus zuverlässig mit WLAN versorgen. Auch diese Architektur auf Basis von Access-Points wird normalerweise in Unternehmen eingesetzt. Privathaushalte setzen meistens auf einfache “WLAN-Verstärker”. Verkabelte, gut positionierte Access-Points sind jedoch bei Weitem die bessere Technologie. In Zahlen gesprochen: Die Access-Points beherrschen Wifi 7 und das Haus ist so ausgeleuchtet, dass überall mindestens 300 MBit/sec zur Verfügung stehen. Diese 300 MBit/sec beziehen sich dabei auf die “dunklen Ecken”. Ich fahre die Access-Points mit reduzierter Leistung und komme so im Schnitt auf ungefähr 1 Gbit/sec an den meisten Stellen im Haus. Die Geräte könnten noch mehr leisten und könnten sogar eine 2,5 GBit/sec LAN-Anbindung nutzen. Aber wie ich oben geschrieben habe, habe ich mich auf 1 GBit/sec als Standardgeschwindigkeit im Netzwerk festgelegt. Also ist es nicht nötig, noch mehr aus den Geräten rauszuholen.

Virtuelle Netzwerkstruktur

Über der physischen Netzwerkstruktur liegt eine virtuelle Struktur auf Basis von VLANs (Virtual Local Area Network). Diese Technologie segmentiert ein physisches Netzwerk in unterschiedliche logische Netzwerke, sodass man ein einziges physisches Netzwerk so aufbauen kann, dass die Geräte in den unterschiedlichen logischen Netzwerken voneinander isoliert sind. Die Technologie bringt mehr Sicherheit in ein Netzwerk und macht es zugleich leichter, größere Netzwerke zu verwalten. Für ein Heimnetzwerk ist es jedoch eher ungewöhnlich.

Die virtuelle Netzwerkstruktur

VLANs

Ich habe mein Netzwerk in folgende 5 logische VLANs unterteilt:

• Server-Netzwerk: Hier stehen alle netzwerkweiten Server sowie die Drucker und Scanner. Das Netzwerk ist von den beiden Client-Netzwerken aus erreichbar, aber sonst von nirgendwoher.
• Geschütztes Client-Netzwerk: In diesem Netzwerk sind die meisten Clients in Form von Laptops, iPads oder iPhones. Das Netzwerk ist mit einer Malware-Protection und einem Adblocker geschützt. Es kann auf das Server-Netzwerk und ins Internet zugreifen.
• Ungeschütztes Client-Netzwerk: Gelegentlich machen die Malware-Protection oder der Adblocker Probleme beim Zugriff auf einzelne Websites. Sollte das passieren, dann kann ich einen Client jederzeit in das ungeschützte Client-Netzwerk umbuchen. Das ist dasselbe wie das geschützte, nur ohne Malware-Protection und Adblocker.
• IoT-Netzwerk: IoT-Geräte machen oft Dinge, die ich nicht kontrollieren kann. Daher sind alle meine IoT-Geräte isoliert voneinander im IoT-Netzwerk. Dieses Netzwerk hat keinen Zugriff auf ein anderes VLAN. Es darf lediglich bedingt ins Internet senden. Bedingt deswegen, weil ich hier diverse Filter vorgeschaltet habe, damit nicht alles überall hin posaunt wird.
• Gäste-Netzwerk: Das Gäste-Netzwerk ist ebenfalls isoliert von den anderen Netzwerken. Es macht nichts anderes, als Gastgeräten einen einfachen Internetzugang zu ermöglichen.

WLANs

Die Access-Points im Haus bauen 3 verschiedene WLANs auf, mit denen sich meine Geräte verbinden können:

• Client-WLAN: Im Client-WLAN befinden sich, wie der Name schon sagt, alle Client-Geräte (Notebooks, iPhones, iPads, AppleTVs, FireTV-Sticks etc.). Normalerweise verbindet sich das Client-WLAN direkt mit dem geschützten Client-Netzwerk. Ich kann allerdings auf Geräteebene einen einzelnen Client in das ungeschützte VLAN umbuchen.
• IoT-WLAN: Hiermit verbinden sich alle IoT-Geräte, die WLAN unterstützen, wie Überwachungskameras, smarte Steckdosen, Sensoren etc.
• Gäste-WLAN: Der Eingangskanal ins Gäste-Netzwerk. Wie der Name schon sagt, dafür gedacht, Gästen einen Internetzugang bereitzustellen.

Netzwerktunnel

Mein Netzwerk ist durch 2 Tunnel von außen erreichbar. Einerseits, damit ich selbst an meine internen Daten komme, wenn ich unterwegs bin. Andererseits, weil ich Anwendungen hoste, die ich im Internet erreichbar machen möchte.

Netzwerk-Tunnel

Interne Erreichbarkeit: WireGuard

Für den ersten Fall - die externe Erreichbarkeit des internen Netzwerks - besteht ein WireGuard-Tunnel, der durch die FritzBox 7350 und den DSL-Anschluss geht und im Cloud Gateway terminiert. Die FritzBox verbindet sich dafür mit einer DynDNS-Adresse, mit der sich wiederum die VPN-Clients auf unseren Client-Geräten verbinden (rechte Seite, grauer Pfeil im Bild).

Bereitstellung von Anwendungen: Cloudflare Tunnel

Der zweite Fall - Bereitstellung von Anwendungen im Internet - wird durch eine vom Kernnetzwerk physisch getrennte demilitarisierte Zone (DMZ) realisiert. Konkret in Form eines kleinen Cloud-Servers, der an der FritzBox 5530 Fiber hängt und sich durch den Glasfaseranschluss nach draußen verbindet. Da der Glasfaseranschluss lediglich eine private IP-Adresse vergibt und Carrier-Grade NAT (CG-NAT) durchführt, nutze ich zur Herstellung der Konnektivität einen Cloudflare-Tunnel. Dieser Tunnel funktioniert wirklich zuverlässig - sofern der Glasfaseranschluss es zulässt. Durch die getrennten Adressbereiche ist der Cloud-Server für das Cloud Gateway draußen und somit stellt dieser, selbst wenn er kompromittiert sein sollte, keine Gefahr für das interne Netzwerk dar.

Serverarchitektur und Backups

In meinem Netzwerk laufen 4 Server mit unterschiedlichen Zwecken:

• Der bereits erwähnte Cloud-Server in der DMZ. Das ist technisch ein ASUS-Barebone mit einer Intel-N100-CPU und 32 GByte RAM. Dort ist Proxmox installiert, auf dem die virtuellen Server laufen, die dann die Anwendungen bereitstellen, die im Netz erreichbar sein sollen. Der Server läuft in keinem meiner VLANs, sondern physisch abgekapselt von meinem Kernnetzwerk in einer DMZ. Da ich abgesehen von den verschlüsselten Backups (siehe unten) keine externen Cloud-Anbieter nutze, stellt dieser Server meine persönliche Cloud bereit. Wie genau diese private, souveräne Cloud aufgebaut ist, beschreibe ich bei Gelegenheit in einem eigenen Artikel.
• Innerhalb des Netzwerks ist der wichtigste Server mein primäres NAS. Früher habe ich dafür gerne Synology-Systeme eingesetzt. Aber seit Synology auf die Idee kam, nur noch eigene Platten und SSDs in ihren Systemen zuzulassen, sind sie für mich raus. Mein primäres NAS ist daher aktuell ein  UGreen DXP2800 mit 16 GByte RAM. Es ist mit einer 4 TByte SSD ausgestattet, die der primäre Ablageort für alle meine Daten ist. Diese SSD beherbergt alle meine Anwendungen, die per Docker verwaltet werden. Weiterhin sind in dem NAS 2 Festplatten als RAID-1 installiert, auf die die Daten der SSD periodisch und versioniert gesichert werden.
• Das sekundäre NAS ist ebenfalls ein UGreen DXP2800. Es ist allerdings nur mit 8 GByte RAM, einer kleinen SSD und 2 Platten in JBOD-Konfiguration ausgestattet. Dort laufen keine Anwendungen, es ist lediglich das externe Backup-Ziel für das primäre NAS. Sollte das primäre NAS ausfallen, könnte das sekundäre NAS einspringen und das primäre NAS vorübergehend ersetzen.
• Als Letztes läuft noch ein kleiner Raspberry Pi 4 mit 8 GByte RAM als Server im Netzwerk, der das Zuhause für meine Home-Assistant-Installation ist. Theoretisch könnte ich Home Assistant auf dem primären NAS laufen lassen, aber ich finde es gut, die Heimautomatisierung getrennt zu halten. So kann ich im Urlaub die NAS-Systeme runterfahren und mein Haus dennoch weiter über den Raspi steuern und überwachen.

Backups

Wie bereits erwähnt, sichert das primäre NAS seine Daten von der SSD auf die internen HDDs und dann auf das sekundäre NAS. Damit habe ich bereits insgesamt 3 Kopien meiner Daten. Allerdings liegt damit noch keine Kopie außer Haus.

Struktur der Backups

Um eine weitere Kopie meiner Daten außer Haus zu sichern, nutze ich eine  Hetzner Storage Box. Dort verwende ich 2 Subaccounts:

• Einen Subaccount für sich häufig ändernde Daten. Diese Daten werden per  Borg verschlüsselt, versioniert und gesichert.
• Einen Subaccount für Daten, die meistens nur ergänzt werden, sich aber selten ändern. Zu diesem Zweck habe ich ein kleines Programm in Go geschrieben, den  Autopacker. Dieser arbeitet sich durch eine Verzeichnisstruktur und verschlüsselt und komprimiert mithilfe von 7-Zip die dortigen Daten. Anschließend werden sie per rsync auf die Storage Box geschrieben.

Die Backup-Läufe erfolgen täglich, sodass ich im Notfall maximal einen Tag an neuen Daten verliere. Durch die mehrstufigen Mechanismen können einzelne Komponenten oder ganze Server ausfallen, ohne dass ich Daten verliere. Selbst ein lokal begrenzter Meteoriteneinschlag auf mein Hausdach wäre - aus Sicht der Backup-Strategie ;-) - verkraftbar.

Anwendungsarchitektur

Die Anwendungslandschaft ist auf meinem primären NAS implementiert und läuft überwiegend dort. Zu diesem Zweck habe ich das UGreen DXP2800 von 8 GByte auf 16 GByte RAM erweitert und eine 4 TByte NVMe SSD eingebaut, auf der die Anwendungen laufen und ihre Daten abgelegt werden.

Ein Teil der Anwendungen läuft direkt auf Betriebssystemebene. Das Betriebssystem ist aktuell UGOS - das native Betriebssystem des NAS. Der andere Teil läuft in der Docker-Umgebung auf dem UGOS. Das Betriebssystem spielt für meine Anwendungen keine große Rolle, solange es ein Linux-Derivat ist, SSH-Zugang bietet und Docker ausführen kann.

Ich unterscheide zwischen den Anwendungen zur Systemverwaltung, die sich um die Dienstbereitstellung, das Logging oder Backups kümmern, und Anwendungen für Endnutzer. Der Endnutzer sieht nur die für ihn bereitgestellten Anwendungen - die Systemverwaltung arbeitet still und leise im Hintergrund.

Meine Systemlandschaft auf Anwendungsebene

Anwendungen zur Systemverwaltung

Docker

Die meisten meiner Anwendungen laufen in der Docker-Umgebung. Dafür nutze ich weitgehend Docker Compose zusammen mit ein paar Cronjobs, die die Container aktuell halten. Ich habe mit Tools wie Watchtower und WhatsUpDocker experimentiert, war damit aber nicht zufrieden. Ich hatte noch kein Verwaltungsproblem, das ich nicht mit einem Shellskript hätte lösen können. Also wozu sich mehr Komplexität ans Bein binden? Als einzigen Luxus erlaube ich mir eine Portainer-Instanz, weil die gelegentlich nützlich ist, um nachzusehen, ob in der Docker-Umgebung noch alles in Ordnung ist.

Basis für Webanwendungen

Für den Betrieb der Webanwendungen in den Docker-Containern war es mir wichtig, dass die Anwendungen eine vernünftige URL haben und der Netzwerkverkehr verschlüsselt ist. Zu diesem Zweck habe ich einen nginx-Server als Reverse Proxy laufen, der die Domain-Namen auflöst und an die Anwendungen verteilt. Die Namensauflösung (DNS) selbst findet in meinem zentralen Cloud Gateway statt. Der nginx macht dann wieder die TLS-Terminierung. Hierfür habe ich mir auf Basis von OpenSSL eine kleine CA gebastelt und das Root-Zertifikat an alle meine Clients verteilt. Durch diesen Mechanismus erreiche ich beispielsweise die Startseite meines Intranets über die URL https://home.lan - verschlüsselt und ohne Zertifikatsfehler!

Logging und Backups

Irgendwann hatte ich den Punkt erreicht, an dem ich es leid war, mir die Logging-Daten meiner Skripte in vielen Dateien zusammenzusuchen. Ich habe dann angefangen, mit Enterprise-Logging-Lösungen zu experimentieren (Grafana und Loki). Das war für meine Zwecke massiver Overkill. Also habe ich mir kurzerhand ein paar kleinere Tools für Logging und Monitoring geschrieben - ich nenne sie HoLa Log für HomeLab Logging. Wer sich die Tools genauer ansehen möchte, kann dies bei  Codeberg tun.

Für meine Backups verwende ich 3 verschiedene Mechanismen:

• rsync, wenn irgendwas nur von A nach B kopiert werden muss
•  Borg für versionierte und verschlüsselte Backups
•  Autopacker für archivierte und verschlüsselte Daten

rsync ist ein Standard-Tool in jeder Linux-Umgebung.  Borg ist ein robustes und ausgereiftes Open-Source-Tool für verschlüsselte und versionierte Backups. Und den Autopacker habe ich selbst geschrieben. Er ist im Großen und Ganzen ein Directory-Crawler und  7-Zip-Frontend. Er arbeitet sich durch einen angegebenen Verzeichnisbaum und packt die definierten Unterverzeichnisse in ein verschlüsseltes 7-Zip-Archiv. Das ist besonders nützlich für Verzeichnisbäume, die sich nicht wesentlich ändern, sondern bei denen lediglich Daten hinzugefügt werden, wie zum Beispiel ein Foto-Archiv. Das Tool und sein Quellcode liegen ebenfalls bei  Codeberg.

Anwendungen für Endnutzer

Homepage

Homepage als Intranet-Startseite

 Homepage ist ein kleines Dashboard, das ich als Startseite für meine Intranet-Anwendungen nutze. Neben einfachen Bookmarks kann es den Status von Docker-Anwendungen auf demselben Host anzeigen. Es ist im Intranet über die URL https://home.lan auf jedem Endgerät als Startseite eingestellt.

Samba

Für die klassische Dateiablage im Netzwerk nutze ich nach wie vor Samba. Auch wenn die Samba-Implementierung auf macOS mittlerweile eine Katastrophe ist, bildet das Protokoll doch das Rückgrat meiner Dateiablage.

OpenCloud

Mit Cloudsystemen zum Selbsthosten habe ich in den vergangenen Jahren viel experimentiert. Angefangen mit OwnCloud und NextCloud über Seafile und heute  OpenCloud. NextCloud habe ich nie produktiv genutzt, weil es sich für mich immer zu langsam und zu fehleranfällig angefühlt hat - zusätzlich dazu, dass es heute viel zu aufgebläht wirkt und tausend Sachen kann, die ich nicht benötige. Seafile ist schnell und zuverlässig, das Deployment war viele Jahre aber dermaßen umständlich, dass es mir wirklich keinen Spaß gemacht hat. Syncthing finde ich vom Prinzip her interessant. Allerdings es hat mir im alltäglichen Gebrauch zu oft Inkonsistenzen bei den synchronisierten Dateien produziert. Daher habe ich lange Synology Drive verwendet. Solange, bis ich von Synology als NAS-Plattform weggegangen bin. Die UGreen-Version von Sync kommt mir bisher noch nicht zuverlässig genug für einen reibungslosen Alltagsbetrieb vor.

Daher setze ich seit gut einem Jahr OpenCloud ein. Das fühlt sich ziemlich robust an und das Deployment per Docker ist zwar kompliziert, aber wenn man einmal eine stabile Konfiguration hat, dann läuft sie. Fehler hat das Ding noch nicht erzeugt und im letzten Jahr gab es nur ein Breaking-Update. Das war zwar ärgerlich und hat ein wenig Zeit gekostet, aber es war verkraftbar. Ich schätze an dem System unter anderem, dass es sehr leicht zu sichern ist: Die Daten liegen als simple Dateien in einem Verzeichnis auf dem Server. Von dort kopiere ich sie regelmäßig weg und habe damit die Backups erledigt.

In OpenCloud liegen vor allem unsere Arbeitsdateien und Dokumente. Mittlerweile speichern wir dort aber auch unsere gesammelten und kuratierten Fotos. Für die Fotos hatte ich zwischendurch Immich ausprobiert. Das ist ganz nett, aber es hat meinen Workflow massiv gestört, dass Immich keine Album-Ordner kennt. Außerdem ist die Datensicherung nicht ganz so einfach wie bei OpenCloud. Auf der anderen Seite ist die Galerieansicht von OpenCloud wirklich brauchbar.

Paperless NGX

Für die Archivierung unserer Dokumente nutzen wir seit geraumer Zeit  Paperless NGX. Zu diesem Zweck steht in unserem Netzwerk ein Dokumentenscanner, der beliebige Papierdokumente schnell und einfach in archivierbare PDF-Dokumente verwandelt. Der Scanner legt die Dateien auf einem Samba-Share ab und Paperless NGX liest sie von dort aus ein und speichert sie im Archiv.

Forgejo

Egal, ob diese Website hier oder der Code, den ich hin und wieder schreibe: Irgendwo muss er gespeichert werden. Ich war noch nie ein Freund davon, Quellcode irgendwo draußen bei einem Anbieter abzulegen (GitHub, GitLab etc.), wenn ich nicht unbedingt muss. Sehr viel früher habe ich daher ein lokales Subversion genutzt, dann irgendwann Gogs, Gitea und aktuell  Forgejo.

Fazit

Mit der IT-Architektur und der daraus resultierenden Systemlandschaft bei mir zu Hause bin ich mittlerweile zufrieden. Alles funktioniert seit einigen Jahren robust im Alltag. Das war allerdings nicht immer so. Die theoretische Architektur, die ich anfangs im Kopf hatte, musste mit einigem Ausprobieren in die Tat umgesetzt werden. Gelegentlich habe ich schöne, aufwendige Lösungen für einzelne Anforderungen wieder verworfen, weil sie zu komplex für das eigentliche Problem waren. Kein großer Unterschied zu alltäglichen IT-Projekten im Unternehmen.

Wenn jemand diese Systemlandschaft nachbauen möchte, gleich die Warnung vorab: Diese IT-Architektur zieht sich über alle Ebenen: von der Auswahl der richtigen Netzwerkkabel über die Konfiguration von VLANs, DNS und Routing-Tabellen, über die Linux- und Docker-Systemadministration bis hin zur Softwareentwicklung für kleinere Hilfsprogramme sowie zur Konfiguration und dem Betrieb diverser Anwendungen für Endnutzer. Auf der anderen Seite: Wer sich mit allen Ebenen in der IT beschäftigen möchte, findet bei einem solchen Projekt eine wunderbare Spielwiese!