Ing. Calogero Bono
Cloudflare a rendu généralement disponible la prise en charge des origines privées, lancée en bêta fermée en juin. Un enregistrement DNS avec proxy peut désormais pointer vers une adresse IP privée, et le trafic atteint le serveur via la connexion Cloudflare One que tu as déjà. Pour qui gère des API internes, des backends d'agents IA ou des outils opérationnels, cela signifie appliquer WAF, cache et gestion des bots sans exposer le serveur sur Internet. Reste à comprendre quels prérequis sont vraiment nécessaires.
Quelques termes avant d'entrer dans les faits. Origine est le serveur qui héberge l'application, derrière Cloudflare. WAF est le pare-feu applicatif qui filtre les requêtes malveillantes. Cloudflare One est la plateforme de connectivité privée de l'entreprise, avec tunnels et réseaux. RFC 1918 définit les adresses IPv4 privées, comme 10.0.0.50. CGNAT désigne les adresses partagées du bloc 100.64.0.0/10, utilisées par les opérateurs.
Qu'a publié Cloudflare ?
Selon le blog officiel de Cloudflare, pendant la bêta fermée l'accès était réservé aux clients éligibles, qui le demandaient à leur account team. Désormais, l'accès s'ouvre au-delà de ce groupe.
On pointe un enregistrement A ou AAAA avec proxy vers une IP privée, et les outils applicatifs fonctionnent comme pour les origines publiques.
- WAF et règles gérées
- Gestion des bots
- Rate limiting
- Mise en cache
- Règles de transformation et de réécriture
- Workers
Quel problème cela résout-il ?
Cloudflare dit avoir souvent entendu le même problème. Les API internes, les backends d'agents IA, les serveurs MCP et les outils opérationnels ne sont pas conçus pour rester sur Internet, mais doivent accepter des requêtes de partenaires, de clients ou d'agents.
Auparavant, placer Cloudflare devant ces services exigeait une IP publique, un port ouvert sur le pare-feu ou cloudflared à côté du serveur. Souvent, les applications privées restaient sans les mêmes protections que les applications publiques.
Qui travaille sur les réseaux privés peut approfondir avec notre guide sur les sous-réseaux privés et les groupes de sécurité sur AWS.
Comment fonctionne le routage privé ?
On crée un enregistrement avec proxy vers l'origine. Pour les plages privées prises en charge, l'option de routage privé s'active automatiquement. Si l'origine a une IP publique joignable uniquement depuis le réseau privé, on l'active manuellement.
Le paramétrage est automatique pour les adresses RFC 1918, pour le bloc CGNAT RFC 6598 et pour les IPv6 locales RFC 4193. Pour ces plages, il ne peut pas être désactivé, et la tentative via API renvoie une erreur.
Via API, il suffit de l'attribut private_routing sur l'enregistrement DNS. Lorsque le proxy le détecte, il transmet la requête au niveau de réseau privé, qui utilise la connectivité existante, parmi IPsec, GRE, Cloudflare Tunnel, CNI ou Cloudflare Mesh. Avec Cloudflare WAN, aucun connecteur n'est nécessaire sur l'origine. Avec Mesh, un connecteur dans le réseau peut servir plusieurs origines.
Que faut-il pour l'activer ?
Il faut quelques prérequis indiqués par Cloudflare.
- L'autorisation Private Origins sur le compte, à demander à l'account team.
- Une connectivité Cloudflare One avec IPsec, GRE, CNI, Tunnel ou Mesh.
- Unified Routing activé, sauf avec Tunnel.
- Avec WAN ou Mesh, une route de retour pour les plages source de Cloudflare, 100.64.0.0/12 pour IPv4 et 2606:4700 – cf1:5000 – – /64 pour IPv6.
Cloudflare prévient que la route de retour manquante est l'erreur de configuration la plus fréquente. Si les requêtes expirent et que rien n'arrive au serveur, vérifie d'abord celle-ci.
Limites à connaître
Des limitations subsistent. Argo Smart Routing et les adresses IP de sortie dédiées du CDN ne sont pas pris en charge, et les contrôles de santé de l'origine exigent l'équilibrage de charge. La liste complète figure dans la documentation pour développeurs. Nous n'avons ni tarifs ni vérifications indépendantes, et l'activation passe par ton account team. Le trafic entre réseaux privés est encore en cours de développement.
Ce qui change pour qui travaille avec le numérique
Si tu exposes des API à des partenaires ou à des agents IA, tu peux garder ton serveur sans IP publique et sans ports ouverts, ce qui réduit la surface d'attaque. Un serveur aux règles d'accès claires reste toutefois à configurer avec soin au niveau du réseau Linux. Les règles WAF, le cache et la gestion des bots déjà en place s'appliquent au nom d'hôte sans autre intervention. Pour les petites entreprises, la contrainte est commerciale, car il faut une infrastructure Cloudflare One et un contact avec le service commercial.
Notre avis
Ce pas est utile, car il apporte les protections publiques là où on renonçait auparavant par commodité. Mais le coût caché, c'est la dépendance. Pour protéger un service privé, on lie réseau, DNS et filtres à un seul fournisseur, avec des prérequis qui passent par l'account team. Pour les entreprises qui utilisent déjà Cloudflare One, c'est pertinent ; pour les autres, mieux vaut comparer des solutions plus simples avant de s'engager.
Questions fréquentes
Que sont les origines privées de Cloudflare ?
Ce sont des serveurs avec une IP privée, joints par Cloudflare via ta connexion Cloudflare One. Ils restent non exposés sur Internet. WAF, cache, gestion des bots et Workers fonctionnent comme pour une origine publique.
Faut-il ouvrir un port sur le pare-feu ?
Non. Selon Cloudflare, l'origine conserve son IP privée et aucune exception entrante n'est nécessaire sur le pare-feu. Avec Cloudflare WAN, il n'est même pas nécessaire d'installer un connecteur sur le serveur.
Quelles connexions sont prises en charge ?
Cloudflare indique IPsec, GRE, CNI, Cloudflare Tunnel et Cloudflare Mesh. Unified Routing fonctionne avec toutes, sauf avec Tunnel.
Pourquoi les requêtes expirent-elles ?
Presque toujours parce que la route de retour manque. Cloudflare affirme que c'est l'erreur la plus fréquente pendant la bêta. Avec WAN ou Mesh, configure les routes pour 100.64.0.0/12 et 2606:4700 – cf1:5000 – – /64.
Cela fonctionne-t-il entre réseaux privés ?
Pas encore. La version actuelle couvre le trafic public vers les origines privées. Cloudflare vise une bêta fermée pour le trafic entre réseaux privés au début de 2027.
Le passage au trafic entre réseaux privés, attendu en 2027
La prochaine étape annoncée par Cloudflare est d'étendre WAF et rate limiting aux échanges entre réseaux privés. Pour l'instant, c'est une ambition, avec une bêta fermée prévue pour les premiers mois de 2027.
- Consulte dans la documentation la liste à jour des limitations avant de planifier une migration.
- Demande à ton account team les conditions d'accès à Private Origins et à la future bêta privée.
- Recense les services internes qui doivent vraiment recevoir des requêtes de l'extérieur, pour savoir où cette protection est nécessaire.
