Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Surveillance du trafic VPN

La surveillance VPN vous permet de déterminer l’accessibilité des équipements pairs en envoyant des requêtes ICMP (Internet Control Message Protocol) aux pairs.

Comprendre les alarmes et l’audit VPN

Configurez la commande suivante pour activer la journalisation des événements de sécurité lors de la configuration initiale de l’équipement. Cette fonctionnalité est prise en charge sur les équipements SRX300, SRX320, SRX340, SRX345, SRX550HM, SRX1500 et les instances vSRX.

set security log cache

Les administrateurs (audit, cryptage, IDS et sécurité) ne peuvent pas modifier la configuration de journalisation des événements de sécurité si la commande ci-dessus est configurée et que chaque rôle d’administrateur est configuré pour disposer d’un ensemble unique de privilèges distincts et distincts de tous les autres rôles administratifs.

Les alarmes sont déclenchées par une défaillance du VPN. Une alarme VPN est générée lorsque le système surveille l’un des événements audités suivants :

  • Authentication failures— Vous pouvez configurer l’unité de manière à générer une alarme système lorsque les défaillances d’authentification des paquets atteignent un nombre spécifié.

  • Encryption and decryption failures— Vous pouvez configurer l’unité de manière à générer une alarme système lorsque les défaillances de chiffrement ou de déchiffrement dépassent un nombre spécifié.

  • IKE Phase 1 and IKE Phase 2 failures—Les négociations de phase 1 d’Internet Key Exchange (IKE) sont utilisées pour établir des associations de sécurité IKE (SAs). Ces accords de niveau de service protègent les négociations de phase 2 de l’IKE. Vous pouvez configurer l’unité afin de générer une alarme système lorsque les défaillances de phase 1 ou IKE de phase 2 dépassent un nombre spécifié.

  • Self-test failures: les autotests permettent de vérifier qu’un équipement est sous tension ou redémarre pour vérifier si un logiciel de sécurité est correctement implémenté sur votre équipement.

    Les autotests garantissent l’exactitude des algorithmes de cryptage. L’image Junos-FIPS effectue des autotests automatiquement lors de la mise sous tension, et en continu pour la génération de paires de clés. Dans les images domestiques ou FIPS, les autotests peuvent être configurés pour être exécutés selon un calendrier défini, à la demande ou immédiatement après la génération de clés.

    Vous pouvez configurer l’unité de manière à générer une alarme système en cas de défaillance d’autotest.

  • IDP flow policy attacks— Une stratégie de détection et de prévention des intrusions (IDP) vous permet d’appliquer diverses techniques de détection et de prévention des attaques sur le trafic réseau. Vous pouvez configurer l’unité de manière à générer une alarme système en cas de violation de la stratégie de flux IDP.

  • Replay attacks- Une attaque en rejeu est une attaque réseau au cours de laquelle une transmission de données valide est malveillante ou frauduleusement répétée ou retardée. Vous pouvez configurer l’unité de manière à générer une alarme système en cas d’attaque en rejeu.

Les messages syslog sont inclus dans les cas suivants :

  • Échec de la génération de clés symétriques

  • Échec de la génération de clés asymétriques

  • Échec de la distribution manuelle des clés

  • Échec de la distribution automatisée des clés

  • Échec de la destruction des clés

  • Échec de la gestion et du stockage des clés

  • Échec du chiffrement ou du déchiffrement des données

  • Échec de la signature

  • Échec de l’accord clé

  • Échec du hachage cryptographique

  • Échec IKE

  • Échec de l’authentification des paquets reçus

  • Erreur de déchiffrement due à un contenu de padding non valide

  • Incompatibilité dans la longueur spécifiée dans le champ d’objet alternatif du certificat reçu à partir d’un équipement d’appairage VPN distant.

Les alarmes sont déclenchées en fonction des messages syslog. Chaque défaillance est enregistrée, mais une alarme n’est générée que lorsqu’un seuil est atteint.

Pour afficher les informations d’alarme, exécutez la show security alarms commande. Le nombre de violations et l’alarme ne persistent pas dans les redémarrages du système. Après un redémarrage, le nombre de violations se réinitialise à zéro et l’alarme est effacée de la file d’attente d’alarme.

Une fois que des mesures appropriées ont été prises, vous pouvez effacer l’alarme. L’alarme reste dans la file d’attente jusqu’à ce que vous la désactiviez (ou jusqu’à ce que vous redémarriez l’unité). Pour effacer l’alarme, exécutez la clear security alarms commande.

