Lorsqu'un tunnel VPN IPSec devient instable, collectez les journaux de produit NSX Data Center for vSphere pour procéder à un dépannage de base. Vous pouvez configurer des sessions de capture de paquets sur le chemin de données et exécuter certaines commandes CLI NSX Edge pour déterminer les causes de l'instabilité du tunnel.

Utilisez la procédure suivante pour découvrir les causes de l'instabilité du tunnel VPN IPSec.

Conditions préalables

Avant de configurer des sessions de capture de paquets sur le chemin de données, assurez-vous que les conditions suivantes sont réunies :
  • Les paquets peuvent être envoyés et reçus sur les ports UDP 500 et 4500.
  • Les règles de pare-feu autorisent le trafic de données à passer par les ports 500 et 4500.
  • Les règles de pare-feu autorisent les paquets ESP (Encapsulating Security Payload).
  • Le routage du sous-réseau local sur l'interface IPSec est configuré correctement.
  • Vérifiez la configuration du MTU pour y déceler des problèmes de fragmentation. Pour ce faire, envoyez une petite charge utile ping, puis une charge utile ping plus importante, à l'adresse IP qui se trouve au bout du tunnel.

Procédure

  1. Collectez les journaux de support à partir des deux sites.
    • Pour collecter des informations de diagnostic pour NSX Data Center for vSphere, consultez l'article de la base de connaissances VMware http://kb.vmware.com/kb/2074678.
    • Pour collecter des informations de diagnostic pour NSX Edge, consultez l'article de la base de connaissances VMware http://kb.vmware.com/kb/2079380.
    Important : En raison de l'espace disque limité sur le dispositif NSX Edge, vous devez rediriger les journaux vers un serveur Syslog. Pour plus d'informations, consultez la section « Configurer des serveurs Syslog à distance » du NSX Data Center for vSphereGuide d'administration.
  2. Assurez-vous que le service VPN IPSec sur le dispositif NSX Edge est correctement configuré pour fonctionner avec les solutions de pare-feu VPN matériel tierces, telles que SonicWall, Watchguard, etc. Si nécessaire, contactez le fournisseur VPN pour obtenir toutes les informations de configuration spécifiques dont vous avez besoin.
  3. Paramétrez une capture de paquets IKE ou ESP entre le dispositif NSX Edge et le pare-feu tiers.
  4. Sur NSX Edge, enregistrez l'état en temps réel lorsque le problème se produit. Exécutez les commandes suivantes et enregistrez les résultats.
    Commande Objectif
    show service ipsec Vérifier l'état du service VPN IPSec.
    show service ipsec sp Vérifier l'état de la stratégie de sécurité.
    show service ipsec sa Vérifier l'état de l'association de sécurité (SA).
  5. Alors que le problème est toujours en cours, capturez les journaux et la sortie liés à IPSec sur la solution VPN tierce.
  6. Examinez les journaux et la sortie liés à IPSec pour déterminer la nature du problème. Assurez-vous que le service VPN IPSec est en cours d'exécution, que les stratégies de sécurité sont créées et que les associations de sécurité entre les périphériques sont configurées.
    Les problèmes courants que vous pouvez repérer dans les journaux sont les suivants :
    • ID non valide : INVALID_ID_INFORMATION ou PAYLOAD_MALFORMED
    • Aucune autorité de certification approuvée : INVALID_KEY_INFORMATION ou une erreur plus spécifique. Par exemple, no RSA public key known for 'C=CN, ST=BJ, O=VMware, OU=CINS, CN=left‘ ou PAYLOAD_MALFORMED.
    • ID de proxy proposé introuvable : INVALID_ID_INFORMATION ou PAYLOAD_MALFORMED.
    • DPD, aucune réponse de l'homologue. Par exemple, DPD: No response from peer - declaring peer dead.
  7. Vérifiez le message d'échec du tunnel dans vSphere Web Client, dans l'interface de ligne de commande de NSX Edge ou en exécutant les REST API de NSX Data Center for vSphere.
    Par exemple, pour afficher le message d'échec dans vSphere Web Client, double-cliquez sur NSX Edge, accédez à la page VPN IPSec et procédez comme suit :
    1. Cliquez sur Afficher les statistiques IPSec (Show IPSec Statistics).
    2. Sélectionnez le canal IPSec inactif.
    3. Pour le canal sélectionné, sélectionnez le tunnel hors service (désactivé) et consultez les détails de l’échec du tunnel.
      • Dans NSX 6.4.6 et versions ultérieures, cliquez sur Désactivé dans la colonne État du tunnel.
      • Dans NSX 6.4.5 et versions antérieures, cliquez sur Afficher les détails dans la colonne État du tunnel.

    Le tableau suivant répertorie les causes possibles des problèmes de connectivité du tunnel IPSec et le message d'échec associé.

    Causes Message d'échec
    Homologue IKEv1 non accessible. Version-IKEv1 Retransmitting IKE Message as no response from Peer.
    Incohérence dans la proposition IKEv1 de Phase 1. Version-IKEv1 No Proposal Chosen. Check configured Encryption/Authentication/DH/IKE-Version.
    Incohérence relative à l'un des éléments suivants :
    • PSK IKEv1
    • ID IKEv1
    • Certificat IKEv1
    Version-IKEv1 Authentication Failed. Check the configured secret or local/peer ID configuration.
    Incohérence dans la proposition IKEv1 de Phase 2. IPSec-SA Proposals or Traffic Selectors did not match.
    Homologue IKEv2 non accessible. Version-IKEv2 Retransmitting IKE Message as no response from Peer.
    Incohérence dans la proposition IKE SA IKEv2. Version-IKEv2 No Proposal Chosen. Check configured Encrypt/Authentication/DH/IKEversion.
    Incohérence dans la proposition IPSec SA IKEv2. IPSec-SA Proposals or Traffic Selectors did not match.
    Incohérence des sélecteurs de trafic IPSec SA IKEv2. Traffic selectors did not match. Check left/right subnet configuration.
    Incohérence relative à l'un des éléments suivants :
    • PSK IKEv2
    • ID IKEv2
    • Certificat IKEv2
    Version-IKEv2 Authentication Failed. Check the configured secret or local/peer ID configuration.
  8. Alors que le problème est toujours en cours, capturez l'état d'exécution, l'état du trafic et les sessions de capture de paquets sur l'intégralité du chemin d'accès de données.
    Pour déterminer où le trafic présente des problèmes, exécutez une commande ping à partir d'un sous-réseau privé d'un côté du tunnel IPSec vers un autre sous-réseau privé de l'autre côté du tunnel IPSec.
    1. Paramétrez la capture de paquets aux points 1, 2, 3 et 4, comme indiqué dans la figure suivante.
    2. Exécutez une commande ping de la machine virtuelle 1 à l'hôte 2.
    3. Exécutez une commande ping de l'hôte 2 à la machine virtuelle 1.
    4. Vérifiez à quel point le transfert de paquets a échoué ou a été abandonné.
    Figure 1. Capture de paquets à des points différents du chemin de données

    L'image est décrite dans le texte qui s'y rapporte.