Zero Trust & Fernzugriff

Büro, Rechenzentrum und Cloud in einem Netz: Standortkopplung mit NetBird

Der Server steht im Büro, die Datensicherung bei einem Rechenzentrum, eine Anwendung in der Cloud. Jede Verbindung dazwischen ist ein eigener Tunnel mit eigener Konfiguration. Dieser Beitrag zeigt, wie ein Mesh-Netz daraus ein zusammenhängendes Netz macht.

Das Wichtigste in Kürze

  • Klassische Standortkopplung braucht einen eigenen Tunnel für jedes Paar von Standorten. Ab drei, vier Umgebungen wird das unübersichtlich.
  • Ein Mesh verbindet jede Umgebung einmal mit dem Verbund; ein Routing-Peer je Umgebung macht die dortigen Netze erreichbar.
  • Die wichtigste Vorarbeit: überschneidungsfreie Adressbereiche. Wer das übersieht, baut sich ein schwer lösbares Problem.

Die IT eines mittelständischen Unternehmens verteilt sich heute selten auf einen einzigen Ort. Da ist der Serverraum im Hauptsitz, vielleicht eine Niederlassung, ein gemieteter Server bei einem Rechenzentrumsanbieter wie Hetzner für die Offsite-Sicherung, und eine Anwendung, die der Hersteller nur noch in einer Cloud wie AWS anbietet.

Jede dieser Umgebungen muss mit den anderen sprechen. Klassisch geschieht das über VPN-Tunnel zwischen Firewalls – einer je Verbindung, jeder mit eigener Konfiguration, eigenen Schlüsseln und eigenen Fehlerquellen. Das Prinzip des Mesh-Netzes, das wir in Vom VPN zum Mesh für den Fernzugriff beschrieben haben, lässt sich auch auf diese Standortkopplung anwenden.

Warum Einzeltunnel nicht mitwachsen

Bei zwei Standorten ist ein Tunnel überschaubar. Bei vier Umgebungen, die alle miteinander sprechen sollen, sind es bereits sechs Tunnel. Jeder davon muss eingerichtet, überwacht und bei Änderungen angepasst werden. Jeder hat seine eigenen Eigenheiten, und wenn einer ausfällt, beginnt die Fehlersuche, die in Das VPN funktioniert nicht beschrieben ist.

Hinzu kommt: Cloud-Umgebungen haben eigene Vorstellungen davon, wie VPN-Verbindungen aussehen. Die Kopplung an die Firewall im Büro ist bei jedem Anbieter etwas anders gelöst.

Wie das Mesh die Kopplung löst

Im Mesh wird jede Umgebung genau einmal an den Verbund angeschlossen – nicht an jede andere Umgebung einzeln. Dafür steht in jeder Umgebung ein kleiner Server oder Container mit NetBird, der sogenannte Routing-Peer. Er macht die Netze seiner Umgebung für den Verbund erreichbar.

Umgebung Routing-Peer Macht erreichbar
Hauptsitz Kleine virtuelle Maschine im Serverraum Servernetz, ausgewählte Systeme
Niederlassung Kleines Gerät oder Container Lokales Netz der Niederlassung
Gemieteter Server (z. B. Hetzner) NetBird direkt auf dem Server Den Server selbst
Cloud-Umgebung (z. B. AWS) Kleine Instanz im privaten Netz der Cloud Die dortigen internen Adressen

Die Verbindungen zwischen den Umgebungen entstehen dann direkt und verschlüsselt, wo immer das möglich ist. Wo nicht, läuft der Verkehr über einen Vermittlungsdienst. Welche Umgebung mit welcher sprechen darf, regeln dieselben Zugriffsregeln wie beim Fernzugriff – eine gemeinsame Stelle für alles, statt Regeln verteilt auf mehrere Firewalls.

Für wichtige Umgebungen lassen sich mehrere Routing-Peers zu einer Gruppe zusammenfassen. Fällt einer aus, übernimmt ein anderer. Damit hängt die Erreichbarkeit einer Umgebung nicht an einem einzelnen Gerät.

Die Vorarbeit: Adressbereiche ohne Überschneidung

Der Punkt, an dem solche Projekte am häufigsten ins Stocken geraten, hat mit NetBird nichts zu tun. Wenn das Büro und die Cloud-Umgebung dieselben internen Adressbereiche verwenden, kann ein Paket nicht wissen, welches Ziel gemeint ist. Das ist gerade bei Standardwerten häufig – viele Router und Cloud-Vorlagen verwenden ab Werk dieselben Bereiche.

Erst den Adressplan, dann die Technik

