Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Configurer les services gRPC

Configurez le serveur gRPC pour permettre à un client d’utiliser les services gRPC sur l’équipement réseau, notamment : les services gRPC Network Operations Interface (gNOI), les services gRPC Network Management Interface (gNMI) et les services gRPC Routing Information Base Interface (gRIBI).

Cette rubrique explique comment configurer les services gRPC sur les équipements Junos, y compris les options d’authentification et comment configurer chaque option. Avant que le serveur et le client puissent établir une session gRPC, vous devez satisfaire aux exigences décrites dans les sections suivantes :

Comprendre l’authentification et l’autorisation pour les services basés sur gRPC

Les interfaces gNMI, gNOI et gRIBI utilisent le framework d’appel de procédure à distance gRPC pour le transport. Le serveur gRPC s’exécute sur le périphérique réseau et écoute les demandes de connexion sur un port spécifié. L’application client gRPC s’exécute sur un système de gestion de réseau distant (NMS) et établit un canal gRPC avec le serveur sur l’hôte et le port spécifiés. Le client exécute des RPC via la session gRPC chiffrée SSL pour effectuer des opérations de service réseau. La figure 1 illustre une connexion simple entre un client et un serveur gRPC.

Figure 1 : Interaction gRPC Server and Client Interaction entre le serveur et le client gRPC

Les canaux gRPC utilisent les informations d’identification des canaux pour gérer l’authentification entre le serveur et le client. Les informations d’identification des canaux standard utilisent des certificats numériques X.509 pour authentifier le serveur et le client. Un certificat numérique permet d’authentifier les utilisateurs par l’intermédiaire d’un tiers de confiance appelé autorité de certification ou autorité de certification (AC). L’AC vérifie l’identité d’un titulaire de certificat et « signe » le certificat pour attester qu’il n’a pas été falsifié ou modifié. La norme X.509 définit le format du certificat. Les certificats numériques peuvent être utilisés pour établir une connexion sécurisée entre deux points de terminaison grâce à la validation des certificats. Pour établir un canal gRPC, chaque point de terminaison (appareil ou application) nécessitant une authentification doit fournir un certificat X.509 dans l’échange.

Les équipements Junos prennent en charge l’authentification serveur uniquement et l’authentification mutuelle pour les sessions gRPC SSL et TLS. Lorsque l’authentification serveur uniquement est configurée, le serveur fournit son certificat de clé publique lorsque le canal est établi. Le client utilise le certificat d'AC racine du serveur pour authentifier le serveur. Lorsque l’authentification mutuelle est configurée, le client fournit également son certificat lorsqu’il se connecte au serveur, et le serveur valide le certificat. Si la validation du certificat réussit, le client est autorisé à passer des appels. Nous vous recommandons de configurer l’authentification mutuelle et d’utiliser des certificats signés par l’AC pour une sécurité maximale, bien que les certificats auto-signés soient acceptés.

Une infrastructure à clé publique (PKI) prend en charge la distribution et l’identification des clés de chiffrement publiques, ce qui permet aux utilisateurs d’échanger des données en toute sécurité sur des réseaux tels qu’Internet et de vérifier l’identité de l’autre partie. Pour les services basés sur gRPC, l’ICP de Junos doit contenir le certificat de l’équipement local faisant office de serveur gRPC. Si vous utilisez l’authentification mutuelle, la PKI Junos doit également contenir les certificats d’AC racine nécessaires pour valider les certificats de tous les clients gRPC qui se connectent à l’équipement.

Le Tableau 1 décrit les exigences générales relatives à l’authentification serveur uniquement et à l’authentification mutuelle lorsqu’un client gRPC se connecte à l’équipement pour exécuter des services basés sur gRPC. Le certificat du serveur gRPC doit définir soit le nom d'hôte du serveur dans le champ Common Name (CN), soit l'adresse IP du serveur dans le champ Subject Alternative Name (subjectAltName ou SAN). L’application cliente doit utiliser la même valeur pour établir la connexion au serveur. Si le certificat définit le champ Adresse IP SubjectAltName, le champ Nom commun est ignoré lors de l’authentification.

Tableau 1 : exigences relatives à l’authentification serveur uniquement et à l’authentification mutuelle pour les sessions gRPC
Exigences Authentification serveur uniquement Authentification mutuelle
Certificats

