Standorte verbinden: VPN, Tailscale, NetBird oder Cloudflare Mesh?

Ich beschäftige mich viel mit der Vernetzung von Betrieben. Dabei bekomme ich immer wieder dieselben Fragen: Was ist die beste Lösung, um Standorte miteinander zu verbinden? Brauche ich dafür öffentliche IP-Adressen? Wie sicher ist das? Und passt die Lösung noch, wenn später eine Zweigstelle, ein anderer Internetanschluss oder zusätzliche Mitarbeiter dazukommen?

Meine Antwort hängt davon ab, was der Betrieb tatsächlich braucht. Zwei feste Standorte mit vorhandenen Firewalls haben andere Voraussetzungen als mehrere kleine Außenstellen hinter wechselnden Anschlüssen. Dazu kommen Fragen, die über den Tunnel hinausgehen: Wer betreibt die Verbindung, wo werden Zugriffe kontrolliert und welche Abhängigkeiten möchte man im Alltag übernehmen?

Ich finde es deshalb sinnvoll, die Architektur zu verstehen, bevor man sich für einen Produktnamen entscheidet. Ein klassisches Site-to-Site-VPN kann sehr gut passen. Tailscale oder NetBird können die Verwaltung und den Verbindungsaufbau erleichtern. Cloudflare Mesh wiederum verlagert den Verbindungspfad ins Netz des Anbieters. Diese Unterschiede bestimmen für mich, wo welche Lösung Sinn ergibt.

Hier geht es um die Verbindung ganzer Standortnetze. Den Zugriff einzelner Mitarbeiter von zu Hause ordne ich später als zusätzliche Remote-Access-Nutzung ein.

Unser Beispiel: Drei miteinander verbundene Standortnetze

Das Büro verwendet 10.1.0.0/24, die Zweigstelle 10.2.0.0/24 und das Homelab 10.3.0.0/24. Jeder Standort bekommt ein Gateway, das entfernte Netze erreichbar macht. Ein Drucker oder NAS dahinter braucht dadurch keinen eigenen VPN-Client. Das ist bei allen verglichenen Modellen das Ziel: dieselben drei Standortnetze kontrolliert miteinander zu verbinden.

Dabei entsteht ein geroutetes Layer-3-Netz. Die Standorte teilen sich weder automatisch dieselbe Broadcast-Domäne noch funktionieren alle lokalen Suchprotokolle plötzlich standortübergreifend. DNS muss interne Namen passend auflösen, und die lokalen Router müssen wissen, wohin sie Pakete für entfernte Netze schicken.

Bei der Auswahl möchte ich zuerst wissen, welches Netz tatsächlich welche Dienste erreichen muss. Die Zweigstelle braucht vielleicht den Dateiserver, aber keinen Zugriff auf die Verwaltung des Homelabs. Der Backup-Server braucht sein Sicherungsziel, aber nicht sämtliche Geräte am anderen Standort. Diese Entscheidung bleibt bei allen Lösungen notwendig.

Site-to-Site beschreibt die Verbindung, nicht die Topologie

Site-to-Site bedeutet Netz zu Netz. Daraus folgt nicht, dass sämtlicher Verkehr zwingend durch eine zentrale Firewall laufen muss. Hub-and-Spoke über die eigene Hauptstelle ist eine verbreitete Topologie; direkte Tunnel zwischen Standortpaaren sind ebenfalls Site-to-Site. Auch die Standort-Gateways von Tailscale, NetBird oder Cloudflare Mesh können diesen Zweck erfüllen.

Bei Tailscale und NetBird sind die Datenwege möglichst direkt, obwohl Anmeldung und Koordination zentral verwaltet werden können. Bei Cloudflare ist das Anbieternetz geografisch verteilt, der Standortverkehr läuft aber weiterhin durch Cloudflare. Das ist keine direkte Peer-to-Peer-Verbindung zwischen den Standorten. Die zentrale eigene Firewall als Durchleitungspunkt wird hier durch das Anbieternetz ersetzt.

Öffentliche IPs und Anforderungen, die sich verändern

