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.
# Résolution des problèmes liés AWS Site-to-Site VPN au dispositif de passerelle client
Lorsque vous résolvez des problèmes liés à votre dispositif de passerelle client, il est important d'adopter une approche structurée. Les deux premières rubriques de cette section fournissent des organigrammes généraux permettant de résoudre les problèmes liés à l'utilisation d'un périphérique configuré pour le routage dynamique (BGP activé) et d'un périphérique configuré pour le routage statique (sans BGP activé), respectivement. Vous trouverez ci-dessous des guides de dépannage spécifiques aux appareils pour les appareils de passerelle client Cisco, Juniper et Yamaha.
Outre les sujets abordés dans cette section, l'activation [AWS Site-to-Site VPN journaux](monitoring-logs.md) peut être très utile pour résoudre les problèmes de connectivité VPN. Pour les instructions générales de test, voir également[Tester une AWS Site-to-Site VPN connexion](HowToTestEndToEnd_Linux.md).
**Topics**
+ [Appareil avec BGP](Generic_Troubleshooting.md)
+ [Appareil sans BGP](Generic_Troubleshooting_noBGP.md)
+ [Cisco ASA](Cisco_ASA_Troubleshooting.md)
+ [Cisco IOS](Cisco_Troubleshooting.md)
+ [Cisco IOS sans BGP](Cisco_Troubleshooting_NoBGP.md)
+ [Juniper JunOS](Juniper_Troubleshooting.md)
+ [Juniper ScreenOS](Juniper_ScreenOs_Troubleshooting.md)
+ [Yamaha](Yamaha_Troubleshooting.md)
**Ressources supplémentaires**
+ [Forum Amazon VPC](https://repost.aws/tags/TATGuEiYydTVCPMhSnXFN6gA/amazon-vpc)
# Résoudre les problèmes de AWS Site-to-Site VPN connectivité lors de l'utilisation du protocole Border Gateway
Le schéma et le tableau suivants fournissent des instructions générales pour la résolution de problèmes sur un périphérique de passerelle client qui utilise le protocole BGP (Border Gateway Protocol). Nous vous recommandons également d'activer les fonctions de débogage de votre appareil. Consultez le fournisseur de votre périphérique de passerelle pour plus de détails.
![\[Diagramme de résolution des problèmes de passerelle client sur un appareil générique\]](http://docs.aws.amazon.com/fr_fr/vpn/latest/s2svpn/images/troubleshooting-cgw-flow-diagram.png)
| | |
| --- |--- |
| IKE | Déterminez si une association de sécurité IKE existe. Une association de sécurité IKE est requise pour échanger les clés utilisées pour établir l'association IPsec de sécurité. Si aucune association de sécurité IKE n'existe, passez en revue vos paramètres de configuration IKE. Vous devez configurer le chiffrement, l'authentification, la confidentialité persistante parfaite (perfect-forward-secrecy) et les paramètres de mode comme répertoriés dans le fichier de configuration. S'il existe une association de sécurité IKE, passez à « IPsec ». |
| IPsec | Déterminez s'il existe une association de IPsec sécurité (SA). Un IPsec SA est le tunnel lui-même. Interrogez votre dispositif de passerelle client pour déterminer si une IPsec SA est active. Assurez-vous de configurer le chiffrement, l'authentification, la confidentialité persistante parfaite (perfect-forward-secrecy) et les paramètres de mode comme répertoriés dans le fichier de configuration. S'il n'existe aucune IPsec SA, passez en revue votre IPsec configuration. Si une IPsec SA existe, passez à « Tunnel ». |
| Tunnel | Vérifiez que les règles de pare-feu nécessaires sont configurées (pour une liste des règles, consultez [Règles de pare-feu pour un dispositif de passerelle AWS Site-to-Site VPN client](FirewallRules.md)). Si c'est le cas, continuez. Déterminez s'il existe une connexion IP via le tunnel. Chaque côté du tunnel possède une adresse IP comme spécifié dans le fichier de configuration. L'adresse de la passerelle réseau privé virtuel est l'adresse utilisée comme l'adresse du voisin BGP. Depuis votre passerelle client, exécutez un test ping de cette adresse pour déterminer si le trafic IP est correctement chiffré et déchiffré. Si le test ping n'est pas réussi, passez en revue la configuration de votre interface de tunnel pour vérifier qu'une adresse IP correcte est configurée. Si le test ping est réussi, passez à « BGP ». |
| BGP | Déterminez si la session d'appairage BGP est active. Pour chaque tunnel, procédez de la façon suivante : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/vpn/latest/s2svpn/Generic_Troubleshooting.html) Si les tunnels ne sont pas dans cet état, passez en revue la configuration de votre BGP. Si l'appairage BGP est instauré, que vous recevez un préfixe et que vous publiez un préfixe, alors votre tunnel est configuré correctement. Assurez-vous que les deux tunnels sont dans cet état. |
# Résolution des problèmes de AWS Site-to-Site VPN connectivité sans Border Gateway Protocol
Le schéma et le tableau suivants fournissent des instructions générales pour la résolution de problèmes sur un périphérique de passerelle client qui n'utilise pas de protocole BGP (Border Gateway Protocol). Nous vous recommandons également d'activer les fonctions de débogage de votre appareil. Consultez le fournisseur de votre périphérique de passerelle pour plus de détails.
![\[Diagramme de résolution des problèmes de passerelle client sur un appareil générique\]](http://docs.aws.amazon.com/fr_fr/vpn/latest/s2svpn/images/troubleshooting-cgw-flow-nobgp-diagram.png)
| | |
| --- |--- |
| IKE | Déterminez si une association de sécurité IKE existe. Une association de sécurité IKE est requise pour échanger les clés utilisées pour établir l'association IPsec de sécurité. Si aucune association de sécurité IKE n'existe, passez en revue vos paramètres de configuration IKE. Vous devez configurer le chiffrement, l'authentification, la confidentialité persistante parfaite (perfect-forward-secrecy) et les paramètres de mode comme répertoriés dans le fichier de configuration. S'il existe une association de sécurité IKE, passez à « IPsec ». |
| IPsec | Déterminez s'il existe une association de IPsec sécurité (SA). Un IPsec SA est le tunnel lui-même. Interrogez votre dispositif de passerelle client pour déterminer si une IPsec SA est active. Assurez-vous de configurer le chiffrement, l'authentification, la confidentialité persistante parfaite (perfect-forward-secrecy) et les paramètres de mode comme répertoriés dans le fichier de configuration. S'il n'existe aucune IPsec SA, passez en revue votre IPsec configuration. Si une IPsec SA existe, passez à « Tunnel ». |
| Tunnel | Vérifiez que les règles de pare-feu nécessaires sont configurées (pour une liste des règles, consultez [Règles de pare-feu pour un dispositif de passerelle AWS Site-to-Site VPN client](FirewallRules.md)). Si c'est le cas, continuez. Déterminez s'il existe une connexion IP via le tunnel. Chaque côté du tunnel possède une adresse IP comme spécifié dans le fichier de configuration. L'adresse de la passerelle réseau privé virtuel est l'adresse utilisée comme l'adresse du voisin BGP. Depuis votre passerelle client, exécutez un test ping de cette adresse pour déterminer si le trafic IP est correctement chiffré et déchiffré. Si le test ping n'est pas réussi, passez en revue la configuration de votre interface de tunnel pour vérifier qu'une adresse IP correcte est configurée. Si le ping réussit, passez à « Routes statiques ». |
| Routes statiques | Pour chaque tunnel, procédez de la façon suivante : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/vpn/latest/s2svpn/Generic_Troubleshooting_noBGP.html) Si les tunnels ne sont pas dans cet état, passez en revue la configuration de votre périphérique. Assurez-vous que les deux tunnels sont dans cet état et vous avez terminé. |
# Résoudre les problèmes AWS Site-to-Site VPN de connectivité avec un dispositif de passerelle client Cisco ASA
Lorsque vous dépannez la connectivité d'un périphérique de passerelle client Cisco, pensez à l'IKE et au routage. IPsec 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.
**Important**
Certains modes Cisco ASAs ne prennent en charge que Active/Standby le mode. Lorsque vous utilisez ces Cisco ASAs, vous ne pouvez avoir qu'un seul tunnel actif à la fois. L'autre tunnel en veille devient actif uniquement si le premier tunnel devient inaccessible. Le tunnel en veille peut générer l'erreur suivante dans vos fichiers journaux, qui peut être ignorée : `Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 0.0.0.0/0.0.0.0/0/0 local proxy 0.0.0.0/0.0.0.0/0/0 on interface outside`.
## 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 indique qu'un dispositif de passerelle client IPsec est correctement configuré.
```
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`. Cela suppose qu'une SA est répertoriée (par exemple,`spi: 0x48B456A6`) et qu'elle IPsec est correctement configurée.
Dans Cisco ASA, le IPsec seul problème apparaît après l'envoi du trafic intéressant (trafic qui doit être chiffré). Pour toujours rester IPsec actif, nous vous recommandons de configurer un moniteur SLA. Le moniteur SLA continue d'envoyer du trafic intéressant, en maintenant le trafic IPsec actif.
Vous pouvez également utiliser la commande ping suivante pour vous forcer IPsec à démarrer la négociation et à monter.
```
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, alors vous IPsec devriez être établi. Si cela ne fonctionne pas, vérifiez vos listes d'accès et reportez-vous à la IPsec section précédente.
Si vous ne pouvez pas atteindre vos instances, vérifiez les points suivants :
1. Vérifiez que la liste d'accès est configurée pour autoriser le trafic associé à la carte de chiffrement.
Vous pouvez le faire à l'aide de la commande suivante.
```
ciscoasa# show run crypto
```
```
crypto ipsec transform-set transform-amzn esp-aes esp-sha-hmac
crypto map VPN_crypto_map_name 1 match address access-list-name
crypto map VPN_crypto_map_name 1 set pfs
crypto map VPN_crypto_map_name 1 set peer AWS_ENDPOINT_1 AWS_ENDPOINT_2
crypto map VPN_crypto_map_name 1 set transform-set transform-amzn
crypto map VPN_crypto_map_name 1 set security-association lifetime seconds 3600
```
1. Vérifiez la liste d'accès à l'aide de la commande suivante.
```
ciscoasa# show run access-list access-list-name
```
```
access-list access-list-name extended permit ip any vpc_subnet subnet_mask
```
1. Vérifiez que la liste d'accès est correcte. L'exemple de liste d'accès suivant autorise tout le trafic interne vers le sous-réseau VPC 10.0.0.0/16.
```
access-list access-list-name extended permit ip any 10.0.0.0 255.255.0.0
```
1. Exécutez un traceroute depuis le périphérique Cisco ASA pour voir s'il atteint les routeurs Amazon (par exemple,*AWS\$1ENDPOINT\$11*/). *AWS\$1ENDPOINT\$12*
S'il atteint le routeur Amazon, vérifiez les routes statiques que vous avez ajoutées à la console Amazon VPC, ainsi que les groupes de sécurité des instances spécifiques.
1. Pour un dépannage plus approfondi, passez en revue la configuration.
## 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 :
1. Exécutez les commandes suivantes :
```
ciscoasa# conf t
ciscoasa(config)# interface tunnel X (where X is your tunnel ID)
ciscoasa(config-if)# shutdown
ciscoasa(config-if)# no shutdown
ciscoasa(config-if)# end
```
Vous pouvez également utiliser une commande d'une seule ligne :
```
ciscoasa# conf t ; interface tunnel X ; shutdown ; no shutdown ; end
```
1. Après avoir fait rebondir l'interface, vérifiez si la connexion VPN a été rétablie et si le trafic circule désormais correctement.
# Résoudre les problèmes de AWS Site-to-Site VPN connectivité avec un dispositif de passerelle client Cisco IOS
Lorsque vous dépannez la connectivité d'un dispositif de passerelle client Cisco, tenez compte de quatre éléments : l'IKE IPsec, le tunnel et le BGP. 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.
```
router# show crypto isakmp sa
```
```
IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
192.168.37.160 72.21.209.193 QM_IDLE 2001 0 ACTIVE
192.168.37.160 72.21.209.225 QM_IDLE 2002 0 ACTIVE
```
Vous devez voir une ou plusieurs lignes contenant une valeur `src` pour la passerelle à distance spécifiée dans les tunnels. `state` doit être `QM_IDLE` et `status` doit être `ACTIVE`. L'absence d'une entrée, ou toute entrée dans un état différent, indique qu'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 indique qu'un dispositif de passerelle client IPsec est correctement configuré.
```
router# show crypto ipsec sa
```
```
interface: Tunnel1
Crypto map tag: Tunnel1-head-0, local addr 192.168.37.160
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 72.21.209.225 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 149, #pkts encrypt: 149, #pkts digest: 149
#pkts decaps: 146, #pkts decrypt: 146, #pkts verify: 146
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 174.78.144.73, remote crypto endpt.: 72.21.209.225
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0
current outbound spi: 0xB8357C22(3090512930)
inbound esp sas:
spi: 0x6ADB173(112046451)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 1, flow_id: Motorola SEC 2.0:1, crypto map: Tunnel1-head-0
sa timing: remaining key lifetime (k/sec): (4467148/3189)
IV size: 16 bytes
replay detection support: Y replay window size: 128
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xB8357C22(3090512930)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2, flow_id: Motorola SEC 2.0:2, crypto map: Tunnel1-head-0
sa timing: remaining key lifetime (k/sec): (4467148/3189)
IV size: 16 bytes
replay detection support: Y replay window size: 128
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
interface: Tunnel2
Crypto map tag: Tunnel2-head-0, local addr 174.78.144.73
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 72.21.209.193 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 26, #pkts encrypt: 26, #pkts digest: 26
#pkts decaps: 24, #pkts decrypt: 24, #pkts verify: 24
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 174.78.144.73, remote crypto endpt.: 72.21.209.193
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0
current outbound spi: 0xF59A3FF6(4120526838)
inbound esp sas:
spi: 0xB6720137(3060924727)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 3, flow_id: Motorola SEC 2.0:3, crypto map: Tunnel2-head-0
sa timing: remaining key lifetime (k/sec): (4387273/3492)
IV size: 16 bytes
replay detection support: Y replay window size: 128
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xF59A3FF6(4120526838)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 4, flow_id: Motorola SEC 2.0:4, crypto map: Tunnel2-head-0
sa timing: remaining key lifetime (k/sec): (4387273/3492)
IV size: 16 bytes
replay detection support: Y replay window size: 128
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
```
Pour chaque interface du tunnel, vous devez voir `inbound esp sas` et `outbound esp sas`. En supposant qu'une SA soit répertoriée (`spi: 0xF95D2F3C`par exemple) et `Status` qu'`ACTIVE`elle IPsec soit correctement configurée.
Pour un dépannage plus approfondi, exécutez les commandes suivantes pour activer le débogage.
```
router# debug crypto ipsec
```
Utilisez la commande suivante pour désactiver le débogage.
```
router# no debug crypto ipsec
```
## Tunnel
Tout d'abord, vérifiez que les règles de pare-feu nécessaires sont instaurées. Pour de plus amples informations, veuillez consulter [Règles de pare-feu pour un dispositif de passerelle AWS Site-to-Site VPN client](FirewallRules.md).
Si vos règles de pare-feu sont correctement configurées, alors continuez le dépannage avec la commande suivante.
```
router# show interfaces tun1
```
```
Tunnel1 is up, line protocol is up
Hardware is Tunnel
Internet address is 169.254.255.2/30
MTU 17867 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 2/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 174.78.144.73, destination 72.21.209.225
Tunnel protocol/transport IPSEC/IP
Tunnel TTL 255
Tunnel transport MTU 1427 bytes
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Tunnel protection via IPSec (profile "ipsec-vpn-92df3bfb-0")
Last input never, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 1 packets/sec
5 minute output rate 1000 bits/sec, 1 packets/sec
407 packets input, 30010 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
```
Assurez-vous que le `line protocol` est opérationnel. Vérifiez que l'adresse IP source du tunnel, l'interface source et la destination correspondent respectivement à la configuration du tunnel pour l'adresse IP externe de la passerelle client, pour l'interface et pour l'adresse IP externe de la passerelle réseau privé virtuel. Assurez-vous que `Tunnel protection via IPSec` est présent. Assurez-vous d'exécuter la commande sur les deux interfaces du tunnel. Pour résoudre les éventuels problèmes, vérifiez la configuration et les connexions physiques à votre passerelle client.
Utilisez également la commande suivante, en remplaçant `169.254.255.1` par l'adresse IP interne de votre passerelle réseau privé virtuel.
```
router# ping 169.254.255.1 df-bit size 1410
```
```
Type escape sequence to abort.
Sending 5, 1410-byte ICMP Echos to 169.254.255.1, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
```
Vous devez voir 5 points d'exclamation.
Pour un dépannage plus approfondi, passez en revue la configuration.
## BGP
Utilisez la commande suivante de l’.
```
router# show ip bgp summary
```
```
BGP router identifier 192.168.37.160, local AS number 65000
BGP table version is 8, main routing table version 8
2 network entries using 312 bytes of memory
2 path entries using 136 bytes of memory
3/1 BGP path/bestpath attribute entries using 444 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 1 (at peak 2) using 32 bytes of memory
BGP using 948 total bytes of memory
BGP activity 4/1 prefixes, 4/1 paths, scan interval 15 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
169.254.255.1 4 7224 363 323 8 0 0 00:54:21 1
169.254.255.5 4 7224 364 323 8 0 0 00:00:24 1
```
Les deux voisins doivent être répertoriés. Pour chacun d'entre eux, vous devez voir la valeur `1` pour `State/PfxRcd`.
Si l'appairage BGP est opérationnel, vérifiez que votre routeur de passerelle client publie la route par défaut (0.0.0.0/0) vers le VPC.
```
router# show bgp all neighbors 169.254.255.1 advertised-routes
```
```
For address family: IPv4 Unicast
BGP table version is 3, local router ID is 174.78.144.73
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Originating default network 0.0.0.0
Network Next Hop Metric LocPrf Weight Path
*> 10.120.0.0/16 169.254.255.1 100 0 7224 i
Total number of prefixes 1
```
En outre, assurez-vous de recevoir le préfixe correspondant à votre VPC depuis la passerelle réseau privé virtuel.
```
router# show ip route bgp
```
```
10.0.0.0/16 is subnetted, 1 subnets
B 10.255.0.0 [20/0] via 169.254.255.1, 00:00:20
```
Pour un dépannage plus approfondi, passez en revue la configuration.
# Résoudre les problèmes de AWS Site-to-Site VPN connectivité avec un dispositif de passerelle client Cisco IOS sans le protocole Border Gateway
Lorsque vous dépannez la connectivité d'un périphérique de passerelle client Cisco, tenez compte de trois éléments : IKE et tunnel. IPsec 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.
```
router# show crypto isakmp sa
```
```
IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
174.78.144.73 205.251.233.121 QM_IDLE 2001 0 ACTIVE
174.78.144.73 205.251.233.122 QM_IDLE 2002 0 ACTIVE
```
Vous devez voir une ou plusieurs lignes contenant une valeur `src` pour la passerelle à distance spécifiée dans les tunnels. `state` doit être `QM_IDLE` 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 indique qu'un dispositif de passerelle client IPsec est correctement configuré.
```
router# show crypto ipsec sa
```
```
interface: Tunnel1
Crypto map tag: Tunnel1-head-0, local addr 174.78.144.73
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 72.21.209.225 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 149, #pkts encrypt: 149, #pkts digest: 149
#pkts decaps: 146, #pkts decrypt: 146, #pkts verify: 146
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 174.78.144.73, remote crypto endpt.:205.251.233.121
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0
current outbound spi: 0xB8357C22(3090512930)
inbound esp sas:
spi: 0x6ADB173(112046451)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 1, flow_id: Motorola SEC 2.0:1, crypto map: Tunnel1-head-0
sa timing: remaining key lifetime (k/sec): (4467148/3189)
IV size: 16 bytes
replay detection support: Y replay window size: 128
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xB8357C22(3090512930)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2, flow_id: Motorola SEC 2.0:2, crypto map: Tunnel1-head-0
sa timing: remaining key lifetime (k/sec): (4467148/3189)
IV size: 16 bytes
replay detection support: Y replay window size: 128
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
interface: Tunnel2
Crypto map tag: Tunnel2-head-0, local addr 205.251.233.122
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 72.21.209.193 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 26, #pkts encrypt: 26, #pkts digest: 26
#pkts decaps: 24, #pkts decrypt: 24, #pkts verify: 24
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 174.78.144.73, remote crypto endpt.:205.251.233.122
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0
current outbound spi: 0xF59A3FF6(4120526838)
inbound esp sas:
spi: 0xB6720137(3060924727)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 3, flow_id: Motorola SEC 2.0:3, crypto map: Tunnel2-head-0
sa timing: remaining key lifetime (k/sec): (4387273/3492)
IV size: 16 bytes
replay detection support: Y replay window size: 128
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xF59A3FF6(4120526838)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 4, flow_id: Motorola SEC 2.0:4, crypto map: Tunnel2-head-0
sa timing: remaining key lifetime (k/sec): (4387273/3492)
IV size: 16 bytes
replay detection support: Y replay window size: 128
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
```
Pour chaque interface du tunnel, vous devez voir un `esp sas` entrant et un `esp sas` sortant. Cela suppose qu'une SA est répertoriée (par exemple,`spi: 0x48B456A6`), que son statut est `ACTIVE` correct et qu'elle IPsec est correctement configurée.
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
```
## Tunnel
Tout d'abord, vérifiez que les règles de pare-feu nécessaires sont instaurées. Pour de plus amples informations, veuillez consulter [Règles de pare-feu pour un dispositif de passerelle AWS Site-to-Site VPN client](FirewallRules.md).
Si vos règles de pare-feu sont correctement configurées, alors continuez le dépannage avec la commande suivante.
```
router# show interfaces tun1
```
```
Tunnel1 is up, line protocol is up
Hardware is Tunnel
Internet address is 169.254.249.18/30
MTU 17867 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 2/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 174.78.144.73, destination 205.251.233.121
Tunnel protocol/transport IPSEC/IP
Tunnel TTL 255
Tunnel transport MTU 1427 bytes
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Tunnel protection via IPSec (profile "ipsec-vpn-92df3bfb-0")
Last input never, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 1 packets/sec
5 minute output rate 1000 bits/sec, 1 packets/sec
407 packets input, 30010 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
```
Assurez-vous que le protocole de ligne est opérationnel. Vérifiez que l'adresse IP source du tunnel, l'interface source et la destination correspondent respectivement à la configuration du tunnel pour l'adresse IP externe de la passerelle client, pour l'interface et pour l'adresse IP externe de la passerelle réseau privé virtuel. Assurez-vous que `Tunnel protection through IPSec` est présent. Assurez-vous d'exécuter la commande sur les deux interfaces du tunnel. Pour résoudre les éventuels problèmes, vérifiez la configuration et les connexions physiques à votre passerelle client.
Vous pouvez également utiliser la commande suivante, en remplaçant `169.254.249.18` par l'adresse IP interne de votre passerelle réseau privé virtuel.
```
router# ping 169.254.249.18 df-bit size 1410
```
```
Type escape sequence to abort.
Sending 5, 1410-byte ICMP Echos to 169.254.249.18, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
```
Vous devez voir 5 points d'exclamation.
### Routage
Pour voir votre table de routage statique, utilisez la commande suivante.
```
router# sh ip route static
```
```
1.0.0.0/8 is variably subnetted
S 10.0.0.0/16 is directly connected, Tunnel1
is directly connected, Tunnel2
```
Vous devez voir que la route statique existe pour le CIDR du VPC via deux tunnels. Si elle n'existe pas, ajoutez les routes statiques comme suit:
```
router# ip route 10.0.0.0 255.255.0.0 Tunnel1 track 100
router# ip route 10.0.0.0 255.255.0.0 Tunnel2 track 200
```
### Vérification du moniteur SLA
```
router# show ip sla statistics 100
```
```
IPSLAs Latest Operation Statistics
IPSLA operation id: 100
Latest RTT: 128 milliseconds
Latest operation start time: *18:08:02.155 UTC Wed Jul 15 2012
Latest operation return code: OK
Number of successes: 3
Number of failures: 0
Operation time to live: Forever
```
```
router# show ip sla statistics 200
```
```
IPSLAs Latest Operation Statistics
IPSLA operation id: 200
Latest RTT: 128 milliseconds
Latest operation start time: *18:08:02.155 UTC Wed Jul 15 2012
Latest operation return code: OK
Number of successes: 3
Number of failures: 0
Operation time to live: Forever
```
La valeur de `Number of successes` indique si le moniteur SLA a bien été configuré.
Pour un dépannage plus approfondi, passez en revue la configuration.
# Résoudre les problèmes AWS Site-to-Site VPN de connectivité avec un dispositif de passerelle client Juniper JunOS
Lorsque vous dépannez la connectivité d'un dispositif de passerelle client Juniper, tenez compte de quatre éléments : IKE IPsec, tunnel et BGP. 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.
```
user@router> show security ike security-associations
```
```
Index Remote Address State Initiator cookie Responder cookie Mode
4 72.21.209.225 UP c4cd953602568b74 0d6d194993328b02 Main
3 72.21.209.193 UP b8c8fb7dc68d9173 ca7cb0abaedeb4bb Main
```
Vous devez voir une ou plusieurs lignes contenant une adresse à distance de la passerelle à distance spécifiée dans les tunnels. `State` doit être `UP`. L'absence d'une entrée, ou toute entrée dans un état différent (comme `DOWN`), indique qu'IKE n'est pas correctement configuré.
Pour un dépannage plus approfondi, autorisez les options de suivi IKE, comme recommandé dans l'exemple de fichier de configuration. Exécutez ensuite la commande suivante pour imprimer différents messages de débogage sur l'écran.
```
user@router> monitor start kmd
```
Depuis un hôte externe, vous pouvez récupérer le fichier journal complet avec la commande suivante.
```
scp username@router.hostname:/var/log/kmd
```
## IPsec
Utilisez la commande suivante de l’. La réponse indique qu'un dispositif de passerelle client IPsec est correctement configuré.
```
user@router> show security ipsec security-associations
```
```
Total active tunnels: 2
ID Gateway Port Algorithm SPI Life:sec/kb Mon vsys
<131073 72.21.209.225 500 ESP:aes-128/sha1 df27aae4 326/ unlim - 0
>131073 72.21.209.225 500 ESP:aes-128/sha1 5de29aa1 326/ unlim - 0
<131074 72.21.209.193 500 ESP:aes-128/sha1 dd16c453 300/ unlim - 0
>131074 72.21.209.193 500 ESP:aes-128/sha1 c1e0eb29 300/ unlim - 0
```
Vous devez notamment voir au moins deux lignes par adresse de passerelle (correspondant à la passerelle à distance). Notez les carets au début de chaque ligne (< >) qui indiquent la direction du trafic pour une entrée en particulier. Le résultat comporte des lignes séparées pour le trafic entrant (« < », trafic de la passerelle réseau privé virtuel vers la passerelle client) et le trafic sortant (« > »).
Pour un dépannage plus approfondi, autorisez les options de suivi IKE (pour plus d'informations, consultez la section précédente sur l'IKE).
## Tunnel
Tout d'abord, vérifiez que les règles de pare-feu nécessaires sont instaurées. Pour obtenir la liste des règles, consultez [Règles de pare-feu pour un dispositif de passerelle AWS Site-to-Site VPN client](FirewallRules.md).
Si vos règles de pare-feu sont correctement configurées, alors continuez le dépannage avec la commande suivante.
```
user@router> show interfaces st0.1
```
```
Logical interface st0.1 (Index 70) (SNMP ifIndex 126)
Flags: Point-To-Point SNMP-Traps Encapsulation: Secure-Tunnel
Input packets : 8719
Output packets: 41841
Security: Zone: Trust
Allowed host-inbound traffic : bgp ping ssh traceroute
Protocol inet, MTU: 9192
Flags: None
Addresses, Flags: Is-Preferred Is-Primary
Destination: 169.254.255.0/30, Local: 169.254.255.2
```
Assurez-vous que la `Security: Zone` est correcte, et que l'adresse `Local` correspond à l'adresse interne du tunnel de la passerelle client.
Ensuite, utilisez la commande suivante, en remplaçant `169.254.255.1` par l'adresse IP interne de votre passerelle réseau privé virtuel. Vos résultats doivent ressembler à la réponse présentée ici.
```
user@router> ping 169.254.255.1 size 1382 do-not-fragment
```
```
PING 169.254.255.1 (169.254.255.1): 1410 data bytes
64 bytes from 169.254.255.1: icmp_seq=0 ttl=64 time=71.080 ms
64 bytes from 169.254.255.1: icmp_seq=1 ttl=64 time=70.585 ms
```
Pour un dépannage plus approfondi, passez en revue la configuration.
## BGP
Exécutez la commande suivante.
```
user@router> show bgp summary
```
```
Groups: 1 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 2 1 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
169.254.255.1 7224 9 10 0 0 1:00 1/1/1/0 0/0/0/0
169.254.255.5 7224 8 9 0 0 56 0/1/1/0 0/0/0/0
```
Pour un dépannage plus approfondi, utilisez la commande suivante, en remplaçant `169.254.255.1` par l'adresse IP interne de votre passerelle réseau privé virtuel.
```
user@router> show bgp neighbor 169.254.255.1
```
```
Peer: 169.254.255.1+179 AS 7224 Local: 169.254.255.2+57175 AS 65000
Type: External State: Established Flags:
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ EXPORT-DEFAULT ]
Options:
Holdtime: 30 Preference: 170 Local AS: 65000 Local System AS: 0
Number of flaps: 0
Peer ID: 169.254.255.1 Local ID: 10.50.0.10 Active Holdtime: 30
Keepalive Interval: 10 Peer index: 0
BFD: disabled, down
Local Interface: st0.1
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 7224)
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 1
Received prefixes: 1
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 1
Last traffic (seconds): Received 4 Sent 8 Checked 4
Input messages: Total 24 Updates 2 Refreshes 0 Octets 505
Output messages: Total 26 Updates 1 Refreshes 0 Octets 582
Output Queue[0]: 0
```
Ici, vous devez voir `Received prefixes` et `Advertised prefixes` avec la valeur 1 pour chacun de ces champs. Ils doivent se trouver dans la section `Table inet.0`.
Si `State` n'est pas `Established`, vérifiez `Last State` et `Last Error` pour plus de détails sur ce que vous devez faire pour corriger le problème.
Si l'appairage BGP est opérationnel, vérifiez que votre routeur de passerelle client publie la route par défaut (0.0.0.0/0) vers le VPC.
```
user@router> show route advertising-protocol bgp 169.254.255.1
```
```
inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 0.0.0.0/0 Self I
```
En outre, assurez-vous de recevoir le préfixe correspondant à votre VPC depuis la passerelle réseau privé virtuel.
```
user@router> show route receive-protocol bgp 169.254.255.1
```
```
inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.110.0.0/16 169.254.255.1 100 7224 I
```
# Résoudre les problèmes de AWS Site-to-Site VPN connectivité avec un dispositif de passerelle client Juniper ScreenOS
Lorsque vous dépannez la connectivité d'un dispositif de passerelle client basé sur Juniper Screenos, tenez compte de quatre éléments : IKE IPsec, tunnel et BGP. 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 et IPsec
Utilisez la commande suivante de l’. La réponse montre une passerelle client avec IKE configuré correctement.
```
ssg5-serial-> get sa
```
```
total configured sa: 2
HEX ID Gateway Port Algorithm SPI Life:sec kb Sta PID vsys
00000002< 72.21.209.225 500 esp:a128/sha1 80041ca4 3385 unlim A/- -1 0
00000002> 72.21.209.225 500 esp:a128/sha1 8cdd274a 3385 unlim A/- -1 0
00000001< 72.21.209.193 500 esp:a128/sha1 ecf0bec7 3580 unlim A/- -1 0
00000001> 72.21.209.193 500 esp:a128/sha1 14bf7894 3580 unlim A/- -1 0
```
Vous devez voir une ou plusieurs lignes contenant une adresse à distance de la passerelle à distance spécifiée dans les tunnels. La valeur de `Sta` doit être `A/-`, et `SPI` doit être un nombre hexadécimal autre que `00000000`. Des entrées dans un état différent indiquent que l'IKE n'est pas correctement configuré.
Pour un dépannage plus approfondi, autorisez les options de suivi IKE, comme recommandé dans l'exemple de fichier de configuration.
## Tunnel
Tout d'abord, vérifiez que les règles de pare-feu nécessaires sont instaurées. Pour obtenir la liste des règles, consultez [Règles de pare-feu pour un dispositif de passerelle AWS Site-to-Site VPN client](FirewallRules.md).
Si vos règles de pare-feu sont correctement configurées, alors continuez le dépannage avec la commande suivante.
```
ssg5-serial-> get interface tunnel.1
```
```
Interface tunnel.1:
description tunnel.1
number 20, if_info 1768, if_index 1, mode route
link ready
vsys Root, zone Trust, vr trust-vr
admin mtu 1500, operating mtu 1500, default mtu 1500
*ip 169.254.255.2/30
*manage ip 169.254.255.2
route-deny disable
bound vpn:
IPSEC-1
Next-Hop Tunnel Binding table
Flag Status Next-Hop(IP) tunnel-id VPN
pmtu-v4 disabled
ping disabled, telnet disabled, SSH disabled, SNMP disabled
web disabled, ident-reset disabled, SSL disabled
OSPF disabled BGP enabled RIP disabled RIPng disabled mtrace disabled
PIM: not configured IGMP not configured
NHRP disabled
bandwidth: physical 0kbps, configured egress [gbw 0kbps mbw 0kbps]
configured ingress mbw 0kbps, current bw 0kbps
total allocated gbw 0kbps
```
Assurez-vous de voir `link:ready` et que l'adresse `IP` correspond à l'adresse interne du tunnel de la passerelle client.
Ensuite, utilisez la commande suivante, en remplaçant `169.254.255.1` par l'adresse IP interne de votre passerelle réseau privé virtuel. Vos résultats doivent ressembler à la réponse présentée ici.
```
ssg5-serial-> ping 169.254.255.1
```
```
Type escape sequence to abort
Sending 5, 100-byte ICMP Echos to 169.254.255.1, timeout is 1 seconds
!!!!!
Success Rate is 100 percent (5/5), round-trip time min/avg/max=32/32/33 ms
```
Pour un dépannage plus approfondi, passez en revue la configuration.
## BGP
Exécutez la commande suivante.
```
ssg5-serial-> get vrouter trust-vr protocol bgp neighbor
```
```
Peer AS Remote IP Local IP Wt Status State ConnID Up/Down
--------------------------------------------------------------------------------
7224 169.254.255.1 169.254.255.2 100 Enabled ESTABLISH 10 00:01:01
7224 169.254.255.5 169.254.255.6 100 Enabled ESTABLISH 11 00:00:59
```
L'état des deux homologues BGP doit être `ESTABLISH`, ce qui signifie que la connexion BGP à la passerelle réseau privé virtuel est active.
Pour un dépannage plus approfondi, utilisez la commande suivante, en remplaçant `169.254.255.1` par l'adresse IP interne de votre passerelle réseau privé virtuel.
```
ssg5-serial-> get vr trust-vr prot bgp neigh 169.254.255.1
```
```
peer: 169.254.255.1, remote AS: 7224, admin status: enable
type: EBGP, multihop: 0(disable), MED: node default(0)
connection state: ESTABLISH, connection id: 18 retry interval: node default(120s), cur retry time 15s
configured hold time: node default(90s), configured keepalive: node default(30s)
configured adv-interval: default(30s)
designated local IP: n/a
local IP address/port: 169.254.255.2/13946, remote IP address/port: 169.254.255.1/179
router ID of peer: 169.254.255.1, remote AS: 7224
negotiated hold time: 30s, negotiated keepalive interval: 10s
route map in name: , route map out name:
weight: 100 (default)
self as next hop: disable
send default route to peer: disable
ignore default route from peer: disable
send community path attribute: no
reflector client: no
Neighbor Capabilities:
Route refresh: advertised and received
Address family IPv4 Unicast: advertised and received
force reconnect is disable
total messages to peer: 106, from peer: 106
update messages to peer: 6, from peer: 4
Tx queue length 0, Tx queue HWM: 1
route-refresh messages to peer: 0, from peer: 0
last reset 00:05:33 ago, due to BGP send Notification(Hold Timer Expired)(code 4 : subcode 0)
number of total successful connections: 4
connected: 2 minutes 6 seconds
Elapsed time since last update: 2 minutes 6 seconds
```
Si l'appairage BGP est opérationnel, vérifiez que votre routeur de passerelle client publie la route par défaut (0.0.0.0/0) vers le VPC. Cette commande s'applique au ScreenOS 6.2.0 et version plus récente.
```
ssg5-serial-> get vr trust-vr protocol bgp rib neighbor 169.254.255.1 advertised
```
```
i: IBGP route, e: EBGP route, >: best route, *: valid route
Prefix Nexthop Wt Pref Med Orig AS-Path
--------------------------------------------------------------------------------------
>i 0.0.0.0/0 0.0.0.0 32768 100 0 IGP
Total IPv4 routes advertised: 1
```
En outre, assurez-vous de recevoir le préfixe correspondant à votre VPC depuis la passerelle réseau privé virtuel. Cette commande s'applique au ScreenOS 6.2.0 et version plus récente.
```
ssg5-serial-> get vr trust-vr protocol bgp rib neighbor 169.254.255.1 received
```
```
i: IBGP route, e: EBGP route, >: best route, *: valid route
Prefix Nexthop Wt Pref Med Orig AS-Path
--------------------------------------------------------------------------------------
>e* 10.0.0.0/16 169.254.255.1 100 100 100 IGP 7224
Total IPv4 routes received: 1
```
# Résoudre les problèmes AWS Site-to-Site VPN de connectivité avec un dispositif de passerelle client Yamaha
Lorsque vous dépannez la connectivité d'un dispositif de passerelle client Yamaha, tenez compte de quatre éléments : IKE IPsec, tunnel et BGP. 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.
**Note**
Le`proxy ID` paramètre utilisé dans la phase 2 d'IKE est désactivé par défaut sur le routeur Yamaha. Cela peut entraîner des problèmes de connexion au Site-to-Site VPN. Si le n'`proxy ID`est pas configuré sur votre routeur, veuillez consulter le fichier d'exemple de configuration AWS fourni pour que Yamaha le configure correctement.
## IKE
Exécutez la commande suivante. La réponse montre une passerelle client avec IKE configuré correctement.
```
# show ipsec sa gateway 1
```
```
sgw flags local-id remote-id # of sa
--------------------------------------------------------------------------
1 U K YOUR_LOCAL_NETWORK_ADDRESS 72.21.209.225 i:2 s:1 r:1
```
Vous devez voir une ligne contenant une valeur de `remote-id` pour la passerelle à distance spécifiée dans les tunnels. Vous pouvez répertorier toutes les associations de sécurité (SAs) en omettant le numéro du tunnel.
Pour un dépannage plus approfondi, exécutez les commandes suivantes pour permettre la consignation des messages de niveau DEBUG qui apportent des informations de diagnostic.
```
# syslog debug on
# ipsec ike log message-info payload-info key-info
```
Pour annuler les éléments enregistrés, utilisez la commande suivante.
```
# no ipsec ike log
# no syslog debug on
```
## IPsec
Exécutez la commande suivante. La réponse indique qu'un dispositif de passerelle client IPsec est correctement configuré.
```
# show ipsec sa gateway 1 detail
```
```
SA[1] Duration: 10675s
Local ID: YOUR_LOCAL_NETWORK_ADDRESS
Remote ID: 72.21.209.225
Protocol: IKE
Algorithm: AES-CBC, SHA-1, MODP 1024bit
SPI: 6b ce fd 8a d5 30 9b 02 0c f3 87 52 4a 87 6e 77
Key: ** ** ** ** ** (confidential) ** ** ** ** **
----------------------------------------------------
SA[2] Duration: 1719s
Local ID: YOUR_LOCAL_NETWORK_ADDRESS
Remote ID: 72.21.209.225
Direction: send
Protocol: ESP (Mode: tunnel)
Algorithm: AES-CBC (for Auth.: HMAC-SHA)
SPI: a6 67 47 47
Key: ** ** ** ** ** (confidential) ** ** ** ** **
----------------------------------------------------
SA[3] Duration: 1719s
Local ID: YOUR_LOCAL_NETWORK_ADDRESS
Remote ID: 72.21.209.225
Direction: receive
Protocol: ESP (Mode: tunnel)
Algorithm: AES-CBC (for Auth.: HMAC-SHA)
SPI: 6b 98 69 2b
Key: ** ** ** ** ** (confidential) ** ** ** ** **
----------------------------------------------------
SA[4] Duration: 10681s
Local ID: YOUR_LOCAL_NETWORK_ADDRESS
Remote ID: 72.21.209.225
Protocol: IKE
Algorithm: AES-CBC, SHA-1, MODP 1024bit
SPI: e8 45 55 38 90 45 3f 67 a8 74 ca 71 ba bb 75 ee
Key: ** ** ** ** ** (confidential) ** ** ** ** **
----------------------------------------------------
```
Pour chaque interface du tunnel, vous devez voir `receive sas` et `send sas`.
Pour un dépannage plus approfondi, exécutez les commandes suivantes pour activer le débogage.
```
# syslog debug on
# ipsec ike log message-info payload-info key-info
```
Utilisez la commande suivante pour désactiver le débogage.
```
# no ipsec ike log
# no syslog debug on
```
## Tunnel
Tout d'abord, vérifiez que les règles de pare-feu nécessaires sont instaurées. Pour obtenir la liste des règles, consultez [Règles de pare-feu pour un dispositif de passerelle AWS Site-to-Site VPN client](FirewallRules.md).
Si vos règles de pare-feu sont correctement configurées, alors continuez le dépannage avec la commande suivante.
```
# show status tunnel 1
```
```
TUNNEL[1]:
Description:
Interface type: IPsec
Current status is Online.
from 2011/08/15 18:19:45.
5 hours 7 minutes 58 seconds connection.
Received: (IPv4) 3933 packets [244941 octets]
(IPv6) 0 packet [0 octet]
Transmitted: (IPv4) 3933 packets [241407 octets]
(IPv6) 0 packet [0 octet]
```
Assurez-vous que la `current status` valeur est en ligne et c'`Interface type`est le cas IPsec. Assurez-vous d'exécuter la commande sur les deux interfaces du tunnel. Pour résoudre tout problème se présentant ici, passez en revue la configuration.
## BGP
Exécutez la commande suivante.
```
# show status bgp neighbor
```
```
BGP neighbor is 169.254.255.1, remote AS 7224, local AS 65000, external link
BGP version 0, remote router ID 0.0.0.0
BGP state = Active
Last read 00:00:00, hold time is 0, keepalive interval is 0 seconds
Received 0 messages, 0 notifications, 0 in queue
Sent 0 messages, 0 notifications, 0 in queue
Connection established 0; dropped 0
Last reset never
Local host: unspecified
Foreign host: 169.254.255.1, Foreign port: 0
BGP neighbor is 169.254.255.5, remote AS 7224, local AS 65000, external link
BGP version 0, remote router ID 0.0.0.0
BGP state = Active
Last read 00:00:00, hold time is 0, keepalive interval is 0 seconds
Received 0 messages, 0 notifications, 0 in queue
Sent 0 messages, 0 notifications, 0 in queue
Connection established 0; dropped 0
Last reset never
Local host: unspecified
Foreign host: 169.254.255.5, Foreign port:
```
Les deux voisins doivent être répertoriés. Pour chacun d'entre eux, vous devez voir la valeur `Active` pour `BGP state`.
Si l'appairage BGP est opérationnel, vérifiez que votre routeur de passerelle client publie la route par défaut (0.0.0.0/0) vers le VPC.
```
# show status bgp neighbor 169.254.255.1 advertised-routes
```
```
Total routes: 1
*: valid route
Network Next Hop Metric LocPrf Path
* default 0.0.0.0 0 IGP
```
En outre, assurez-vous de recevoir le préfixe correspondant à votre VPC depuis la passerelle réseau privé virtuel.
```
# show ip route
```
```
Destination Gateway Interface Kind Additional Info.
default ***.***.***.*** LAN3(DHCP) static
10.0.0.0/16 169.254.255.1 TUNNEL[1] BGP path=10124
```