Brevet FR3157044A1 — publié le 20250620

Il est proposé un procédé mis en œuvre par une passerelle de centre de données, DCGW, et comprenant les étapes de : recevoir (1) un premier message contenant une annonce d’une route vers un premier dispositif d’un premier client, CER2, ledit premier dispositif étant attaché à un réseau privé virtuel, VPN2, recevoir un message distinct du premier message, relatif à une ouverture d’une session d’échange de route avec un routeur, MP-RR, le message distinct comprenant un attribut spécifiant un rôle de serveur ou de client attribué à l’un parmi le client et la passerelle dans une relation serveur-client avec le routeur, lorsque l’attribut spécifie un rôle de serveur à la passerelle ou un rôle de client au routeur, annoncer (2) au routeur une route vers le premier dispositif, CER2, ladite route comprenant un identifiant d’acheminement associé au réseau privé virtuel pour au moins un deuxième dispositif d’un deuxième client, CEL2, ledit deuxième dispositif étant également attaché au réseau privé virtuel par l’intermédiaire d’un dispositif mandataire préalablement configuré avec l’identifiant d’acheminement, et lorsque l’attribut spécifie un rôle de client à la passerelle ou un rôle de serveur au routeur, recevoir (8, 9) une annonce dudit identifiant par le routeur. Figure de l’abrégé : Figure 4 Coordination d’identifiant d’acheminement symétrique pour l’établissement d’un tunnel de communication La présente divulgation se situe dans le domaine des technologies de l'information et des communications, et plus précisément dans le domaine de la gestion de réseaux et de la communication entre dispositifs dans un environnement de réseau privé virtuel. Elle concerne une passerelle de centre de données, un procédé mis en œuvre par une telle passerelle, un programme d’ordinateur pour la mise en œuvre d’un tel procédé et un support d’enregistrement non transitoire lisible par un ordinateur sur lequel est enregistré un tel programme. La technique antérieure dans le domaine des passerelles de centres de données et du routage de réseau privé virtuel (VPN) comprend généralement des systèmes et des méthodes pour l'échange de routes et la gestion de tunnels de communication entre différents dispositifs clients attachés à un VPN. Ces systèmes utilisent des protocoles de routage comme BGP (en anglais Border Gateway Protocol) pour annoncer et recevoir des informations de routage, permettant ainsi la communication entre différents dispositifs sur le réseau. Les VPNs sont par exemple mis en œuvre à partir de technologies MPLS. Un exemple de mise en œuvre d’un tel VPN dans une architecture comprend par exemple une première dorsale, déployée sur un réseau étendu (Internet par exemple) mise en œuvre par exemple par un opérateur, et une deuxième dorsale, mise en œuvre sur réseau local (typiquement dans un centre de données). La connectivité entre un premier dispositif d’un client connecté à la première dorsale et un deuxième dispositif d’un client attaché à la deuxième dorsale (ou entre deux clients attachés à deux deuxièmes dorsales) est rendue effective par le déploiement de deux tunnels juxtaposés sur les dorsales respectives, ces deux tunnels étant joints par une passerelle, par exemple du centre de données, et s’établissant pour la première dorsale entre la passerelle et un routeur d’accès (par exemple un routeur PE, en anglais Provider Edge), auquel est attaché le premier dispositif, et pour la seconde dorsale entre la passerelle et un équipement mandataire (par exemple un proxy MPLS), auquel est attaché le deuxième dispositif. Les architectures de l’état de la technique souffrent de quelques inconvénients pour la mise en œuvre du tunnel sur la dorsale du réseau local (ou dans le centre de données) parmi lesquels : Il faut attendre que la passerelle annonce une route pour le VPN avant de pouvoir configurer l’équipement mandataire. Pendant ce temps, si les clients à l’intérieur du centre de données doivent déjà communiquer entre eux, il est nécessaire de configurer un autre VPN interne au centre de données et qui ne nécessite pas de communiquer avec la passerelle. Si la passerelle décide de changer d’identifiant ou de label MPLS pour un VPN donné, il est nécessaire de reconfigurer les serveurs mandataires associés, ce qui perturbe le fonctionnement des clients. L’entité en charge de la configuration des serveurs mandataires doit s’interfacer avec un Réflecteur de Routes du centre de données pour récupérer le label annoncé par la passerelle, ce qui nécessite l’implémentation d’une API (en anglais Application Programming Interface) entre le Réflecteur de Routes et l’entité en charge de la configuration. Ces différents inconvénients, non exhaustifs, démontrent que les approches existantes sont limitées en termes de flexibilité et d’efficacité, notamment lors de l’établissement de sessions d’échange de route et de la configuration de tunnels bidirectionnels. Résumé L’invention vise à améliorer la situation. Il est proposé, selon un aspect, un procédé mis en œuvre par une passerelle de centre de données, DCGW, et comprenant les étapes de : recevoir un premier message contenant une annonce d’une route vers un premier dispositif d’un premier client, CER2, ledit premier dispositif étant attaché à un réseau privé virtuel, VPN2, et recevoir, de manière asynchrone par rapport à la réception du premier message, un deuxième message comprenant un identifiant d’acheminement associé au réseau privé virtuel, l’identifiant étant choisi par une entité d’orchestration de conteneurs d’applications pour au moins un deuxième dispositif d’un deuxième client, CEL2, ledit deuxième dispositif étant également attaché au réseau privé virtuel, VPN2, par l’intermédiaire d’un équipement mandataire, l’identifiant d’acheminement étant préalablement configuré sur l’équipement mandataire en vue de l’établissement d’un tunnel bidirectionnel entre la passerelle et l’équipement mandataire, ledit tunnel étant constitutif du réseau privé virtuel VPN2. Le procédé proposé est particulièrement utile pour établir et gérer des tunnels bidirectionnels en collaboration avec des proxy MPLS, facilitant la connexion entre deux dispositifs au sein d’un même VPN. Cette fonctionnalité assure une communication fluide et sécurisée entre les dispositifs raccordés. Notamment, le procédé permet de mettre en place un tunnel dans un centre de données, ledit tunnel fonctionnant de manière bidirectionnelle en utilisant un identifiant unique pour les deux sens de communication. Cela élimine le besoin d'annoncer des routes spécifiques par la passerelle, simplifiant ainsi l'architecture globale. De plus, cela évite la nécessité d'une interaction complexe entre l'entité responsable de l'orchestration des données et les dispositifs de gestion des itinéraires, tels que les réflecteurs de routes. Transmettre le même identifiant à la fois à l’équipement mandataire et à la passerelle garantit une cohérence et une uniformité dans la gestion de l'identifiant, assurant ainsi une communication fluide et efficace à travers le tunnel dans les deux directions. L’équipement mandataire, tel qu’un proxy MPLS, requiert un choix symétrique de l’identifiant, c’est-à-dire que les identifiants utilisés dans les deux directions du tunnel soient identiques. En effet, l’équipement mandataire marque en émission les paquets d’un identifiant et en réception, il retire le label en vérifiant que c’est bien le même. Par exemple, pour une communication entre deux dispositifs rattachés au même VPN dans le même centre de données, c’est le même identifiant qui est ajouté par l’équipement mandataire en émission que pour une communication entre l’un de ces dispositifs (le deuxième dispositif) et un dispositif en dehors du centre de données (le premier dispositif). De manière générale, le procédé proposé favorise une utilisation plus efficace de l’infrastructure réseau existante, facilitant une communication structurée et efficiente. Cela peut contribuer à réduire les coûts et à simplifier la gestion du réseau. Il offre notamment une intégration souple avec des systèmes d’orchestration tels que Kubernetes proposant une entité d’orchestration de conteneurs d’applications. Cette adaptabilité est particulièrement avantageuse pour les applications distribuées et les services basés sur le cloud, simplifiant notamment le déploiement de réflecteurs de routes ayant par exemple des architectures réseau à deux étages. La réception de l’identifiant d’acheminement en provenance de l’entité d’orchestration avant toute annonce de route permet de sélectionner l’identifiant reçu pour les prochaines annonces et donc de bénéficier d’un identifiant adapté pour le tunnel bidirectionnel, notamment en ayant un identifiant identique pour les deux directions du tunnel. Dans un exemple, la réception du deuxième message permet d’initier une configuration de la passerelle de centre de données pour l’établissement du tunnel bidirectionnel avec l’équipement mandataire, ce tunnel étant établi à partir de la passerelle de centre de données pour l’acheminement de données entre le premier dispositif et le deuxième dispositif et utilisant ledit identifiant d’acheminement pour l’acheminement des dites données dans les deux directions du tunnel, correspondant au tunnel sur la seconde dorsale, tel que décrit ci-dessus. Le procédé vise en en effet la mise en œuvre du tunnel bidirectionnel dans le centre de données, ce tunnel étant juxtaposé à un autre tunnel déployé sur un réseau étendu. Dans un exemple, la réception du premier message et la réception du deuxième message permettent d’effectuer un transfert d’une communication entre le deuxième dispositif et le premier dispositif à travers au moins le tunnel. Un tel tunnel, utilisant l’identifiant d’acheminement, assure l’étanchéité de la transmission des données entre les dispositifs vis-à-vis d’autres VPNs ou de l’Internet, améliorant ainsi la performance et la fiabilité de la communication en garantissant une intégrité et une continuité des données échangées. Dans un exemple, le procédé comprend en outre, après la réception du deuxième message : envoyer une notification à un réflecteur de route, la notification indiquant que le premier dispositif est accessible via la passerelle de centre de données dans le réseau privé virtuel. L’envoi d’une notification au réflecteur de route après la réception du deuxième message améliore la visibilité et la gestion du trafic dans le réseau VPN, facilitant un routage plus précis et une meilleure disponibilité des ressources réseau. Dans un exemple, le deuxième message contient au moins un identifiant du réseau privé virtuel. L’identifiant du réseau virtuel dans le second message permet à la passerelle du centre de données de déterminer pour quel VPN l’identifiant d’acheminement doit être utilisé. Dans un exemple, le deuxième message contient une annonce d’une route vers le deuxième dispositif. Dans un exemple, la réception du deuxième message fait suite à une annonce préalable, à l’entité émettrice du deuxième message, de la route vers le deuxième dispositif. L’entité émettrice, qui peut être par exemple un réflecteur de routes d’un centre de données, obtient par exemple une annonce de route vers le deuxième dispositif associé à l’identifiant du VPN permettant à l’entité émettrice de mettre à jour sa table de routage et de pouvoir en informer ensuite la passerelle avant que celle-ci n’annonce la route vers le premier dispositif. Il est également proposé, selon un aspect, une passerelle de centre de données, DCGW, configurée pour : recevoir un premier message contenant une annonce d’une route vers un premier dispositif d’un premier client, CER2, ledit premier dispositif étant attaché à un réseau privé virtuel, VPN2, et recevoir, de manière asynchrone par rapport à la réception du premier message, un deuxième message comprenant un identifiant d’acheminement associé au réseau privé virtuel, l’identifiant étant choisi par une entité d’orchestration de conteneurs d’applications pour au moins un deuxième dispositif d’un deuxième client, CEL2, ledit deuxième dispositif étant également attaché au réseau privé virtuel, VPN2, par l’intermédiaire d’un équipement mandataire, l’identifiant d’acheminement étant préalablement configuré sur l’équipement mandataire en vue de l’établissement d’un tunnel bidirectionnel entre la passerelle et l’équipement mandataire, ledit tunnel étant constitutif du réseau privé virtuel, VPN2. Il est également proposé, selon un autre aspect, un procédé mis en œuvre par une passerelle de centre de données, DCGW, et comprenant les étapes de : recevoir un premier message contenant une annonce d’une route vers un premier dispositif d’un premier client, CER2, ledit premier dispositif étant attaché à un réseau privé virtuel, VPN2, recevoir un message distinct du premier message, relatif à une ouverture d’une session d’échange de route avec un routeur, MP-RR, le message distinct comprenant un attribut spécifiant un rôle de serveur ou de client attribué à l’un parmi le routeur et la passerelle dans une relation serveur-client avec le routeur, et lorsque l’attribut spécifie un rôle de client à la passerelle ou un rôle de serveur au routeur, préalablement à l’annonce au routeur de la route vers le premier dispositif, CER2, recevoir du routeur une annonce d'un identifiant d’acheminement associé au réseau privé virtuel pour au moins un deuxième dispositif d’un deuxième client, CEL2, ledit deuxième dispositif étant également attaché au réseau privé virtuel par l’intermédiaire d’un dispositif mandataire préalablement configuré avec l’identifiant d’acheminement. Dans un exemple, le procédé comprend en outre, lorsque l’attribut spécifie un rôle de serveur à la passerelle ou un rôle de client au routeur, annoncer au routeur une route vers le premier dispositif, CER2, ladite route comprenant un identifiant d’acheminement associé au réseau privé virtuel pour au moins un deuxième dispositif d’un deuxième client, CEL2, ledit deuxième dispositif étant également attaché au réseau privé virtuel par l’intermédiaire d’un dispositif mandataire préalablement configuré avec l’identifiant d’acheminement. Cette méthode permet une attribution dynamique et flexible des rôles de serveur et de client entre la passerelle et le routeur. Dans un exemple, le procédé comprend en outre une réception en provenance du routeur d’une route vers le deuxième dispositif du deuxième client, ladite route comprenant l’identifiant d’acheminement. Cette réception permet ainsi à la passerelle de mettre à jour sa table de routage et de configurer une route entre le deuxième dispositif du centre de données et le premier dispositif, par exemple accessible par l’intermédiaire du VPN sur la dorsale Internet. Dans un exemple, l’identifiant d’acheminement est utilisé pour l’établissement d’un tunnel bidirectionnel entre la passerelle et le dispositif mandataire, l’identifiant d’acheminement étant utilisé pour acheminer les données dans les deux directions du tunnel. Cela permet notamment de vérifier l’utilisation du même identifiant dans les deux directions du tunnel bidirectionnel au sein du centre de données. Dans un exemple, lorsque l’attribut indique l’affectation du rôle de client à la passerelle, l’identifiant contenu dans l’annonce reçue par la passerelle est choisi par une entité d’orchestration de conteneurs d’applications. La passerelle jouant un rôle de client et ne décidant pas de l’identifiant d’acheminement, il peut être intéressant que cet identifiant soit déterminé par une entité d’orchestration de conteneurs d’applications, par exemple de type Kubernetes, pilotant l’affectation des identifiants aux différents VPNs sur les équipements tel que la passerelle et le routeur. Dans un exemple, la réception de l’annonce dudit identifiant est mise en œuvre de manière asynchrone par rapport à la réception du premier message. L’annonce des routes vers le premier dispositif et des identifiants d’acheminement vers le second dispositif sont avantageusement décorrélés évitant ainsi à la passerelle de sélectionner un identifiant d’acheminement dès la réception du premier message, évitant ainsi de mettre en œuvre un tunnel bidirectionnel avec des identifiants différents pour les deux directions au sein du centre de données. Dans un exemple, le procédé comprend en outre notifier au routeur une acceptation du rôle affecté. Ainsi, le routeur se verra confirmer le rôle de chaque entité, passerelle et routeur, et pourra ainsi déterminer si la passerelle attend une annonce d’identifiant d’une autre entité, telle qu’une entité d’orchestration de conteneurs d’applications ou bien si le routeur doit s’attendre à recevoir une annonce de route dont l’identifiant aura été sélectionné par la passerelle. Si le routeur sait que la passerelle est cliente, alors il devra informer la passerelle sur l’identifiant d’acheminement à utiliser pour annoncer la route vers le premier dispositif. Il est également proposé, selon un autre aspect, un procédé mis en œuvre par un routeur et comprenant les étapes de : transmettre un message relatif à une ouverture d’une session d’échange de route avec une passerelle de centre de données, DCGW, le message comprenant un attribut spécifiant un rôle de serveur ou de client attribué à l’un parmi le routeur et la passerelle dans une relation serveur-client avec le routeur, et lorsque l’attribut spécifie un rôle de client à la passerelle ou un rôle de serveur au routeur, préalablement à la réception d’une annonce par la passerelle d’une route vers un premier dispositif d’un premier client, CER2, annoncer à la passerelle un identifiant d’acheminement associé au réseau privé virtuel pour au moins un deuxième dispositif d’un deuxième client, CEL2, ledit deuxième dispositif étant également attaché au réseau privé virtuel par l’intermédiaire d’un dispositif mandataire préalablement configuré avec l’identifiant d’acheminement. Dans un exemple, le procédé comprend en outre, lorsque l’attribut spécifie un rôle de serveur à la passerelle ou un rôle de client au routeur, recevoir une route vers le premier dispositif, ladite route comprenant ledit identifiant d’acheminement. Il est également proposé, selon un autre aspect, une passerelle de centre de données, DCGW, configurée pour : recevoir un premier message contenant une annonce d’une route vers un premier dispositif d’un premier client, CER2, ledit premier dispositif étant attaché à un réseau privé virtuel, VPN2, recevoir un message distinct du premier message, relatif à une ouverture d’une session d’échange de route avec un routeur, MP-RR, le message distinct comprenant un attribut spécifiant un rôle de serveur ou de client attribué à l’un parmi le routeur et la passerelle dans une relation serveur-client avec le routeur, et lorsque l’attribut spécifie un rôle de client à la passerelle ou un rôle de serveur au routeur, préalablement à l’annonce au routeur de la route vers le premier dispositif, CER2, recevoir du routeur une annonce d'un identifiant d’acheminement associé au réseau privé virtuel pour au moins un deuxième dispositif d’un deuxième client, CEL2, ledit deuxième dispositif étant également attaché au réseau privé virtuel par l’intermédiaire d’un dispositif mandataire préalablement configuré avec l’identifiant d’acheminement. Optionnellement, la passerelle est configurée en outre pour, lorsque l’attribut spécifie un rôle de serveur à la passerelle ou un rôle de client au routeur, annoncer au routeur une route vers le premier dispositif, CER2, ladite route comprenant ledit identifiant d’acheminement. Il est également proposé, selon un autre aspect, un routeur configuré pour : transmettre un message relatif à une ouverture d’une session d’échange de route avec une passerelle de centre de données, DCGW, le message comprenant un attribut spécifiant un rôle de serveur ou de client attribué à l’un parmi le routeur et la passerelle dans une relation serveur-client avec le routeur, et lorsque l’attribut spécifie un rôle de client à la passerelle ou un rôle de serveur au routeur, préalablement à la réception d’une annonce par la passerelle d’une route vers un premier dispositif d’un premier client, CER2, annoncer à la passerelle un identifiant d’acheminement associé au réseau privé virtuel pour au moins un deuxième dispositif d’un deuxième client, CEL2, ledit deuxième dispositif étant également attaché au réseau privé virtuel par l’intermédiaire d’un dispositif mandataire préalablement configuré avec l’identifiant d’acheminement. Optionnellement, le routeur est configuré en outre pour, lorsque l’attribut spécifie un rôle de serveur à la passerelle ou un rôle de client au routeur, recevoir une route vers un premier dispositif, CER2, ladite route comprenant ledit identifiant d’acheminement. Il est également proposé, selon un autre aspect, un système comprenant la passerelle de centre de données et le routeur évoqués. Il est également proposé, selon un aspect, un programme d’ordinateur comprenant des instructions qui, lorsque le programme est mis en œuvre par un processeur, conduisent à mettre en œuvre l’un des procédés évoqués. Il est également proposé, selon un aspect, un support d’enregistrement non transitoire lisible par un ordinateur sur lequel est enregistré un programme pour la mise en œuvre du procédé évoqué lorsque ce programme est exécuté par un processeur. D’autres caractéristiques, détails et avantages apparaîtront à la lecture de la description détaillée ci-après, et à l’analyse des dessins annexés, sur lesquels : Fig. 1 FIG. 1 est un diagramme de séquence illustrant des opérations mises en œuvre dans un système de communication pour l’établissement d’un tunnel bidirectionnel entre deux dispositifs selon l’état de la technique. Fig. 2 FIG. 2 représente une vue d’ensemble d’un système de communication selon un exemple de réalisation. Fig. 3 FIG. 3 représente une autre vue d’ensemble du système de communication selon l’exemple de réalisation de FIG. 2 . Fig. 4 FIG. 4 est un diagramme de séquence illustrant des opérations mises en œuvre dans un système de communication pour l’établissement d’un tunnel bidirectionnel entre deux dispositifs selon l’exemple de réalisation de FIG. 2 et FIG. 3 . Fig. 5 FIG. 5 est un diagramme de séquence illustrant des opérations mises en œuvre dans un système de communication pour l’établissement d’un tunnel bidirectionnel entre deux dispositifs selon un autre exemple de réalisation. Dans la description qui va suivre, des chiffres de référence identiques désignent des éléments identiques ou ayant des fonctions similaires. La description qui va suivre emploie par ailleurs des termes techniques fréquemment utilisés dans le secteur des réseaux informatiques et des télécommunications. Ces termes, fournis le cas échéant en anglais, ainsi que les acronymes correspondants sont définis ci-dessous pour faciliter la compréhension. « Internet Protocol » (IP) est un protocole de communication pour le transfert de datagrammes sur un réseau. Il existe en deux versions : IPv4 (Internet Protocol version 4) et IPv6 (Internet Protocol version 6). Un « préfixe IP » est une expression d'une plage d'adresses IP, généralement représentée par une adresse IP suivie d'un masque de sous-réseau (comme 192.168.0.0/24). Elle dénote un ensemble d'adresses IP qui partagent les mêmes bits initiaux. « MultiProtocol Label Switching » (MPLS) est une technologie de réseau qui oriente des données d'un nœud à un autre en s’appuyant sur des étiquettes courtes plutôt que de longues adresses réseau. Cette technologie est souvent utilisée pour créer des tunnels sur des réseaux Ethernet. « Border Gateway Protocol » (BGP) est un protocole de routage utilisé pour échanger des informations de routage et de portée entre les systèmes autonomes (AS) sur Internet. Il est conçu pour gérer des routes complexes et supporter un grand nombre de préfixes de réseau. BGP est souvent utilisé pour le routage inter-domaine, permettant ainsi la communication entre différents réseaux indépendants. « Virtual Private Network » (VPN) désigne un réseau dont les flux IP sont isolés de ceux d’autres réseaux privés virtuels ou encore du réseau public, comme Internet, pour interdire toute communication avec ces autres réseaux. MP-BGP est une extension de BGP qui supporte le routage pour plusieurs familles d'adresses (comme IPv4, IPv6) et de types de services (comme unicast, multicast, et MPLS VPN). MP-BGP permet aux routeurs de partager des informations sur des routes non seulement pour les adresses IP traditionnelles mais aussi pour des routes spécifiques à des applications comme les VPNs MPLS, en utilisant des extensions comme les attributs AFI (Address Family Identifier) et SAFI (Subsequent Address Family Identifier). Dans le domaine du réseau et des télécommunications, une « route » est un chemin déterminé par lequel les paquets de données sont acheminés à travers un réseau ou entre différents réseaux. Une route est généralement définie par une adresse de destination (ou un préfixe d'adresse IP) et parfois des attributs supplémentaires qui spécifient comment atteindre cette destination. Dans le contexte des protocoles de routage comme BGP ou MP-BGP, une route inclut les informations nécessaires pour diriger le trafic vers la bonne destination, souvent en se basant sur les adresses IP et d'autres critères spécifiques au réseau. « Address Family Identifier » (AFI) est un identifiant utilisé dans le protocole MP-BGP pour spécifier la famille d'adresses de la route annoncée. Il permet de distinguer entre différents types d'adresses (comme IPv4 ou IPv6) dans les messages de routage. Cela permet à MP-BGP de gérer plusieurs types d'adresses de manière cohérente et efficace. « Subsequent Address Family Identifier » SAFI complète AFI en fournissant des informations supplémentaires sur le type de service ou les caractéristiques des routes annoncées dans MP-BGP. Par exemple, il peut indiquer si la route est pour un trafic unicast ou multicast, ou si elle est spécifique à un service comme un VPN MPLS. Le SAFI permet donc une plus grande spécificité et une meilleure gestion du routage pour divers services et applications. « Network Layer Reachability Information » (NLRI) est un terme utilisé dans BGP pour désigner les informations relatives à la portée des adresses de couche réseau. C'est essentiellement un ensemble de routes ou de préfixes IP que le routeur annonce comme accessibles. « Length », dans le contexte d’un message BGP, se réfère à la longueur en bits ou octets des informations suivantes dans le message, comme les labels MPLS ou les informations de routage. « Length of Next Hop Network Address » désigne, toujours dans le contexte d’un message BGP, la longueur de l'adresse du prochain saut réseau. Elle indique la taille en bits ou octets de l'adresse de prochain saut dans un message BGP. Par exemple, pour IPv4, elle serait généralement de 4 octets. « Route Target » est un identifiant utilisé dans les réseaux MPLS VPN pour déterminer à quels VPN une route appartient. Il permet de contrôler l'importation et l'exportation des routes entre différentes instances de VPN. Un « attribut » désigne dans le contexte des protocoles de routage une propriété associée à une route, qui influence le choix ou la propagation de cette route dans un réseau. Par exemple, l'attribut EXTENDED_COMMUNITIES dans un message UPDATE BGP peut contenir des informations comme le Route Target pour un VPN. « Route Distinguisher » est un identifiant ajouté aux routes dans un environnement MPLS VPN pour distinguer des routes identiques (en termes de préfixes IP) dans différents VPN. Cela permet de maintenir la séparation du trafic entre différents VPNs. « Withdrawn Routes » ou routes retirées désigne, dans le protocole BGP, des routes qui ne sont plus valables et doivent être supprimées de la table de routage. Elles sont annoncées dans des messages de mise à jour ou « messages UPDATE » pour informer les autres routeurs de leur invalidité. « Forwarding Information Base » (FIB) désigne une table de routage utilisée dans des réseaux IP/MPLS pour déterminer un chemin à suivre pour acheminer des paquets de données. « Label Forwarding Information Base » (LFIB) désigne une table de commutation spécifique à MPLS, qui associe des étiquettes, ou « labels » en anglais, à des chemins de transmission dans le réseau. Du fait de cette association, de telles étiquettes sont également désignées dans le présent document par l’expression « identifiant d’acheminement ». Un « proxy MPLS » est un dispositif intermédiaire dans un réseau MPLS qui agit au nom d'autres dispositifs ou clients. Ce rôle peut inclure la gestion des identifiants ou labels MPLS, la facilitation de la communication entre différents segments du réseau, et l'acheminement des données. En fonctionnant comme un proxy, il peut simplifier les configurations de réseau, gérer la distribution des labels et assurer une communication efficace entre des réseaux ou des dispositifs qui ne peuvent pas directement interagir en raison de contraintes de compatibilité ou de configuration. Un « Container » ou « conteneur » ou encore « conteneur d’applications » en français est une unité logicielle qui comprend un code d’une application et toutes ses dépendances afin que l’application s'exécute rapidement et de manière fiable d'un environnement informatique à un autre. « Virtual Network Function » (VNF) désigne une fonction réseau implémentée sous forme de logiciel sur des serveurs informatiques dits standard, pouvant résider dans des machines virtuelles (VM) ou dans des Containers. « Virtual Infrastructure Manager » (VIM) désigne un système qui gère la création et la maintenance de machines virtuelles ou de pods, c’est-à-dire de groupes de Containers, sur un serveur informatique. Kubernetes est un exemple de VIM, mais d'autres gestionnaires de virtualisation sont également utilisables. Un VIM peut être également désigné sous l’expression « système d’orchestration de conteneurs d’applications », un tel système étant formé d’une pluralité d’entités, ou « entités VIM » qui sont des composants fonctionnels (matériels et/ou logiciels) du VIM. Un « Réflecteur de Routes » est un dispositif dans un réseau qui permet de propager des informations de routage, notamment dans des réseaux BGP, sans nécessiter de connexions directes entre tous les routeurs. « Application Programming Interface » (API) est un ensemble de règles et de définitions qui permet à des logiciels ou des applications de communiquer entre eux, facilitant l'échange de données et la réalisation de fonctions ou de commandes spécifiques. Ainsi, par exemple, il est possible de définir une API entre un réflecteur de routes et un VIM ; une telle API est spécialement conçue pour permettre la communication et l'échange de données entre un réflecteur de routes (qui gère les informations de routage dans un réseau) et un VIM (qui gère l'infrastructure virtualisée), optimisant ainsi la gestion du réseau et des ressources virtualisées. « Network Attachment Definition » (NAD) désigne un objet au sein de Kubernetes contenant les détails de configuration réseau pour les Pods qui seront déployés. Un « plugin » est un composant logiciel qui ajoute une fonctionnalité spécifique ou étendue à un système informatique existant. « Container Network Interface » (CNI) désigne un plugin dans Kubernetes qui interprète un NAD pour appliquer la configuration réseau aux Pods déployés. « Datacenter » (DC) ou « centre de données » en français désigne une installation composée d’un ensemble de serveurs informatiques connectés à des commutateurs via des interfaces Ethernet. « Datacenter Gateway » (DCGW) ou « passerelle de centre de données » en français désigne un routeur IP/MPLS connecté d'une part aux commutateurs d'un datacenter et d'autre part à des réseaux dorsaux ou de collecte IP/MPLS. « Customer Edge » (CE) désigne un client d’un VPN. Dans le contexte du présent document, un CE est par exemple implémenté sous forme d'un Pod ou d'une VM. « Provider Edge » (PE) désigne un routeur IP/MPLS qui connecte des clients ou d'autres PE à des VPNs. La description qui va suivre fait référence à des technologies de réseaux privés virtuels dont de nombreux aspects sont standardisés. La technique proposée s’inscrit dans une potentielle évolution des standards actuels. Une vue d’ensemble des standards actuels de l’IETF est fournie afin de faciliter la compréhension de la technique proposée. Les standards de l’IETF relatifs aux VPNs sont détaillés dans les documents RFC4364, RFC3032, RFC4026 et RFC4110 de l’IETF. Ces documents décrivent une architecture connue de VPN incluant des Provider Edge (PE) et des Customer Edge (CE) et comment le protocole MPLS peut être utilisé pour mettre en œuvre des VPN IP de manière standard. Le protocole MP-BGP est décrit dans le document RFC4760 comme une extension du protocole BGP pour mettre en œuvre des VPNs, avec deux attributs supplémentaires MP_REACH_NLRI (pour Multiprotocol Reachable NLRI) et MP_UNREACH_NLRI (pour Multiprotocol Unreachable NLRI) du message UPDATE défini par le protocole BGP4 dans le document IETF RFC4271. L’attribut EXTENDED_COMMUNITIES est défini dans le document IETF RFC4360 et permet de spécifier une ou plusieurs communautés de type Route Target pour contrôler la propagation des routes par BGP. Le document IETF RFC4364 explique comment l’utiliser pour faciliter la propagation des routes de VPNs. En utilisant par exemple un Route Target différent pour chaque VPN. On notera que plusieurs Route Targets peuvent être utilisés pour un même VPN. Pour annoncer des routes dans plusieurs VPNs différents, un routeur IP/MPLS peut envoyer un message de mise à jour, ou « message UPDATE » avec l’attribut EXTENDED_COMMUNITIES et l’attribut MP_REACH_NLRI, qui permet d’indiquer en plus les paramètres suivants : Address Family Identifier (AFI) : « IPv4 » ou « IPv6 » suivant la version des adresses/préfixes IP annoncés, Subsequent Address Family Identifier (SAFI) : « Labeled VPN Unicast », pour indiquer que les paquets IP sont encapsulés dans des trames MPLS, Length of Next Hop Network Address : la longueur, « length » en anglais, ou taille en octets, de l’adresse de prochain saut, « next-hop network address » en anglais. Network Address of Next Hop : l’adresse de prochain saut (IPv4, IPv6 GUA ou LLA) tel que défini dans les documents RFC1171, RFC4659, RFC4798 et RFC5549 Network Layer Reachability Information (NLRI) : un champ d’information dont la structure dépend du couple AFI/SAFI. Comme précisé dans le document IETF RFC8277, dans le cas où les adresses annoncées sont des adresses IPv4, l’AFI doit être égal à 1 et dans le cas où les adresses annoncées sont des adresses IPv6, l’AFI doit être égal à 2. De même le document IETF RFC8277 rappelle que dans le cas où les adresses annoncées ne sont pas spécifiques à un VPN, le SAFI doit être égal à 4 et dans le cas où les adresses annoncées sont spécifiques à un VPN, le SAFI doit être égal à 128. Lorsque le champ SAFI est égal à 4, le document IETF RFC3107 indique que le champ NLRI doit être composé des informations suivantes : Length : longueur en bits des informations suivantes, Labels : un ou plusieurs labels MPLS de 3 octets chacun Prefix : adresses ou préfixes IPv4 ou IPv6 accessibles via le prochain saut (Next Hop) Le champ SAFI peut être choisi égal à 128, de manière à pouvoir annoncer des adresses IPv4 ou IPv6 spécifiques à un VPN. Pour distinguer les adresses relatives aux différents VPN, elles sont assorties d’un paramètre Route Distinguisher spécifique à chaque VPN tel que défini dans le document IETF RFC 4364. Ainsi l’information Prefix définie dans le document IETF RFC 3107 contient des adresses ou préfixes IPv4 ou IPv6 précédées du paramètre Route Distinguisher associé au VPN pour lequel ils sont annoncés. Pour supprimer des routes dans plusieurs VPNs différents, un routeur IP/MPLS peut envoyer un message UPDATE avec l’attribut EXTENDED_COMMUNITIES et l’attribut MP_UNREACH_NLRI, qui permet en plus d’indiquer les paramètres suivants : Address Family Identifier (AFI) : « IPv4 » ou « IPv6 » suivant la version des adresses IP annoncées, Subsequent Address Family Identifier (SAFI) : « Labeled VPN Unicast », pour indiquer que les paquets IP sont encapsulés dans des trames MPLS, Withdrawn Routes : les routes à supprimer. On notera que les routes à supprimer sont dans un format similaire au champ NLRI d’un message MP_REACH_NLRI. Dans le cas où l’information Length est égale à 0, alors toutes les routes apprises pour le couple AFI/SAFI doivent être supprimées. Enfin, le protocole BGP permet à des nœuds BGP d’échanger les options qu’ils supportent au moment de l’établissement de la session BGP. Le document RFC5492 définit un attribut CAPABILITIES pouvant être inséré pour chaque option supportée dans le message OPEN utilisé pour initier une session BGP. L’attribut CAPABILITIES contient notamment un champ Capability Code dont le numéro doit correspondre à l’un des numéros spécifiés par l’IANA à l’URL suivante : https://www.iana.org/assignments/capability-codes/capability-codes.xhtml. En particulier pour annoncer qu’il supporte l’extension Multiprotocol et qu’il peut donc traiter les attributs MP_REACH_NLRI et MP_UNREACH_NLRI dans les messages UPDATE, un nœud BGP doit utiliser le code 1. A la lumière des définitions et de la vue d’ensemble des standards actuels telles que fournies ci-avant, la technique proposée est maintenant présentée. La technique proposée concerne, selon un aspect, un procédé mis en œuvre par une passerelle de centre de données (DCGW). Le procédé comprend la réception par la passerelle d’un premier message et d’un deuxième message. Cela implique que la passerelle est spécifiquement configurée pour recevoir et, optionnellement, traiter ces deux messages. Ces deux messages concernent deux dispositifs distincts (ci-après le premier dispositif et le deuxième dispositif) attachés à un même réseau privé virtuel (VPN2). Le deuxième dispositif est attaché au réseau privé virtuel par l’intermédiaire d’un équipement mandataire, également appelé équipement proxy. Plus spécifiquement, le premier message contient une annonce d’une route vers un premier dispositif d’un premier client (CER2). Le deuxième message comprend un identifiant d’acheminement associé au réseau privé virtuel. L’identifiant d’acheminement est choisi par une entité d’orchestration de conteneurs d’applications pour au moins un deuxième dispositif d’un deuxième client (CEL2). L’identifiant d’acheminement est préalablement configuré sur l’équipement mandataire en vue de l’établissement d’un tunnel bidirectionnel, constitutif du réseau privé virtuel, entre la passerelle et l’équipement mandataire. Le deuxième message est reçu de manière asynchrone par rapport à la réception du premier message. C’est-à-dire que, lorsque la passerelle reçoit le premier message à un instant courant, elle reste en attente de réception du deuxième message sans pouvoir prédire l’instant futur de réception de ce deuxième message. La technique proposée concerne également une passerelle de centre de données configurée pour mettre en œuvre un tel procédé, ainsi qu’un programme d’ordinateur pour la mise en œuvre d’un tel procédé et un support d’enregistrement non transitoire lisible par un ordinateur sur lequel est enregistré un tel programme. La technique proposée peut aider à optimiser l'utilisation de l'infrastructure de réseau existante en permettant une communication plus structurée et efficace, réduisant potentiellement les coûts et la complexité liés à la gestion du réseau. Elle permet en outre une intégration flexible avec les systèmes d'orchestration de conteneurs, offrant ainsi une adaptabilité accrue pour les applications distribuées et les services cloud. Elle contribue notamment à simplifier le déploiement par un système d'orchestration de conteneurs, tels que Kubernetes, d’un réflecteur de routes à deux étages pour un proxy MPLS. La capacité de traiter les premier et deuxième messages de manière asynchrone, c'est-à-dire indépendamment, permet une plus grande flexibilité et efficacité dans la gestion du trafic réseau. Cela peut être particulièrement bénéfique dans des environnements où les conditions de réseau et les demandes de trafic changent rapidement. Dans la technique proposée, la passerelle de centre de données reçoit un identifiant unique déjà configuré dans l'équipement mandataire en vue de l’établissement d’un tunnel bidirectionnel avec l’équipement mandataire, ce tunnel utilisant le même identifiant pour les deux sens de communication. Cette unification de l'identifiant d'acheminement, orchestrée par une seule entité, comme une entité d’un système tel que Kubernetes, permet de répondre aux problèmes techniques identifiés dans l’art antérieur. Notamment, la technique proposée permet de simplifier et d’optimiser la manière dont les données sont acheminées à travers le VPN. Elle permet également d’améliorer la fiabilité et l’efficacité de la communication entre les premier et deuxième dispositifs. Le procédé proposé trouve une application particulière dans l'établissement et la gestion, en collaboration notamment avec un proxy MPLS, d’un tunnel bidirectionnel entre deux dispositifs raccordés à un même réseau privé virtuel. Dans le cadre actuel des réseaux IP/MPLS, les équipements de périphérie, tels que les passerelles de centre de données (DCGW), jouent un rôle clé dans la gestion des labels MPLS pour les réseaux privés virtuels (VPNs). Typiquement, dans une architecture standard, les labels MPLS sont configurés de manière asymétrique pour les trajets aller et retour, permettant ainsi à chaque routeur MPLS de déterminer indépendamment le label à utiliser en réception. Ce mécanisme implique une communication entre les routeurs pour s'accorder sur les labels à utiliser en émission. Actuellement, une méthode existante pour établir une symétrie de labels MPLS entre la DCGW et les proxies MPLS du datacenter repose sur un processus séquentiel. Ce processus commence par l'annonce d'une route VPN par la DCGW, suivie par la configuration correspondante sur le proxy MPLS, basée sur le label annoncé. Cependant, cette approche présente des défis. Un premier défi concerne le délai de configuration. Le temps d'attente nécessaire pour l'annonce d'une route VPN par la DCGW retarde la configuration des proxies MPLS. Ce délai peut affecter les communications internes au datacenter si un VPN interne distinct est requis. Un deuxième défi concerne les changements de labels. Si la DCGW modifie les labels MPLS pour un VPN, il devient nécessaire de reconfigurer les proxies MPLS associés, perturbant ainsi les communications entre CEs. Un troisième défi concerne la dépendance à une API. La configuration des proxies MPLS exige une interaction avec le Réflecteur de Routes du datacenter pour récupérer le label MPLS annoncé par la DCGW. Cela nécessite la mise en place d'une API entre le réflecteur de routes et l'entité VIM, complexifiant l'architecture globale. La technique proposée permet de s’affranchir de ces contraintes, notamment en évitant le développement d’une API entre le Réflecteur de Routes et le VIM. La technique proposée permet ainsi de mettre en œuvre, à la place, un Réflecteur de Routes plus simple à déployer avec Kubernetes. Pour illustrer la mise en œuvre, selon l’état de la technique antérieure, d’un tunnel bidirectionnel au moyen d’un réflecteur de routes, éventuellement à deux étages, avec Kubernetes, il est à présent fait référence à FIG. 1 . FIG. 1 est un diagramme de séquence représentant des opérations successives mises en œuvre dans un système de communication pour l’établissement d’un tunnel bidirectionnel entre un premier dispositif d’un premier client (CER2) et un deuxième dispositif d’un deuxième client (CEL2) lorsque CEL2 est accessible à travers un proxy MPLS (MPLS-Proxy) selon l’état de la technique. Un Provider Edge noté « PE2 » raccorde le premier dispositif du premier client (CER2) à un VPN noté « VPN2 ». PE2 annonce (1), à une passerelle de centre de données DCGW, une route vers l’adresse IP de CER2 dans le VPN2 accessible via l’adresse IP (de prochain saut) de PE2 avec comme identifiant d’acheminement un label noté « MPLS-B ». Le réflecteur de routes, noté « MP-RR », interagit avec la passerelle DCGW de manière à ouvrir une session de commande MP-BGP. Une fois la session de commande ouverte, la passerelle DCGW annonce (2), à l’étage frontal du réflecteur de routes, une route vers l’adresse IP de CER2 dans le VPN2 accessible via l’adresse IP (de prochain saut) de DCGW avec comme identifiant d’acheminement un identifiant ou label noté « MPLS-X ». En parallèle, une entité VIM Kubernetes est configurée pour gérer le déploiement (6) d’un pod associé au deuxième dispositif du deuxième client (Pod CEL2). Pour cela, l’entité Kubernetes commence par choisir (4) comme identifiant d’acheminement un label noté « MPLS-2 » pour VPN2, par ajouter sur MP-RR un service BGP pour le VPN2, et par mettre à jour la configuration de MP-RR pour le VPN2 avec comme identifiant d’acheminement le label MPLS-2. L’entité Kubernetes transmet (5) ensuite sur le Proxy MPLS une règle permettant de joindre le CEL2 avec comme identifiant d’acheminement le label MPLS-2. Enfin, l’entité Kubernetes est en mesure de déployer (6) le Pod CEL2. A l’instar de l’interaction initiale entre le réflecteur de routes (MP-RR) et la passerelle (DCGW), CEL2 interagit également avec le réflecteur de routes (MP-RR) de manière à ouvrir une session de commande BGP pour le VPN2. MP-RR annonce (3) à CEL2 sur la session de commande BGP pour le VPN2 une route vers l’adresse IP de CER2 accessible via l’adresse IP (de prochain saut) de la passerelle DCGW et en retour CEL2 annonce (7) à MP-RR sur la session de commande BGP pour le VPN2 une route vers des adresses CEL2_IP-D@ accessibles via l’adresse IP (de prochain saut) de CEL2. Suite à l’obtention, par MP-RR, du label MPLS-2 issue de l’entité Kubernetes et de la route annoncée par CEL2, MP-RR annonce (8) à DCGW une route vers des adresses CEL2_IP-D@ dans le VPN2 accessibles via l’adresse IP (de prochain saut) de CEL2 avec comme identifiant d’acheminement le label MPLS-2. DCGW annonce alors à PE2 une route vers des adresses CEL2_IP-D@ dans le VPN2 accessibles via l’adresse IP (de prochain saut) de DCGW avec comme identifiant d’acheminement un label noté « MPLS-Y ». L’ensemble de ce processus d’annonces permet à DCGW de mettre en place une communication IP entre CEL2 et CER2 basé sur l’établissement de deux tunnels juxtaposés au niveau de la passerelle DCWG. Dans un sens, des données reçues depuis les adresses CEL2_IP-S@ transitent jusqu’à DCGW par un tunnel établi entre le dispositif mandataire MPLS Proxy et DCGW avec comme identifiant d’acheminement le label MPLS-X puis jusqu’aux adresses CER2_IP-D@ par autre tunnel, établi entre la DCGW et PE2, avec comme identifiant d’acheminement le label MPLS-B. Dans le sens opposé, des données reçues depuis les adresses CER2_IP-S@ transitent jusqu’à DCGW par un tunnel, établi entre PE2 et DCGW, avec comme identifiant d’acheminement le label MPLS-Y puis jusqu’aux adresses CEL2_IP-D@ par autre tunnel, entre DCGW et le MPLS proxy, avec comme identifiant d’acheminement le label MPLS-2. Dans la mise en œuvre du processus d’annonce ainsi décrit, il est possible d’utiliser un Réflecteur de Routes à deux étages non décrit sur la FIG. 1 . Ce type d’architecture à deux étages comprend ainsi un réflecteur de routes en plus de MP-RR. Dans ce cas, il n’est pas nécessaire de déployer un service BGP sur MP-RR mais le réflecteur de routes supplémentaire doit être configuré pour assurer le routage du VPN2 en lui transmettant le label MPLS-2 et l’annonce de route pour les adresses CEL2_IP-D@. Dans la suite de cette description, les expressions « premier étage », « étage frontal », « premier étage du Réflecteur de Routes » et « étage frontal du Réflecteur de Routes » sont interchangeables. En effet, le premier étage du Réflecteur de Routes est un étage frontal avec la DCGW. De même, les expressions « deuxième étage » et « deuxième étage du Réflecteur de Routes » sont également interchangeables. Le premier étage doit être déployé dès la création du cluster Kubernetes et doit être configuré pour communiquer avec la DCGW en utilisant le protocole MP-BGP, permettant, en plus des routes (i.e. adresse de prochain saut, ou next hop address) vers les adresses/préfixes IP annoncés, d’indiquer le VPN pour lequel ces routes sont valides, en ajoutant, comme spécifié dans les standards, les paramètres Route Target et Route Distinguisher associés, ainsi que le label MPLS à insérer lors de l’émission des paquets IP/MPLS pour qu’ils soient aiguillés en réception avec la table de routage correspondant au label. Il peut y avoir plusieurs premiers étages (ou étages frontaux) du Réflecteur de Routes, soit pour des raisons de redondance, soit pour des raisons de changement de configuration ou de version logicielle. Une session MP-BGP frontale est établie entre chaque étage frontal et la DCGW via un VLAN sur lequel à la fois la DCGW et chaque étage frontal doit être raccordé. Lors du déploiement par Kubernetes des étages frontaux, la CNI Multus peut être utilisée pour ajouter une interface aux Pods implémentant un Réflecteur de Routes et une CNI de type Bridge, OVS, OVN ou bien encore SR-IOV peut être utilisée pour raccorder cette interface supplémentaire à un Bridge Linux, un Switch OVS, ou bien un Virtual Edge Bridge d’une carte SR-IOV. Cette liste est non exhaustive. Le premier étage du Réflecteur de Routes échange les routes avec la DCGW pour l’ensemble des VPNs auxquels les CEs du cluster doivent être rattachés. Il échange également des routes avec le ou les deuxièmes étages du Réflecteur de Routes, comme indiqué ci-après. Comme le protocole MP-BGP est utilisé aussi bien vers la DCGW que vers les deuxièmes étages du Réflecteur de Routes, toutes les routes (i.e. adresse de prochain saut, ou next hop address) vers des adresses/préfixes IP annoncées par la DCGW ou par les deuxièmes étages du Réflecteur de Routes peuvent être échangées, en conservant les informations de label MPLS à utiliser, les informations de VPN (Route Target et Route Distinguisher), et bien sûr les adresses de prochain saut (next-hop address), qui doivent rester inchangées afin la DCGW et les CEs du cluster puissent échanger directement leurs paquets IP à travers le VLAN et les Proxy MPLS sans passer par les premiers étages du Réflecteur de Routes. Par ailleurs, on peut mettre en œuvre un Service Kubernetes pour répartir, vers les étages frontaux, les requêtes de sessions MP-BGP en provenance du ou des deuxièmes étages. Un Service Kubernetes est implémenté par le composant kube-proxy de Kubernetes et consiste en un Traducteur d’adresses IP de destination (D-NAT) qui change l’adresse IP de Service utilisée comme adresse IP de destination du flux TCP supportant la session MP-BGP en une adresse IP choisie parmi les adresses IP de chacun des étages frontaux. Le Service Kubernetes est accessible sur l’interface par défaut des Pods et ne nécessite pas d’interface supplémentaire. Les deuxièmes étages du Réflecteur de Routes sont en nombre au moins égal au nombre de VPNs gérés. Chaque deuxième étage du Réflecteur de Routes communique avec un étage frontal en utilisant le protocole MP-BGP. Un deuxième étage n’échange des routes (i.e. adresse de prochain saut, ou next hop address) vers des adresses/préfixes IP annoncées avec l’étage frontal que pour un seul VPN, en indiquant les paramètre Route Target et Route Distinguisher associés, ainsi que le label MPLS à insérer lors de l’émission des paquets IP/MPLS. Il peut également échanger des routes avec les CEs du cluster Kubernetes, comme indiqué ci-après. Il peut y avoir plusieurs deuxièmes étages pour un même VPN, soit pour des raisons de redondance, soit pour des raisons de changement de configuration ou de version logicielle. Ainsi, on peut mettre en œuvre pour chaque VPN du cluster, un Service Kubernetes pour répartir, vers les deuxièmes étages gérant ce VPN, les requêtes de sessions BGP en provenance des CEs du cluster ayant une interface sur ce VPN. Un Service Kubernetes est implémenté par le composant kube-proxy de Kubernetes et consiste en un Translateur d’Adresses IP Destination (D-NAT) qui change l’adresse IP de Service utilisée comme adresse IP de destination du flux TCP supportant la session MP-BGP en une adresse IP choisie parmi les adresses IP de chacun des deuxièmes étages gérant le VPN associé à l’adresse IP de Service. Lorsqu’un nouveau VPN doit être utilisé pour un nouveau Pod implémentant un CE dans le cluster Kubernetes, il suffit de déployer un ou plusieurs Pods implémentant un deuxième étage (avec un réflecteur de routes associé) avec la configuration nécessaire pour échanger en utilisant le protocole MP-BGP avec les étages frontaux des routes sur le nouveau VPN, notamment les paramètres Route Target et Route Distinguisher associés, ainsi qu’un label MPLS non encore utilisé dans le datacenter pour d’autres VPNs et pouvant être choisi dans une plage de labels MPLS standards et fixée par configuration. Un opérateur Kubernetes, peut être développé pour déployer, s’ils ne le sont pas encore, les Pods implémentant un deuxième étage pour le nouveau VPN, ainsi qu’un nouveau Service Kubernetes pour permettre à des CEs d’établir une session BGP avec ces nouveaux deuxièmes étages pour ce nouveau VPN. Cet opérateur pourra simplement être appelé par un plugin CNI que l’on nommera CNI-VPN, pour récupérer dans un objet NAD le Route Target et le Route Distinguisher, ainsi qu’une plage de labels MPLS. Ce plugin CNI-VPN aura pour rôle de choisir, pour chaque nouveau VPN identifié par le Route Target et le Route Distinguisher, un label MPLS dans la plage de labels MPLS spécifiée. Une fois ce choix réalisé, le plugin CNI-VPN peut configurer le Proxy MPLS avec le label MPLS associé au VPN lors de la création de chaque Pod implémentant un CE du cluster et devant être raccordé au VPN, tandis que l’opérateur Kubernetes peut déclencher le déploiement des deuxièmes étages avec la bonne configuration de VPN, ainsi que le Service Kubernetes associé. De manière alternative, il est possible de remplir manuellement par l’administrateur du datacenter ou du cluster Kubernetes une table associant pour chaque VPN (Route Target et/ou Route Distinguisher) du VLAN un label MPLS, un Route Target et un Route Distinguisher. Cette table pourra être utilisée pour configurer à la volée, à l’aide d’un composant Kustomize de la suite Kubernetes, les fichiers utilisés par Kubernetes pour déployer, pour le nouveau VPN, les deuxièmes étages, le Service Kubernetes associé, ainsi que le NAD permettant de configurer le Proxy MPLS avec le label MPLS associé au VPN lors de la création de chaque Pod implémentant un CE du cluster. Un nouveau CE du cluster Kubernetes peut ainsi échanger des routes (i.e. adresse de prochain saut, ou next hop address) vers les adresses/préfixes IP annoncées, avec un deuxième étage en établissant une session BGP vers l’adresse IP de Service associée au VPN choisi. Dans le cas où le CE n’a pas cette faculté, il est possible d’ajouter des routes statiques vers les adresses/préfixes IP du CE dans la configuration des deuxièmes étages gérant ce VPN, mais alors, il sera nécessaire de redéployer au moins un deuxième étage pour ce VPN avec la nouvelle configuration. Dans le cas où un opérateur est utilisé pour déployer les Pods implémentant un deuxième étage ainsi que le Service Kubernetes associé, il est également possible lors du déploiement d’un Pod implémentant un CE sans faculté de monter une session BGP, de faire en sorte que l’opérateur ajoute au Pod un container implémentant un client BGP pour annoncer au deuxième étage une route statique vers les adresses/préfixes IP du CE. Pour cela, le plugin CNI-VPN devra également pouvoir interpréter un champ du NAD contenant les routes statiques vers les adresses/préfixes IP du CE. De la même manière, un deuxième étage peut échanger des routes (i.e. adresse de prochain saut, ou next hop address) vers les adresses/préfixes IP annoncées par les CE du même VPN, avec un CE ayant établi une session BGP vers l’adresse IP de Service associée au VPN choisi. De cette façon, tous les CEs raccordés au même VPN pourront échanger leurs routes, indirectement au travers des deuxièmes étages gérant le même VPN. L’adresse de prochain saut (next-hop address), qui n’est autre que l’adresse IP des CEs, doit rester inchangée, pour que les CEs du cluster puissent échanger directement leurs paquets IP à travers le VLAN et les Proxy MPLS sans passer par les deuxièmes étages. Par ailleurs, un deuxième étage peut échanger avec les étages frontaux les routes (i.e. adresse de prochain saut, ou next hop address) vers les adresses/préfixes IP annoncées par les CEs du cluster. Pour cela, un deuxième étage doit récupérer de la table de routage par défaut les routes annoncées en BGP par les CEs du cluster et les répercuter dans sa table de routage de VPN (FIB) par un processus de fuite de route (Route Leaking) en ajoutant aux adresses/préfixes IP l’identifiant de VPN (Route Distinguisher) ainsi que le label MPLS associé au VPN, sur la base des informations contenues dans sa configuration. On notera que l’adresse de prochain saut (next-hop address) correspondant à l’adresse IP du CE ayant annoncé la route doit être conservée, pour que la DCGW puisse envoyer directement ses paquets IP vers les CEs du cluster à travers le VLAN et les Proxy MPLS sans passer par les deuxièmes étages. Enfin pour annoncer les routes apprises des CEs du cluster vers les étages frontaux, un deuxième étage doit indiquer le Route Target associé au VPN qu’il gère, sur la base des informations contenues dans sa configuration. Enfin, un deuxième étage peut échanger avec les CEs du cluster les routes (i.e. adresse de prochain saut, ou next hop address) vers les adresses/préfixes IP annoncées par les étages frontaux pour un VPN donné. Pour cela un deuxième étage va sélectionner parmi les routes apprises des étages frontaux, celles qui contiennent le Route Target associé au VPN qu’il doit gérer, et qui est contenus dans sa configuration. Une fois les routes sélectionnées, le deuxième étage peut les répercuter dans sa table de routage par défaut par un processus de fuite de route (Route Leaking), en retirant le Route Distinguisher des adresses/prefixes IP annoncés et en conservant l’adresse de prochain saut (next-hop address), qui n’est autre que l’adresse IP de la passerelle de datacenter, pour que les CEs du cluster puissent envoyer directement leurs paquets IP vers la DCGW à travers le VLAN et les Proxy MPLS sans passer par les deuxièmes étages. Avant d’annoncer en utilisant le protocole BGP vers les CE du cluster les routes apprises via le protocole MP-BGP des étages frontaux et en utilisant le protocole BGP des CEs du cluster, le deuxième étage peut vouloir vérifier la connectivité vers les adresses de prochain saut (next-hop). Pour cela, le deuxième étage pourra devoir être également raccordé au VLAN de la DCGW et des Proxy MPLS. Lors du déploiement par Kubernetes des deuxièmes étages, la CNI Multus peut être utilisée pour ajouter une interface aux Pods implémentant un deuxième étage et une CNI de type Bridge, OVS, OVN ou bien encore SR-IOV peut être utilisée pour raccorder cette interface supplémentaire à un Bridge Linux, un Switch OVS, ou bien un Virtual Edge Bridge d’une carte SR-IOV. Cette liste est non exhaustive. On notera que les Proxy MPLS laissant passer les requêtes ARP et les messages ICMPv6 de Neighbor Discovery sans ajouter de tag MPLS, la vérification de connectivité vers les CEs par un deuxième étage reste possible. Ainsi les deuxièmes étages annoncent les routes apprises des CEs en BGP ou bien les routes statiques qui y sont configurées vers les étages frontaux via leurs sessions MP-BGP en ajoutant au moins un identifiant du VPN (Route Target et Route Distinguisher) ainsi que le label MPLS associé. Réciproquement, les deuxièmes étages peuvent, via la session BGP, annoncer aux CEs compatibles les routes (i.e. adresse de prochain saut, ou next hop address) vers les adresses/préfixes IP annoncées, apprises des premiers étages, mais en retirant les identifiants de VPN ainsi que le label MPLS, qui ne peuvent pas être échangés dans une simple session BGP. Dans le cas des CEs non compatibles, une route statique devra être prévue dans leur configuration. Pour profiter de ces échanges de routes, les Pods implémentant les CEs du cluster Kubernetes doivent disposer d’une interface additionnelle à l’interface par défaut utilisée pour établir la session BGP vers l’adresse de Service Kubernetes associée au VPN. Lors du déploiement par Kubernetes de ces Pods, la CNI Multus peut être utilisée pour leur ajouter une interface ainsi qu’une CNI permettant le pilotage d’un Proxy MPLS raccordé au même VLAN que la DCGW. Elle peut être dérivée d’une CNI de type Bridge, OVS, OVN ou bien encore SR-IOV et piloter un Bridge Linux, un Switch OVS, ou bien un Virtual Edge Bridge d’une carte SR-IOV pour insérer le tag MPLS. Cette liste est non exhaustive. Une configuration Kubernetes de type Network Attachement Definition (NAD) peut être utilisée pour chaque VPN, en plus des informations d’adressage IP et de VLAN, le label MPLS à ajouter par le Proxy MPLS. De manière astucieuse, le fichier de configuration NAD peut être créé en même temps que le fichier de configuration du deuxième étage associé au VPN, de sorte que le même label MPLS soit spécifié dans les deux fichiers de configuration. L’adresse de prochain saut (next hop) vers les adresses/préfixes IP annoncée par le CE ou bien sinon configurée de manière statique dans les deuxièmes étages doit être l’adresse IP de cette interface additionnelle connectée au Proxy MPLS. Cela peut être une adresse IPv4, une adresse globale IPV6 (Global Unicast Address) ou bien encore une adresse locale IPv6 (Link Local Address). Ainsi, les paquets IP émis ou relayés par un CE du cluster sur son interface additionnelle à destination d’une adresse CER2_IP_D@ annoncée par la DCGW et relayée par les étages frontaux et du deuxième étage peuvent être envoyés vers l’interface de la DCGW à travers le Proxy MPLS configuré pour ajouter le label MPLS associé au VPN voulu, de sorte que la DCGW puisse à la réception retrouver la table de routage associée au VPN et relayer les paquets IP vers la bonne destination à travers le bon VPN. En retour, les paquets IP émis par CER2_IP_D@ pour répondre à CEL2_IP_S@ peuvent être relayés par la DCGW en insérant le label MPLS annoncé via MP-BGP par un étage frontal pour le VPN associé, puis par le proxy MPLS qui vérifie que le label MPLS est bien celui attendu, avant de le retirer et relayer les paquets IP vers CEL2_IP_S@. Il peut être constaté que quel que soit le fonctionnement du réflecteur de routes, à un ou à deux étages, ainsi décrit suppose que pour un VPN donné, le label MPLS-2 annoncé par les étages frontaux via MP-BGP à la DCGW pour la route vers CEL2_IP_S@ soit identique au label MPLS-X annoncé pour le même VPN par la DCGW aux étages frontaux pour la route vers CER2_IP_D@.Or , comme décrit dans la FIG. 1 , les deux labels (MPLS-X et MPLS-2) utilisés pour les deux directions du tunnel bidirectionnel entre DCGW et l’équipement mandataire sont différents. Cette unicité des labels ou identifiants des deux directions n’est pas garantie dans les standards, l’état de la technique ou les implémentations actuelles de MP-BGP, comme démontré dans la FIG. 1 . En effet, comme déjà indiqué, pour les VPNs basés sur une architecture standard, les réseaux IP/MPLS utilisent des labels différents pour le sens aller et le sens retour. Ceci permet à chaque routeur MPLS de décider seul le label MPLS qu’il configure en réception, il lui suffit juste d’informer les routeurs distants afin qu’ils positionnent en émission le label attendu par le routeur en réception. Il est à présent fait référence à FIG. 2 et FIG. 3 qui offrent deux vues d’ensemble d’un même système de communication. FIG. 2 et FIG. 3 représentent la topologie d'un exemple de système de communication complexe pour la gestion de réseaux privés virtuels (VPN) dans un contexte de centre de données. Au cœur du schéma se trouve une passerelle de centre de données (DCGW) (100), qui sert de point central pour l'acheminement des messages entre différents composants du réseau et notamment entre une dorsale d’un réseau IP/MPLS étendu et un environnement VLAN tel qu’un centre de données de type Cloud. Les éléments clés de la topologie incluent un nombre quelconque de dispositifs (CEL1, CEL2, CER1, CER2) et un nombre quelconque de réseaux privés virtuels (VPN1, VPN2). L’un de ces dispositifs est identifié comme le premier dispositif d'un premier client (CER2) (102) et l'autre comme un deuxième dispositif d'un deuxième client (CEL2) (106). Un Provider Edge (PE2) est le point de raccordement du dispositif CER2 au VPN2. Un dispositif mandataire aussi appelé Proxy MPLS (108) représente le dispositif CEL2 au sein du VPN2. Les dispositifs CEL2 et CER2 sont connectés à la passerelle (100) via un réseau privé virtuel désigné VPN2 (104), ce qui implique une isolation de leur communication dans le cadre d'un centre de données partagé. La DCGW (100) est configurée pour annoncer des routes vers les dispositifs (CEL1, CEL2, CER1, CER2) de clients, utilisant des identifiants d'acheminement spécifiques sous forme d’identifiants, c’est-à-dire des labels MPLS (MPLS-1, MPLS-2, MPLS-A-Z, MPLS-B-Y). Un composant clé dans cette topologie est le réflecteur de routes (MP-RR), qui joue le rôle d'intermédiaire dans la gestion des routes BGP (Border Gateway Protocol) au sein du réseau. Le MP-RR interagit avec la DCGW pour établir des sessions de commande et annoncer des routes vers les dispositifs clients. Il est également impliqué dans l'orchestration des conteneurs d'applications via Kubernetes, indiquant une intégration avec des services d'orchestration modernes pour la gestion des applications dans les conteneurs. Dans l’exemple de réalisation de FIG. 2 et FIG. 3 , le réflecteur de routes est représenté comme ayant deux services (S1, S2) associés aux dispositifs clients CEL1 et CEL2). L’infrastructure qui comprend le réflecteur de routes (110) est conçue pour intégrer une entité logicielle d’orchestration de conteneurs, telle qu'un système VIM ou système Kubernetes. Cette entité, qui n’est pas explicitement représentée sur FIG. 2 et FIG. 3 , est responsable de la gestion du déploiement, de l'orchestration et de l'opérationnalisation des conteneurs d'applications au sein du VLAN (112). Elle permet que les tunnels bidirectionnels mis en œuvre dans l’environnement VLAN, et contribuant aux VPNs, bénéficient de labels identiques dans les deux directions du tunnel en transmettant le label à utiliser (MPLS-2) au MPLS -proxy et à la passerelle, possiblement via le MPLS-RR. Elle permet en outre d’automatiser le processus de configuration réseau en assurant que les dispositifs clients tels que CEL2 sont capables de communiquer efficacement au travers de sessions de commande BGP établies et que les routes nécessaires sont annoncées et maintenues à jour, Le schéma illustre également la présence de tunnels, qui facilitent le transport des données entre les dispositifs clients. Les adresses IP de prochain saut et les labels MPLS sont utilisés pour l'identification et l'acheminement des paquets à travers le réseau. Le tunnel entre DCGW et le proxy MPLS 108 est dit « symétrique » en ce qu’il utilise un même identifiant d’acheminement MPLS-2 dans les deux directions. Le tunnel entre DCGW et PE2 est dit « asymétrique » en ce qu’il utilise un identifiant d’acheminement MPLS-B dans une direction et un autre identifiant d’acheminement MPLS-Y dans la direction opposée. Ces deux tunnels contribuent un chemin de communication entre CEL2 et CER2. Il est à présent fait référence à FIG. 4 , qui représente un diagramme de séquence pour l’établissement d’une communication entre CEL2 et CER2 dans un exemple de réalisation. La première étape est identique à celle en FIG. 1 : PE2 annonce (1), à la passerelle DCGW, une route vers l’adresse IP du client CER2 dans le VPN2 accessible via l’adresse IP (de prochain saut) de routeur PE2 avec comme identifiant d’acheminement un label noté « MPLS-B ». Le routeur MP-RR ouvre une session de commande MP-BGP avec la passerelle DCGW à l’aide d’un processus de signalisation approprié pour la mise en place par la passerelle DCGW d’un tunnel symétrique entre DCGW et CEL2. Une possibilité est que MP-RR envoie d’abord à DCGW un message indiquant que MP-RR est capable d’agir en tant que serveur dans une relation serveur-client pour la désignation d’un label MPLS permettant la mise en place d’un tel tunnel symétrique utilisant ce label MPLS, puis que DCGW envoie à MP-RR un message indiquant que DCGW est capable d’agir en tant que client dans la relation serveur-client précitée. Les actions de l’entité Kubernetes sont identiques à celles en FIG. 1 : l’entité Kubernetes commence par choisir (4) comme identifiant d’acheminement un label noté « MPLS-2 » pour VPN2, par ajouter sur MP-RR un service BGP pour le VPN2, et par mettre à jour la configuration de MP-RR pour le VPN2 avec comme identifiant d’acheminement le label MPLS-2. L’entité Kubernetes transmet (5) ensuite sur le Proxy MPLS une règle pour le CEL2 avec comme identifiant d’acheminement le label MPLS-2. Enfin, l’entité Kubernetes est en mesure de déployer (6) le Pod CEL2. Lorsque la configuration de MP-RR pour le VPN2 est mise à jour avec comme identifiant d’acheminement le label MPLS-2, MP-RR annonce (9) le label MPLS-2 en tant qu’identifiant d’acheminement. Dans ce processus, il peut être noté que, du point de vue de DCGW, l’annonce du label MPLS-2 par MP-RR s’effectue de manière asynchrone par rapport à l’annonce précédente du label MPLS-B par PE2. Une fois ces deux annonces reçues par DCGW, DCGW annonce (2) à MP-RR une route vers l’adresse IP de CER2 dans le VPN2 accessible via l’adresse IP (de prochain saut) de DCGW avec comme identifiant d’acheminement le label MPLS-2. L’interaction entre MP-RR et CEL2 est inchangée par rapport à FIG. 1 et aboutit de manière identique à ce que MP-RR annonce (8) à DCGW une route vers des adresses CEL2_IP-D@ dans le VPN2 accessibles via l’adresse IP (de prochain saut) de CEL2 avec comme identifiant d’acheminement le label MPLS-2. L’ensemble de ce processus d’annonces permet à DCGW de mettre en place une communication entre CEL2 et CER2 comprenant un tunnel symétrique entre le Proxy MPLS et DCGW. Comme déjà indiqué, ce tunnel est dit symétrique car le même label MPLS, l'identifiant MPLS-2, est utilisé pour l'acheminement des données dans les deux sens de communication entre le Proxy MPLS et DCGW. La différence principale entre FIG. 1 et FIG. 4 est que dans FIG. 1 , donc selon la technique antérieure, l’annonce (2) de route MP-BGP de la DCGW vers MP-RR est effectuée dès la réception (1) de l’annonce de route MP-BGP de PE2 vers DCGW, sans attendre une quelconque annonce de route MP-BGP de MP-RR vers DCGW permettant à DCGW d’être configurée par Kubernetes avec le même identifiant que celui configuré sur le MPLS Proxy. Il n’est donc pas possible pour DCGW de connaître le label MPLS-2 du proxy MPLS pour l’insérer dans l’annonce (2) de route à MP-RR et le configurer dans ses tables FIB et LFIB en réception du tunnel MPLS. C’est donc un autre label MPLS-X qui est mis à la place et qui est incompatible avec la configuration désirée du Proxy MPLS pour ce VPN. Dans FIG. 4 , la DCGW attend avant d’envoyer l’annonce de route (2) vers MP-RR et de configurer un label MPLS dans ses tables FIB et LFIB en réception du tunnel MPLS. Une annonce simple (9) est envoyée par MP-RR avec les identifiants du VPN (Route Target et Route Distinguisher) ainsi que le label MPLS-2 inséré dans la configuration de MP-RR et identique à celle poussée dans le Proxy MPLS tel que décrit dans le NAD associé au Pod pour ce VPN. Lorsque MP-RR est un réflecteur de routes à deux étages comme décrit précédemment, cette annonce simple (9) peut être mise en œuvre dès la création du deuxième étage du réflecteur de routes pour le VPN considéré. Dans ce scénario, l’annonce simple est initialement émise par le deuxième étage à destination de l’étage frontal concerné, puis relayée par cet étage frontal vers la DCGW. C’est seulement après avoir reçu cette annonce simple (9) que la DCGW envoie le message (2) avec le bon label MPLS-2 vers l’étage frontal et configure le bon label MPLS-2 dans ses tables FIB et LFIB en réception du tunnel MPLS. La DCGW est donc alignée avec la configuration désirée du Proxy MPLS pour ce VPN. Dans cet exemple, la technique proposée implique une nouvelle signalisation, et en particulier un nouveau message d’annonce simple de label MPLS pour un VPN. Concrètement, l’annonce simple de label MPLS peut correspondre à un message UPDATE contenant au moins un attribut EXTENDED_COMMUNITIES avec un Route Target relatif au VPN considéré et un attribut MP_REACH_NLRI contenant les informations suivantes : Soit sans adresse de prochain saut : Address Family Identifier (AFI) : « IPv4 » ou « IPv6 » suivant la version des adresses/préfixes IP annoncés, Subsequent Address Family Identifier (SAFI) : « Labeled VPN Unicast », pour indiquer que les paquets IP sont encapsulés dans des trames MPLS, Length of Next Hop Network Address : 0 pour indiquer l’absence d’adresse de prochain saut, Network Layer Reachability Information (NLRI) : un champ d’information dont la structure dépend du couple AFI/SAFI Soit avec une adresse de prochain saut quelconque : Address Family Identifier (AFI) : « IPv4 » ou « IPv6 » suivant la version des adresses/préfixes IP annoncés, Subsequent Address Family Identifier (SAFI) : « Labeled VPN Unicast », pour indiquer que les paquets IP sont encapsulés dans des trames MPLS, Length of Next Hop Network Address : taille d’une adresse IPv4 ou IPv6, Network Address of Next Hop : adresse de prochain saut quelconque 0.0.0.0/0 pour IPv4, ::/0 pour IPv6 Network Layer Reachability Information (NLRI) : un champ d’information dont la structure dépend du couple AFI/SAFI Dans l’un ou l’autre des cas, le champ NLRI pourra être renseigné de la façon suivante : Length : longueur en bits des informations suivantes, Labels : le label MPLS symétrique émis par le Réflecteur de Routes pour le VPN Prefix : Route Distinguisher suivi de l’adresse quelconque 0.0.0.0/0 pour IPv4, ou de l’adresse quelconque ::/0 pour IPv6 Ou bien encore de la façon suivante : Length : longueur en bits des informations suivantes, Labels : le label MPLS symétrique émis par le Réflecteur de Routes Prefix : Route Distinguisher suivi de l’adresse d’exclusion: 255.255.255.255/32 pour IPv4 ou ffff:ffff:ffff:ffff: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff /128 pour IPv6 Dans une autre réalisation, l’annonce simple de label MPLS peut correspondre à un message UPDATE contenant au moins un attribut EXTENDED_COMMUNITIES avec un Route Target relatifs au VPN considéré et un attribut MP_UNREACH_NLRI contenant les informations suivantes : Address Family Identifier (AFI) : « IPv4 » ou « IPv6 » suivant la version des adresses IP annoncées, Subsequent Address Family Identifier (SAFI) : « Labeled VPN Unicast », pour indiquer que les paquets IP sont encapsulés dans des trames MPLS, Withdrawn Routes : l’un des champs NLRI définis ci-dessus. Il est à présent fait référence à FIG. 5 , qui représente un diagramme de séquence pour l’établissement d'une communication entre CEL2 et CER2 empruntant un tunnel entre une passerelle DCGW et le Proxy MPLS dans un autre exemple de réalisation que celui de FIG. 4 . Les premières étapes du processus sont identiques à celles en FIG. 4 . PE2 annonce (1) à DCGW, comme dans FIG. 1 et FIG. 4 , une route vers l’adresse IP de CER2 dans le VPN2 accessible via l’adresse IP (de prochain saut) de PE2 avec comme identifiant d’acheminement un label noté « MPLS-B ». MP-RR ouvre, comme dans FIG. 4 , une session de commande MP-BGP avec DCGW à l’aide d’un processus de signalisation approprié pour la mise en place par DCGW d’une portion de tunnel symétrique entre DCGW et le MPLS Proxy auquel est attaché le CEL2. L’entité Kubernetes commence, comme dans FIG. 4 , par choisir (4) comme identifiant d’acheminement un label noté « MPLS-2 » pour VPN2, par ajouter sur MP-RR un service BGP pour le VPN2, et par mettre à jour la configuration de MP-RR pour le VPN2 avec comme identifiant d’acheminement le label MPLS-2. Par ailleurs Kubernetes transmet au MPLS proxy l’identifiant MPLS-2 à utiliser pour la configuration du tunnel avec DCGW pour le VPN2. L’interaction entre MP-RR et CEL2 est inchangée par rapport à FIG. 1 et FIG. 4 et aboutit de manière identique à ce que MP-RR annonce (8) à DCGW une route vers des adresses CEL2_IP-D@ dans le VPN2 accessible via l’adresse IP (de prochain saut) de CEL2 avec comme identifiant d’acheminement le label MPLS-2. Comme dans FIG. 4 , DCGW attend de recevoir (8) de MP-RR un message contenant l’identifiant MPLS-2 avant d’annoncer (2) une route à MP-RR et de configurer un label MPLS dans ses tables FIB et LFIB. Le résultat final, sous la forme du tunnel bidirectionnel mis en place, est également identique à celui obtenu dans FIG. 4 . FIG. 5 diffère de FIG. 4 par le processus menant MP-RR à transmettre l’identifiant MPLS-2 à DCGW. En effet, dans FIG. 4 , MP-RR envoie (9) dans un premier temps une annonce simple à DCGW, l’annonce simple contenant le label MPLS-2 en tant qu’identifiant d’acheminement pour le VPN2. MP-RR envoie (8) une annonce de route dans un second temps à DCGW après que DCGW configure le label (ou l’identifiant) MPLS-2 dans ses tables FIB et LFIB du tunnel MPLS. L’annonce contient une route vers des adresses CEL2_IP-D@ dans le VPN2 accessibles via l’adresse IP (de prochain saut) de CEL2 avec comme identifiant d’acheminement le label MPLS-2. L’annonce est effectuée dès que la configuration de MP-RR est mise à jour par l’entité VIM/Kubernetes pour le VPN2 avec comme identifiant d’acheminement le label MPLS-2. A l’inverse dans FIG. 5 , aucune annonce simple n’est effectuée par MP-RR à DCGW avant l’annonce de route. Au contraire, l’annonce de route MP-BGP est envoyée (8) par MP-RR uniquement après qu’il ait reçu (7) de CEL2 une annonce de route BGP et avant que DCGW configure le label (ou l’identifiant) MPLS-2 dans les tables FIB et LFIB du tunnel MPLS. Comme l’annonce de route BGP ne contient que l’adresse de prochain saut (next hop) vers les adresses/préfixes IP annoncée, MP-RR relaie cette annonce de route vers DCGW en lui ajoutant les identifiants du VPN (Route Target et Route Distinguisher) ainsi que le label MPLS-2 inséré dans la configuration de MP-RR, identique à celle poussée dans le Proxy MPLS, associé au Pod implémentant le CE, pour ce VPN. C’est ainsi seulement à ce moment que la DCGW envoie (2) le message avec le bon label MPLS-2 vers MP-RR et configure le bon label MPLS-2 dans les tables FIB et LFIB du tunnel MPLS. La DCGW est donc alignée avec la configuration désirée du proxy MPLS pour ce VPN. Dans une réalisation où le réflecteur de routes MP-RR est à deux étages, le processus d’annonce (8) de route par MP-RR à DCGW peut être détaillé de la manière suivante. Le deuxième étage pour le VPN considéré, par exemple un réflecteur de route propre au deuxième étage, reçoit (7) une annonce de route BGP depuis le CEL2. Ce deuxième étage (le réflecteur de routes) envoie, à l’étage frontal concerné, c’est-à-dire au MP-RR, un message relayant l’annonce de route et comprenant en outre les identifiants du VPN (Route Target et Route Distinguisher) ainsi que le label MPLS-2 préalablement inséré dans la configuration du deuxième étage par l’entité VIM/Kubernetes. Cette annonce est relayée (8) dans l’annonce de route normale MP-BGP par l’étage frontal (MP-RR) vers la DCGW. Parmi les exemples de réalisation fournis, ceux selon FIG. 4 et FIG. 5 confèrent à DCGW un rôle de client dans une relation client-serveur avec MP-RR, où MP-RR, assumant le rôle de serveur, annonce le label MPLS-2 à DCGW, assumant le rôle de client. Ce label MPLS-2 est ensuite utilisé pour l’établissement par DCGW du tunnel bidirectionnel ayant une portion symétrique entre DCGW et le dispositif mandataire MPLS Proxy. A l’inverse, l’exemple de réalisation selon FIG. 1 confère à DCGW un rôle de serveur dans la relation client-serveur avec MP-RR dans la mesure où DCGW, assumant le rôle de serveur, annonce le label MPLS-X à MP-RR, assumant le rôle de client. Ce label MPLS-X est ensuite utilisé, avec le label MPLS-2 pour l’établissement par DCGW du tunnel bidirectionnel ayant une portion asymétrique entre DCGW et le MPLS Proxy, ce qui ne répond pas aux problèmes identifiés initialement. Dans le cas où un système de communication supporte potentiellement aussi bien au moins l’un des exemples de réalisation selon FIG. 4 et FIG. 5 ] qu’un exemple de réalisation selon FIG. 1 ou analogue à ce dernier, il peut être judicieux de prévoir une signalisation entre MP-RR (ou plus précisément l’étage frontal dans une configuration à deux étages) et DCGW qui permette d’affecter à l’un un rôle de serveur et à l’autre un rôle de client dans la relation client-serveur précitée. Cette signalisation peut permettre de négocier, établir ou modifier les rôles de client et de serveur. Lors de l'ouverture d'une session BGP, MP-RR envoie un message OPEN à DCGW contenant des attributs ou champs nouveaux. Ces éléments incluent un attribut qui spécifie un rôle affecté proposé (client ou serveur) pour DCGW (ou pour MP-RR) dans la relation client-serveur. Ce message peut également contenir des paramètres de configuration supplémentaires, comme des préférences pour les types de routes à échanger ou des options de sécurité renforcée. En réponse au message de MP-RR, DCGW peut envoyer un message contenant par exemple l'acceptation de la proposition de rôle de MP-RR ou une contre-proposition. Inversement, la signalisation peut débuter par un message OPEN envoyé par DCGW à MP-RR et suivre le même principe qu’exposé ci-dessus. Pour faciliter la configuration dynamique des rôles dans la relation client-serveur entre DCGW et MP-RR, il est envisageable d'introduire un nouveau champ dans le processus de signalisation. Ce champ, potentiellement nommé REFLEXIVE_LABEL, peut être intégré dans le message OPEN envoyé par DCGW. Une autre option est d’utiliser une terminologie plus explicite et d’utiliser un champ associé spécifiquement au serveur et au client, tel que par exemple SYMMETRIC_LABEL_SERVER pour le serveur et SYMMETRIC_LABEL_CLIENT pour le client. Ce(s) champ(s) indiquent que DCGW est capable de supporter une signalisation particulière, suggérant ainsi un rôle spécifique (soit client, soit serveur) dans la session BGP. Si DCGW annonce par exemple le code REFLEXIVE_LABEL, cela indique à MP-RR (ou plus précisément à l'étage frontal dans une configuration à deux étages) que DCGW est prête à assumer un rôle de client. En conséquence, MP-RR peut alors propager cette signalisation vers les deuxièmes étages, et relayer vers DCGW les annonces simples de label (comme indiqué dans l’exemple de réalisation de FIG. 4 ou les annonces normales de routes, comme dans l’exemple de réalisation de FIG. 5 , reçues de ces deuxièmes étages. Ainsi, DCGW, en reconnaissant le code REFLEXIVE_LABEL et s’identifiant donc comme client, s'attend à recevoir ces annonces avant d'envoyer ses propres annonces de routes vers le premier étage avec le label symétrique pour chaque VPN. Dans le cas où DCGW ne transmet pas le code REFLEXIVE_LABEL, le premier étage, à savoir MP-RR dans ce contexte, peut ne pas être en mesure d'accepter l'ouverture de sessions BGP avec les deuxièmes étages dans le cas d’une architecture à deux étages. Cela implique une limitation dans la flexibilité de la signalisation et de la configuration des rôles, nécessitant ainsi une approche alternative ou une configuration manuelle pour établir la relation client-serveur souhaitée. Une fois la session BGP établie, DCGW et MP-RR peuvent continuer à négocier ou à ajuster leurs rôles par l'envoi de messages BGP UPDATE. Ces messages peuvent inclure des champs supplémentaires pour proposer des changements dans les rôles ou les paramètres de la session, en fonction de l'évolution des conditions réseau ou des exigences opérationnelles. Pour assurer la sécurité et la validité de la signalisation, des mécanismes de vérification tels que des signatures numériques ou des échanges de clés peuvent être intégrés. Cela garantit que les messages de signalisation proviennent de sources authentiques et que les informations échangées sont intactes et fiables. Bien que la technique proposée ait été décrite en détail avec référence à certaines formes de réalisation préférées, diverses modifications et variations peuvent être apportées sans s’écarter du domaine de l’invention tel que défini dans les revendications jointes. Par exemple, les procédures décrites peuvent être effectuées dans un ordre différent, des éléments peuvent être ajoutés ou supprimés, et des caractéristiques de différents modes de réalisation peuvent être combinées comme il convient. Procédé mis en œuvre par une passerelle de centre de données, DCGW, et comprenant les étapes de : recevoir (1) un premier message contenant une annonce d’une route vers un premier dispositif d’un premier client, CER2, ledit premier dispositif étant attaché à un réseau privé virtuel, VPN2, recevoir un message distinct du premier message, relatif à une ouverture d’une session d’échange de route avec un routeur, MP-RR, le message distinct comprenant un attribut spécifiant un rôle de serveur ou de client attribué à l’un parmi le client et la passerelle dans une relation serveur-client avec le routeur, et lorsque l’attribut spécifie un rôle de client à la passerelle ou un rôle de serveur au routeur, préalablement à l’annonce au routeur de la route vers le premier dispositif, CER2, recevoir (8, 9) du routeur une annonce d'un identifiant d’acheminement associé au réseau privé virtuel pour au moins un deuxième dispositif d’un deuxième client, CEL2, ledit deuxième dispositif étant également attaché au réseau privé virtuel par l’intermédiaire d’un dispositif mandataire préalablement configuré avec l’identifiant d’acheminement. Procédé selon la revendication 1, comprenant en outre, lorsque l’attribut spécifie un rôle de serveur à la passerelle ou un rôle de client au routeur, annoncer (2) au routeur une route vers le premier dispositif, CER2, ladite route comprenant un identifiant d’acheminement associé au réseau privé virtuel pour au moins un deuxième dispositif d’un deuxième client, CEL2, ledit deuxième dispositif étant également attaché au réseau privé virtuel par l’intermédiaire d’un dispositif mandataire préalablement configuré avec l’identifiant d’acheminement. Procédé selon la revendication 1 ou 2, comprenant en outre une réception en provenance du routeur d’une route vers le deuxième dispositif du deuxième client, CEL2, ladite route comprenant l’identifiant d’acheminement. Procédé selon l’une des revendications 1 à 3, dans lequel l’identifiant d’acheminement est utilisé pour l’établissement d’un tunnel bidirectionnel entre la passerelle et le dispositif mandataire, l’identifiant d’acheminement étant utilisé pour acheminer les données dans les deux directions du tunnel. Procédé selon l’une des revendications 1 à 4, dans lequel lorsque l’attribut indique l’affectation du rôle de client à la passerelle, l’identifiant contenu dans l’annonce reçue par la passerelle est choisi par une entité d’orchestration de conteneurs d’applications. Procédé selon l’une des revendications 1 à 5, dans lequel la réception de l’annonce dudit identifiant est mise en œuvre de manière asynchrone par rapport à la réception du premier message. Procédé selon l’une des revendications 1 à 6, comprenant en outre : notifier au routeur une acceptation du rôle affecté. Procédé mis en œuvre par un routeur et comprenant les étapes de : transmettre un message relatif à une ouverture d’une session d’échange de route avec une passerelle de centre de données, DCGW, le message comprenant un attribut spécifiant un rôle de serveur ou de client attribué à l’un parmi le client et la passerelle dans une relation serveur-client avec le routeur, et lorsque l’attribut spécifie un rôle de client à la passerelle ou un rôle de serveur au routeur, préalablement à la réception d’une annonce par la passerelle d’une route vers un premier dispositif d’un premier client, CER2, annoncer (8, 9) à la passerelle un identifiant d’acheminement associé au réseau privé virtuel pour au moins un deuxième dispositif d’un deuxième client, CEL2, ledit deuxième dispositif étant également attaché au réseau privé virtuel par l’intermédiaire d’un dispositif mandataire préalablement configuré avec l’identifiant d’acheminement. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications 1 à 8 lorsque ce programme est exécuté par un processeur. Support d’enregistrement non transitoire lisible par un ordinateur sur lequel est enregistré un programme pour la mise en œuvre du procédé selon l’une des revendications 1 à 8 lorsque ce programme est exécuté par un processeur. Passerelle de centre de données, DCGW, configurée pour : recevoir (1) un premier message contenant une annonce d’une route vers un premier dispositif d’un premier client, CER2, ledit premier dispositif étant attaché à un réseau privé virtuel, VPN2, recevoir un message distinct du premier message et relatif à une ouverture d’une session d’échange de route avec un routeur, MP-RR, le deuxième message comprenant un attribut spécifiant un rôle de serveur ou de client attribué à l’un parmi le client et la passerelle dans une relation serveur-client avec le routeur, et lorsque l’attribut spécifie un rôle de client à la passerelle ou un rôle de serveur au routeur, préalablement à l’annonce au routeur de la route vers le premier dispositif, CER2, recevoir (8, 9) du routeur une annonce d'un identifiant d’acheminement associé au réseau privé virtuel pour au moins un deuxième dispositif d’un deuxième client, CEL2, ledit deuxième dispositif étant également attaché au réseau privé virtuel par l’intermédiaire d’un dispositif mandataire préalablement configuré avec l’identifiant d’acheminement. Routeur configuré pour : transmettre un message relatif à une ouverture d’une session d’échange de route avec une passerelle de centre de données, DCGW, le message comprenant un attribut spécifiant un rôle de serveur ou de client attribué à l’un parmi le client et la passerelle dans une relation serveur-client avec le routeur, et lorsque l’attribut spécifie un rôle de client à la passerelle ou un rôle de serveur au routeur, préalablement à la réception d’une annonce par la passerelle d’une route vers un premier dispositif d’un premier client, CER2, annoncer (8, 9) à la passerelle un identifiant d’acheminement associé au réseau privé virtuel pour au moins un deuxième dispositif d’un deuxième client, CEL2, ledit deuxième dispositif étant également attaché au réseau privé virtuel par l’intermédiaire d’un dispositif mandataire préalablement configuré avec l’identifiant d’acheminement. Système comprenant une passerelle de centre de données selon la revendication 11 et un routeur selon la revendication 12.