Comprendre la surveillance VPN

La surveillance VPN utilise des requêtes d’écho ICMP (ou pings) pour déterminer si un tunnel VPN est opérationnel. Lorsque la surveillance VPN est activée, l’équipement de sécurité envoie des pings via le tunnel VPN à la passerelle d’appairage ou à une destination spécifiée à l’autre extrémité du tunnel. Les pings sont envoyés par défaut à des intervalles de 10 secondes pendant une période pouvant aller jusqu’à 10 fois consécutives. Si aucune réponse n’est reçue après 10 pings consécutifs, le VPN est considéré comme indisponible et l’association de sécurité IPsec (SA) est effacée.

La surveillance VPN est activée pour un VPN spécifié en configurant l’option vpn-monitor au niveau de la hiérarchie [edit security ipsec vpn vpn-name]. L’adresse IP de la passerelle pair est la destination par défaut; vous pouvez toutefois spécifier une adresse IP de destination différente (par exemple un serveur) à l’autre extrémité du tunnel. Le point de terminaison du tunnel local est l’interface source par défaut, mais vous pouvez spécifier un autre nom d’interface.

La surveillance VPN d’un équipement connecté de l’extérieur (comme un PC) n’est pas prise en charge sur les équipements SRX5400, SRX5600 et SRX5800. La destination de la surveillance VPN doit être une interface locale sur les équipements SRX5400, SRX5600 ou SRX5800.

L’option de surveillance optimized VPN envoie des pings uniquement lorsqu’il y a du trafic sortant et aucun trafic entrant via le tunnel VPN. S’il y a du trafic entrant via le tunnel VPN, l’équipement de sécurité considère que le tunnel est actif et n’envoie pas de pings à l’appairage. La configuration de l’option optimized permet d’enregistrer des ressources sur l’équipement de sécurité, car les pings ne sont envoyés que lorsque des données livelines d’appairage doivent être déterminées. L’envoi de pings peut également activer des liens de sauvegarde coûteux qui ne seraient pas utilisés autrement.

Vous pouvez configurer l’intervalle à laquelle les pings sont envoyés et le nombre de pings consécutifs envoyés sans réponse avant que le VPN ne soit considéré comme étant indisponible. Celles-ci sont configurées avec les intervalthreshold options, respectivement, au niveau de la hiérarchie [edit security ipsec vpn-monitor-options].

La surveillance VPN peut provoquer un basculement de tunnel dans certains environnements VPN si les paquets ping ne sont pas acceptés par l’pair en fonction de l’adresse IP source ou de destination du paquet.

Comprendre la vérification des chemins de données IPsec

Présentation

Par défaut, l’état des interfaces du tunnel sécurisé (st0) configurées en mode point à point dans les VPN basés sur le routage est basé sur l’état du tunnel VPN. Peu après l’établissement du SA IPsec, les routes associées à l’interface st0 sont installées dans la table de transfert Junos OS. Dans certaines topologies de réseau, par exemple lorsqu’un pare-feu de transit se trouve entre les points de terminaison du tunnel VPN, le trafic de données IPsec qui utilise des routes actives pour un tunnel VPN établi sur l’interface st0 peut être bloqué par le pare-feu de transit. Cela peut entraîner des pertes de trafic.

Lorsque vous activez la vérification du chemin de données IPsec, l’interface st0 n’est pas activée tant que le chemin de données n’est pas vérifié. La vérification est configurée avec l’instruction set security ipsec vpn vpn-name vpn-monitor verify-path pour les tunnels VPN de point de terminaison dynamiques, de site à site et basés sur le routage.

Si un équipement NAT se trouve devant le point de terminaison du tunnel d’appairage, l’adresse IP du point de terminaison du tunnel d’appairage est traduite en adresse IP de l’équipement NAT. Pour que la requête ICMP de surveillance VPN atteigne le point de terminaison du tunnel pair, vous devez spécifier explicitement l’adresse IP d’origine non traduite du point de terminaison du tunnel pair derrière l’équipement NAT. Cette configuration est configurée set security ipsec vpn vpn-name vpn-monitor verify-path destination-ip .

À partir de Junos OS version 15.1X49-D120, vous pouvez configurer la taille du paquet utilisé pour vérifier un chemin de données IPsec avant l’apparition de l’interface st0 . Utilisez la set security ipsec vpn vpn-name vpn-monitor verify-path packet-size configuration. La taille de paquet configurable varie de 64 à 1 350 octets ; la valeur par défaut est de 64 octets.

