Ce qui a changé

État de configuration de l’étiquette de flux pour les services EVPN ELAN La sortie de la show evpn instance extensive commande affiche désormais l’état opérationnel flow-label et flow-label-static d’un périphérique et non des instances de routage. Un appareil avec flow-label activé prend en charge les étiquettes de flux FAT (Flow-Aware Transport) et annonce sa prise en charge à ses voisins. Un appareil avec flow-label-static activé prend en charge les étiquettes de flux FAT, mais n’annonce pas ses capacités.

Spécifier le port source UDP dans une opération de superposition ping ou traceroute — Dans les versions de Junos OS antérieures à la version 22.4R1, vous ne pouviez pas configurer le port source UDP dans une opération de superposition ping ou traceroute. Vous pouvez maintenant configurer cette valeur dans un environnement EVPN-VXLAN à l’aide de hash. L’option hash de configuration remplacera toutes les autres options de hachage-* qui peuvent être utilisées pour déterminer la valeur du port source.

Trafic ESP relais en mode PMI : à partir de Junos OS version 22.1R3, nous prenons en charge le traitement du chemin express PMI pour le trafic ESP relais sur les SRX4100, SRX4200 et vSRX.

Prise en charge opérationnelle de la commande de session de flux pour la sécurité du contenu (SRX Series et vSRX) : nous avons étendu la show security flow session prise en charge des commandes opérationnelles pour afficher les détails des fonctionnalités de sécurité du contenu de filtrage de contenu et de filtrage Web du contenu.

[Voir Afficher la session de flux de sécurité.]

Lors de l’abonnement au chemin d’accès aux ressources /junos/system/linecard/environment, le préfixe du chemin d’accès diffusé en continu côté collecteur s’affichait sous la forme /junos/linecard/environment. Ce problème est résolu dans Junos OS 23.1R1 et Junos OS Evolved 23.1R1 et le chemin d’accès à l’abonnement et le chemin d’accès diffusé en continu correspondent à l’affichage /junos/system/linecard/environment.

Prise en charge des fuseaux horaires pour la vérification des certificats locaux (SRX1500 et SRX5600) : à partir de cette version, lorsque la vérification du certificat local échoue, vous pouvez voir le fuseau horaire du certificat local ayant échoué dans la sortie de la commande et les messages du journal système.

La capture de paquets s’appelle désormais Control Plane Packet Capture (SRX Series)— À partir de la version 23.1R1 de Junos OS, nous avons renommé capture de paquets en capture de plan de contrôle sous le menu Administration de périphérique . Vous pouvez utiliser cette page pour capturer et analyser le trafic du plan de contrôle sur un routeur.

[Voir Capture de paquets dans le plan de contrôle.]

operator login class ne peut pas afficher les fichiers de trace NETCONF qui sont no-world-readable (ACX Series, EX Series, MX Series, QFX Series, SRX Series, vMX et vSRX) : lorsque vous configurez les options de suivi NETCONF au niveau de la [edit system services netconf traceoptions] hiérarchie et que vous limitez l’accès au fichier au propriétaire du fichier en définissant ou en omettant l’instruction no-world-readable (valeur par défaut), les utilisateurs affectés à la operator classe de connexion ne sont pas autorisés à afficher le fichier de trace.

La prise en charge de l' junos:cli-feature Extension YANG (ACX Series, EX Series, MX Series, QFX Series, SRX Series, vMX et vSRX) : l’extension cli-feature YANG identifie certaines propriétés CLI associées à certaines options de commande et instructions de configuration. Les modules Junos YANG qui définissent la configuration ou les RPC incluent l’instruction cli-feature extension, le cas échéant, dans les schémas émis avec les extensions. Cette extension est utile lorsqu’un client utilise des modèles de données YANG, mais pour certains flux de travail, le client doit générer des outils basés sur CLI.

[ Reportez-vous à la section Présentation du module YANG des extensions DDL Junos.]

XML dans la get-system-yang-packages balise Réponse RPC modifiée (ACX Series, EX Series, MX Series, QFX Series, SRX Series, vMX et vSRX) : la get-system-yang-packages réponse RPC remplace la xmlproxy-yang-modules balise par la proxy-xml-yang-modules balise dans la sortie XML.

Modifications apportées à l'élément du <rpc-error> serveur NETCONF lorsque l' operation="delete" opération supprime un objet de configuration inexistant (ACX Series, EX Series, MX Series, QFX Series, SRX Series, vMX et vSRX) : nous avons modifié la <rpc-error> réponse renvoyée par le serveur NETCONF lorsque l <edit-config> 'opération ou <load-configuration> est utilisée operation="delete" pour supprimer un élément de configuration absent de la configuration cible. La gravité de l’erreur est error au lieu d’warning, et l’élément <rpc-error> inclut les <error-tag>data-missing</error-tag> éléments and <error-type>application</error-type> .