Die Frage nach der öffentlichen IP taucht bei solchen Überlegungen schnell auf. Ich trenne dabei zwei Dinge: Ist ein Anschluss von außen erreichbar, und bleibt seine Adresse gleich? Eine feste öffentliche Adresse erleichtert die Planung eines erreichbaren VPN-Endpunkts. Sie ist aber nicht an jedem Standort zwingend erforderlich. Ein Außenstandort kann seinen Tunnel ausgehend zu einem erreichbaren zentralen Gateway aufbauen; bei einer wechselnden Adresse kann je nach Aufbau auch dynamisches DNS helfen.

Schwieriger wird es, wenn beide Seiten hinter restriktivem Carrier-Grade NAT sitzen und keine direkt erreichbare Gegenstelle vorhanden ist. Gerade bei Mobilfunkanschlüssen sollte man deshalb prüfen, welche Adressen und eingehenden Verbindungen der Anbieter tatsächlich ermöglicht. Tailscale und NetBird versuchen, die Teilnehmer durch NAT hindurch direkt zu verbinden, und können bei Bedarf auf Relays ausweichen. Cloudflare Mesh baut stattdessen ausgehende Verbindungen zum Anbieternetz auf.

Ich möchte eine Standortvernetzung außerdem so auswählen, dass die nächste Änderung noch beherrschbar bleibt. Ein zusätzlicher Standort, ein Providerwechsel oder ein Anschluss ohne eingehende Erreichbarkeit kann aus einer überschaubaren Konfiguration eine andere Aufgabe machen. Die bestehende Lösung muss deshalb nicht vorsorglich ersetzt werden. Diese Möglichkeiten gehören aber in die Entscheidung, bevor man sich auf eine bestimmte Topologie festlegt.

Klassisches Site-to-Site-VPN: Die Gateways übernehmen

Beim klassischen Ansatz bauen zwei Firewalls oder Router einen verschlüsselten Tunnel auf, häufig mit IPsec oder manuell konfiguriertem WireGuard. Die lokale Routingtabelle schickt den Verkehr für das entfernte Netz zum Tunnel. Am anderen Ende entschlüsselt das Gateway die Pakete und leitet sie ins Zielnetz weiter.

Bei drei Standorten kann das Büro als Hub dienen. Zweigstelle und Homelab bauen jeweils einen Tunnel dorthin auf. Das vereinfacht die Struktur, führt Verkehr zwischen den beiden Außenstandorten aber durch das Büro. Ein Full Mesh verbindet jedes Standortpaar direkt. Bei n Standorten sind dafür n × (n − 1) / 2 Verbindungen nötig: drei bei drei Standorten, bereits 45 bei zehn. Controller und dynamische Verfahren können diese Arbeit reduzieren; klassische VPNs sind keineswegs auf manuell gepflegte Hub-Netze beschränkt.

Vorteile: Der Ansatz passt gut zu vorhandenen Firewalls und klaren Standortgrenzen. Die Tunnelenden liegen unter eigener Kontrolle. Es gibt keinen zusätzlichen Mesh-Anbieter im Datenweg, und Regeln, Routing sowie Protokollierung lassen sich in die bestehende Administration einbinden.

Nachteile: Mit jedem Standort wachsen Routing-, Schlüssel- und Betriebsaufgaben. NAT, wechselnde Internetadressen und unterschiedliche Hersteller können die Fehlersuche erschweren. Für mobile Nutzer kommt häufig ein eigener Remote-Access-Betrieb hinzu.

Eine feste öffentliche Adresse an jedem Standort ist keine allgemeine Voraussetzung. Ein erreichbarer Hub und ausgehend aufgebaute Tunnel reichen in vielen Konfigurationen. Dynamisches DNS und NAT-Traversal helfen ebenfalls. Sind jedoch beide Seiten hinter restriktivem CGNAT, ist ein direkter Tunnel ohne erreichbare Gegenstelle oder Vermittlung deutlich schwieriger.

Für zwei stabile Standorte mit geeigneten Firewalls bleibt das eine sehr vernünftige Lösung. Ein funktionierendes VPN muss man nicht ersetzen, nur weil ein anderes Produkt weniger Konfigurationsfelder zeigt.

Tailscale: Direkte Verbindungen mit zentraler Koordination

Tailscale ergänzt WireGuard um Geräteanmeldung, Koordination und Zugriffsregeln. Die Steuerung hilft den Teilnehmern, sich zu finden. Der Nutzverkehr läuft möglichst direkt zwischen den Peers. Gelingt das durch NAT oder Firewall-Beschränkungen nicht, kann ein Relay einspringen. Auch über ein DERP-Relay bleibt der Verkehr zwischen den Tailscale-Peers verschlüsselt.

