Cloudflare Mesh veröffentlicht – sicheres privates Networking für Nutzer, Nodes, Agenten und Workers

• In einer Zeit, in der AI-Agenten sicher auf Ressourcen in privaten Netzwerken zugreifen müssen, stoßen bestehende Tools wie VPNs oder SSH-Tunnel an strukturelle Grenzen, da sie nicht für autonome Software statt für Menschen ausgelegt sind
• Cloudflare Mesh ist eine bidirektionale Private-Networking-Lösung, die mit einem einzigen leichtgewichtigen Connector persönliche Geräte, entfernte Server und Agenten verbindet
• Durch die Erweiterung von Workers VPC können mit dem Agents SDK entwickelte Agenten direkt auf das Mesh-Netzwerk zugreifen; die Verbindung zu internen Services wird über einen einzigen gebundenen fetch()-Aufruf unterstützt
• Für bestehende Cloudflare-One-Nutzer werden Gateway-Richtlinien, Access-Regeln und Device-Posture-Checks automatisch auf Mesh-Traffic angewendet, ganz ohne zusätzliche Konfiguration
• Mit kostenlos bis zu 50 Nodes und 50 Nutzern sowie globalem Edge-Routing über mehr als 330 Städte ist eine sofortige Einführung vom Startup bis zum Enterprise möglich

---

Das Problem des Zugriffs auf private Netzwerke im Agenten-Zeitalter

• Workflows, in denen AI-Agenten private Ressourcen erreichen müssen, nehmen stark zu – etwa beim Abfragen von Staging-Datenbanken, beim Aufruf interner APIs oder beim Zugriff auf Services im Heimnetz
• Grenzen bestehender Werkzeuge:
  • VPNs erfordern interaktive Anmeldung
  • SSH-Tunnel erfordern manuelle Konfiguration
  • Wird ein Service öffentlich exponiert, entstehen Sicherheitsrisiken
  • Es fehlt an Transparenz darüber, was ein Agent nach dem Verbindungsaufbau tatsächlich tut

Drei zentrale Workflows

• Remote-Zugriff für persönliche Agenten: Wenn OpenClaw auf einem Mac mini läuft und von Mobilgerät oder Laptop aus genutzt wird, öffnet eine öffentliche Exponierung zugleich Shell-, Dateisystem- und Netzwerkzugriff – eine einzige Fehlkonfiguration kann ein Sicherheitsrisiko auslösen
• Zugriff von Coding-Agenten auf Staging-Umgebungen: Tools wie Claude Code, Cursor oder Codex müssen auf Services in einer privaten Cloud-VPC zugreifen, was bisher häufig eine Internet-Exponierung oder Tunneling der gesamten VPC erfordert
• Verbindung bereitgestellter Agenten mit privaten Services: Wenn Workers-Agenten auf Basis des Agents SDK auf interne APIs oder Datenbanken zugreifen, sind eng begrenzte Berechtigungen, Audit-Trails und Schutz vor dem Abfluss von Zugangsdaten erforderlich

Architektur und Funktionsweise von Cloudflare Mesh

• Ein einzelner leichtgewichtiger Connector (Binärdatei) verbindet persönliche Geräte, entfernte Server und Benutzerendpunkte
• Verbundene Geräte kommunizieren bidirektional über private IPs und nutzen dabei Cloudflares globales Netzwerk mit mehr als 330 Städten
• Der bisherige WARP Connector wird in Cloudflare Mesh node umbenannt, der WARP Client in Cloudflare One Client
• Konkrete Nutzungsszenarien:
  • Mit dem Cloudflare One Client für iOS wird vom Mobilgerät aus eine sichere Verbindung zu OpenClaw auf dem lokalen Mac mini hergestellt
  • Mit dem Cloudflare One Client für macOS kann ein Coding-Agent auf dem Laptop auf Staging-Datenbanken und APIs zugreifen
  • Über einen Mesh-Node auf einem Linux-Server lassen sich externe Cloud-VPCs miteinander verbinden, sodass Agenten auf Ressourcen und MCP in privaten externen Netzwerken zugreifen können

Unterschied zwischen Mesh und Tunnel

• Cloudflare Tunnel: geeignet als Proxy für unidirektionalen Traffic vom Cloudflare-Edge zu einem bestimmten privaten Service wie Webserver oder Datenbank
• Cloudflare Mesh: stellt ein bidirektionales Many-to-Many-Netzwerk bereit, in dem alle Geräte und Nodes über private IPs gegenseitig erreichbar sind
  • Statt für jede Ressource einen separaten Tunnel zu konfigurieren, kann auf alle an das Mesh angebundenen Ressourcen zugegriffen werden

