Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Solucione problemas de AWS Site-to-Site VPN conectividad con un dispositivo de puerta de enlace para clientes JunOS de Juniper
Cuando solucione los problemas de conectividad de un dispositivo de pasarela de cliente de Juniper, tenga en cuenta cuatro aspectos: IKE IPsec, túnel y BGP. Puede solucionar problemas en estas áreas en cualquier orden, pero recomendamos empezar por IKE (en la parte inferior de stack de red) y continuar de forma ascendente.
## IKE
Use el siguiente comando. La respuesta mostrará un dispositivo de gateway de cliente con el IKE configurado correctamente.
```
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
```
Debería ver una o varias líneas que contienen una dirección remota de la gateway remota especificada en los túneles. El valor de `State` debería ser `UP`. La ausencia de entradas o la aparición de una entrada con otro estado (como `DOWN`) indican que IKE no se ha configurado correctamente.
Para realizar una solución de problemas más profunda, habilite las opciones de seguimiento de IKE, según lo recomendado en el archivo de configuración de ejemplo. A continuación, ejecute el siguiente comando para imprimir diversos mensajes de depuración en la pantalla.
```
user@router> monitor start kmd
```
Desde un host externo, puede recuperar el archivo completo de log con el siguiente comando.
```
scp username@router.hostname:/var/log/kmd
```
## IPsec
Use el siguiente comando. La respuesta muestra un dispositivo de pasarela de cliente configurado correctamente. IPsec
```
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
```
En concreto, debería ver al menos dos líneas por dirección de gateway (correspondientes a la gateway remota). Los signos de intercalación al principio de cada línea (< >) indican la dirección del tráfico de la entrada en particular. El resultado son líneas separadas para el tráfico entrante ("<", tráfico de la gateway privada virtual a ese dispositivo de gateway de cliente) y el tráfico saliente (">").
Para realizar una solución de problemas más profunda, habilite las opciones de seguimiento de IKE (para obtener más información, consulte la sección anterior acerca de IKE).
## Túnel
En primer lugar, vuelva a comprobar si tiene las reglas de firewall necesarias aplicadas. Para obtener una lista de reglas, consulte [Reglas de firewall para un dispositivo de puerta de enlace del AWS Site-to-Site VPN cliente](FirewallRules.md).
Si sus reglas de firewall están configuradas correctamente, continúe realizando la solución de problemas con el siguiente comando.
```
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
```
Asegúrese de que el valor de `Security: Zone` es correcto y de que la dirección de `Local` coincide con el túnel del dispositivo de gateway de cliente dentro de la dirección.
A continuación, utilice el siguiente comando, reemplazando `169.254.255.1` por la dirección IP interna de su gateway privada virtual. Sus resultados deberían ser parecidos a la respuesta que se muestra aquí.
```
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
```
Para una solución de problemas más profunda, revise la configuración.
## BGP
Ejecute el comando siguiente.
```
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
```
Para una solución de problemas más profunda, utilice el siguiente comando, reemplazando `169.254.255.1` por la dirección IP interna de su gateway privada virtual.
```
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
```
Aquí debería ver `Received prefixes` y `Advertised prefixes` enumerados en 1 cada uno. Esto debería encontrarse en la sección `Table inet.0`.
Si el valor de `State` no es `Established`, compruebe `Last State` y `Last Error` para ver los detalles de lo que se necesita para corregir el problema.
Si el intercambio de tráfico BGP está activado, compruebe si el dispositivo de gateway de cliente indica la ruta predeterminada (0.0.0.0/0) a la 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
```
Asimismo, asegúrese de estar recibiendo el prefijo correspondiente a su VPC desde la gateway privada virtual.
```
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
```