Für ganze LANs übernehmen Subnet-Router den Übergang ins Tailnet. Für das dokumentierte Site-to-Site-Szenario verwendet Tailscale Linux an beiden Tunnelenden. Endgeräte dahinter bleiben ohne Agent erreichbar, brauchen aber passende Routen. Wer Quelladressen erhalten will und deshalb Source NAT abschaltet, muss insbesondere den Rückweg sauber planen.

Vorteile: Bestehende LAN-Geräte können über Subnet-Router teilnehmen. Direkte Verbindungen zwischen diesen Gateways vermeiden den festen Umweg über einen zentralen Standort. Zusätzliche einzelne Nutzergeräte lassen sich über dieselbe Plattform anbinden.

Nachteile: Ein direkter Datenweg ist nicht garantiert. Relay-Verbindungen können andere Latenz- und Durchsatzwerte liefern. Der gehostete Koordinationsdienst bleibt eine betriebliche Abhängigkeit; Tarif und Funktionsumfang müssen zum Einsatz passen.

Die WireGuard-Verschlüsselung endet am jeweiligen Peer. Ist dieser Peer ein Subnet-Router, liegt der anschließende LAN-Abschnitt außerhalb dieses Tunnels. HTTPS oder SSH bleiben deshalb auch innerhalb des privaten Netzes sinnvoll.

NetBird: Ähnliches Mesh, mit eigener Betriebsoption

Auch NetBird baut auf WireGuard auf, versucht direkte Peer-Verbindungen herzustellen und verwendet bei Bedarf Relays. Für Netze ohne eigenen Client dienen Routing Peers als Übergang. Die aktuelle Site-to-Site-Anleitung beschreibt dafür Networks, Ressourcen und passende Zugriffsrichtlinien.

Vorteile: Das Open-Source-Projekt bietet eine selbst betreibbare Alternative zum Cloud-Dienst. Das ist interessant, wenn Infrastruktur und Verwaltung unter eigener Verantwortung bleiben sollen. Gruppen und Richtlinien helfen, den Zugriff gezielt zu begrenzen.

Nachteile: Self-Hosting bringt Updates, Backups, Monitoring und die Erreichbarkeit von Steuerung und Relays mit sich. Diese Arbeit verschwindet nicht durch eine schnelle Erstinstallation. Beim dokumentierten Networks-Site-to-Site-Aufbau sollte Masquerading aktiviert bleiben; dadurch sieht das Ziel nicht einfach die ursprüngliche Quelladresse. Andere Routingvarianten müssen gesondert geplant werden.

Tailscale und NetBird sind daher nahe Verwandte, aber keine austauschbaren Oberflächen für dieselbe Konfiguration. Ich würde beide mit dem eigenen Routing- und Identitätsmodell prüfen. Open Source ist außerdem kein Freibrief für beliebige Nutzung jeder Produktfunktion: Das NetBird-Repository verwendet unter anderem BSD-3-Clause und AGPLv3; Lizenzumfang und gewünschte Funktionen gehören zur Auswahl.

Cloudflare Mesh: Das Anbieternetz wird zum Verbindungspfad

Bei Cloudflare Mesh verbinden sich die Teilnehmer ausgehend mit Cloudflare. Der Verkehr zwischen den Standorten durchläuft dessen Netz. Damit muss man weder jeden Standort direkt mit jedem anderen verbinden noch einen eigenen zentralen VPN-Hub betreiben. Es ist trotzdem ein anderer Vertrauens- und Datenweg als bei einem direkten WireGuard-Mesh.

Vorteile: Der Ansatz bündelt Vernetzung und zentrale Gateway-Richtlinien. Er kann besonders gut passen, wenn Cloudflare One bereits Teil der Umgebung ist. Standorte hinter NAT und mobile Clients lassen sich über ausgehende Verbindungen anbinden.

Nachteile: Betrieb und Datenweg hängen vom Anbieter ab. Für sensible Daten muss die Verarbeitung durch Cloudflare zur eigenen Vertrauens- und Datenschutzanforderung passen. Anwendungsschutz durch TLS oder SSH bleibt sinnvoll. Ob der Umweg für eine konkrete Anwendung günstig ist, muss eine Messung zeigen; ein globales Backbone ist kein pauschaler Geschwindigkeitsbeweis.