Dépréciation des options liées à l’inscription des certificats (Junos) : à partir de la version 23.2R1 de Junos OS, nous abandonnons les options CLI antérieures liées à l’infrastructure à clé publique (PKI) pour inscrire et réinscrire un certificat local via le protocole SCEP (Simple Certificate Enrolment Protocol). Le tableau ci-dessous présente les commandes et les instructions de configuration de l’interface de ligne de commande Junos, dont les options sont déconseillées. Vous pouvez trouver les mêmes options CLI maintenant disponibles sous scep option dans ces commandes et instructions.

[ Reportez-vous à la réinscription automatique (sécurité), à l’inscription scep du certificat local pki de demande et à l’inscription du certificat local du nœud pki de sécurité et à l’inscription du certificat local du nœud pki de sécurité.]

Modifier le format des noms de profil d’accès distant (SRX Series et vSRX 3.0) —À partir de la version 23.1R1 de Junos OS, nous avons modifié le format des noms de profil d’accès à distance pour améliorer l’expérience de l’utilisateur final avec Juniper Secure Connect. Dans les versions antérieures à Junos OS version 23.1R1, vous configurez le nom du profil d’accès distant à l’aide du nom de domaine au niveau de la hiérarchie [edit security remote-access profile realm-name]. Toutefois, lorsque les organisations se connectent à plusieurs passerelles, il devient impossible d’utiliser plusieurs fois les noms de profil d’accès à distance ( hr) dans le profil de connexion à distance.

Pour résoudre ce problème, nous introduisons une nouvelle convention pour la configuration des noms de profil d’accès à distance. Vous pouvez désormais configurer des noms de profil avec des URL à l’aide de l’un des formats suivants au niveau de la hiérarchie [edit security remote-access profile realm-name], afin que les utilisateurs finaux puissent se connecter à la passerelle appropriée :

• FQDN/RealmName

• FQDN

• IP address/RealmName

• IP address

Par exemple, vous pouvez désormais utiliser ra.example.com/hr, ra1.example.com/hr et ra.example.com comme noms de royaume.

Avec l’introduction de cette convention, nous devons déprécier l’option existante default-profile au niveau de la hiérarchie [edit security remote-access]. Les noms de vos profils d’accès à distance font référence à des URL avec un nom de domaine complet ou avec une adresse IP, selon la façon dont les utilisateurs finaux se connectent (par exemple, ra.example.com/hr, ra.example.com, 192.168.1.10/h ou 192.168.1.10). Grâce à cette modification, l’utilisateur final verra désormais le nom du profil de connexion dans l’application Juniper Secure Connect sous la forme ra.example.com/hr au lieu de hr, comme c’était le cas dans les versions précédentes.

Dans les déploiements existants, pour assurer une transition en douceur avec cette modification, nous vous recommandons de modifier le nom de profil hr dans la configuration actuelle en ra.example.com/hr ou 192.168.1.10/h au niveau de la hiérarchie [edit] à l’aide des commandes suivantes :

[Voir le profil (Juniper Secure Connect).]

Améliorations apportées à la réinscription automatique d’un certificat d’entité finale locale (EE) (SRX300, SRX320, SRX550HM, SRX1500, SRX4100, SRX4600, SRX5400, SRX5600, SRX5800) : à partir de Junos OS version 23.2R1, l’option re-enroll-trigger-time-percentage devient facultative. Mais vous devez configurer l’un ou l’autre re-enroll-time pour re-enroll-trigger-time-percentage que le commit-check réussisse.

[Voir Réinscription automatique (Sécurité).]

Suppression du mode d’alimentation IPsec Intel QAT option dans IPsec VPN (SRX Series)—Nous avons supprimé l’option power-mode-ipsec-qat au niveau de la hiérarchie [edit security flow] de l’interface de ligne de commande Junos pour l’affichage. Cette option est désormais masquée car il n’est pas recommandé de la configurer avec plusieurs tunnels VPN IPsec. Nous continuons d’utiliser AES-NI en mode PMI pour de meilleures performances que le QAT.

[ Reportez-vous à la section Amélioration des performances IPsec avec PowerMode IPsec.]

Indisponibilité de l’option pour la solution VPN d’accès distant (SRX Series et vSRX 3.0) —À partir de default-profileJunos OS version 23.1R1, nous avons masqué l’option default-profile au niveau de la hiérarchie [edit security remote-access]. Dans les versions antérieures à Junos OS version 23.1R1, vous utilisez cette option pour spécifier l’un des profils d’accès distant comme profil par défaut dans Juniper Secure Connect. Mais avec les modifications apportées au format des noms de profil d’accès à distance, nous n’avons plus besoin de cette default-profile option.

