Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Dépannage AWS Site-to-Site VPN connectivité avec un dispositif de passerelle client Cisco ASA

Quand vous résolvez les problèmes de connexion d'une passerelle client Cisco, prenez en compte trois critères : IKE (Internet Key Exchange), IPsec (Internet Protocol Security) et le routage. Vous pouvez résoudre des problèmes dans ces domaines dans n'importe quel ordre mais nous vous recommandons de commencer avec l'IKE (en bas du stack réseau) et de remonter.

IKE

Utilisez la commande suivante de l’. La réponse montre une passerelle client avec IKE configuré correctement.

ciscoasa# show crypto isakmp sa

   Active SA: 2
   Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 2

1   IKE Peer: AWS_ENDPOINT_1
    Type    : L2L             Role    : initiator
    Rekey   : no              State   : MM_ACTIVE

Vous devez voir une ou plusieurs lignes contenant une valeur src pour la passerelle à distance spécifiée dans les tunnels. La valeur de state doit être MM_ACTIVE et status doit être ACTIVE. L'absence d'une entrée, ou toute entrée dans un état différent, indique que l'IKE n'est pas correctement configuré.

Pour un dépannage plus approfondi, exécutez les commandes suivantes pour permettre la consignation des messages qui apportent des informations de diagnostic.

router# term mon
router# debug crypto isakmp

Pour désactiver le débogage, utilisez la commande suivante.

router# no debug crypto isakmp

IPsec

Utilisez la commande suivante de l’. La réponse montre une passerelle client avec IPsec configuré correctement.

ciscoasa# show crypto ipsec sa

interface: outside
    Crypto map tag: VPN_crypto_map_name, seq num: 2, local addr: 172.25.50.101

      access-list integ-ppe-loopback extended permit ip any vpc_subnet subnet_mask
      local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
      remote ident (addr/mask/prot/port): (vpc_subnet/subnet_mask/0/0)
      current_peer: integ-ppe1

      #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
      #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #send errors: 0, #recv errors: 0

      local crypto endpt.: 172.25.50.101, remote crypto endpt.: AWS_ENDPOINT_1

      path mtu 1500, ipsec overhead 74, media mtu 1500
      current outbound spi: 6D9F8D3B
      current inbound spi : 48B456A6

    inbound esp sas:
      spi: 0x48B456A6 (1219778214)
         transform: esp-aes esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 2, }
         slot: 0, conn_id: 4710400, crypto-map: VPN_cry_map_1
         sa timing: remaining key lifetime (kB/sec): (4374000/3593)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001
    outbound esp sas:
      spi: 0x6D9F8D3B (1839172923)
         transform: esp-aes esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 2, }
         slot: 0, conn_id: 4710400, crypto-map: VPN_cry_map_1
         sa timing: remaining key lifetime (kB/sec): (4374000/3593)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
         0x00000000 0x00000001

Pour chaque interface du tunnel, vous devez voir inbound esp sas et outbound esp sas. Ceci suppose qu'une SA (Security Association, association de sécurité) est répertoriée (par exemple, spi: 0x48B456A6), et qu'IPsec est correctement configuré.

Dans Cisco ASA, IPsec n'apparaît qu'après l'envoi d'un trafic intéressant (trafic qui doit être chiffré). Pour qu'IPsec demeure toujours actif, nous vous recommandons de configurer un moniteur SLA. Le moniteur SLA continue d'envoyer le trafic intéressant, tout en gardant IPsec actif.

Vous pouvez aussi utiliser la commande ping suivante pour forcer votre IPsec à démarrer les négociations et remonter.

ping ec2_instance_ip_address

Pinging ec2_instance_ip_address with 32 bytes of data:

Reply from ec2_instance_ip_address: bytes=32 time<1ms TTL=128
Reply from ec2_instance_ip_address: bytes=32 time<1ms TTL=128
Reply from ec2_instance_ip_address: bytes=32 time<1ms TTL=128

Ping statistics for 10.0.0.4:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),

Approximate round trip times in milliseconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

Pour un dépannage plus approfondi, exécutez les commandes suivantes pour activer le débogage.

router# debug crypto ipsec

Pour désactiver le débogage, utilisez la commande suivante.

router# no debug crypto ipsec

Routage

Effectuez un test ping sur l'autre entrée du tunnel. Si cela fonctionne, votre IPsec doit être établi. Si cela ne fonctionne pas, vérifiez vos listes d'accès et consultez la section IPsec précédente.

Si vous ne pouvez pas atteindre vos instances, vérifiez les points suivants :

Faites rebondir l'interface du tunnel

Si le tunnel semble ouvert mais que le trafic ne circule pas correctement, le fait de rebondir (désactiver et réactiver) l'interface du tunnel peut souvent résoudre les problèmes de connectivité. Pour faire rebondir l'interface du tunnel sur un Cisco ASA :