Für einen neuen Aufbau würde ich dem aktuell dokumentierten Client-Weg folgen. Cloudflare führt Mesh als Beta und verlangt MASQUE im Geräteprofil der Mesh-Knoten. Für WireGuard nennt der Anbieter Einschränkungen bei Hochverfügbarkeit, IPv6- und Hostnamen-Routen. Dass ein Router WireGuard unterstützt, reicht deshalb für sich allein nicht aus, um ihn als gleichwertigen Mesh-Knoten einzuplanen.

Cloudflare Mesh sollte man außerdem nicht mit einem cloudflared-Tunnel für einzelne Anwendungen gleichsetzen. Für dieses Beispiel geht es um bidirektionale private IP-Verbindungen zwischen Teilnehmern und gerouteten Netzen.

Die Unterschiede auf einen Blick

Für die Auswahl sind das die Unterschiede, die ich zuerst gegeneinander abwäge. Den benötigten Tarif und den tatsächlichen Verbindungspfad muss man für die konkrete Umgebung prüfen.

Was für mich eine sichere Standortvernetzung ausmacht

Bei der Frage nach der sichersten Lösung schaue ich zuerst auf die erlaubten Verbindungen und die Verwaltung der Zugänge. Ein verschlüsselter Tunnel kann trotzdem viel zu weitreichende Zugriffe erlauben. Ich möchte festlegen können, welches Netz welche Dienste erreicht, wie Administratoren geschützt sind und wie sich ein Zugang wieder entziehen lässt. MFA für die Administration und persönlich angemeldete Nutzer, begrenzte Berechtigungen und gepflegte Gateways gehören für mich zu dieser Bewertung.

Auch die Verschlüsselungsgrenzen unterscheiden sich. Beim klassischen VPN endet der Tunnel an den Standort-Gateways. Bei Tailscale und NetBird liegt die WireGuard-Verbindung zwischen den Peers, gegebenenfalls den Subnet-Routern. Der anschließende LAN-Abschnitt ist dadurch nicht automatisch verschlüsselt. Bei Cloudflare muss zusätzlich die Verarbeitung im Anbieternetz zu den Anforderungen des Betriebs passen. HTTPS oder SSH bleiben für die jeweilige Anwendung sinnvoll.

Eine ausgehend aufgebaute Verbindung kann die Einrichtung vereinfachen und einen öffentlich erreichbaren VPN-Dienst am Außenstandort vermeiden. Sie ersetzt keine Zugriffsrichtlinie. Umgekehrt macht eine öffentliche IP eine Firewall nicht automatisch unsicher. Entscheidend sind die tatsächlich erreichbaren Dienste, deren Schutz und der laufende Betrieb. Aus dem Produktnamen allein leite ich deshalb keine Sicherheitsrangfolge ab.

Was ich vor der Freigabe prüfen möchte

Bei der Standortvernetzung müssen Hin- und Rückweg zusammenpassen. Die Route zu 10.2.0.0/24 gehört auf den zuständigen Router oder Client. Wenn der Zielhost über ein anderes Standardgateway antwortet, braucht auch die Rückrichtung eine passende Route. SNAT kann diesen Rückweg vereinfachen, verändert aber die sichtbare Quelladresse. Das wirkt sich auf Logs und Regeln aus und sollte bei der Planung bewusst entschieden werden.

Für Hochverfügbarkeit reicht es nicht, zwei Knoten im Overlay anzulegen. Die LAN-Geräte müssen ihr nächstes Gateway auch nach einem Ausfall erreichen. Eine virtuelle Gateway-Adresse lässt sich beispielsweise mit Keepalived und VRRP bereitstellen. Gleichzeitig müssen die entfernten Routen einen gesunden Knoten auswählen. Bei der Abnahme möchte ich deshalb sehen, was mit neuen und bestehenden TCP-Sitzungen passiert, wenn ein Gateway oder dessen Tunnel ausfällt. Ein laufender Tunnelprozess und ein erfolgreicher Ping beantworten diese Frage nur teilweise.

