Résumé

  • L’exemple public de Cloudflare conserve une route de production étendue dans le réseau par défaut et décrit son accessibilité hors du chevauchement après sélection de staging.
  • La présentation actuelle limite son explication d’un possible repli de route non trouvée aux routes WAN ; elle ne prouve pas un comportement universel de tous les tunnels.
  • L’entrée du trafic client, le contexte de routage et la politique d’autorisation restent des décisions distinctes.

Le nom rassure avant de préciser

Un environnement appelé staging paraît décrire une limite : le travail de test d’un côté, la production de l’autre. Ce nom est utile aux équipes, mais il ne suffit pas à déterminer l’ensemble des destinations accessibles. Une organisation pourrait acheter une capacité de connexion tout en supposant, sans l’avoir établi, qu’une sélection d’environnement constitue aussi un refus de tout le reste.

Les adresses privées expliquent pourquoi un contexte est nécessaire. RFC 1918 leur donne une unicité locale, dans une entreprise ou un ensemble coordonné d’entreprises, et non une identité mondiale. Deux systèmes peuvent donc partager la même adresse sans être la même destination. Lorsqu’on relie les environnements, il faut conserver le sens local de cette adresse.

Le guide des réseaux virtuels de Cloudflare associe les routes qui se chevauchent à des contextes différents, sélectionnables via Cloudflare One Client. La destination ne se réduit alors plus à une chaîne IP : elle dépend aussi du contexte dans lequel la chaîne est résolue.

Cette capacité peut avoir une valeur commerciale sans qu’un montant économisé soit établi ici. Elle permet de ne pas considérer toute duplication privée comme un défaut à supprimer avant l’intégration. En revanche, le travail se reporte vers les associations de routes et la sélection des clients. La question des destinations autorisées ne disparaît pas.

Une route de production reste en place

Le parcours consacré aux IP qui se chevauchent, mis à jour le 23 avril 2026, décrit un cas précis. La production utilise 10.0.0.0/8 via Tunnel-A ; le test utilise 10.0.1.0/24 via Tunnel-B. Les deux appartiennent d’abord au réseau par défaut. Dans la partie commune, la route plus spécifique dirige le trafic vers le test.

L’exemple ajoute ensuite une route de production précise pour 10.0.1.0/24 et attribue les deux versions de cette plage aux réseaux virtuels production et staging. La route large 10.0.0.0/8 reste cependant dans default. Le texte indique qu’en choisissant staging, l’utilisateur atteint encore les autres adresses de production, tandis que la partie commune conduit au test.

C’est l’énoncé d’un exemple publié, pas un chemin mesuré chez un client. Il suffit néanmoins à distinguer deux résultats : sélectionner correctement la destination du chevauchement et interdire toutes les destinations de production. Dans cet exemple, le premier n’est pas une preuve du second.

Ce choix peut être intentionnel. Certains utilisateurs peuvent avoir besoin de la plage partagée et de son exception de test. Rien ne permet de qualifier cette organisation de violation. L’erreur d’achat consisterait à retenir une garantie négative parce que le nom paraît l’exprimer, alors que l’exemple ne la donne pas.

Ne pas fabriquer une règle générale

La présentation des réseaux virtuels, mise à jour le 25 août 2026, décrit des tables séparées. Elle précise qu’une route non trouvée dans le réseau sélectionné peut conduire à un repli vers la table par défaut pour les routes WAN. Les connexions WAN par IPsec, GRE ou CNI sont décrites comme utilisant default uniquement.

Cette restriction de portée importe. Elle ne démontre pas que toute absence de route dans n’importe quel tunnel conduise systématiquement à une route Tunnel par défaut. La portée de l’exemple d’avril et celle de la formulation WAN d’août ne doivent pas être fusionnées en un algorithme universel inventé par le lecteur.

La conclusion solide porte sur la preuve requise avant engagement. Le comportement doit être compris pour les produits et connexions proposés. Si les documents ne donnent pas la même portée, une clarification du fournisseur est plus utile qu’une certitude supplémentaire ajoutée par le modèle de sélection.

Aucune configuration client ni sonde réseau n’a été utilisée ici pour résoudre ce périmètre. Aucun défaut d’isolation, fuite de données ou incident de disponibilité n’est établi. Le sujet est ce qu’une description publique permet de promettre dans un dossier d’investissement.

Le client décide aussi quel trafic entre

Le guide de connexion d’une IP ou d’un CIDR, mis à jour le 23 juin 2026, ajoute une autre frontière. Une route sans réseau virtuel précisé va dans default. Le client exclut également par défaut le trafic RFC 1918 : une sélection appropriée de Split Tunnels doit donc faire entrer le trafic privé voulu dans le service.

Créer une route ne prouve pas que tous les paquets visés y seront présentés. À l’inverse, inclure une plage privée trop étendue peut affecter des ressources locales de l’utilisateur ; le guide évoque ce risque. L’accord opérationnel couvre donc la flotte de clients, pas seulement les connecteurs.

Il ne s’agit pas ici d’une recette de configuration ni d’une invitation à modifier des appareils. La question commerciale est de savoir qui possède cette décision de sélection et si elle correspond aux destinations comprises dans le service acheté. Un inventaire de tunnels seul peut laisser ce travail sans responsable.

Le routage n’est pas l’autorisation

Le guide de connexion recommande séparément un filtrage Gateway, avec un blocage général et des permissions prioritaires par application ou IP. Son propos sur l’accessibilité par défaut concerne les appareils inscrits, pas toute personne sur Internet. Un chemin réseau n’est pas non plus une acceptation par l’application cible.

La documentation des politiques réseau, mise à jour le 24 août 2026, décrit une action et une expression logique. Elle propose un sélecteur Virtual Network pour le trafic passant par un contexte donné via Cloudflare One Client. Le contexte peut donc entrer dans la politique ; son nom ne constitue pas à lui seul cette politique.

L’acheteur a besoin de deux descriptions concordantes : où le trafic peut être routé et ce qu’il doit pouvoir atteindre. Une plage privée peut être correctement distinguée tout en appartenant à un ensemble autorisé plus large que celui prévu par l’équipe. Cohérence technique et adéquation de l’accès ne sont pas synonymes.

Les réseaux virtuels répondent ainsi à une véritable ambiguïté. Le bon achat conserve autour d’eux l’entrée client, le contexte, la portée par défaut et les décisions d’autorisation. Le nom staging ouvre le travail. Il ne prouve pas que toutes les frontières utiles soient terminées.

Sources