View a markdown version of this page

Solução de problemas AWS Site-to-Site VPN conectividade com um dispositivo Juniper JunoS Customer Gateway - AWS Site-to-Site VPN

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Solução de problemas AWS Site-to-Site VPN conectividade com um dispositivo Juniper JunoS Customer Gateway

Ao solucionar um problema de conectividade em um dispositivo gateway do cliente da Juniper, considere quatro fatores: IKE, IPsec túnel e BGP. É possível solucionar problemas nessas áreas em qualquer sequência, mas é recomendável começar pelo IKE (na parte inferior da pilha de rede) e seguir em frente.

IKE

Use o seguinte comando. A resposta mostra um dispositivo de gateway do cliente com o IKE configurado corretamente.

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

Você deve ver uma ou mais linhas contendo um endereço remoto do gateway remoto especificado nos túneis. O State deve ser UP. A ausência de uma entrada, ou de qualquer entrada em outro estado (como DOWN), indica que o IKE não está configurado apropriadamente.

Para solucionar outros problemas, habilite as opções de rastreamento de IKE, conforme recomendado no arquivo de configuração de exemplo. Em seguida, execute o comando a seguir para imprimir na tela uma variedade de mensagens de depuração.

user@router> monitor start kmd

Em um host externo, é possível recuperar o arquivo de log completo com o comando a seguir.

scp username@router.hostname:/var/log/kmd

IPsec

Use o seguinte comando. A resposta mostra um gateway do cliente com o IPsec configurado corretamente.

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

Mais especificamente, você deve ver pelo menos duas linhas por endereço de gateway (correspondentes ao gateway remoto). Os operadores maior e menor no início de cada linha (< >) indicam a direção do tráfego para a entrada específica. A saída tem linhas distintas para tráfego de entrada ("<", tráfego do gateway privado virtual para esse dispositivo de gateway do cliente) e tráfego de saída (">").

Para solucionar outros problemas, habilite as opções de rastreamento de IKE (para obter mais informações, consulte a seção precedente sobre IKE).

Túnel

Primeiro, verifique novamente se você implementou as regras de firewall necessárias. Para obter uma lista de regras, consulte Regras de firewall para um AWS Site-to-Site VPN dispositivo de gateway do cliente.

Se as regras de firewall estiverem configuradas corretamente, dê prosseguimento à solução de problemas com o comando a seguir.

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

Verifique se Security: Zone está correto e se o endereço Local corresponde ao túnel do dispositivo de gateway do cliente dentro do endereço.

Em seguida, use o comando a seguir e substitua 169.254.255.1 pelo endereço IP interno de seu gateway privado virtual. Os resultados devem ser semelhantes à resposta mostrada aqui.

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 solucionar outros problemas, revise a configuração.

BGP

Execute o seguinte comando.

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 solucionar outros problemas, use o comando a seguir e substitua 169.254.255.1 pelo endereço IP interno de seu gateway privado 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: <ImportEval Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ EXPORT-DEFAULT ] Options: <Preference HoldTime PeerAS LocalAS Refresh> 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

Aqui você deve visualizar Received prefixes e Advertised prefixes listados com 1. Isso dever estar dentro da seção Table inet.0.

Se o State não for Established, verifique o Last State e o Last Error para obter detalhes sobre o que é necessário para corrigir o problema.

Se o peering do BGP estiver ativo, verifique se o dispositivo de gateway do cliente está anunciando a rota padrão (0.0.0). 0/0) para o 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

Além disso, verifique se você está recebendo o prefixo que corresponde à VPC do gateway privado 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