Nous avons déprécié l’option default-profile , plutôt que de la supprimer immédiatement, pour offrir une compatibilité descendante et une chance de rendre votre configuration existante conforme à la configuration modifiée. Vous recevrez un message d’avertissement si vous continuez à utiliser l’option default-profile dans votre configuration. Toutefois, la modification de la configuration actuelle n’affecte pas les déploiements existants.

Dans les déploiements existants, pour assurer une transition en douceur avec cette modification, nous vous recommandons de modifier le nom du profil dans la configuration actuelle hr en ra.example.com/hr ou 192.168.1.10/h au niveau de la hiérarchie [edit] à l’aide des commandes suivantes :

Pour les nouvelles configurations, envisagez les scénarios suivants pour créer un profil d’accès distant basé sur la façon dont vos utilisateurs finaux se connectent à l’aide de l’application Juniper Secure Connect :

• Si vos utilisateurs finaux se connectent à l’aide d’une adresse IP, spécifiez l’adresse IP dans le nom de profil.

• Si vos utilisateurs finaux se connectent à l’aide d’un nom de domaine complet, spécifiez-le dans le nom de profil.

• Si vous devez séparer les utilisateurs avec des valeurs de domaine différentes, telles que hr, ajoutez /hr à l’adresse IP ou au nom de domaine complet comme suit :

  • [edit security remote-access profile ra.example.net/hr]

  • [edit security remote-access profile 192.168.1.10/hr]

[Voir profil par défaut (Juniper Secure Connect) .

La solution VPN d'accès à distance ne prend pas en charge le pré-partage hexadécimal (SRX Series et vSRX 3.0)—Avec la solution VPN d'accès à distance, pour la méthode d'authentification basée sur la clé pré-partagée, nous prenons en charge le format texte ascii. Cela signifie qu’il ne faut pas utiliser le format hexadémique pour les clés pré-partagées dans votre configuration pour la solution VPN d’accès à distance. Par conséquent, configurez l’instruction ascii-text au format texte ascii au niveau de [edit security ike policy policy-name pre-shared-key] la hiérarchie pour l’utiliser avec Juniper Secure Connect.

Amélioration de l’inscription du certificat SCEP PKI : l’option Système logique est ajoutée à l’inscription du certificat SCEP PKI.

[ Reportez-vous à la demande de certificat local pki de demande d’inscription scep.]

Modifications apportées à la charge utile de demande de certificat dans la négociation IKE VPN IPsec (SRX Series)—Pour le profil ca/ca de confiance configuré dans la stratégie IKE pour la négociation IKE SA, la charge utile de demande de certificat de cette négociation IKE SA contient le certificat d’autorité de certification associé à ce profil ca/ca approuvé. Par exemple, pour le profil trusted-ca/ca-profile dans la stratégie IKE à edit security ike policy policy-name certificate trusted-ca ca-profile certificate-authority , la charge utile de demande de certificat de la négociation IKE SA utilisant cette stratégie policy-name IKE contiendra le certificat de l’autorité de certification de l’autorité de certification certificate-authority.

Prise en charge limitée des certificats ECDSA avec proxy SSL (SRX Series et vSRX 3.0)—Avec le proxy SSL configuré sur les pare-feu SRX Series et les pare-feu virtuels vSRX,

• Les sites Web basés sur ECDSA avec des certificats de serveur P-384/P-521 ne sont pas accessibles avec un certificat root-ca, car le périphérique de sécurité est limité à la prise en charge du groupe P-256.

• Lorsque root-ca basé sur RSA et le certificat root-ca ECDSA P-384/P-521 sont configurés, tous les sites Web ECDSA ne seront pas accessibles car SSL-Terminator est négocié avec RSA, c’est pourquoi le dispositif de sécurité n’envoie que des chiffrements et des sigalgs RSA au serveur Web de destination lors de l’établissement de liaison SSL. Pour vous assurer que les sites Web basés sur ECDSA et RSA sont accessibles avec le certificat racine RSA, configurez un certificat racine ECDSA 256 bits.

• Dans certains scénarios, même si un certificat racine ECDSA 256 bits est utilisé dans la configuration du proxy SSL, les sites Web basés sur ECDSA avec des certificats de serveur P-256 ne sont pas accessibles si le serveur ne prend pas en charge les groupes P-256.

• Dans d’autres scénarios, même si un certificat racine ECDSA 256 bits est utilisé dans la configuration du proxy SSL, les sites Web basés sur ECDSA avec des certificats de serveur P-256 ne sont pas accessibles si le serveur prend en charge des serveurs autres que P-256. Le problème se produit en mode de déchargement matériel avec échec de la vérification des signatures. Étant donné que le déchargement matériel pour le certificat ECDSA est introduit dans Junos OS version 22.1R1, ce problème ne sera pas observé si vous utilisez Junos OS publié avant la version 22.1R1. De plus, le problème n’est pas visible si le proxy SSL pour le certificat ECDSA est géré dans le logiciel.