Le serveur doit disposer d’un certificat de clé publique X.509.

Si le client se connecte à l'adresse IP du serveur au lieu du nom d'hôte, le certificat du serveur doit inclure le champ d'extension de l'adresse IP subjectAltName (SAN) avec l'adresse IP du serveur.

Le serveur et le client doivent chacun disposer d’un certificat de clé publique X.509.

Si le client se connecte à l'adresse IP du serveur au lieu du nom d'hôte, le certificat du serveur doit inclure le champ d'extension de l'adresse IP subjectAltName (SAN) avec l'adresse IP du serveur.
Junos PKI

Le certificat local du serveur doit être chargé dans la PKI Junos.

Le certificat local du serveur et le certificat d'AC racine de chaque client doivent être chargés dans l'ICP Junos.
Identifiants de canal

Le client doit transmettre le certificat AC racine du serveur lorsque le canal gRPC est établi.

Le client doit transmettre son certificat et sa clé ainsi que le certificat de AC racine du serveur lorsque le canal gRPC est établi.

Les informations d’identification du canal sont attachées au canal gRPC et permettent à l’application cliente d’accéder au service. Les identifiants d’appel, quant à eux, sont attachés à une opération de service spécifique (demande RPC) et fournissent des informations sur la personne qui utilise l’application cliente. Les identifiants d’appel sont envoyés par requête, c’est-à-dire pour chaque appel RPC. Pour exécuter des opérations basées sur gRPC sur des équipements Junos, vous devez fournir des informations d’identification d’appel dans la demande. L’utilisateur doit avoir un compte d’utilisateur défini localement sur l’appareil, ou l’utilisateur doit être authentifié par un serveur TACACS+, qui mappe ensuite l’utilisateur à un compte de modèle d’utilisateur défini localement sur l’appareil. Vous pouvez fournir les informations d'identification de l'appel (nom d'utilisateur et mot de passe) dans l'argument du metadata RPC. Si l’authentification réussit, l’équipement Junos exécute la requête RPC à l’aide des privilèges de compte de l’utilisateur spécifié.

Remarque :

Au lieu de transmettre les identifiants d’appel pour chaque RPC exécuté sur un équipement Junos, vous pouvez utiliser l’API Juniper Extension Toolkit jnx_authentication_service pour vous connecter à l’appareil une seule fois au début de la session gRPC, et tous les RPC suivants exécutés dans le canal sont authentifiés. Vous pouvez télécharger la bibliothèque IDL du client JET à partir du site de téléchargement de Juniper Networks.

Par défaut, les équipements Junos autorisent un client gRPC authentifié à exécuter tous les RPC gRPC. Vous pouvez éventuellement configurer la classe de connexion d'un utilisateur gRPC pour autoriser ou refuser explicitement des RPC gRPC spécifiques. Pour spécifier les RPC, vous configurez les instructions et deny-grpc-rpc-regexps définissez les allow-grpc-rpc-regexps expressions régulières qui correspondent aux RPC. Pour plus d’informations, consultez Configurer l’autorisation RPC gRPC.

Obtenir des certificats X.509

Une session gRPC utilise des certificats de clé publique X.509 pour authentifier le serveur et le client gRPC. Pour l’authentification serveur uniquement, le serveur gRPC doit disposer d’un certificat. Pour l’authentification mutuelle, le serveur gRPC et le client doivent tous deux disposer de certificats. Les exigences pour les certificats sont les suivantes :

  • Le certificat peut être signé par un AC ou auto-signé.

  • Le certificat doit être encodé en PEM.

  • Le certificat du serveur gRPC doit définir soit le nom d'hôte du serveur gRPC dans le champ Common Name (CN), soit l'adresse IP du serveur gRPC dans le champ SubjectAltName (SAN). Le client gRPC doit utiliser la même valeur pour établir la connexion au serveur. Si le certificat définit l’adresse IP SubjectAltName, le champ Nom commun est ignoré lors de l’authentification.

Pour utiliser OpenSSL afin d'obtenir le certificat du serveur gRPC :

  1. Générez une clé privée et spécifiez la longueur de la clé en bits.
  2. Si le client gRPC se connecte à l’adresse IP du serveur gRPC, mettez à jour votre fichier de configuration openssl.cnf ou équivalent pour définir l’extension avec l’adresse subjectAltName=IP IP du serveur gRPC.
  3. Générez une demande de signature de certificat (CSR), qui contient la clé publique de l'entité et des informations sur son identité.

    Vous pouvez également fournir les informations CSR en une seule commande, par exemple :

  4. Générez le certificat en procédant de l’une des manières suivantes :

    • Envoyez le CSR à un AC pour demander un certificat X.509 et fournissez le fichier de configuration pour inclure toute extension supplémentaire.

    • Signez le CSR avec une AC pour générer le certificat et incluez l’option -extfile si vous devez référencer votre fichier de configuration et vos extensions.

    • Signez le CSR avec la clé du serveur pour générer un certificat auto-signé et incluez l’option -extfile si vous devez référencer votre fichier de configuration et vos extensions.

  5. Vérifiez que le champ Nom usuel (CN) et les extensions du certificat, le cas échéant, sont corrects.

Pour l'authentification mutuelle, répétez les étapes précédentes avec les informations permettant au client gRPC de générer la clé et le certificat du client. Le certificat client ne nécessite pas le champ Extension de l’IP SAN.

Chargez le certificat local du serveur gRPC dans la PKI Junos

Le périphérique réseau exécutant le serveur gRPC doit disposer d’un certificat X.509 qui identifie le périphérique auprès des clients gRPC. Pour exécuter des services basés sur gRPC sur l’équipement Junos, vous devez charger la clé publique, le certificat et la clé de l’équipement de réseau local dans l’ICP Junos. Une fois que vous avez chargé le certificat et effectué la configuration initiale, les clients gRPC peuvent utiliser n’importe quel microservice pour mettre à jour le certificat. Par exemple, un client gRPC peut utiliser le service gNOI CertificateManagement pour installer un nouveau certificat ou remplacer un certificat existant.

Pour charger le certificat et la clé de l'appareil local dans l'ICP :

  1. Téléchargez le certificat et la clé de l’appareil qui agit en tant que serveur gRPC sur cet appareil.
  2. En mode opérationnel, définissez un identifiant et chargez le certificat et la clé de l'appareil local dans la PKI.

    Par exemple :

  3. (Facultatif) Vérifiez que le certificat est présent dans la base de données PKI.

Activer les services gRPC

Les services basés sur gRPC utilisent un paramètre de connexion API basé sur la technologie Secure Socket Layer (SSL) ou couche transport Sécurité (TLS). Pour ces connexions, vous devez spécifier un certificat local qui identifie le serveur gRPC.

Une fois que vous avez activé les services gRPC et spécifié un certificat local, le périphérique réseau utilise l’authentification serveur uniquement. Vous pouvez ensuite configurer l’authentification mutuelle en suivant les étapes décrites dans Configuration de l’authentification mutuelle (bidirectionnelle) pour les services gRPC.

Vous pouvez configurer votre équipement réseau pour les services gRPC et spécifier le certificat local utilisé pour l’authentification du serveur à l’un des niveaux hiérarchiques suivants :

  • [edit system services http servers]: utilise cette hiérarchie d’instructions pour configurer un ou plusieurs serveurs gRPC qui hébergent différents ensembles de services sur des ports uniques. De plus, chaque serveur peut prendre en charge des adresses d’écoute, des certificats et des instances de routage différents.

  • [edit system services extension-service request-response grpc ssl]: utilisez cette hiérarchie d’instructions lorsque vous n’avez besoin que d’un seul serveur gRPC prenant en charge tous les services gRPC sur la même adresse d’écoute et le même port.

Pour configurer l'appareil pour les services gRPC, suivez les instructions du niveau hiérarchique qui répond aux exigences de votre environnement.

[edit system services http servers]

Pour configurer un ou plusieurs serveurs gRPC au niveau de la [edit system services http servers] hiérarchie :

  1. Accédez au niveau hiérarchique des serveurs gRPC et spécifiez un identifiant pour le serveur.

    Par exemple :

  2. Configurez le port à utiliser pour les services gRPC. Le port doit être unique pour chaque serveur gRPC.

    Par exemple :

  3. Configurez les services gRPC hébergés par ce serveur.

    Dans cet exemple, le serveur héberge les services gNMI et gNOI.

  4. Spécifiez le certificat local qui identifie le serveur à un client.

    Entrez l’identificateur du certificat local que vous avez précédemment chargé dans la PKI Junos à l’aide de la request security pki local-certificate load commande mode opérationnel.

    L’exemple suivant configure le certificat gnoi-serverlocal :

  5. (Facultatif) Spécifiez l’adresse IPv4 ou IPv6 sur laquelle le serveur écoute les connexions entrantes.

    Par exemple :

    Remarque :

    Si vous ne spécifiez pas d’adresse IP, l’adresse par défaut :: est utilisée pour écouter les connexions entrantes.

  6. (Facultatif) Configurez l’instance de routage à utiliser pour ce serveur gRPC, si elle diffère de l’instance de routage par défaut.

    L’exemple suivant utilise l’instance de routage mgmt-junos.

  7. (Facultatif) Configurez le nombre maximal de connexions que ce serveur gRPC prend en charge.

    L’exemple suivant configure un maximum de 10 connexions. La valeur par défaut est 5.

  8. Validez la configuration.

Pour configurer l’authentification mutuelle au lieu de l’authentification serveur uniquement, vous devez également suivre les étapes décrites dans Configuration de l’authentification mutuelle (bidirectionnelle) pour les services gRPC.

[edit system services extension-service request-response grpc ssl]

Pour configurer un seul serveur gRPC au niveau de la [edit system services extension-service request-response grpc ssl] hiérarchie :

  1. Accédez aux paramètres de connexion API basés sur SSL pour les services gRPC.

  2. Configurez le port à utiliser pour les services gRPC.

    Par exemple :

  3. Spécifiez le certificat local qui identifie le serveur à un client.

    Entrez l’identificateur du certificat local que vous avez précédemment chargé dans la PKI Junos à l’aide de la request security pki local-certificate load commande mode opérationnel.

    L’exemple suivant configure le certificat gnoi-serverlocal :

  4. Configurez l’appareil pour utiliser la base de données PKI pour les certificats.

  5. Permet à l’appareil de recharger les certificats sans mettre fin à la session gRPC.

  6. (Facultatif) Spécifiez une adresse IP à écouter pour les connexions entrantes.

    Par exemple :

    Remarque :

    Si vous ne spécifiez pas d’adresse IP, l’adresse par défaut :: est utilisée pour écouter les connexions entrantes.

  7. (Facultatif) Configurez le suivi pour les services d’extension afin de déboguer les problèmes qui peuvent survenir.

    Remarque :

    Pour afficher les fichiers de trace Junos OS Evolved pour les services d’extension, utilisez les show trace application jsd commandes et mode show trace application jsd live opérationnel.

  8. Validez la configuration.

Pour configurer l’authentification mutuelle au lieu de l’authentification serveur uniquement, vous devez également suivre les étapes décrites dans Configuration de l’authentification mutuelle (bidirectionnelle) pour les services gRPC.

Configurer l’authentification mutuelle (bidirectionnelle) pour les services gRPC

Vous pouvez configurer l’authentification mutuelle (bidirectionnelle) pour les sessions gRPC, qui authentifie à la fois le périphérique réseau en tant que serveur gRPC et NMS en tant que client gRPC à l’aide de certificats. L’équipement Junos utilise les informations d’identification fournies par le client externe pour authentifier le client et autoriser une connexion.

Vous pouvez configurer l’authentification mutuelle sur les équipements Junos à l’aide de l’une des options suivantes :

  • Configurez les paramètres d’authentification mutuelle directement dans la configuration.

  • Configurez initialement l’authentification sur serveur uniquement, puis utilisez le service gNOI CertificateManagement pour charger les certificats AC nécessaires sur l’appareil.

Si vous configurez l’authentification mutuelle directement dans la configuration de l’appareil, la configuration de l’appareil est prioritaire sur toute configuration effectuée à l’aide des services gNOI.

Avant de commencer :

Les sections suivantes décrivent les différentes méthodes de configuration de l’authentification mutuelle. Vous pouvez utiliser la méthode la mieux adaptée à votre environnement.

Configurer l’authentification mutuelle dans la configuration de l’appareil

Pour configurer l’authentification du client gRPC directement dans la configuration de l’équipement réseau :

  1. Téléchargez le certificat de l'AC racine qui sera utilisé pour valider le certificat du client sur l'appareil local faisant office de serveur gRPC.

  2. Configurez un profil d'AC pour l'AC racine du certificat client au niveau de la [edit security pki] hiérarchie.

    Par exemple :

  3. Validez la configuration.

  4. En mode opérationnel, chargez le certificat d'AC racine qui sera utilisé pour vérifier le certificat du client dans l'ICP Junos. Spécifiez l’identificateur ca-profile que vous avez configuré dans les étapes précédentes.

    Par exemple :

    Conseil :

    Pour charger un bundle de certificats AC, exécutez la request security pki ca-certificate ca-profile-group load ca-group-name ca-group-name filename bundle-path commande.

    Après avoir chargé le certificat, entrez en mode configuration et continuez à configurer l’authentification mutuelle. Vous devez configurer l’authentification mutuelle au même niveau hiérarchique que celui où vous avez configuré votre serveur. Effectuez les étapes décrites dans la section pour votre niveau hiérarchique.

[modifier les serveurs HTTP des services système]

Pour configurer l’authentification mutuelle pour un serveur configuré au niveau de la [edit system services http servers] hiérarchie :

  1. Accédez à l’instruction sous la tls configuration de votre serveur.

    Par exemple :

  2. Activez l’authentification mutuelle et spécifiez les exigences relatives aux certificats client.

    Par exemple, pour spécifier l’authentification la plus forte, qui nécessite un certificat et sa validation, utilisez request-and-require-cert-and-verify, qui est également la valeur par défaut.

  3. Spécifiez le profil d’AC qui sera utilisé pour vérifier le certificat client.

    Le profil d’AC a été configuré à l’étape 2 de la configuration du profil d’AC.

    Par exemple, pour spécifier le profil de l’AC nommé gnoi-client:

  4. Validez la configuration.

[modifier services système extension-service-demande-réponse grpc ssl]

Pour configurer l’authentification mutuelle pour un serveur configuré au niveau de la [edit system services extension-service request-response grpc ssl] hiérarchie :

  1. Activez l’authentification mutuelle et spécifiez les exigences relatives aux certificats client.

    Par exemple, pour spécifier l’authentification la plus forte, qui nécessite un certificat et sa validation, utilisez require-certificate-and-verify.

    Remarque :

    La valeur par défaut est no-certificate. Les autres options sont : request-certificate, request-certificate-and-verify, require-certificate, require-certificate-and-verify.

    Nous vous recommandons d’utiliser l’option no-certificate uniquement dans un environnement de test.

  2. Spécifiez le profil d’AC qui sera utilisé pour vérifier le certificat client.

    Le profil d’AC a été configuré à l’étape 2 de la configuration du profil d’AC.

    Par exemple, pour spécifier le profil de l’AC nommé gnoi-client:

  3. Validez la configuration.

Configurer l’authentification mutuelle à l’aide du service gNOI CertificateManagement

Vous pouvez utiliser le service gNOI CertificateManagement pour configurer l’authentification mutuelle entre le client gRPC et le serveur gRPC au lieu de configurer les paramètres directement dans la configuration de l’appareil. Vous configurez d’abord l’authentification serveur uniquement, puis utilisez les RPC du service gNOI CertificateManagement pour charger les certificats d’AC client. Pour plus d’informations sur le chargement des certificats à l’aide du service gNOI, consultez Service de gestion des certificats gNOICertificateManagement.

Le serveur gRPC ne prend en charge qu’un seul bundle global de certificats d’AC pour les services gNOI. Lorsque vous utilisez le service gNOI CertificateManagement pour charger le bundle de certificats AC, le périphérique utilise implicitement l’authentification mutuelle. Cependant, vous devez prendre note des points suivants :

  • Le CertificateManagement service charge toujours le bundle de certificats d’AC à l’aide de l’identifiant ca-profile-group gnoi-ca-bundleréservé .

  • Si vous utilisez le service pour charger le bundle de certificats d’AC CertificateManagement , l’appareil utilise implicitement l’authentification mutuelle.

  • Si le service envoie une demande de chargement d’un CertificateManagement nouveau bundle de certificats d’AC, le serveur efface les certificats du bundle d’AC précédent de l’appareil et charge les nouveaux.

  • Si vous utilisez le CertificateManagement service pour charger un bundle de certificats AC et que vous configurez explicitement l’authentification mutuelle dans la configuration de l’appareil, les instructions configurées sont prioritaires.

Configurer le compte d’utilisateur pour les services gRPC

Les informations d’identification du canal sont attachées au canal gRPC et permettent à l’application cliente d’accéder au service. Les identifiants d’appel sont joints à une demande RPC spécifique et fournissent des informations sur l’utilisateur qui utilise l’application cliente. Vous devez fournir des identifiants d’appel dans chaque requête RPC, qui nécessite un compte d’utilisateur pour l’équipement réseau. L’utilisateur doit avoir un compte d’utilisateur défini localement sur l’équipement réseau, ou l’utilisateur doit être authentifié par un serveur TACACS+, qui mappe ensuite l’utilisateur à un compte modèle d’utilisateur défini localement sur l’appareil.

Pour créer un compte d’utilisateur :

  1. Configurez l’instruction user avec un nom d’utilisateur unique et incluez-la class pour spécifier une classe de connexion disposant des autorisations requises pour toutes les actions à effectuer par l’utilisateur. Par exemple :
  2. Pour les comptes d'utilisateurs locaux, configurez le mot de passe de l'utilisateur.

    Vous pouvez omettre le mot de passe des comptes de modèle d’utilisateur local car l’utilisateur est authentifié via un serveur d’authentification distant.

  3. (Facultatif) Configurez l’instruction full-name pour spécifier le nom de l’utilisateur.
  4. Validez la configuration pour activer le compte d’utilisateur sur l’appareil.
  5. Répétez les étapes précédentes sur chaque équipement réseau sur lequel le client gRPC exécutera des RPC dans une session gRPC.

Configurer l’autorisation RPC gRPC

Par défaut, les équipements Junos autorisent un client gRPC authentifié à exécuter tous les RPC gRPC. Vous pouvez configurer une classe de connexion Junos pour autoriser ou refuser explicitement les RPC gRPC. Pour spécifier les RPC, vous configurez les instructions et deny-grpc-rpc-regexps définissez les allow-grpc-rpc-regexps expressions régulières qui correspondent aux RPC. S’il existe des expressions conflictuelles dans les listes autoriser et refuser, la liste de refus est prioritaire. Si un RPC ne correspond à aucune des listes, le RPC est autorisé par défaut.

Les équipements Junos utilisent la syntaxe suivante pour spécifier les RPC gRPC :

Où package, service, et rpc sont les noms définis dans l'instruction respective dans le fichier de proto-définition de ce service. Par exemple :

Vous pouvez configurer plusieurs allow-grpc-rpc-regexps instructions et deny-grpc-rpc-regexps avec une ou plusieurs expressions. Placer chaque expression entre guillemets (« »). Placez plusieurs expressions entre crochets [ ] et séparez-les par un espace.

Pour créer une classe de connexion qui définit l’autorisation pour les RPC gRPC :

  1. Configurez le nom et les autorisations de la classe de connexion.

    Par exemple :

  2. Dans la classe, configurez les expressions régulières pour les RPC autorisés par la classe.

    Par exemple, l’instruction suivante autorise le RPC gNMI Get() et tous les RPC de service gNOI System .

  3. Configurez les expressions régulières pour les RPC que la classe refuse.

    Par exemple, les instructions suivantes refusent le RPC gNMI Set() et refusent également tous les RPC du gRIBI service ainsi que le service gNOI CertificateManagement .

  4. Attribuez la classe de connexion aux utilisateurs gRPC appropriés.

    Par exemple, l’instruction suivante affecte la grpc-operator classe à l’utilisateur grpc-user .

Après avoir activé les services gRPC sur le périphérique réseau, configurez le NMS distant en tant que client gRPC. Pour permettre au client d’exécuter des opérations gNOI, configurez-le comme indiqué dans Configuration des services gNOI.

Tableau de l’historique des modifications

La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.

Libération
Descriptif
25.2R1 et 25.2R1-EVO
À partir de Junos OS version 25.2R1 et Junos OS Evolved version 25.2R1, vous pouvez configurer plusieurs serveurs gRPC qui hébergent différents ensembles de services sur des ports uniques.