Ing. Calogero Bono
Cloudflare hat die Unterstützung für private Ursprünge allgemein verfügbar gemacht, nachdem sie im Juni in einer geschlossenen Beta gestartet war. Ein DNS-Eintrag mit Proxy kann jetzt auf eine private IP zeigen, und der Traffic erreicht den Server über die bereits bestehende Cloudflare-One-Verbindung. Wer interne APIs, Backends von KI-Agenten oder Betriebstools betreibt, kann damit WAF, Cache und Bot Management nutzen, ohne den Server ins Internet zu stellen. Offen bleibt aber, welche Voraussetzungen wirklich nötig sind.
Ein paar Begriffe, bevor wir in die Fakten einsteigen. Ursprung ist der Server, auf dem die Anwendung liegt, hinter Cloudflare. WAF ist die Web Application Firewall, die schädliche Anfragen filtert. Cloudflare One ist die Plattform des Unternehmens für private Konnektivität, mit Tunnels und Netzen. RFC 1918 definiert private IPv4-Adressen wie 10.0.0.50. CGNAT bezeichnet die geteilten Adressen aus dem Block 100.64.0.0/10, die Netzbetreiber verwenden.
Was hat Cloudflare veröffentlicht?
Laut dem offiziellen Blog von Cloudflare war der Zugang während der geschlossenen Beta geeigneten Kunden vorbehalten, die ihn über ihren Account Team anfragen mussten. Jetzt öffnet sich der Zugang über diesen Kreis hinaus.
Man richtet einen A- oder AAAA-Eintrag mit Proxy auf eine private IP, und die Anwendungstools funktionieren wie bei öffentlichen Ursprüngen.
- WAF und verwaltete Regeln
- Bot Management
- Rate Limiting
- Caching
- Transformations- und Rewrite-Regeln
- Workers
Welches Problem löst das?
Cloudflare berichtet, dass ihnen dasselbe Problem immer wieder begegnet ist. Interne APIs, Backends von KI-Agenten, MCP-Server und Betriebstools sind nicht fürs Internet gebaut, müssen aber Anfragen von Partnern, Kunden oder Agenten annehmen.
Bisher erforderte es, Cloudflare vor diese Dienste zu stellen, eine öffentliche IP, einen offenen Port an der Firewall oder cloudflared neben dem Server. Oft blieben private Anwendungen deshalb ohne den gleichen Schutz wie öffentliche.
Wer in privaten Netzen arbeitet, findet in unserem Leitfaden zu privaten Subnetzen und Security Groups auf AWS weitere Details.
Wie funktioniert das private Routing?
Man legt einen proxied Eintrag zum Ursprung an. Für die unterstützten privaten Bereiche aktiviert sich die Option für privates Routing von selbst. Hat der Ursprung eine öffentliche IP, die nur aus dem privaten Netz erreichbar ist, schaltet man sie manuell ein.
Die Einstellung ist automatisch für RFC-1918-Adressen, für den CGNAT-Block RFC 6598 und für lokale IPv6-Adressen nach RFC 4193. Für diese Bereiche lässt sie sich nicht deaktivieren, und ein entsprechender Versuch über die API liefert einen Fehler.
Über die API genügt das Attribut private_routing am DNS-Eintrag. Sieht der Proxy es, leitet er die Anfrage an die private Netzwerkebene weiter, die die bestehende Verbindung nutzt, also IPsec, GRE, Cloudflare Tunnel, CNI oder Cloudflare Mesh. Mit Cloudflare WAN braucht es keinen Connector am Ursprung. Mit Mesh kann ein Connector im Netz mehrere Ursprünge bedienen.
Was braucht man zur Aktivierung?
Cloudflare nennt einige Voraussetzungen.
- Die Berechtigung Private Origins für das Konto, die man beim Account Team anfragt.
- Cloudflare-One-Konnektivität mit IPsec, GRE, CNI, Tunnel oder Mesh.
- Aktives Unified Routing, außer bei Tunnel.
- Bei WAN oder Mesh eine Rückroute für die Quellbereiche von Cloudflare, 100.64.0.0/12 für IPv4 und 2606:4700 – cf1:5000 – – /64 für IPv6.
Cloudflare warnt, dass die fehlende Rückroute der häufigste Konfigurationsfehler war. Laufen Anfragen in ein Timeout und kommt am Server nichts an, prüfe zuerst diese Route.
Grenzen, die du kennen solltest
Es bleiben Einschränkungen. Argo Smart Routing und dedizierte Egress-IPs des CDN werden nicht unterstützt, und die Health Checks des Ursprungs erfordern Load Balancing. Die vollständige Liste steht in der Entwicklerdokumentation. Preise und unabhängige Tests liegen nicht vor, und die Aktivierung läuft über den Account Team. Der Traffic zwischen privaten Netzen ist noch in Arbeit.
Was sich für alle ändert, die digital arbeiten
Wer APIs für Partner oder KI-Agenten bereitstellt, kann den Server ohne öffentliche IP und ohne offene Ports betreiben und so die Angriffsfläche verkleinern. Ein Server mit klaren Zugriffsregeln muss trotzdem auf Netzwerkebene unter Linux sorgfältig konfiguriert werden. Bereits genutzte WAF-Regeln, Cache und Bot Management greifen auf den Hostnamen ohne weitere Eingriffe. Für kleine Unternehmen ist die Hürde vor allem kommerziell, denn es braucht eine Cloudflare-One-Infrastruktur und den Kontakt zum Vertrieb.
Unsere Einschätzung
Der Schritt ist sinnvoll, weil er öffentliche Schutzmechanismen dorthin bringt, wo man bisher aus Bequemlichkeit darauf verzichtet hat. Der versteckte Preis ist aber die Abhängigkeit. Um einen privaten Dienst zu schützen, bindet man Netzwerk, DNS und Filter an einen einzigen Anbieter, und die Voraussetzungen laufen über den Account Team. Für Unternehmen, die Cloudflare One bereits nutzen, ergibt das Sinn. Alle anderen sollten einfachere Lösungen prüfen, bevor sie sich festlegen.
Häufig gestellte Fragen
Was sind die privaten Ursprünge von Cloudflare?
Das sind Server mit privater IP, die Cloudflare über deine Cloudflare-One-Verbindung erreicht. Sie bleiben aus dem Internet unerreichbar. WAF, Cache, Bot Management und Workers funktionieren wie bei einem öffentlichen Ursprung.
Muss ich einen Port an der Firewall öffnen?
Nein. Laut Cloudflare behält der Ursprung seine private IP, und an der Firewall ist keine eingehende Ausnahme nötig. Mit Cloudflare WAN braucht es auf dem Server nicht einmal einen Connector.
Welche Verbindungen werden unterstützt?
Cloudflare nennt IPsec, GRE, CNI, Cloudflare Tunnel und Cloudflare Mesh. Unified Routing funktioniert mit allen außer Tunnel.
Warum laufen Anfragen in ein Timeout?
Meistens fehlt die Rückroute. Laut Cloudflare war das in der Beta der häufigste Fehler. Mit WAN oder Mesh richte die Routen für 100.64.0.0/12 und 2606:4700 – cf1:5000 – – /64 ein.
Funktioniert das auch zwischen privaten Netzen?
Noch nicht. Die Veröffentlichung deckt öffentlichen Traffic zu privaten Ursprüngen ab. Cloudflare plant eine geschlossene Beta für den Traffic zwischen privaten Netzen Anfang 2027.
Der Schritt zum Traffic zwischen privaten Netzen, erwartet 2027
Der nächste angekündigte Schritt von Cloudflare ist, WAF und Rate Limiting auch zwischen privaten Netzen verfügbar zu machen. Vorerst ist das ein Vorhaben, die geschlossene Beta ist für die ersten Monate 2027 angesetzt.
- Lies in der Dokumentation die aktuelle Liste der Einschränkungen, bevor du eine Migration planst.
- Frag deinen Account Team nach den Zugangsbedingungen für Private Origins und die kommende private Beta.
- Erfasse, welche internen Dienste tatsächlich Anfragen von außen erhalten müssen, damit du weißt, wo dieser Schutz nötig ist.
