Méthodes de surveillance VPN

Pourquoi avez-vous besoin d’une vérification IPsec du chemin de données ?

L’état de l’interface de tunnel sécurisé (st0) en mode point à point pour les VPN basés sur le routage dépend généralement de l’état du tunnel VPN. Une fois que l’équipement a établi l’association de sécurité IPsec, Junos OS ajoute les routes associées à l’interface st0 à la table de transfert. Si votre réseau dispose d’un pare-feu de transit entre les points de terminaison du tunnel VPN, le pare-feu peut bloquer le trafic de données IPsec qui utilise des routes actives sur l’interface st0. Par conséquent, vous risquez de rencontrer des pertes de trafic.

Pour éviter une telle perte de trafic, vous devez activer la vérification IPsec des chemins de données. Lorsque vous activez cette fonctionnalité, le périphérique Junos OS n’affiche pas l’interface st0 tant qu’il n’a pas vérifié le chemin de données. Vous pouvez configurer la vérification du chemin d’accès aux données avec les options suivantes :

• Vous pouvez configurer à l’aide de l’instruction [set security ipsec vpn vpn-name vpn-monitor verify-path] pour les tunnels VPN basés sur une route et site à site.

• Si un périphérique NAT se trouve devant le point de terminaison du tunnel homologue, le pare-feu convertit l’adresse IP du point de terminaison du tunnel homologue en adresse IP du périphérique NAT. Pour que la demande ICMP du moniteur VPN atteigne le point de terminaison du tunnel homologue, vous devez spécifier explicitement l’adresse IP d’origine non traduite du point de terminaison du tunnel homologue derrière le périphérique NAT. Vous pouvez le configurer à l’aide de l’instruction de [set security ipsec vpn vpn-name vpn-monitor verify-path destination-ip] configuration.

• À 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’affichage de l’interface st0. Utilisez l’instruction de [set security ipsec vpn vpn-name vpn-monitor verify-path packet-size] configuration. La taille de paquet configurable varie de 64 à 1350 octets ; La valeur par défaut est de 64 octets.

Tenez compte des points suivants lors de l’utilisation de la vérification de chemin de données IPsec :

• L’interface source et les adresses IP de destination que vous configurez pour l’opération de 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 IPsec du chemin de données, Junos OS active automatiquement la surveillance VPN uniquement après l’activation de l’interface st0. Nous vous recommandons de configurer l’option au niveau de la hiérarchie lorsque vous activez la [edit security ipsec vpn vpn-name]vérification IPsec des chemins de données.vpn-monitor optimized 

• Si un basculement de cluster de châssis se produit pendant la vérification du chemin de données IPsec, le nouveau nœud actif redémarre la vérification. Junos OS n’active pas l’interface st0 tant que la vérification n’a pas réussi.

• Pour les reclés d’association de sécurité IPsec, Junos OS n’effectue pas de vérification IPsec du chemin de données, car l’état de l’interface st0 ne change pas pour les reclés.

• Junos OS ne prend pas en charge la vérification IPsec du chemin de données sur les interfaces st0 en mode point à multipoint utilisées avec AutoVPN, Auto Discovery VPN (ADVPN) et plusieurs sélecteurs de trafic.

• La surveillance VPN et la vérification IPsec des chemins de données ne prennent pas en charge les adresses IPv6. Par conséquent, vous ne pouvez pas utiliser la vérification IPsec des chemins de données avec les tunnels IPv6.

Comment fonctionne la vérification IPsec des chemins de données ?

Lorsque vous configurez la vérification IPsec du chemin de données, les événements suivants se produisent :

1. Une fois que l’appareil a établi le tunnel VPN, il envoie une requête ICMP au point de terminaison du tunnel homologue pour vérifier le chemin de données IPsec. Le point de terminaison du tunnel homologue doit être accessible par les requêtes ICMP du moniteur VPN et doit être en mesure de répondre à la demande ICMP. Lorsque la vérification du chemin de données est en cours, le champ de la sortie de la show security ipsec security-association detail commande affiche la lettre VVPN Monitoring .

2. Junos OS active l’interface st0 uniquement lorsqu’il reçoit une réponse de l’homologue. La show interface st0.x sortie de la commande affiche l’état de l’interface st0 pendant et après la vérification du chemin de données : Link-Layer-Down avant la fin de la vérification et Up après la fin de la vérification.

3. Si l’homologue n’envoie pas de réponse ICMP, l’appareil envoie une autre requête ICMP à l’intervalle de surveillance VPN configuré jusqu’à ce qu’il atteigne la valeur de seuil de surveillance VPN configurée. Notez que l’intervalle de surveillance VPN par défaut est de 10 secondes et que la valeur de seuil de surveillance VPN par défaut est de 10 fois. Si la vérification échoue, l’entrée du KMD_VPN_DOWN_ALARM_USER journal système indique qu’il s’agit d’une erreur de vérification du chemin de vérification de la surveillance VPN. L’appareil consigne une erreur sous les événements de tunnel dans la sortie de la show security ipsec security-association detail commande. La show security ipsec tunnel-events-statistics commande affiche le nombre de fois que l’erreur s’est produite. Vous pouvez configurer l’intervalle de surveillance VPN et la valeur de seuil de surveillance VPN à l’aide de l’optionvpn-monitor-options de configuration au niveau de la hiérarchie [].edit security ipsec 

