O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve como solucionar os problemas mais comuns de túneis de segurança de protocolo Internet (IPsec) para dispositivos de terceiros com Internet Key Exchange versão 2 (IKEv2) configurada. Mais comumente referenciado como Túneis de Serviço/Transporte na documentação do Cisco SD-WAN. Este documento também explica como habilitar e ler depurações de IKE e associá-las à troca de pacotes para entender o ponto de falha em uma negociação de IPsec.
A Cisco recomenda que você tenha conhecimento destes tópicos:
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Cada pacote IKE contém informações de payload para o estabelecimento do túnel. O glossário IKE explica as abreviações mostradas nesta imagem como parte do conteúdo da carga útil para a troca de pacotes.
Note: É importante verificar em que troca de pacotes da negociação IKE o túnel IPsec não consegue analisar rapidamente qual configuração está envolvida para resolver o problema de forma eficaz.
Note: Este documento não descreve mais profundamente a troca de pacotes IKEv2. Para obter mais referências, navegue até IKEv2 Packet Exchange e Protocol Level Debugging
É necessário correlacionar a configuração do vEdge com a configuração do Cisco IOS® XE. Além disso, é útil combinar os conceitos de IPsec e o conteúdo de payload para trocas de pacotes IKEv2 como mostrado na imagem.
Note: Cada parte da configuração modifica um aspecto da troca de negociação IKE. É importante correlacionar os comandos à negociação de protocolo de IPsec.
No vEdges debug iked habilita as informações de nível de depuração de IKEv1 ou IKEv2.
debug iked misc high
debug iked event high
É possível exibir as informações de depuração atuais no vshell e executar o comando tail -f <debug path>.
vshell
tail -f /var/log/message
Na CLI, também é possível exibir os logs/informações de depuração atuais do caminho especificado.
monitor start /var/log/messages
É possível separar três cenários IPsec diferentes. É um bom ponto de referência para identificar o sintoma para ter uma melhor abordagem para saber como começar.
Para que o túnel IPsec não estabeleça sintomas, é necessário depurar em tempo real para verificar qual é o comportamento atual na negociação de IKE.
Para o túnel IPsec caiu e foi restabelecido em seus próprios sintomas, mais comumente conhecido como túnel Flapped e a análise da causa raiz (RCA) é necessária. É indispensável saber o timestamp quando o túnel caiu ou ter um tempo estimado para examinar as depurações.
Para o túnel IPsec desligado e permanece em sintomas de estado de inatividade, significa que o túnel funcionou antes, mas por qualquer motivo, ele desceu e precisamos saber o motivo do desligamento e o comportamento atual que impede que o túnel seja estabelecido com sucesso novamente.
Identifique os pontos antes do início da solução de problemas:
Todas as depurações e registros são salvos em arquivos /var/log/messages, para os registros atuais, eles são salvos no arquivo de mensagens, mas para esse sintoma específico, o flap pode ser identificado horas/dias após o problema, provavelmente as depurações relacionadas estariam em mensagens1, 2, 3, etc. É importante saber o timestamp para examinar o arquivo de mensagem correto e analisar as depurações (charon) para a negociação IKE do túnel IPsec relacionado.
A maioria das depurações não imprime o número do túnel IPsec. A maneira mais frequente de identificar a negociação e os pacotes é com o endereço IP do peer remoto e o endereço IP onde o túnel é originado na borda. Alguns exemplos de depurações de IKE impressas:
Jun 18 00:31:22 vedge01 charon: 09[CFG] vici initiate 'child_IPsec2_1'
Jun 18 00:31:22 vedge01 charon: 16[IKE] initiating IKE_SA ipsec2_1[223798] to 10.10.10.1
Jun 18 00:31:22 vedge01 charon: 16[IKE] initiating IKE_SA ipsec2_1[223798] to 10.10.10.1
As depurações da negociação IKE INIT mostram o número do túnel IPsec. Entretanto, as informações subsequentes para troca de pacotes usam apenas os endereços IP do túnel IPsec.
Jun 18 00:31:22 vedge01 charon: 09[CFG] vici initiate 'child_ipsec2_1'
Jun 18 00:31:22 vedge01 charon: 16[IKE] initiating IKE_SA ipsec2_1[223798] to 10.10.10.1
Jun 18 00:31:22 vedge01 charon: 16[IKE] initiating IKE_SA ipsec2_1[223798] to 10.10.10.1
Jun 18 00:31:22 vedge01 charon: 16[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Jun 18 00:31:22 vedge01 charon: 16[NET] sending packet: from 10.132.3.92[500] to 10.10.10.1[500] (464 bytes)
Jun 18 00:31:22 vedge01 charon: 12[NET] received packet: from 10.10.10.1[500] to 10.132.3.92[500] (468 bytes)
Jun 18 00:31:22 vedge01 charon: 12[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HTTP_CERT_LOOK) N(FRAG_SUP) V ]
Jun 18 00:31:22 vedge01 charon: 12[ENC] received unknown vendor ID: 4f:85:58:17:1d:21:a0:8d:69:cb:5f:60:9b:3c:06:00
Jun 18 00:31:22 vedge01 charon: 12[IKE] local host is behind NAT, sending keep alives
Configuração de túnel IPsec:
interface ipsec2
ip address 192.168.1.9/30
tunnel-source 10.132.3.92
tunnel-destination 10.10.10.1
dead-peer-detection interval 30
ike
version 2
rekey 86400
cipher-suite aes256-cbc-sha1
group 14
authentication-type
pre-shared-key
pre-shared-secret $8$wgrs/Cw6tX0na34yF4Fga0B62mGBpHFdOzFaRmoYfnBioWVO3s3efFPBbkaZqvoN
!
!
!
ipsec
rekey 3600
replay-window 512
cipher-suite aes256-gcm
perfect-forward-secrecy group-14
!
Como o problema pode ser a primeira implementação para o túnel, ele não foi ativado e as depurações de IKE são a melhor opção.
Como mencionado anteriormente, geralmente esse sintoma é endereçado para saber a causa raiz do motivo pelo qual o túnel caiu. Com a análise da causa básica conhecida, às vezes, o administrador da rede evita mais problemas.
Identifique os pontos antes do início da solução de problemas:
Neste exemplo, o túnel caiu em 18 de junho às 00:31:17.
Jun 18 00:31:17 vedge01 FTMD[1472]: %Viptela-vedge01-FTMD-6-INFO-1000001: VPN 1 Interface ipsec2 DOWN
Jun 18 00:31:17 vedge01 FTMD[1472]: %Viptela-vedge01-ftmd-6-INFO-1400002: Notification: interface-state-change severity-level:major host-name:"vedge01" system-ip:4.0.5.1 vpn-id:1 if-name:"ipsec2" new-state:down
Note: Os registros para o túnel IPsec inativo não fazem parte de depurações ligadas, são registros FTMD. Portanto, nem charon nem IKE seriam impressos.
Note: Os registros relacionados geralmente não são impressos em conjunto, há mais informações entre eles não relacionadas ao mesmo processo.
Etapa 1. Depois que o carimbo de data/hora for identificado e a hora e os registros estiverem correlacionados, comece a revisar os registros de baixo para cima.
Jun 18 00:31:17 vedge01 charon: 11[IKE] giving up after 3 retransmits
Jun 18 00:28:22 vedge01 charon: 08[IKE] retransmit 3 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2)
Jun 18 00:28:22 vedge01 charon: 08[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)
Jun 18 00:26:45 vedge01 charon: 06[IKE] retransmit 2 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2)
Jun 18 00:26:45 vedge01 charon: 06[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)
Jun 18 00:25:21 vedge01 charon: 08[IKE] sending DPD request
Jun 18 00:25:21 vedge01 charon: 08[ENC] generating INFORMATIONAL request 543 [ ]
Jun 18 00:25:21 vedge01 charon: 08[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)
Jun 18 00:25:51 vedge01 charon: 05[IKE] retransmit 1 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2)
Jun 18 00:25:51 vedge01 charon: 05[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)
A última troca de pacotes DPD bem-sucedida é descrita como solicitação nº 542.
Jun 18 00:24:08 vedge01 charon: 11[ENC] generating INFORMATIONAL request 542 [ ]
Jun 18 00:24:08 vedge01 charon: 11[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)
Jun 18 00:24:08 vedge01 charon: 07[NET] received packet: from 13.51.17.190[4500] to 10.10.10.1[4500] (76 bytes)
Jun 18 00:24:08 vedge01 charon: 07[ENC] parsed INFORMATIONAL response 542 [ ]
Etapa 2. Junte todas as informações na ordem correta:
Jun 18 00:24:08 vedge01 charon: 11[ENC] generating INFORMATIONAL request 542 [ ]
Jun 18 00:24:08 vedge01 charon: 11[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)
Jun 18 00:24:08 vedge01 charon: 07[NET] received packet: from 10.10.10.1[4500] to 10.132.3.92[4500] (76 bytes)
Jun 18 00:24:08 vedge01 charon: 07[ENC] parsed INFORMATIONAL response 542 [ ]
Jun 18 00:25:21 vedge01 charon: 08[IKE] sending DPD request
Jun 18 00:25:21 vedge01 charon: 08[ENC] generating INFORMATIONAL request 543 [ ]
Jun 18 00:25:21 vedge01 charon: 08[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)
Jun 18 00:25:51 vedge01 charon: 05[IKE] retransmit 1 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2)
Jun 18 00:25:51 vedge01 charon: 05[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)
Jun 18 00:26:45 vedge01 charon: 06[IKE] retransmit 2 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2)
Jun 18 00:26:45 vedge01 charon: 06[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)
Jun 18 00:28:22 vedge01 charon: 08[IKE] retransmit 3 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2)
Jun 18 00:28:22 Lvedge01 charon: 08[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)
Jun 18 00:31:17 vedge01 charon: 11[IKE] giving up after 3 retransmits
Jun 18 00:31:17 vedge01 FTMD[1472]: %Viptela-LONDSR01-FTMD-6-INFO-1000001: VPN 1 Interface ipsec2 DOWN
Jun 18 00:31:17 vedge01 FTMD[1472]: %Viptela-LONDSR01-ftmd-6-INFO-1400002: Notification: interface-state-change severity-level:major host-name:"LONDSR01" system-ip:4.0.5.1 vpn-id:1 if-name:"ipsec2" new-state:down
Para o exemplo descrito, o túnel cai devido ao vEdge01 não receber os pacotes DPD de 10.10.10.1. Ele é esperado após 3 retransmissões DPD, o peer IPsec é definido como "perdido" e o túnel é desativado. Há várias razões para esse comportamento, geralmente, ele está relacionado ao ISP onde os pacotes são perdidos ou descartados no caminho. Se o problema ocorrer uma vez, não há como rastrear o tráfego perdido, no entanto, se o problema persistir, o pacote poderá ser rastreado com o uso de capturas no vEdge, no peer remoto de IPSec e no ISP.
Como mencionado anteriormente neste sintoma, o túnel funcionava normalmente, mas por qualquer razão, desceu e o túnel não pôde ser estabelecido novamente com sucesso. Nesse cenário, há um efeito na rede.
identifique os pontos antes do início da solução de problemas:
Neste exemplo, a solução de problemas não começa com o carimbo de data e hora quando o túnel cai. À medida que o problema persiste, as depurações de IKE são a melhor opção.
interface ipsec1
description VWAN_VPN
ip address 192.168.0.101/30
tunnel-source-interface ge0/0
tunnel-destination 10.10.10.1
ike
version 2
rekey 28800
cipher-suite aes256-cbc-sha1
group 2
authentication-type
pre-shared-key
pre-shared-secret "$8$njK2pLLjgKWNQu0KecNtY3+fo3hbTs0/7iJy6unNtersmCGjGB38kIPjsoqqXZdVmtizLu79\naQdjt2POM242Yw=="
!
!
!
ipsec
rekey 3600
replay-window 512
cipher-suite aes256-cbc-sha1
perfect-forward-secrecy group-16
!
mtu 1400
no shutdown
O campo debug iked está ativado e a negociação é exibida.
daemon.info: Apr 27 05:12:56 vedge01 charon: 16[NET] received packet: from 10.10.10.1[4500] to 172.28.0.36[4500] (508 bytes)
daemon.info: Apr 27 05:12:56 vedge01 charon: 16[ENC] parsed CREATE_CHILD_SA request 557 [ SA No TSi TSr ]
daemon.info: Apr 27 05:12:56 vedge01 charon: 16[CFG] received proposals: ESP:AES_GCM_16_256/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA2_256_128/NO_EXT_SEQ
daemon.info: Apr 27 05:12:56 vedge01 charon: 16[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_4096/NO_EXT_SEQ
daemon.info: Apr 27 05:12:56 vedge01 charon: 16[IKE] no acceptable proposal found
daemon.info: Apr 27 05:12:56 vedge01 charon: 16[IKE] failed to establish CHILD_SA, keeping IKE_SA
daemon.info: Apr 27 05:12:56 vedge01 charon: 16[ENC] generating CREATE_CHILD_SA response 557 [ N(NO_PROP) ]
daemon.info: Apr 27 05:12:56 vedge01 charon: 16[NET] sending packet: from 172.28.0.36[4500] to 10.10.10.1[4500] (76 bytes)
daemon.info: Apr 27 05:12:57 vedge01 charon: 08[NET] received packet: from 10.10.10.1[4500] to 172.28.0.36[4500] (76 bytes)
daemon.info: Apr 27 05:12:57 vedge01 charon: 08[ENC] parsed INFORMATIONAL request 558 [ ]
daemon.info: Apr 27 05:12:57 vedge01 charon: 08[ENC] generating INFORMATIONAL response 558 [ ]
daemon.info: Apr 27 05:12:57 vedge01 charon: 08[NET] sending packet: from 172.28.0.36[4500] to 10.10.10.1[4500] (76 bytes)
daemon.info: Apr 27 05:12:58 vedge01 charon: 07[NET] received packet: from 10.10.10.1[4500] to 172.28.0.36[4500] (396 bytes)
daemon.info: Apr 27 05:12:58 vedge01 charon: 07[ENC] parsed CREATE_CHILD_SA request 559 [ SA No TSi TSr ]
daemon.info: Apr 27 05:12:58 vedge01 charon: 07[CFG] received proposals: ESP:AES_GCM_16_256/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA2_256_128/NO_EXT_SEQ
daemon.info: Apr 27 05:12:58 vedge01 charon: 07[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_4096/NO_EXT_SEQ
daemon.info: Apr 27 05:12:58 Avedge01 charon: 07[IKE] no acceptable proposal found
daemon.info: Apr 27 05:12:58 vedge01 charon: 07[IKE] failed to establish CHILD_SA, keeping IKE_SA
Observação: os pacotes CREATE_CHILD_SA são trocados por cada chave nova ou SA nova. Para obter mais referências, navegue até Understanding IKEv2 Packet Exchange (Compreendendo o Intercâmbio de Pacotes IKEv2)
As depurações de IKE mostram o mesmo comportamento e são repetidas constantemente, de modo que é possível pegar uma parte das informações e analisá-las:
CREATE_CHILD_SA significa um rechaveamento, com a finalidade de que o novo SPIS seja gerado e trocado entre os endpoints IPsec.
Neste ponto, a questão é: Por que há uma incompatibilidade de configuração se o túnel funcionou anteriormente e nenhuma alteração foi feita?
Analisar profundamente, há um campo extra nas propostas configuradas que o peer não está enviando.
propostas configuradas: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_4096/NO_EXT_SEQ
Propostas recebidas:
ESP:AES_GCM_16_256/NO_EXT_SEQ,
ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ,
ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ,
ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ,
ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ,
ESP:3DES_CBC/HMAC_SHA2_256_128/NO_EXT_SEQ
MODP_4096 é o grupo DH 16, que as bordas configuraram para PFS (perfeito para encaminhamento de sigilo) na fase 2 (seção IPsec).
O PFS é a única configuração de incompatibilidade na qual o túnel pode ser estabelecido com êxito ou não de acordo com quem é o iniciador ou respondente na negociação IKE. No entanto, quando a chave rekey inicia, o túnel não pode continuar e esse sintoma pode ser apresentado ou relacionado a ele.
Consulte o bug da Cisco ID CSCvx86427 para obter mais informações sobre esse comportamento.
Conforme o problema persiste, as depurações de IKE são as melhores opções. No entanto, para esse bug específico se as depurações estiverem habilitadas, nenhuma informação será exibida nem no terminal nem no arquivo de mensagem.
Para reduzir esse problema e verificar se o vEdge atinge o bug da Cisco ID CSCvx86427, é necessário encontrar o momento em que o túnel cai.
identifique os pontos antes do início da solução de problemas:
Depois que o carimbo de data/hora for identificado e o tempo e os registros estiverem correlacionados, revise os registros logo antes de quando o túnel cair.
Apr 13 22:05:21 vedge01 charon: 12[IKE] received DELETE for IKE_SA ipsec1_1[217]
Apr 13 22:05:21 vedge01 charon: 12[IKE] deleting IKE_SA ipsec1_1[217] between 10.16.0.5[10.16.0.5]...10.10.10.1[10.10.10.1]
Apr 13 22:05:21 vedge01 charon: 12[IKE] deleting IKE_SA ipsec1_1[217] between 10.16.0.5[10.16.0.5]...10.10.10.1[10.10.10.1]
Apr 13 22:05:21 vedge01 charon: 12[IKE] IKE_SA deleted
Apr 13 22:05:21 vedge01 charon: 12[IKE] IKE_SA deleted
Apr 13 22:05:21 vedge01 charon: 12[ENC] generating INFORMATIONAL response 4586 [ ]
Apr 13 22:05:21 vedge01 charon: 12[NET] sending packet: from 10.16.0.5[4500] to 10.10.10.1[4500] (80 bytes)
Apr 13 22:05:21 vedge01 charon: 12[KNL] Deleting SAD entry with SPI 00000e77
Apr 13 22:05:21 vedge01 FTMD[1269]: %Viptela-AZGDSR01-FTMD-6-INFO-1000001: VPN 1 Interface ipsec1 DOWN
Apr 13 22:05:21 vedge01 FTMD[1269]: %Viptela-AZGDSR01-ftmd-6-INFO-1400002: Notification: interface-state-change severity-level:major host-name:"vedge01" system-ip:4.1.0.1 vpn-id:1 if-name:"ipsec1" new-state:down
Observação: há vários pacotes DELETES em uma negociação IPsec e DELETE para CHILD_SA é uma DELETE esperada para um processo REKEY, esse problema é visto quando um pacote IKE_SA DELETE puro é recebido sem nenhuma negociação IPsec específica. Essa EXCLUSÃO remove todo o túnel IPsec/IKE.
Revisão | Data de publicação | Comentários |
---|---|---|
2.0 |
18-Nov-2021 |
Adicionando mais informações ao documento |
1.0 |
29-Sep-2021 |
Versão inicial |