Zu den Funktionstests gehören für mich auch bewusst gesperrte Verbindungen. Wenn SSH erlaubt und eine andere Anwendung gesperrt sein soll, muss genau das überprüfbar sein. Ein erfolgreicher ICMP-Test sagt nichts darüber aus, ob eine TCP-Regel greift. Die Anmeldung, die Zugriffsrichtlinie und die Firewall am Zielsystem müssen zusammenpassen.

Dann bleiben die unscheinbaren Themen, die den Alltag trotzdem bestimmen: eindeutige Netzpräfixe, interne Namensauflösung und die passende MTU. Weder 192.168.x.x noch 10.x.x.x garantiert ein konfliktfreies Netz. Wenn kleine Pings funktionieren, größere Übertragungen aber hängen, möchte ich die Verbindung noch nicht als fertig betrachten.

Für eine belastbare Leistungsbewertung braucht es denselben Dateitransfer und dieselbe interaktive Anwendung über die tatsächlichen Anschlüsse. Dazu gehören der direkte oder vermittelte Datenpfad, die CPU-Auslastung und das Verhalten nach einem Internetwechsel. Meine Auswahl hier beruht auf den Architektur- und Betriebsunterschieden; eine gemessene Geschwindigkeitsrangliste dieser Produkte ist damit nicht verbunden.

Remote Access: Einzelne Geräte zusätzlich anbinden

Verbindet sich der Laptop eines Mitarbeiters von zu Hause mit dem Firmennetz, ist das Remote Access beziehungsweise Client-to-Site. Der Client läuft auf dem Laptop; dadurch wird nicht automatisch dessen gesamtes Heimnetz mit dem Büro verbunden. Das kann über einen Remote-Access-Dienst auf der zentralen Firewall oder über die Clients der verglichenen Plattformen geschehen. Bei einem persönlich angemeldeten Client lassen sich Berechtigungen zusätzlich an Benutzer und Gruppen knüpfen.

Ein Homeoffice kann dagegen auch ein Site-to-Site-Standort sein: Dann verbindet ein Gateway dort ein freigegebenes Netz oder VLAN mit dem Büro. Entscheidend ist also nicht, ob jemand zu Hause oder in einer Zweigstelle sitzt, sondern ob ein einzelnes Gerät oder ein Netz angebunden wird. Für einzelne Mitarbeitergeräte ist Remote Access häufig der passendere Umfang. Es gibt keinen Grund, dafür ungefragt das gesamte private Heimnetz erreichbar zu machen.

Wo für mich welche Lösung Sinn ergibt

Für wenige feste Standorte mit vorhandenen Firewalls würde ich zuerst das klassische VPN ansehen und bewusst zwischen Hub-and-Spoke und direkten Tunneln wählen. Für Standorte hinter NAT und eine zentral verwaltete Vernetzung mit möglichst direkten Datenwegen würde ich Tailscale und NetBird gegeneinander ausprobieren. Wenn eigener Betrieb der Steuerung eine klare Anforderung ist, gehört NetBird besonders früh in diesen Test. In einer Umgebung mit vorhandenen Cloudflare-One-Richtlinien würde ich Cloudflare Mesh genauer prüfen, einschließlich des Beta-Status und der Verarbeitung im Anbieternetz. Zusätzlicher Remote Access ist anschließend ein eigenes Auswahlkriterium.

Als zusätzliche Option ist Headscale interessant: eine selbst betriebene Implementierung des Tailscale-Koordinationsservers. Es ist ein eigenes Projekt mit eigenem Funktionsumfang und kein vollständiger Ersatz für jedes Merkmal des gehosteten Dienstes. Manuell betriebenes WireGuard wiederum gehört bereits zum klassischen Modell und ist sinnvoll, wenn wenige Tunnel ohne zusätzliche Verwaltungsebene reichen.

Wenn ich nach der besten Lösung gefragt werde, möchte ich am Ende eine Empfehlung geben können, die zum Betrieb und zu dessen nächsten Änderungen passt. Für einen überschaubaren Aufbau mit vorhandenen Firewalls kann das weiterhin das klassische VPN sein. Bei anderen Anschlussbedingungen oder Anforderungen an die Verwaltung lohnt sich der Blick auf die Mesh-Ansätze. Ich würde die Entscheidung daran festmachen, ob sich die benötigten Verbindungen sicher betreiben, nachvollziehen und bei einem Ausfall wiederherstellen lassen.

Bis zum nächsten Mal,
Euer Joe