Nutzung des Cloudflare-Netzwerks: Lösung für NAT-Traversal-Probleme

• Ein Großteil des Internets befindet sich hinter NAT (Network Address Translation); wenn zwei Geräte beide hinter NAT sitzen, ist bei fehlgeschlagener Direktverbindung meist ein Relay-Server nötig
• Ist die Relay-Infrastruktur nur mit begrenzten PoPs (Points of Presence) ausgestattet, läuft ein erheblicher Teil des Traffics über Relays, was zu höherer Latenz und geringerer Zuverlässigkeit führt
• Cloudflare Mesh routet den gesamten Traffic über Cloudflares globales Netzwerk und bietet dadurch konsistente Performance ohne separate Relay-Server
• Gerade bei Cross-Region- und Multi-Cloud-Traffic liefert es durchgehend bessere Performance als Routing über das öffentliche Internet

Zentrale Leistungsmerkmale

• 50 Nodes und 50 Nutzer kostenlos: in jedem Cloudflare-Konto enthalten
• Globales Edge-Routing: mehr als 330 Städte, optimiertes Backbone-Routing, keine leistungsschwachen Fallback-Pfade
• Sicherheitskontrollen ab Tag 1: Gateway-Richtlinien, DNS-Filterung, DLP, Traffic-Inspektion und Device-Posture-Checks lassen sich auf derselben Plattform aktivieren; jede Funktion per einfachem Toggle zuschaltbar
• Hohe Verfügbarkeit (HA): Mehrere Connectoren können mit demselben Token im Active-Passive-Modus betrieben werden, bewerben dieselbe IP-Route und ermöglichen bei Ausfällen automatisches Failover

Workers-VPC-Integration

• Workers VPC wird erweitert, sodass das gesamte Mesh-Netzwerk aus Workers und Durable Objects heraus zugänglich ist
• Im wrangler.jsonc-File wird das Mesh-Netzwerk über das reservierte Schlüsselwort cf1:network gebunden:
  • "vpc_networks": [{ "binding": "MESH", "network_id": "cf1:network", "remote": true }]
• Im Worker-Code ist mit env.MESH.fetch("http://10.0.1.50/api/data") direkter Zugriff auf private Hosts möglich, ohne vorherige Registrierung
• Die parallele Nutzung zusammen mit Tunnel-basierten VPC-Bindings ist möglich und erweitert die Auswahl an Netzwerksicherheitsmodellen
• Damit lassen sich Cross-Cloud-Agenten und MCPs aufbauen, die sicher auf private Datenbanken, interne APIs und MCP zugreifen

Komponenten der Gesamtarchitektur

• Mesh-Nodes: Auf Servern, VMs und Containern läuft eine Headless-Version des Cloudflare One Client, erhält eine Mesh-IP und ermöglicht bidirektionale private IP-Kommunikation zwischen Services
• Geräte: Auf Laptops und Smartphones läuft der Cloudflare One Client und greift direkt auf Mesh-Nodes zu — SSH, Datenbankabfragen und API-Aufrufe erfolgen vollständig über private IPs
• Workers-Agenten: Greifen über Workers-VPC-Network-Bindings auf private Services zu; das Netzwerk steuert die Reichweite des Agenten, der MCP-Server steuert das Verhalten des Agenten

Kommende Roadmap

• Hostname-Routing

  • Im Laufe dieses Sommers soll das Hostname-Routing von Cloudflare Tunnel auf Mesh erweitert werden
  • Traffic kann dann über private Hostnames wie wiki.local oder api.staging.internal geroutet werden, wodurch die Pflege von IP-Listen entfällt
  • Das reduziert Routing-Komplexität bei dynamischen IPs, Auto-Scaling-Gruppen und temporären Container-Umgebungen

• Mesh DNS

  • Später in diesem Jahr sollen alle am Mesh beteiligten Nodes und Geräte automatisch routbare interne Hostnames erhalten
  • Zugriff auf postgres-staging.mesh wird ohne DNS-Konfiguration oder manuelle Records möglich
  • In Kombination mit Hostname-Routing wird dadurch Zugriff ohne IP-Adressen wie ssh postgres-staging.mesh oder curl http://api-prod.mesh:3000/health möglich