Bevor die erste Umgebung angeschlossen wird, gehört ein Adressplan auf Papier: welcher Bereich wo verwendet wird, mit Reserve für künftige Standorte. Eine neue Cloud-Umgebung lässt sich beim Anlegen leicht mit einem freien Bereich versehen – nachträglich umzunummerieren ist dagegen aufwendig.

Namensauflösung nicht vergessen

Ein Netz, in dem man Systeme nur über Adressen erreicht, ist im Alltag unbrauchbar. Die Namensauflösung muss mitgeplant werden: Welche internen Namen sollen aus welcher Umgebung auflösbar sein, und welcher Namensserver ist dafür zuständig? NetBird kann interne Domänen über den Verbund bereitstellen. Wie das im Einzelfall am saubersten gelöst wird, hängt davon ab, welche Namensdienste bereits bestehen.

Aufwand und Betrieb

Der Anschluss einer einzelnen Umgebung ist schnell erledigt: Routing-Peer einrichten, Netze freigeben, Regeln anlegen. Der Aufwand steckt im Adressplan, in der Namensauflösung und in der Übergangsphase, in der alte Tunnel und neues Mesh parallel laufen. Bewährt hat sich, eine Umgebung nach der anderen umzuziehen und die alten Tunnel erst abzubauen, wenn der neue Weg mehrere Wochen stabil lief.

Im laufenden Betrieb gibt es weniger zu pflegen als bei mehreren Einzeltunneln: eine Oberfläche, ein Regelwerk, eine Stelle für die Fehlersuche. Die Routing-Peers sind normale Systeme und brauchen Aktualisierungen wie jedes andere.

Wo die Grenzen liegen

  • Kosten für Datenverkehr in der Cloud. Viele Cloud-Anbieter berechnen ausgehenden Verkehr. Wer große Datenmengen regelmäßig aus der Cloud ins Büro holt, sollte das vorher durchrechnen – unabhängig von der Vernetzungstechnik.
  • Die Sicherheitsregeln der Cloud bleiben. Die Schutzmechanismen des Cloud-Anbieters für die eigenen Instanzen werden nicht überflüssig. Der Routing-Peer muss dort ausdrücklich erlaubt sein, und alles andere sollte geschlossen bleiben.
  • Latenz lässt sich nicht wegverbinden. Eine Anwendung, die mit ihrer Datenbank in einer anderen Umgebung spricht, wird durch die Entfernung langsamer. Das ist Physik, nicht Konfiguration.
  • Zwei Standorte mit stabiler Kopplung. Wenn nur zwei Standorte bestehen und ihre Verbindung zuverlässig läuft, gibt es keinen zwingenden Grund für einen Umbau.

Fazit

Sobald mehr als zwei Umgebungen miteinander sprechen müssen, spielt ein Mesh seine Stärke aus: Jede Umgebung wird einmal angeschlossen, die Regeln liegen an einer Stelle, und der Verkehr fließt direkt, wo es geht. Die wichtigste Arbeit ist dabei unspektakulär – ein sauberer Adressplan und eine durchdachte Namensauflösung. Wer das vorher klärt, hat anschließend deutlich weniger zu pflegen als mit einzelnen Tunneln.

Wir planen und betreiben solche Vernetzungen – für die Zugriffsregeln im Detail siehe Mikrosegmentierung mit NetBird, für unser Angebot Netzwerk & IT-Sicherheit und Cloud & Microsoft 365.

Beitrag teilen
Weiterlesen

Passende Beiträge.

Zero Trust & Fernzugriff 6 Min. Lesezeit

Vom VPN zum Mesh: Fernzugriff mit NetBird statt Einwahl ins Firmennetz

Wer sich per VPN einwählt, steht anschließend im Firmennetz – mit allem, was dort erreichbar ist. Dieser Beitrag zeigt, wie ein Mesh-Netz auf WireGuard-Basis den Zugriff auf einzelne Dienste begrenzt, ohne die tägliche Arbeit umständlicher zu machen.

Zero Trust & Fernzugriff 6 Min. Lesezeit

Fernwartung im Browser: Was Apache Guacamole für externe Zugriffe ändert

Der Maschinenlieferant braucht Zugriff, der Softwarehersteller auch – und hinterher weiß niemand, wer wann was gemacht hat. Ein Zugangsportal im Browser bündelt diese Zugriffe an einer Stelle, ohne dass auf der Gegenseite Software installiert werden muss.

Zero Trust & Fernzugriff 4 Min. Lesezeit

Mikrosegmentierung mit NetBird: Wer darf was erreichen – bis auf den Port

Ein Netz, in dem jedes Gerät jedes andere erreicht, ist bequem – bis ein Gerät übernommen wird. Mikrosegmentierung schränkt das auf das Nötige ein. Dieser Beitrag zeigt, wie das mit NetBird aussieht, ohne dass die Regelwerke unübersichtlich werden.