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é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
```