• Identity-aware Routing

  • Derzeit verwenden Mesh-Nodes auf der Netzwerkebene eine gemeinsame ID; Geräte authentifizieren sich mit Benutzer-IDs, aber Nodes verfügen nicht über eine separate Routing-ID, die Gateway-Richtlinien unterscheiden könnten
  • Ziel ist es, jedem Node, Gerät und Agenten eine eindeutige ID zuzuweisen, damit Richtlinien nach dem zugreifenden Subjekt statt nach IP-Bereichen geschrieben werden können
  • Vorgesehenes Modell für Agenten-IDs:
    • Principal/Sponsor: die Person, die die Aktion genehmigt hat
    • Agent: das AI-System, das die Aktion ausführt, einschließlich Session-ID
    • Scope: der zulässige Aufgabenbereich des Agenten
  • So sollen feingranulare Richtlinien möglich werden, etwa „Lesen für Agenten erlaubt, Schreiben nur direkt durch Menschen“
  • Die Infrastruktur ist bereits vorhanden (Node-spezifische Tokens, Benutzer-IDs, servicebezogene VPC-Bindings); derzeit wird die ID-Sichtbarkeit in der Policy-Ebene umgesetzt

• Unterstützung für Mesh-Container

  • Aktuell laufen Mesh-Nodes auf VMs und Bare-Metal-Linux-Servern
  • Ein Mesh-Docker-Image für Container-Umgebungen wie Kubernetes-Pods, Docker-Compose-Stacks und CI/CD-Runner ist in Vorbereitung
  • Durch Hinzufügen eines Mesh-Sidecars zu einem Docker-Compose-Stack erhalten alle Services im Stack privaten Netzwerkzugang
  • In CI/CD-Pipelines kann ein GitHub-Actions-Runner das Mesh-Container-Image laden, dem Netzwerk beitreten, Integrationstests gegen die Staging-Umgebung ausführen und den Node beim Beenden des Containers automatisch entfernen
  • Bereitstellung ist für später in diesem Jahr geplant

So legst du los

• Cloudflare Mesh: Im Cloudflare-Dashboard unter Networking > Mesh starten, kostenlos bis zu 50 Nodes und 50 Nutzer
• Agents SDK + Workers VPC: mit npm i agents installieren; siehe Workers-VPC-Quickstart und Leitfaden für Remote-MCP-Server
• Bestehende Cloudflare-One-Nutzer: kompatibel mit vorhandenen Einstellungen; Gateway-Richtlinien, Device-Posture-Checks und Access-Regeln werden automatisch auf Mesh-Traffic angewendet

[eoeoe]

Ich hatte ursprünglich einen Tunnel auf meinem Heimcomputer eingerichtet und nur RDP genutzt ... den Agenten sollte ich wohl auch mal ausprobieren!

[yangeok]

Wenn der Preis kostenlos ist und die Sicherheit stimmt, nutzt man so etwas natürlich sofort, haha.

Wenn man so etwas sieht, bekommt man auch eine ungefähre Ahnung davon, in welche Richtung sich DevOps verändern wird.

[xguru]

Als ich „Mesh“ gelesen habe, dachte ich erst, das sei so etwas Ähnliches wie Tailscale, aber es ist doch leicht anders.
Es ist keine P2P-Struktur wie bei Tailscale, sondern läuft über das CF-Edge-Netzwerk,
dadurch werden Sicherheitsfunktionen wie Gateway-Richtlinien oder DLP automatisch angewendet,
und dass man aus dem Workers-/Agents-SDK mit einer einzigen fetch()-Zeile einen privaten Service aufrufen kann, ist der eigentliche Unterschied.
Ich bleibe einfach bei Tailscale..

[minhoryang]

Ich hatte eher den Eindruck, dass dadurch, dass das Cloudflare Edge die Rolle des DERP-Relay von Tailscale übernimmt, nicht ein noch stärkerer Wettbewerber aufgetaucht ist. Auch Tailscale sendet die Kommunikation über ein DERP-Relay, wenn P2P nicht möglich ist. Der Teil „Wenn die PoPs (Points of Presence) der Relay-Infrastruktur begrenzt sind, läuft ein erheblicher Teil des Traffics über das Relay, was zu höherer Latenz und geringerer Zuverlässigkeit führt“ klang für mich besonders so, als sei damit Tailscale gemeint. Ich werde wahrscheinlich beide gemischt nutzen. Ich gehe direkt zum Experimentieren über.

[minhoryang]

Die Cloudflare-Edge verwendet ebenfalls einen Bereich, der mit 100.96.0.0, also 100., beginnt. Ich wollte es zusammen mit Tailscale nutzen, aber von der Installation bis zur Verwendung gibt es hier und da einige Hürden. Wer es wie ich gleichzeitig verwenden möchte, sollte das beachten.