Avertissements

L’interface source et les adresses IP de destination qui peuvent être configurées pour le fonctionnement de la surveillance VPN n’ont aucun effet sur la vérification du chemin de données IPsec. La source des requêtes ICMP dans la vérification du chemin de données IPsec est le point de terminaison du tunnel local.

Lorsque vous activez la vérification des chemins de données IPsec, la surveillance VPN est automatiquement activée et utilisée après l’activation de l’interface st0. Nous vous recommandons de configurer l’option d’optimisation de la surveillance VPN à l’aide de la commande chaque fois que vous activez la set security ipsec vpn vpn-name vpn-monitor optimized vérification du chemin de données IPsec.

Si un basculement de cluster de châssis se produit lors de la vérification du chemin de données IPsec, le nouveau nœud actif repart à la vérification. L’interface st0 n’est pas activée tant que la vérification n’a pas réussi.

Aucune vérification du chemin de données IPsec n’est effectuée pour les clés à clé SA IPsec, car l’état de l’interface st0 ne change pas pour les clés de nouveau.

La vérification du chemin de données IPsec n’est pas prise en charge sur les interfaces st0 configurées en mode point à multipoint, utilisées avec AutoVPN, Auto Discovery VPN et plusieurs sélecteurs de trafic. La surveillance VPN et la vérification des chemins de données IPsec ne prennent pas en charge les adresses IPv6. La vérification des chemins de données IPsec ne peut donc pas être utilisée avec les tunnels IPv6.

Comprendre les fonctionnalités globales de surveillance SPI et VPN

Vous pouvez surveiller et maintenir l’efficacité de votre VPN à l’aide des fonctionnalités VPN globales suivantes :

  • SPI : les pairs d’une association de sécurité (SA) peuvent devenir non synchronisés en cas d’échec de l’un des pairs. Par exemple, si l’un des deux redémarrages, il peut envoyer un index de paramètres de sécurité (SPI) incorrect. Vous pouvez permettre à l’unité de détecter un tel événement et de resynchroniser les pairs en configurant la fonction de réponse SPI malveillante.

  • Surveillance VPN : vous pouvez utiliser la fonctionnalité globale de surveillance VPN pour envoyer périodiquement des requêtes ICMP (Internet Control Message Protocol) à l’pair afin de déterminer si l’appairage est joignable.

Comprendre la surveillance VPN et le DPD

La surveillance VPN et la détection des pairs morts (DPD) sont des fonctionnalités disponibles sur les équipements SRX Series pour vérifier la disponibilité des équipements VPN pairs. Cette section compare le fonctionnement et la configuration de ces fonctionnalités.

L’équipement SRX Series répond aux messages DPD envoyés par les pairs VPN même si le DPD n’est pas configuré sur l’équipement. Vous pouvez configurer l’équipement SRX Series pour lancer des messages DPD vers des pairs VPN. Vous pouvez également configurer la surveillance DPD et VPN pour qu’elles fonctionnent simultanément sur le même équipement SRX Series, même si le nombre de pairs pouvant être surveillés avec l’une ou l’autre méthode est réduit.

La surveillance VPN est un mécanisme junos OS qui surveille uniquement les associations de sécurité de phase 2. La surveillance VPN est activée par VPN avec l’instruction vpn-monitor au niveau de la hiérarchie [edit security ipsec vpn vpn-name]. L’adresse IP de destination et l’interface source doivent être spécifiées. L’option optimized permet à l’équipement d’utiliser des modèles de trafic comme preuve de la directline des pairs ; Les requêtes ICMP sont supprimées.

Les options de surveillance VPN sont configurées avec l’instruction vpn-monitor-options au niveau de la hiérarchie [edit security ipsec]. Ces options s’appliquent à tous les VPN pour lesquels la surveillance VPN est activée. Les options que vous pouvez configurer incluent l’intervalle à laquelle les requêtes ICMP sont envoyées à l’pair (la valeur par défaut est 10 secondes) et le nombre de requêtes ICMP consécutives envoyées sans recevoir de réponse avant que l’pair ne soit jugé inaccessible (la valeur par défaut est 10 requêtes consécutives).

DPD est une implémentation de RFC 3706, une méthode basée sur le trafic pour détecter les pairs IKE (Dead Internet Key Exchange). Il fonctionne au niveau IKE et surveille l’appairage en fonction de l’activité du trafic IKE et IPsec.

