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.

Compréhension des alarmes et de 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 SRX300, SRX320, SRX340, SRX345, SRX550HM et SRX1500 équipements et instances vSRX instances.

set security log cache

Les administrateurs (audit, cryptographique, 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 a un ensemble distinct de privilèges uniques, à l’exception 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’équipement pour générer une alarme système lorsque les échecs d’authentification des paquets atteignent un numéro spécifié.

  • Encryption and decryption failures—Vous pouvez configurer l’équipement pour 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—Internet Key Exchange (IKE) Les négociations de phase 1 sont utilisées pour mettre en place IKE associations de sécurité de l’industrie (SAS). Ces SA protègent les négociations IKE phase 2. Vous pouvez configurer l’équipement pour générer une alarme système lorsque IKE défaillances de phase 1 IKE de phase 2 dépassent un nombre spécifié.

  • Self-test failures—Les auto-tests sont des tests qu’un équipement est mis sous alimentation ou redémarrage pour vérifier si le logiciel de sécurité est correctement mis en œuvre sur votre équipement.

    Les auto-tests garantissent la correction des algorithmes cryptographiques. L’image Junos-FIPS effectue des auto-tests automatiquement lors de la connexion sous alimentation, et en continu pour la génération de paires de clés. Dans les images nationales ou FIPS, les auto-tests peuvent ê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’équipement pour générer une alarme système en cas de défaillance auto-test.

  • 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’équipement pour générer une alarme système en cas IDP violations des stratégies de flux.

  • Replay attacks— Une attaque par rejeu est une attaque réseau au cours de laquelle une transmission de données valide est réséquente, frauduleuse ou malveillante. Vous pouvez configurer l’équipement pour générer une alarme système lors d’une attaque par rejeu.

Les messages syslog sont inclus dans les cas suivants:

  • Échec de la génération de clés générationnel

  • Génération de clés asymétrique défaie

  • Échec de la distribution manuelle des clés

  • Échec de la distribution automatique des clés

  • Échec de la destruction des clés

  • Gestion et stockage de clés en panne

  • Chiffrement ou déchiffrement de données défactulés

  • Signature in échec

  • Échec de l’accord clé

  • Échec du hachage cryptographique

  • IKE échec

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

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

  • Inaltérée dans la longueur spécifiée dans le champ d’objet alternatif du certificat reçu d’un équipement d’pair VPN distant.

Les alarmes sont établies en fonction des messages syslog. Chaque panne est consignée, mais une alarme n’est générée que lorsqu’un seuil est atteint.

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

Une fois les mesures appropriées prises, vous pouvez effacer l’alarme. L’alarme reste dans la file d’attente jusqu’à ce que vous la clairiez (ou jusqu’à ce que vous redémarrageiez l’équipement). Pour effacer l’alarme, exécutez clear security alarms la commande.

Compréhension de la surveillance VPN

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

La surveillance VPN est activée pour un VPN spécifié en configurant l’option au vpn-monitor niveau [ edit security ipsec vpn vpn-name ] hiérarchique. L’adresse IP de la passerelle pair est la destination par défaut. cependant, vous pouvez spécifier une autre adresse IP de destination (comme 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 (tel qu’un ordinateur) n’est pas prise en charge SRX5400, SRX5600 et SRX5800 périphériques. La destination de la surveillance VPN doit être une interface locale sur SRX5400, SRX5600 ou SRX5800 périphérique.

L’option de surveillance VPN n’envoie des pings qu’en cas de trafic sortant et d’absence de optimized trafic entrant via le tunnel VPN. Si le trafic entrant passe par le tunnel VPN, l’équipement de sécurité considère que le tunnel est actif et n’envoie pas de pings à l’pair. La configuration de l’option peut enregistrer des ressources sur l’équipement de sécurité, car les pings sont envoyés uniquement lorsque le niveau de convivialité optimized des pairs doit être déterminé. L’envoi de pings peut également activer des liens de sauvegarde coûteux qui sinon ne seraient pas utilisés.

Vous pouvez configurer l’intervalle au cours duquel les pings sont envoyés et le nombre de pings consécutivement envoyés sans réponse avant que le VPN ne soit considéré comme down. Ces configurations sont configurées avec les intervalthreshold options et, respectivement, au niveau de edit security ipsec vpn-monitor-options [ ] hiérarchie.

La surveillance VPN peut provoquer des tunnels 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.

Understanding IPsec Datapath Verification

Présentation

Par défaut, l’état des interfaces de tunnel sécurisé (st0) configurées en mode point à point dans les VPN basés sur le routeur est basé sur l’état du tunnel VPN. Peu après la mise en place du SA IPsec, les routes associées à l’interface st0 sont installées dans la table Junos OS de communication. Dans certaines topologies 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 établir un tunnel VPN 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 des chemins de données IPsec, l’interface st0 n’est pas mise en place et activée jusqu’à ce que le parcours de données soit vérifié. La vérification est configurée avec l’instruction pour les tunnels VPN dynamiques, site à site et set security ipsec vpn vpn-name vpn-monitor verify-path de point d’extrémité.

Si un équipement de NAT se trouve devant le terminal du tunnel, l’adresse IP du terminal du tunnel pair est traduite sur l’adresse IP de l’équipement NAT pair. Pour que le VPN surveille la requête ICMP pour atteindre le point de terminaison du tunnel, vous devez spécifier expressément l’adresse IP d’origine nontranslée du terminal du tunnel pair derrière l’équipement NAT. Celle-ci est configurée en même temps que la set security ipsec vpn vpn-name vpn-monitor verify-path destination-ip configuration.

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

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 des chemins de données IPsec. La source des requêtes ICMP dans le processus de vérification des chemins 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 activée automatiquement et utilisée après la mise en service de l’interface st0. Il est recommandé de configurer l’option optimisée de surveillance VPN avec la commande dès que vous activez la vérification des chemins de données set security ipsec vpn vpn-name vpn-monitor optimized IPsec.

Si un échec du cluster de châssis se produit lors de la vérification des chemins de données IPsec, le nouveau nœud actif lance à nouveau la vérification. L’interface st0 n’est activée que lorsque la vérification est réussi.

Aucune vérification des chemins de données IPsec n’est effectuée pour les clés sa IPsec, car l’état de l’interface st0 ne change pas pour les re-clés.

La vérification des chemins 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 sont pas en mesure de répondre aux adresses IPv6; la vérification des chemins de données IPsec ne peut donc pas être utilisée avec des tunnels IPv6.

Compréhension des 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-chronisés en cas de échec de l’un d’entre eux. Par exemple, si l’un des pairs redémarre, il peut envoyer un index de paramètres de sécurité (SPI) incorrect. Vous pouvez permettre à l’équipement de détecter un tel événement et resynchroniser les pairs en configurant la fonction de réponse SPI mauvaise.

  • Surveillance VPN: vous pouvez utiliser la fonction de surveillance VPN globale pour envoyer régulièrement des requêtes ICMP (Internet Control Message Protocol) à l’pair afin de déterminer si ce dernier est accessible.

Compréhension de la surveillance VPN et de la DPD

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

L SRX Series répond aux messages DPD envoyés par les pairs VPN même si ce dernier n’est pas configuré. Vous pouvez configurer l’SRX Series pour envoyer des messages DPD aux pairs VPN. Vous pouvez également configurer la surveillance DPD et VPN pour qu’elle fonctionne simultanément sur le même équipement SRX Series, même si le nombre d’pairs qui peuvent ê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 au niveau vpn-monitor de edit security ipsec vpn vpn-name [ ] hiérarchie. L’adresse IP de destination et l’interface source doivent être spécifiées. Cette option permet à l’équipement d’utiliser des modèles de trafic comme preuve de bon sens de optimized peer-liveliness; Les requêtes ICMP sont supprimées.

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

DPD est une implémentation de RFC 3706, une méthode basée sur le trafic qui permet de détecter les pairs morts Internet Key Exchange (IKE). Il fonctionne au niveau supérieur et surveille les pairs en fonction IKE IKE activité de trafic IPsec et de surveillance.

Le DPD est configuré sur une passerelle individuelle IKE avec dead-peer-detection l’instruction au niveau [ ] edit security ike gateway gateway-name hiérarchique. 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 a envoyé des paquets sortants à l’pair. Les autres options configurables incluent l’intervalle au cours duquel les messages DPD sont envoyés à l’pair (l’intervalle par défaut est de 10 secondes) et le nombre de messages DPD consécutifs envoyés sans recevoir de réponse avant que le pair ne soit considéré comme indisponible (le par défaut est cinq requêtes consécutives).

Understanding Dead Peer Detection

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

Vous pouvez utiliser la technologie DPD comme alternative à la surveillance VPN. La surveillance VPN s’applique à un VPN IPsec individuel, alors que la DPD n’est configurée que dans IKE contexte de passerelle.

Un équipement effectue la vérification DPD en envoyant des charges utiles de notification de phase 1 (messages R-U-THERE) chiffrées de IKE à un pair et en attente d’accusé de réception de DPD (messages R-U-THERE-ACK). L’équipement envoie un message R-U-THERE uniquement s’il n’a pas reçu de trafic de la part de l’pair au cours d’un intervalle DPD spécifié. Si l’équipement reçoit un message R-U-THERE-ACK de l’pair pendant cet intervalle, il le considère comme en vie. Si l’équipement reçoit du trafic sur le tunnel par l’pair, il réinitialise son compteur de message R-U-THERE pour ce tunnel, en commençant ainsi un nouvel intervalle. Si l’équipement ne reçoit pas de message R-U-THERE-ACK pendant l’intervalle, il estime que l’pair est mort. Lorsque l’équipement modifie l’état d’un équipement pair pour qu’il soit mort, l’équipement supprime l’association de sécurité de phase 1 (SA) et tous les SA de phase 2 pour ce pair.

Les modes DPD suivants sont pris en charge sur les SRX Series de sécurité:

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

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

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

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

    Il est recommandé d’utiliser le mode tunnel au ralenti au lieu du always-send mode.

Les timeurs DPD sont actifs dès la phase 1 SA. Le comportement de 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 le 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 Release 15.1X49-D130, l’intervalle autorisé pour l’envoi des messages R-U-THERE à l’équipement pair est réduit de 10 à 60 secondes à 2 secondes à 60 secondes. Le paramètre de seuil minimum doit être 3, lorsque l’intervalle DPD est définir moins de 10 secondes.

  • Le paramètre de seuil spécifie le nombre maximal de fois pour envoyer le message R-U-THERE sans la réponse de l’pair avant d’envisager la mort de l’pair. 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 commencés sans suppression des SA 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 ces tunnels. IKE et les SA IPsec ne sont pas affectés.

  • La modification d’une option de configuration DPD, telle que le mode, l’intervalle ou les valeurs de seuil, met à jour le fonctionnement du DPD sans effacer les SA 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, DPD ne négociation pas la phase 1. Lors de la configuration du DPD, l’option d’établissement de tunnels immédiatement doit également être configurée en même temps pour détruire l’interface st0 lorsqu’il n’y a pas de SA de phase 1 et 2.

  • Si la passerelle IKE est configurée avec plusieurs adresses IP pair et DPD mais que la phase 1 SA ne parvient pas à établir la première adresse IP, un SA de phase 1 est tenté avec l’adresse IP de la prochaine pair. La DPD n’est active qu’après la mise en place d’un SA de phase 1.

  • Si la passerelle IKE est configurée avec plusieurs adresses IP de pair et DPD mais que DPD échoue avec l’adresse IP de l’pair actuel, les SA de phase 1 et 2 sont autorisées et un retour en avant est déclenché vers l’adresse IP du pair suivant.

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

Comprendre les événements de tunnel

Lorsqu’un problème réseau est associé à un VPN, seul l’état du tunnel est suivi une fois le tunnel mis en place. De nombreux problèmes peuvent se produire avant que le tunnel ne surviennent. Ainsi, au lieu de suivre uniquement l’état du tunnel, les problèmes de tunnel down ou les échecs de négociation, les événements réussis tels que les négociations SA IPsec réussies, le re-key IPsec et les re-clés de IKE SA sont maintenant suivis. Ces événements sont appelés événements de tunnel.

Pour la phase 1 et la phase 2, les événements de négociation pour un tunnel donné sont suivis ainsi que les événements se produisent dans des daemons 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 de mise à jour et le nombre de fois que l’événement est survenu.

Au total, 16 événements sont suivis: huit événements pour la phase 1 et huit pour la phase 2. Certains événements peuvent se reproduire et remplir la mémoire d’événement, ce qui peut entraîner la suppression d’événements importants. Pour éviter les overwritings, un événement n’est pas stocké sauf si un tunnel est en panne.

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

  • Expiration de la durée de vie en kilooctets pour IPsec SA

  • Expiration de la durée de vie difficile des sas IPsec

  • Charge utile de suppression IPsec SA reçue de peer, autorisation des SA IPsec correspondantes

  • Paires SA de secours redondantes non autorisées IPsec

  • Autorisation de suppression des SA IPsec IKE sa correspondante

Des tunnels VPN automatiques sont créés et supprimés de manière dynamique, ce qui fait que les événements correspondant à ces tunnels sont de courte durée. Dans certains cas, ces événements de tunnel ne peuvent pas être associés à un tunnel. C’est pourquoi la journalisation du système est utilisée à la place pour le débogage.

Exemple: Définition d’une alerte de sécurité comme notification d’une alarme de sécurité

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

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 qui 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 alarmiste:

  1. Activez les alarmes de sécurité.

  2. Indiquez que vous souhaitez être informé des alarmes de sécurité avec un signal de notification.

  3. Si vous avez terminé la configuration de l’équipement, commit the 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 aux violations potentielles

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

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 l’élever lorsque:

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

  • Le self-test cryptographique échoue.

  • Le self-test non cryptographique échoue.

  • Le self-test de génération clé est un échec.

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

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

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

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

  • Une attaque par rejeu est en cours.

Configuration

Procédure

CLI configuration rapide

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

Procédure étape par étape

L’exemple suivant vous oblige à naviguer dans différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la manière de vous y rendre, consultez le manuel Using the CLI Editor in Configuration Mode dans le Junos OS CLI User Guide.

Pour configurer des alarmes en réponse aux violations potentielles:

  1. Activez les alarmes de sécurité.

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

  3. Indiquez qu’une alarme doit être alarme en cas de défaillance du auto-test cryptographique.

  4. Indiquez qu’une alarme doit être élevée en cas de défaillance d’un auto-test non cryptographique.

  5. Indiquez qu’une alarme doit être élevée en cas de défaillance d’un auto-test de génération clé.

  6. Indiquez qu’une alarme doit être élevée en cas de défaillance de cryptage.

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

  8. Indiquez qu’une alarme doit être retentie en cas IKE défaillance de phase 1.

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

  10. Indiquez qu’une alarme doit être élevée lors d’une attaque par rejeu.

Résultats

À partir du mode de 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 dans cet exemple pour la corriger.

Si vous avez terminé la configuration de l’équipement, commit saisissez-le en mode de configuration.

Vérification

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

Tableau de l'historique des versions
Version
Description
15.1X49-D130
À partir de Junos OS Release 15.1X49-D130, l’intervalle autorisé pour l’envoi des messages R-U-THERE à l’équipement pair est réduit de 10 à 60 secondes à 2 secondes à 60 secondes. Le paramètre de seuil minimum doit être 3, lorsque l’intervalle DPD est définir moins de 10 secondes.
15.1X49-D120
À partir Junos OS version 15.1X49-D120, vous pouvez configurer la taille du paquet utilisé pour vérifier un chemin de données IPsec avant la mise en place de st0 l’interface.