Ein Kunde mit zwei Standorten brauchte ein einziges, redundantes und sicheres Netzwerk zwischen ihnen — ohne Abhängigkeit von einem einzigen ISP oder einem einzigen Server. An jedem Standort haben wir einen Linux-Server aufgebaut, der Routing, VLAN-Trunking, Dual-ISP mit sofortigem Failover, eine L2-VPN-Bridge zwischen VLANs, den gesamten Sicherheits-Stack und KVM-Virtualisierung übernimmt — plus einen Backup-Server, der die Produktion in 15 Minuten übernimmt. Umgesetzt im Februar 2020, auf Debian 10, mit Suricata 5.
Der Kontext
Anfangs hatte jeder Standort einen Mikrotik für Routing und VLANs, mit einem einzigen ISP. Es funktionierte, hatte aber klare Grenzen:
- Ein einziger ISP pro Standort — fiel der Provider aus, war der Standort isoliert
- Keine einheitliche L2-Konnektivität zwischen den zwei Standorten — die VLANs konnten sich standortübergreifend nicht "sehen"
- Minimale Perimeter-Sicherheit — kein IPS, keine dynamische Angriffsblockierung, keine Traffic-Sichtbarkeit
- Keine Server-Redundanz — ein Single Point of Failure pro Standort
Der Kunde wollte, dass die zwei Standorte als ein Netzwerk funktionieren, den Ausfall eines ISP oder eines Servers überstehen und am Perimeter wirklich geschützt sind.
Die Herausforderung
Wir mussten die zwei Standorte auf L2-Ebene verbinden — jedes VLAN sollte sich verhalten, als wären beide Standorte im selben Gebäude — mit ISP- und Server-Redundanz, einem starken Sicherheitsperimeter und ohne Ausfallzeit bei einem Fehler. Alles ohne Änderung der Adressierung oder der dahinterliegenden Anwendungen.
Die Lösung / Architektur
An jedem Standort haben wir einen Debian-Linux-Server installiert, der die Rolle des alten Mikrotik übernimmt und erweitert. Derselbe Server fungiert gleichzeitig als Router, VLAN-Trunk, VPN-Terminator, Firewall, IPS und Virtualisierungs-Host.
- VLAN-Trunk (802.1Q) — der Server hat eine Trunk-Schnittstelle mit allen VLANs; darauf erfolgen die Routing- und internen Zugriffsregeln zwischen VLANs und zwischen Standorten
- Dual-ISP — zwei Provider auf jedem Server, für Internet-Redundanz
- OpenVPN im Bridge-Modus (L2) — eine OpenVPN-Instanz pro VLAN, sodass sich jedes VLAN auf L2-Ebene über beide Standorte erstreckt
- KVM-Virtualisierung — VMs auf jedem Server, mit synchronisierten Konfigurationen zwischen den Standorten
- Ein Backup-Server an jedem Standort, bereit, die Produktion zu übernehmen
Hardware und Infrastruktur
Jeder Standort ist eine Fabrik mit Hunderten von Endpunkten — PCs, Produktionsmaschinen und IoT-Geräte — alle im internen Netzwerk. Der Hauptserver an jedem Standort ist ein Dell PowerEdge R640 (14. Gen, 1U, Dual-CPU, 128 GB RAM), mit 4x 1GbE aggregiert in einem LACP-Port-Channel, aktiv verteilt auf zwei Dell N1500-Switches im Stack — volle Redundanz auf Core-Switch-Ebene. Fällt ein Switch aus, läuft der Verkehr unterbrechungsfrei über den anderen. Die 2x 10GbE liefern die Dual-ISP-Konnektivität. Der Backup-Server an jedem Standort ist ein Dell PowerEdge R730 (13. Gen, 2017 angeschafft), mit derselben NIC-Konfiguration und Konnektivität — ältere Hardware, identische Architektur.
Die Umsetzung
Schritt 1 — Der Linux-Server als Router + VLAN-Trunk
Der Debian-Server übernahm die Rolle des Mikrotik, aber mit weit mehr Leistung. Alle VLANs erreichen die 802.1Q-Trunk-Schnittstelle, und die Routing- und internen Zugriffsregeln erfolgen auf dem Server — wer wen erreichen darf, zwischen VLANs und zwischen den zwei Standorten. Die Segmentierung bleibt sauber, aber von einem einzigen Ort aus kontrolliert.
Schritt 2 — Dual-ISP mit sofortigem Failover
Jeder Server hat zwei ISPs. Fällt ein Provider aus, wechseln die OpenVPN-Verbindungen sofort zum anderen ISP — der Tunnel zwischen den Standorten bricht für die Nutzer nicht sichtbar ab. Ein durchtrenntes Kabel oder ein Provider-Ausfall isoliert keinen Standort mehr.
Schritt 3 — L2-VPN-Bridge zwischen VLANs
Die Konnektivität zwischen den zwei Standorten läuft über OpenVPN im Bridge-Modus, mit einer separaten Instanz für jedes VLAN. Praktisch erstreckt sich jedes VLAN auf L2-Ebene über beide Standorte — ein Gerät an einem Standort ist im selben Netzwerk wie eines am anderen, als wären sie am selben Switch. Anwendungen, die dasselbe lokale Netzwerk voraussetzen, funktionieren ohne Änderungen.
Warum 12 OpenVPN-Instanzen und nicht eine einzige
Ein Einwand, den wir oft hören: eine L2-Bridge pro VLAN, mit einer separaten OpenVPN-Instanz für jede, müsste schwerfällig sein. In der Praxis ist sie es nicht. Wir betreiben 12 OpenVPN-Instanzen im Bridge-Modus, eine pro VLAN, und das System läuft seit Februar 2020 reibungslos in Produktion. Die Trennung pro Instanz ist sogar ein Vorteil: jedes VLAN hat seinen eigenen isolierten Tunnel, Prozess und Schlüsselsatz — fällt einer aus oder wird neu konfiguriert, bleiben die übrigen unberührt. Die Fehlersuche ist viel einfacher als bei einem einzigen Tunnel. Broadcast und ARP bleiben pro VLAN isoliert. Bei Bedarf skalieren wir, indem wir eine weitere Instanz für ein neues VLAN hinzufügen, ohne den Rest anzufassen.
Schritt 4 — KVM-Virtualisierung mit synchronisierter Konfiguration
Auf jedem Server läuft KVM, und die VMs haben synchronisierte Konfigurationen zwischen den zwei Standorten. Ein Dienst kann am anderen Standort mit derselben Konfiguration gestartet werden, ohne manuellen Wiederaufbau.
Sicherheit — ein Perimeter auf jedem Server
Jeder Linux-Server ist auch Firewall, IPS und Sichtbarkeitspunkt. Der Sicherheits-Stack ist an beiden Standorten identisch:
- Suricata IPS — Deep Packet Inspection; erkennt und blockiert Exploit-Versuche, bevor sie die internen Netzwerke erreichen
- ipset mit dynamischen Listen — sehr schnelle Blockierung auf Kernel-Ebene großer IP-Listen, die sich dynamisch aktualisieren (Threat-Feeds, IP-Reputation) — Angreifer werden am Tor abgewiesen
- GeoIP-Filterung — Filterung auf Länderebene, verkleinert die Angriffsfläche aus Regionen ohne legitime Nutzer
- nftables — die Basis-Firewall auf jedem Server, mit strengen Zugriffsregeln zwischen VLANs und nach außen
- Fail2ban — blockiert automatisch IPs, die Brute-Force auf Dienste (SSH und andere) versuchen
Verfügbarkeit und Failover
Die Redundanz besteht auf drei Ebenen: ISP, Server und Standort.
- ISP — sofortiges Failover zwischen den zwei Providern auf jedem Server; die OpenVPN-Tunnel brechen nicht sichtbar ab
- Server — an jedem Standort gibt es einen Backup-Server, der 15 Minuten nach dem Ausfall des Hauptservers automatisch in Produktion geht, oder sofort über einen Befehl, der eine Bestätigung verlangt
- Standort — die zwei Standorte decken sich gegenseitig auf Netzwerk- und Monitoring-Ebene ab
Warum 15 Minuten und nicht sofort? Weil es Wartungsfenster gibt, in denen Betriebssystem-Upgrades durchgeführt werden, und ein geplanter Reboot etwa 5 Minuten dauert. Ein sofortiges Failover würde den Backup-Server bei jedem Reboot hochstufen — ein Fehlalarm. Die 15-Minuten-Schwelle lässt den Hauptserver einen normalen Reboot abschließen, ohne das Failover auszulösen. Und wenn Sie manuell übernehmen wollen, gibt es einen Befehl, der eine Bestätigung verlangt — das Failover kann also nicht versehentlich ausgelöst werden.
Zwischen dem Haupt- und dem Backup-Server an jedem Standort besteht eine kontinuierliche Konfigurationssynchronisation: jede Firewall-, Routing- oder Zugriffsregel, die auf dem Hauptserver geändert wird, wird automatisch auf den Backup-Server übertragen. Wenn der Backup-Server die Produktion übernimmt, tut er das mit genau derselben Konfiguration — keine Überraschungen, keine manuelle Neukonfiguration.
Monitoring — redundantes Nagios
Die Linux-Server fungieren auch als Nagios. Das Monitoring läuft auf den Hauptservern an jedem Standort, aber da wir zwei Standorte haben, die sich auf L2-Ebene sehen, übernimmt bei Ausfall eines Hauptservers das Nagios am anderen Standort das Monitoring — man ist nicht genau dann blind, wenn man einen Vorfall hat.
Das Ergebnis
- ✅ Die zwei Standorte funktionieren als ein einziges L2-Netzwerk — eine VPN-Bridge pro VLAN, transparent für Anwendungen
- ✅ Dual-ISP mit sofortigem Failover — ein Provider-Ausfall isoliert keinen Standort mehr
- ✅ Server-Redundanz — ein Backup, das in 15 Minuten oder auf Befehl mit Bestätigung in Produktion geht
- ✅ Ein vollständiger Sicherheitsperimeter: Suricata IPS + ipset mit dynamischen Listen + GeoIP + nftables + Fail2ban, identisch an beiden Standorten
- ✅ Redundantes Nagios-Monitoring — ein Standort deckt den anderen ab
- ✅ Die alten Mikrotiks zu einem einzigen Linux-Server pro Standort konsolidiert, der alles macht: Routing, VLAN, VPN, Sicherheit, Virtualisierung
Haben Sie mehrere Standorte, die als einer funktionieren müssen?
Wir bauen redundante Multi-Standort-Netzwerke: L2/L3-Konnektivität zwischen Standorten, Dual-ISP mit Failover, einen identischen Sicherheitsperimeter überall, Virtualisierung und einen Standby-Server, der die Produktion in Minuten übernimmt. Ohne Abhängigkeit von einem einzigen ISP, einem einzigen Server oder einem einzigen Standort.