Le DPD est configuré sur une passerelle IKE individuelle avec l’instruction dead-peer-detection au niveau de la hiérarchie [edit security ike gateway gateway-name]. Vous pouvez configurer les modes de fonctionnement DPD. Le mode par défaut (optimisé) envoie des messages DPD à l’pair s’il n’y a pas de trafic IKE ou IPsec entrant dans un intervalle configuré après que l’équipement local envoie des paquets sortants à l’pair. D’autres options configurables incluent l’intervalle à partir duquel les messages DPD sont envoyés à l’pair (la valeur par défaut est 10 secondes) et le nombre de messages DPD consécutifs envoyés sans recevoir de réponse avant que l’pair ne soit jugé indisponible (la valeur par défaut est cinq requêtes consécutives).

Comprendre la détection des pairs morts

La détection des pairs morts (DPD) est une méthode utilisée par les équipements réseau pour vérifier l’existence et la disponibilité actuelles d’autres équipements pairs.

Vous pouvez utiliser le DPD comme alternative à la surveillance VPN. La surveillance VPN s’applique à un VPN IPsec individuel, tandis que le DPD est configuré uniquement dans un contexte de passerelle IKE individuelle.

Un équipement procède à la vérification DPD en envoyant des charges utiles de notification IKE cryptées de phase 1 (messages R-U-THERE) à un pair et en attendant les accusés de réception DPD (messages R-U-THERE-ACK) de l’pair. L’équipement envoie un message R-U-THERE uniquement s’il n’a reçu aucun trafic de la part de l’pair pendant un intervalle DPD spécifié. Si l’équipement reçoit un message R-U-THERE-ACK de la part de l’pair pendant cet intervalle, il considère l’pair vivant. Si l’unité reçoit du trafic sur le tunnel de la part de l’appairage, il réinitialise son compteur de messages R-U-THERE pour ce tunnel, commençant ainsi un nouvel intervalle. Si l’unité ne reçoit pas de message R-U-THERE-ACK pendant l’intervalle, elle considère que l’unité est morte. Lorsque l’équipement modifie l’état d’un équipement pair comme étant mort, il retire l’association de sécurité (SA) de phase 1 et tous les SAS de phase 2 pour cet appairage.

Les modes DPD suivants sont pris en charge sur les équipements SRX Series :

  • Optimisé : les messages R-U-THERE sont déclenchés s’il n’y a pas de trafic IKE ou IPsec entrant dans un intervalle configuré après que l’équipement envoie des paquets sortants à l’pair. Il s’agit du mode par défaut.

  • Tunnel d’inactivité de l’sonde : les messages R-U-THERE sont déclenchés s’il n’y a pas de trafic IKE ou IPsec entrant ou sortant dans un intervalle configuré. Les messages R-U-THERE sont envoyés périodiquement à l’pair jusqu’à ce qu’il y a une activité de trafic. Ce mode facilite la détection précoce d’un pair en panne et rend le tunnel disponible pour le trafic de données.

    Lorsque plusieurs sélecteurs de trafic sont configurés pour un VPN, plusieurs tunnels peuvent être établis pour le même IKE SA. Dans ce scénario, le mode tunnel au ralenti de la sonde déclenche l’envoi de messages R-U-THERE si un tunnel associé à l’IKE SA devient inactif, même s’il peut y avoir du trafic dans un autre tunnel pour le même IKE SA.

  • Toujours envoyé : les messages R-U-THERE sont envoyés à des intervalles configurés, indépendamment de l’activité de trafic entre les pairs.

    Il est recommandé d’utiliser le mode tunnel au ralenti de la sonde plutôt que le always-send mode.

Les timers DPD sont actifs dès l’établissement de la phase 1 SA. Le comportement du DPD est le même pour les protocoles IKEv1 et IKEv2.

Vous pouvez configurer les paramètres DPD suivants :

  • Le paramètre d’intervalle spécifie la durée (exprimée en secondes) que l’équipement attend du trafic de son pair avant d’envoyer un message R-U-THERE. L’intervalle par défaut est de 10 secondes. À partir de Junos OS Version 15.1X49-D130, la plage de paramètres d’intervalle autorisé à laquelle les messages R-U-THERE sont envoyés à l’équipement pair est réduite de 10 à 60 secondes à 2 secondes à 60 secondes. Le paramètre de seuil minimum doit être 3, lorsque le paramètre de l’intervalle DPD est défini à moins de 10 secondes.

  • Le paramètre de seuil spécifie le nombre maximum de fois pour envoyer le message R-U-THERE sans réponse de la part de l’pair avant de considérer l’pair mort. Le nombre de transmissions par défaut est cinq fois, avec une plage autorisée de 1 à 5 tentatives.

