Technisches Verständnis aus der Elektrotechnik trifft auf Netzwerke, Linux und moderne IT-Infrastruktur.
Maximilian Deiner
Fachinformatiker für Systemintegration
in Umschulung
Meine beruflichen Wurzeln liegen in der Elektrotechnik. Mehr als zehn Jahre Arbeit mit technischen Anlagen,
Steuerungen und elektrischen Systemen haben mein Verständnis für komplexe Systeme und strukturierte
Fehlersuche geprägt. Heute übertrage ich diese Erfahrung auf die IT und insbesondere auf die Systemintegration.
Besonders interessieren mich Linux-Systeme, Netzwerke, Virtualisierung und der sichere Betrieb von
Serverdiensten. Vieles davon beschäftigt mich nicht nur im Rahmen meiner Umschulung, sondern auch praktisch in
eigenen Projekten und Testumgebungen.
Erfahrung
Elektroniker für Betriebstechnik · über 10 Jahre
Umschulung
Fachinformatiker für Systemintegration
Fokus
Systemintegration · Linux · Netzwerke · Server-Infrastruktur
Eine selbst konzipierte und aufgebaute Proxmox-Umgebung mit segmentierten
Netzen, zentraler Firewall und getrennten Bereichen für öffentliche Dienste,
Management, Monitoring und Fernzugriff. Die sieben Abschnitte zeigen jeweils
Aufgabe, Umsetzung und Ergebnis.
Host & Storage
Virtualisierung
Aufgabe
Um mehrere Dienste unabhängig voneinander betreiben zu
können, sollte eine Virtualisierungsplattform entstehen, die
strukturiert erweiterbar ist und den Ausfall einzelner
Datenträger übersteht.
Umsetzung
Als Basis dient Proxmox VE auf einem Debian-System. Vier
NVMe-SSDs sind zu zwei getrennten ZFS-Spiegeln zusammengefasst:
Das kleinere Paar trägt System und Boot, das größere den
Datenpool der virtuellen Maschinen. Darauf laufen derzeit
dreizehn Maschinen. Als organisatorische Konvention kodieren
die VM-IDs zusätzlich VLAN und Hostanteil und erlauben dadurch
eine schnelle Zuordnung.
Ergebnis
Der Ausfall eines Datenträgers je Spiegel bleibt folgenlos,
und System und Nutzdaten liegen getrennt voneinander. Dadurch
lassen sich einzelne Dienste ergänzen oder neu aufsetzen, ohne
die Plattform als Ganzes anzufassen.
Proxmox VE
Debian
ZFS
NVMe
Plattform
Proxmox VE auf Debian
Maschinen
13 virtuelle Maschinen
Redundanz
2 ZFS-Spiegel
Datenträger
2 × 3,84 TB + 2 × 1,92 TB NVMe
Netzsegmentierung
Netzwerk
Aufgabe
Management, öffentliche Dienste, interne Systeme, Monitoring
und Fernzugriff sollten logisch voneinander isoliert werden,
statt sämtliche Maschinen in ein gemeinsames Netz zu hängen.
Umsetzung
OPNsense übernimmt Routing und Filterung zentral und ist die
einzige Maschine an der Uplink-Bridge. Alle übrigen Systeme
hängen an einer zweiten, VLAN-fähigen Linux Bridge ohne
physischen Port. Sieben VLANs trennen die Bereiche
voneinander, Kea DHCP versorgt die zugehörigen Subnetze mit
IPv4- und IPv6-Adressen.
Ergebnis
Die Kommunikation zwischen zwei Netzen läuft zwangsläufig über
die Firewall. Dadurch lässt sich der Verkehr zwischen den
VLANs an einer zentralen Stelle kontrollieren und nur dort
freigeben, wo er tatsächlich benötigt wird.
OPNsense
Linux Bridge
VLAN
Kea DHCP
Segmente
7 VLANs
Uplink
nur die Firewall-VM
Adressvergabe
Kea DHCP, 7 Subnetze
Adressierung
Dual-Stack
Firewall-Regelwerk
IT-Security
Aufgabe
Um die Segmentierung wirksam zu machen, sollte die
Kommunikation zwischen den Netzen auf die tatsächlich
benötigten Verbindungen beschränkt werden.
Umsetzung
Die Regeln liegen nicht an einzelnen Interfaces, sondern in
Gruppen für Uplink, Management, VLANs und die einzelnen
Tunnel. Quellen, Ziele und Ports stehen ausschließlich in
Aliasen, sodass eine Netzänderung genau eine Stelle betrifft.
Am Uplink filtern zusätzlich mehrere Blocklisten sowie die
Bogon-Netze vor allen weiteren Regeln.
Ergebnis
Zwischen den VLANs besteht standardmäßig keine Kommunikation.
Jede Verbindung ist eine bewusste Freigabe, und bei einer
Änderung am Netz bleibt das Regelwerk selbst unangetastet.
OPNsense
Aliases
Blocklisten
Default-Deny
Grundregel
Default-Deny zwischen VLANs
Struktur
Regelgruppen statt Interface-Regeln
Adressen
ausschließlich über Aliase
Uplink-Filter
Blocklisten und Bogon-Netze
Reverse Proxy
Dienste
Aufgabe
Um Webdienste öffentlich bereitzustellen, ohne die
dahinterliegenden Maschinen direkt aus dem Internet
erreichbar zu machen, war ein kontrollierter Einstiegspunkt
nötig.
Umsetzung
Von außen sind ausschließlich TCP 80 und 443 erreichbar.
OPNsense leitet beide per DNAT an eine nginx-Instanz in einem
eigenen Proxy-VLAN weiter, die dort TLS terminiert und die
Anfragen an die zuständigen Docker-Dienste im Web-VLAN
weiterreicht. Öffentlich erreichbare und rein interne
Docker-Hosts sind dabei voneinander getrennt; für die
internen Seiten arbeitet eine zweite nginx-Instanz.
Ergebnis
Kein Dienst ist direkt aus dem Internet erreichbar. Neue
Anwendungen werden über den Proxy veröffentlicht, ohne dass
dafür eine weitere Portfreigabe an der Firewall entsteht.
nginx
Docker
DNAT
TLS
Öffentlich
nur TCP 80 und 443
Einstieg
1 Reverse Proxy im eigenen VLAN
Verschlüsselung
TLS am Proxy terminiert
Backend
öffentliche und interne Hosts getrennt
Fernzugriff
Remote Access
Aufgabe
Unterschiedliche Zugriffsarten sollten voneinander getrennt
werden, statt einen einzigen VPN-Zugang für alle Zwecke zu
verwenden.
Umsetzung
Vier WireGuard-Instanzen laufen parallel, jede mit eigenem
Tunnelnetz und einer eigenen Regelgruppe auf der Firewall.
Für administrative Aufgaben steht eine Remote-Maschine im
Fernzugriffsnetz bereit, die über einen festgelegten Port für
Fernwartung erreichbar ist.
Ergebnis
Kein Zugang erhält automatisch Zugriff auf sämtliche internen
Netze. Welche Ziele über welchen Tunnel erreichbar sind,
steht ausschließlich in der jeweiligen Regelgruppe.
WireGuard
VPN
Remote Access
OPNsense
Zugangswege
4 getrennte WireGuard-Instanzen
Trennung
eigenes Tunnelnetz je Instanz
Regeln
eigene Gruppe je Tunnel
Administration
Remote-VM im Fernzugriffsnetz
Monitoring & Betrieb
Betrieb
Aufgabe
Zustand und Erreichbarkeit der wichtigen Systeme sollten
überwacht werden, ohne dass das Monitoring dafür Zugriff auf
alles bekommt.
Umsetzung
Checkmk läuft auf einem eigenen Host in einem eigenen
Monitoring-VLAN. Die Firewall gibt von dort aus gezielt die
Verbindungen zu den überwachten Systemen frei, ICMP nur dort,
wo es zur Diagnose gebraucht wird. Syncthing übernimmt
daneben einen definierten Abgleich zwischen zwei Netzen über
feste Ports.
Ergebnis
Das Monitoring arbeitet über einzeln definierte
Kommunikationsbeziehungen statt über pauschale Rechte. Fällt
der Monitoring-Host aus, bleibt kein weit geöffneter
Netzzugang zurück.
Checkmk
Monitoring
Syncthing
ICMP
Überwachung
Checkmk auf eigenem Host
Lage
separates Monitoring-VLAN
Freigaben
je überwachtem System einzeln
Abgleich
Syncthing über feste Ports
Infrastrukturübersicht
Architektur
Die Gesamtübersicht zeigt die wichtigsten Netzsegmente,
Kommunikationswege und zentralen Komponenten im Zusammenspiel: den
Uplink über die Firewall, die sieben VLANs an der internen Bridge,
den Reverse Proxy als einzigen öffentlichen Einstiegspunkt sowie die
getrennten Wege für Fernzugriff und Monitoring. Alle darin
enthaltenen Aussagen stehen ausführlich in den sechs vorherigen
Abschnitten.
// Technologien
Der Stack, mit dem ich arbeite.
Von Virtualisierung bis Frontend.
Klick auf eine Technologie, um eine kurze Beschreibung zu sehen.
// klick eine kachel
// Terminal
So sieht mein Arbeitsalltag aus.
Fünf typische Sitzungen aus Entwicklung und Serverbetrieb.
Sie spielen sich selbst ab, sobald sie ins Bild kommen.