4. Si l’homologue n’envoie pas de réponse ICMP même après avoir atteint la valeur seuil du moniteur VPN, n Junos OS arrête le tunnel VPN et renégocie le tunnel VPN.

Comment fonctionne DPD ?

Lors de la création d’un tunnel IPsec, les homologues VPN négocient pour décider d’utiliser ou non la méthode DPD (Dead Peer Detection). Si les homologues acceptent d’utiliser la méthode DPD, lorsqu’il n’y a pas de trafic actif, le protocole DPD envoie des messages périodiques à l’homologue et attend une réponse. Si l’homologue ne répond pas aux messages, le protocole DPD suppose que l’homologue n’est plus disponible. Le comportement de DPD est le même pour les protocoles IKEv1 et IKEv2. Les minuteries DPD sont actives dès que l’IKE établit la phase 1 de l’association de sécurité (SA).

Un pare-feu SRX Series utilise le protocole DPD pour détecter l’activité d’une connexion VPN IPsec.

Figure 1 : Échange de messages dans le protocole DPD

Figure 1 montre l’échange de messages DPD entre les homologues IKE dans un tunnel VPN IPsec. Les événements suivants se produisent lorsque le pare-feu effectue DPD :

1. Le pare-feu SRX-A attend l’intervalle DPD spécifié pour vérifier s’il a reçu du trafic de son homologue, SRX-B.

2. Si le SRX-A ne reçoit aucun trafic de SRX-B pendant l’intervalle DPD spécifié, il envoie à SRX-B une charge utile de notification IKE de phase 1 chiffrée (un message R-U-THERE).

3. SRX-A attend l’accusé de réception DPD (un message R-U-THERE-ACK) de la part de SRX-B.

   1. Si SRX-A reçoit un message R-U-THERE-ACK de SRX-B au cours de cet intervalle, il considère que l’homologue est actif. Ensuite, SRX-A réinitialise son compteur de messages R-U-THERE pour ce tunnel et démarre un nouvel intervalle.

   2. Si SRX-A ne reçoit pas de message R-U-THERE-ACK pendant l’intervalle, il considère que l’homologue, SRX-B, est inactif. Le SRX-A supprime ensuite l’association de sécurité de phase 1 et toutes les associations de sécurité de phase 2 pour cet homologue.

Paramètres DPD configurables

Voici une liste des paramètres DPD que vous devrez configurer :

• Mode : en fonction de l’activité du trafic, vous pouvez configurer DPD dans l’un des modes suivants :

  • Optimisé : en mode optimisé , lorsque l’appareil à l’origine envoie des paquets sortants à l’homologue, s’il n’y a pas de trafic IKE ou IPsec entrant de l’homologue dans l’intervalle configuré, l’appareil à l’origine déclenche des messages R-U-THERE. DPD fonctionne dans ce mode par défaut, sauf si vous configurez un autre mode.

  • Tunnel inactif de la sonde : en mode tunnel inactif de la sonde , l’appareil déclenche des messages R-U-THERE s’il n’y a pas de trafic IKE ou IPsec entrant ou sortant au cours d’un intervalle configuré. L’appareil envoie régulièrement des messages R-U-THERE à l’homologue jusqu’à ce qu’il y ait une activité de trafic. Ce mode permet de détecter précocement un homologue en panne, garantissant ainsi la disponibilité du tunnel pendant le flux de trafic actif.



    REMARQUE :

    Dans ce scénario, lorsque vous configurez le mode tunnel inactif de la sonde, l’appareil déclenche des messages R-U-THERE si un tunnel devient inactif, quel que soit le trafic dans un autre tunnel pour la même association de sécurité IKE.

  • Always-send (Envoi permanent) : en mode d’envoi permanent , l’appareil envoie des messages R-U-THERE à un intervalle configuré, quelle que soit l’activité du trafic entre les homologues. Nous vous recommandons d’utiliser le mode tunnel inactif de la sonde au lieu du mode d’envoi permanent.

• Interval (Intervalle) : utilisez le paramètre interval (en secondes) pour spécifier la durée (en secondes) pendant laquelle l’appareil attend le trafic de son homologue avant d’envoyer un message R-U-THERE. L’intervalle par défaut est de 10 secondes. À partir de la version 15.1X49-D130 de Junos OS, nous avons réduit la plage de paramètres d’intervalle autorisée à laquelle les messages R-U-THERE sont envoyés au périphérique homologue de 10 secondes à 60 secondes à 2 secondes à 60 secondes. Nous vous recommandons de définir le paramètre de seuil minimum sur 3, lorsque le paramètre d’intervalle DPD est défini sur moins de 10 secondes.