Notez les considérations suivantes avant de configurer DPD :

  • Lorsqu’une configuration DPD est ajoutée à une passerelle existante avec des tunnels actifs, les messages R-U-THERE sont lancés sans supprimer les SAS de phase 1 ou 2.

  • Lorsqu’une configuration DPD est supprimée d’une passerelle existante avec des tunnels actifs, les messages R-U-THERE sont arrêtés pour les tunnels. Les SAS IKE et IPsec ne sont pas affectés.

  • La modification de toute option de configuration DPD, telle que le mode, l’intervalle ou les valeurs de seuil, met à jour le fonctionnement du DPD sans supprimer les SAS de phase 1 ou 2.

  • Si la passerelle IKE est configurée avec la surveillance DPD et VPN, mais que la possibilité d’établir des tunnels immédiatement n’est pas configurée, le DPD n’entame pas de négociation de phase 1. Lors de la configuration du DPD, l’option immédiatement d’établissement de tunnels doit également être configurée en même temps pour déchirer l’interface st0 en l’absence d’AAS de phase 1 et 2.

  • Si la passerelle IKE est configurée avec plusieurs adresses IP homologues et DPD, mais que l’adresse SA de phase 1 n’est pas établie sur la première adresse IP d’appairage, une sa de phase 1 est tentée avec la prochaine adresse IP d’appairage. Le DPD n’est actif qu’après l’établissement d’une SA de phase 1.

  • Si la passerelle IKE est configurée avec plusieurs adresses IP d’appairage et DPD, mais que celle-ci échoue avec l’adresse IP de l’pair actuel, les AAS de phase 1 et 2 sont autorisés et un basculement vers l’adresse IP d’appairage suivante est déclenché.

  • Plusieurs phases 1 ou 2 SA peuvent exister avec le même pair en raison de négociations simultanées. Dans ce cas, des messages R-U-THERE sont envoyés sur tous les SAS de phase 1. Le fait de ne pas recevoir de réponses DPD pour le nombre configuré de fois consécutives efface l’AA de phase 1 et le SA de phase 2 associé (pour IKEv2 uniquement).

Comprendre les événements dans les tunnels

Lorsqu’un problème de réseau est lié à un VPN, une fois le tunnel détecté, seul l’état du tunnel est suivi. De nombreux problèmes peuvent survenir avant l’apparition du tunnel. Par conséquent, au lieu de suivre uniquement l’état du tunnel, les problèmes liés à la mise en service d’un tunnel ou les échecs de négociation, les événements réussis tels que les négociations IPsec SA réussies, la rekey IPsec et les rekeys IKE SA sont désormais suivis. Ces événements sont appelés événements de tunnel.

Pour les phases 1 et 2, les événements de négociation pour un tunnel donné sont suivis ainsi que les événements qui se produisent dans des démons externes comme AUTHD ou PKID. Lorsqu’un événement de tunnel se produit plusieurs fois, une seule entrée est conservée avec l’heure mise à jour et le nombre de fois qu’il s’est produit.

Dans l’ensemble, 16 événements sont suivis : huit événements pour la phase 1 et huit événements pour la phase 2. Certains événements peuvent se reproduire et remplir la mémoire de l’événement, ce qui entraîne la suppression d’événements importants. Pour éviter l’écrasement, un événement n’est pas stocké à moins qu’un tunnel ne soit en panne.

Les événements spéciaux suivants relèvent de cette catégorie :

  • Durée de vie en kilo-octets expiré pour IPsec SA

  • La durée de vie difficile de iPsec SA a expiré

  • La charge utile de suppression IPsec SA reçue de l’appairage, les AS IPSec correspondants sont effacés

  • Paires SA IPsec redondantes et non utilisées

  • SAs IPsec effacés en tant que sa IKE supprimés

Les tunnels AutoVPN sont créés et supprimés de manière dynamique. Par conséquent, les événements de tunnel correspondant à ces tunnels sont de courte durée. Parfois, ces événements de tunnel ne peuvent pas être associés à un tunnel, de sorte que la journalisation système est utilisée pour le débogage à la place.

Exemple : Définition d’une alerte d’alarme de sécurité en tant que notification d’une alarme de sécurité