• Threshold (Seuil ) : utilisez le paramètre threshold (seuil) pour spécifier le nombre maximal de fois que l’appareil envoie le message R-U-THERE sans recevoir de réponse de l’homologue avant de considérer que l’homologue est en panne. Le nombre par défaut de transmissions est de cinq, avec une plage autorisée de 1 à 5 tentatives.

Notez les considérations suivantes avant de configurer DPD :

• Une fois que vous avez ajouté la configuration DPD à une passerelle existante avec des tunnels actifs, l’appareil commence à déclencher des messages R-U-THERE sans effacer les associations de sécurité de phase 1 ou de phase 2.

• Lorsque vous supprimez la configuration DPD d’une passerelle existante avec des tunnels actifs, l’appareil cesse de déclencher des messages R-U-THERE pour les tunnels. Mais cela n’affecte pas les associationsde sécurité IKE et IPsec.

• Lorsque vous modifiez des paramètres de configuration DPD tels que le mode, l’intervalle ou les valeurs de seuil, IKE met à jour l’opération DPD sans effacer les associationsde sécurité de phase 1 ou de phase 2.

• Si vous configurez la passerelle IKE avec la surveillance DPD et VPN sans spécifier l’option permettant d’établir des tunnels immédiatement, IKE ne lance pas la négociation de phase 1. Lorsque vous configurez DPD, vous devez également configurer l’option establish-tunnels immediately au niveau de la hiérarchie [edit security ipsec vpn vpn-name] pour supprimer l’interface st0 lorsqu’aucune associationde sécurité de phase 1 et de phase 2 n’est disponible. Voir vpn (sécurité) pour l’optionestablish-tunnels .

• Si vous configurez la passerelle IKE avec plusieurs adresses IP homologues et DPD, mais que vous ne parvenez pas à établir la phase 1 SA avec la première adresse IP homologue, IKE tente d’établir avec l’adresse IP homologue suivante. DPD n’est actif qu’une fois que l’IKE a établi l’association de sécurité de phase 1. Reportez-vous à la section détection des pairs morts.

• Si vous configurez la passerelle IKE avec plusieurs adresses IP homologues et DPD, mais que la connexion échoue avec l’adresse IP de l’homologue actuel, IKE efface les associationsde sécurité des phases 1 et 2 et DPD effectue un basculement vers l’adresse IP de l’homologue suivant. Voir passerelle (IKE de sécurité).

• Plusieurs SA de phase 1 ou de phase 2 peuvent exister avec le même homologue en raison de négociations simultanées. Dans ce cas, DPD envoie des messages R-U-THERE à toutes les associationsde sécurité de phase 1. Si la passerelle ne parvient pas à recevoir les réponses DPD pendant le nombre configuré de fois consécutifs, elle efface l’association de sécurité de phase 1 et l’association de sécurité de phase 2 associée (pour IKEv2 uniquement).

Si l’homologue IKE est actif, cela signifie-t-il que le VPN sous-jacent est opérationnel ?

Comment fonctionne la surveillance des tunnels VPN ?

La surveillance VPN utilise les requêtes d’écho (ou pings) ICMP (Internet Control Message Protocol) et les données de signature, telles que l’ID de tunnel, dans le paquet ICMP pour déterminer si le tunnel VPN est actif.

Lorsque vous activez la surveillance VPN, l’appareil envoie des demandes d’écho ICMP via le tunnel VPN à la passerelle homologue ou à une destination spécifiée à l’autre extrémité du tunnel. L’appareil envoie les requêtes par défaut à des intervalles de 10 secondes pour un maximum de 10 fois consécutives. Si l’appareil ne reçoit aucune réponse après 10 pings consécutifs, il considère que le VPN est en panne et efface l’association de sécurité IPsec.

Utilisez les modes de fonctionnement suivants pour surveiller les tunnels VPN :

• Mode d’envoi permanent : dans ce mode, l’appareil envoie un paquet de surveillance VPN une fois par intervalle configuré, quel que soit le trafic dans le tunnel. Une fois que vous avez activé la surveillance VPN, Junos OS utilise le mode d’envoi permanent comme mode par défaut si vous n’en spécifiez pas.

• Mode optimisé : dans ce mode, l’appareil envoie un paquet de surveillance VPN une fois par intervalle configuré, uniquement s’il y a du trafic sortant et aucun trafic entrant via le tunnel pendant l’intervalle. S’il y a du trafic entrant via le tunnel VPN, l’appareil considère que le tunnel est actif et cesse d’envoyer des pings à l’homologue. Vous pouvez utiliser le mode optimisé pour économiser des ressources sur l’appareil, car dans ce mode, l’appareil envoie des pings uniquement lorsqu’il a besoin de déterminer l’activité de l’homologue. L’envoi de pings peut également activer des liens de sauvegarde coûteux qui ne seraient pas utilisés autrement.

  L’appareil fonctionne en mode d’envoi permanent par défaut si vous ne configurez pas explicitement le mode optimisé.