Cet exemple montre comment configurer un équipement afin de générer un signal d’alerte système en cas de nouvel événement de sécurité. Par défaut, les alarmes ne sontpassantsesses. Cette fonctionnalité est prise en charge sur les équipements SRX300, SRX320, SRX340, SRX345, SRX550HM, SRX1500 et les instances vSRX.

Conditions préalables

Aucune configuration particulière au-delà de l’initialisation de l’équipement n’est requise avant de configurer cette fonctionnalité.

Présentation

Dans cet exemple, vous définissez un signal signalant qu’il doit être généré en réponse à une alarme de sécurité.

Configuration

Procédure

Procédure étape par étape

Pour définir une alarme d’enseillement :

  1. Activez les alarmes de sécurité.

  2. Indiquez que vous souhaitez être averti des alarmes de sécurité à l’aide d’un bip d’écip.

  3. Si vous avez terminé la configuration de l’unité, validez la configuration.

Vérification

Pour vérifier que la configuration fonctionne correctement, saisissez la show security alarms detail commande.

Exemple : Génération d’alarmes de sécurité en réponse à d’éventuelles violations

Cet exemple montre comment configurer l’unité afin de générer une alarme système en cas de violation potentielle. Par défaut, aucune alarme n’est déclenchée en cas de violation potentielle. Cette fonctionnalité est prise en charge sur les équipements SRX300, SRX320, SRX340, SRX345, SRX550HM, SRX1500 et les instances vSRX.

Conditions préalables

Aucune configuration particulière au-delà de l’initialisation de l’équipement n’est requise avant de configurer cette fonctionnalité.

Présentation

Dans cet exemple, vous configurez une alarme pour qu’elle soit déclenchée lorsque :

  • Le nombre de défaillances d’authentification dépasse 6.

  • L’autotest cryptographique échoue.

  • L’autotest non cryptographique échoue.

  • L’autotest de génération clé échoue.

  • Le nombre de échecs de chiffrement dépasse 10.

  • Le nombre de défaillances de déchiffrement dépasse 1.

  • Le nombre de défaillances de phase 1 IKE dépasse 10.

  • Le nombre de défaillances IKE de phase 2 dépasse 1.

  • Une attaque en rejeu se produit.

Configuration

Procédure

Configuration rapide CLI

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez tous les sauts de ligne, modifiez tous les détails nécessaires pour correspondre à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis entrez commit du mode de configuration.

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur cette méthode, reportez-vous à Using the CLI Editor in Configuration Mode dans le Junos OS CLI User Guide.

Pour configurer les alarmes en réponse à d’éventuelles violations :

  1. Activez les alarmes de sécurité.

  2. Indiquez qu’une alarme doit être déclenchée en cas de défaillance de l’authentification.

  3. Indiquez qu’une alarme doit être déclenchée en cas de défaillance d’un autotest cryptographique.

  4. Indiquez qu’une alarme doit être déclenchée en cas de défaillance d’autotest non cryptographique.

  5. Indiquez qu’une alarme doit être déclenchée en cas de défaillance d’autotest de génération de clés.

  6. Indiquez qu’une alarme doit être déclenchée en cas de défaillance du chiffrement.

  7. Indiquez qu’une alarme doit être déclenchée en cas de défaillance du déchiffrement.

  8. Indiquez qu’une alarme doit être déclenchée en cas de défaillance de la phase 1 de l’IKE.

  9. Indiquez qu’une alarme doit être déclenchée en cas de défaillance de la phase 2 de l’IKE.

  10. Indiquez qu’une alarme doit être déclenchée en cas d’attaque en rejeu.

Résultats

Depuis le mode configuration, confirmez votre configuration en entrant la show security alarms commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration fournies dans cet exemple pour la corriger.

Si vous avez terminé la configuration de l’unité, entrez commit dans le mode de configuration.

Vérification

Pour vérifier que la configuration fonctionne correctement, saisissez la commande depuis le show security alarms mode opérationnel.

Tableau de l'historique des versions
Version
Description
15.1X49-D130
À partir de Junos OS Version 15.1X49-D130, la plage de paramètres d’intervalle autorisé à laquelle les messages R-U-THERE sont envoyés à l’équipement pair est réduite de 10 à 60 secondes à 2 secondes à 60 secondes. Le paramètre de seuil minimum doit être 3, lorsque le paramètre de l’intervalle DPD est défini à moins de 10 secondes.
15.1X49-D120
À partir de Junos OS version 15.1X49-D120, vous pouvez configurer la taille du paquet utilisé pour vérifier un chemin de données IPsec avant l’apparition de l’interface st0 .