Solucionar problemas comuns de GETVPN

Introduction

Este documento descreve quais depurações coletar para a maioria dos problemas comuns de VPN de transporte criptografado por grupo (GETVPN).

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

• GETVPN
• Uso do Servidor Syslog

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

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. If your network is live, make sure that you understand the potential impact of any command.

Informações gerais - Ferramentas de identificação e solução de problemas de GETVPN

O GETVPN fornece um amplo conjunto de ferramentas de solução de problemas para facilitar o processo de solução de problemas. É importante entender quais dessas ferramentas estão disponíveis e quando são adequadas para cada tarefa de solução de problemas. Ao solucionar problemas, é sempre uma boa ideia começar com os métodos menos intrusivos, para que o ambiente de produção não seja afetado negativamente. Para ajudar nesse processo, esta seção descreve algumas das ferramentas mais usadas disponíveis:

Ferramentas de Depuração do Plano de Controle

comandos show

Os comandos show são comumente usados para mostrar operações de tempo de execução em um ambiente GETVPN.

Syslogs

O GETVPN tem um conjunto aprimorado de mensagens de syslog para eventos de protocolo significativos e condições de erro. Esse deve ser sempre o primeiro lugar a ser observado antes de executar qualquer depuração.

Rastreamento de evento do domínio de grupo da interpretação (GDOI)

Este recurso foi adicionado na versão 15.1(3)T. O rastreamento de eventos oferece rastreamento leve e sempre ativo para eventos e erros GDOI significativos. Há também o rastreamento de caminho de saída com o retorno de rastreamento ativado para condições de exceção.

Depurações condicionais do GDOI

Este recurso foi adicionado na versão 15.1(3)T. Ele permite depurações filtradas para um determinado dispositivo com base no endereço do peer e deve ser sempre usado quando possível, especialmente no Servidor de chaves.

Depurações globais de criptografia e GDOI

Essas são todas as várias depurações do GETVPM. Os administradores devem ter cuidado ao depurar em ambientes de grande escala. Com depurações GDOI, cinco níveis de depuração são fornecidos para maior granularidade de depuração:

GM1#debug crypto gdoi gm rekey ?
  all-levels  All levels
  detail      Detail level
  error       Error level
  event       Event level
  packet      Packet level
  terse       Terse level

Nível de Depuração	O que você receberá
Erro	Condições de erro
Terse	Mensagens importantes para o usuário e problemas de protocolo
Evento	Transições de estado e eventos como rechaves de envio e recebimento
Detalhe	Informações mais detalhadas sobre a mensagem de depuração
Pacote	Inclui o despejo de informações detalhadas do pacote
Todos	Todas as anteriores

Ferramentas de Depuração do Plano de Dados

Aqui estão algumas ferramentas de depuração de plano de dados:

• Listas de acesso
• Contabilidade de precedência de IP
• Netflow
• Contadores de interface
• Contadores de criptografia
• Contadores de queda global e por recurso do IP Cisco Express Forwarding (CEF)
• Captura de pacote incorporado (EPC)
• Depurações do plano de dados (pacote IP e depurações CEF)

Troubleshoot

Preparação da instalação de registro e outras práticas recomendadas

Antes de começar a solucionar o problema, certifique-se de ter preparado o recurso de registro conforme descrito aqui. Algumas práticas recomendadas também estão listadas aqui:

• Verifique a quantidade de memória livre do roteador e configure o logging buffered debugging para um valor grande (10 MB ou mais, se possível).
  
  
• Desative o registro nos servidores de console, monitor e syslog.
  
  
• Recupere o conteúdo do buffer de registro com o comando show log em intervalos regulares, a cada 20 minutos a uma hora, para evitar perda de log devido à reutilização do buffer.
  
  
• O que quer que aconteça, insira o comando show tech dos membros do grupo afetados (GMs) e dos servidores-chave (KSs) e examine a saída do comando show ip route no global e cada Virtual Routing and Forwarding (VRF) envolvido, se houver necessidade.
  
  
• Use o Network Time Protocol (NTP) para sincronizar o relógio entre todos os dispositivos que são depurados. Habilite os timestamps de milissegundo (msec) para mensagens de depuração e registro:
  

  service timestamps debug datetime msec
  service timestamps log datetime msec

  
  
  
• Certifique-se de que as saídas do comando show estejam marcadas por tempo.
  

  Router#terminal exec prompt timestamp

  
  
  
• Quando você coleta saídas do comando show para eventos do plano de controle ou contadores do plano de dados, sempre coleta várias iterações da mesma saída.

Identificar e Solucionar Problemas do Estabelecimento de IKE

Quando o processo de registro começa, os GMs e KSs negociam sessões de Internet Key Exchange (IKE) para proteger o tráfego GDOI.

• No GM, verifique se o IKE foi estabelecido com êxito:
  

  gm1#show crypto isakmp sa
  IPv4 Crypto ISAKMP SA
  dst             src             state          conn-id status
  172.16.1.9      172.16.1.1      GDOI_REKEY        1068 ACTIVE
  172.16.1.1      172.16.1.9      GDOI_IDLE         1067 ACTIVE

  
  

  Note: O estado GDOI_IDLE, que é a base do registro, expira rapidamente e desaparece, porque não é mais necessário após o registro inicial.

  
  
  
• No KS, você deve ver:
  

  ks1#show crypto isakmp sa
  IPv4 Crypto ISAKMP SA
  dst             src             state          conn-id status
  172.16.1.1      172.16.1.9      GDOI_IDLE         1001 ACTIVE

  
  

  Note: A sessão de rechaveamento é exibida somente quando necessário no KS.

  
  
  

Siga estes passos se você não atingir esse estado:

• Para obter informações sobre a causa da falha, verifique a saída desse comando:

  router# show crypto isakmp statistics

• Se a etapa anterior não for útil, você poderá obter informações no nível do protocolo se habilitar as depurações IKE comuns:

  router# debug crypto isakmp

  Notas:
  * Embora o IKE seja usado, ele não é usado na porta UDP/500 normal, mas sim no UDP/848.
  * Se você encontrar um problema nesse nível, forneça as depurações para o KS e o GM afetado.

  
  
  
• Devido à dependência dos sinais Rivest-Shamir-Adleman (RSA) para os rechaveamentos de grupo, o KS deve ter uma chave RSA configurada e deve ter o mesmo nome do especificado na configuração de grupo.
  
  Para verificar isso, insira este comando:
  
  

  ks1# show crypto key mypubkey rsa

Solucionar problemas do registro inicial

No GM, para verificar o status do registro, examine a saída deste comando:

gm1# show crypto gdoi | i Registration status
       Registration status  : Registered
gm1#

Se a saída indicar algo diferente de Registered, insira estes comandos:

Nos GMs:

• Desative as interfaces ativadas por criptografia.
  

  Caution: Espera-se que o gerenciamento fora de banda esteja habilitado.

  
  
  
• Ative estas depurações:
  

  gm1# debug crypto gdoi infra packet
  gm1# debug crypto gdoi gm packet

  
  
  
• Ative as depurações no lado do KS (consulte a próxima seção).
  
  
• Quando as depurações do KS estiverem prontas, desative as interfaces ativadas por criptografia e aguarde o registro (para acelerar o processo, emita o comando clear crypto gdoi no GM).

No KSs:

• Verifique a presença da chave RSA no KS:
  

  ks1# show crypto key mypubkey rsa

  
  
  
• Ative estas depurações:
  

  ks1# debug crypto gdoi infra packet
  ks1# debug crypto gdoi ks packet 

Solucionar problemas relacionados à política

O problema de política ocorre antes do registro (relacionado à política de falha de fechamento)

Esse problema afeta apenas os GMs, portanto, reúna essa saída do GM:

gm1# show crypto ruleset

Note: No Cisco IOS-XE^?, essa saída está sempre vazia, já que a classificação do pacote não foi feita no software.

A saída do comando show tech do dispositivo afetado fornece o resto das informações necessárias.

Problema de política Ocorre no registro POST e pertence à política global enviada

Geralmente, há duas maneiras de este problema se manifestar:

• O KS não pode levar as políticas para a GM.
• Existe uma aplicação parcial da política entre os OGM.

Para ajudar a solucionar qualquer problema, faça o seguinte:

1. No GM afetado, colete esta saída:
   

   gm1# show crypto gdoi acl 
   gm1# show crypto ruleset

   
   
   
2. Ative essas depurações no GM:
   

   gm1# debug crypto gdoi infra packet 
   gm1# debug crypto gdoi gm acls packet

   
   
   
3. No KS ao qual a GM afetada se registra, recolher esta saída:
   

   ks1# show crypto gdoi ks members
   ks1# show crypto gdoi ks policy

   
   
   

   Note: Para identificar a qual KS o GM se conecta, insira o comando show crypto gdoi group.

   
   
   
4. No mesmo KS, ative estas depurações:
   

   ks1# debug crypto gdoi infra packet
   ks1# debug crypto gdoi ks acls packet

   
   
   
5. Force o GM a se registrar com esse comando no GM:
   

   clear crypto gdoi

Problema de política ocorre no registro POST e diz respeito à mesclagem de política global e substituições locais

Esse problema geralmente se manifesta na forma de mensagens que indicam que um pacote criptografado foi recebido para o qual as políticas locais indicam que ele não deve ser criptografado e vice-versa. Todos os dados solicitados na seção anterior e a saída do comando show tech são necessários nesse caso.

Solucionar problemas de reinicialização

Nos GMs:

• Colete estas depurações:
  

  gm1# debug crypto gdoi infra packet 
  gm1# debug crypto gdoi gm packet 
  gm1# debug crypto gdoi gm rekey packet 

  
  
  
• Insira este comando para verificar se o GM ainda tem uma Associação de Segurança IKE (SA) do tipo GDOI_REKEY:
  

  gm1# show crypto isakmp sa

No KSs:

• Colete a saída do comando show crypto key mypubkey rsa de CADA KS. Espera-se que as chaves sejam idênticas.
  
  
• Insira estas depurações para ver o que ocorre no KS:
  

  ks1# debug crypto gdoi infra packet 
  ks1# debug crypto gdoi ks packet 
  ks1# debug crypto gdoi ks rekey packet 

Solução de problemas de reprodução de tempo (TBAR)

O recurso TBAR exige a manutenção de tempo entre os grupos e, portanto, exige que os relógios de pseudotempo dos GMs sejam constantemente sincronizados. Isso é feito durante a chave ou a cada duas horas, o que ocorrer primeiro.

Note: Todas as saídas e depurações devem ser coletadas ao mesmo tempo de GMs e KS para que possam ser correlacionadas adequadamente.

Para investigar problemas que ocorrem nesse nível, colete essa saída.

• Nos GMs:
  

  gm1# show crypto gdoi 
  gm1# show crypto gdoi replay

  
  
  
• No KS:
  

  ks1# show crypto gdoi ks members 
  ks1# show crypto gdoi ks replay

Para investigar a manutenção de tempo do TBAR de uma forma mais dinâmica, habilite estas depurações:

• Sobre o GM:
  

  gm1# debug crypto gdoi gm rekey packet 
  gm1# debug crypto gdoi replay packet (verbosity might need to be lowered)

  
  
  
• No KS:
  

  ks1# debug crypto gdoi ks rekey packet
  ks1# debug crypto gdoi replay packet (verbosity might need to be lowered)

A partir do Cisco IOS versão 15.2(3)T, a capacidade de registrar erros TBAR foi adicionada, o que facilita a detecção desses erros. No GM, use este comando para verificar se há erros de TBAR:

R103-GM#show crypto gdoi gm replay
Anti-replay Information For Group GETVPN:
  Timebased Replay:
    Replay Value             : 512.11 secs
    Input Packets            : 0        Output Packets           : 0
    Input Error Packets    : 0        Output Error Packets   : 0
    Time Sync Error         : 0        Max time delta            : 0.00secs

TBAR Error History (sampled at 10pak/min):
    No TBAR errors detected

Para obter mais informações sobre como solucionar problemas de TBAR, consulte Falha de antirrepetição baseada em tempo.

Solucionar problemas de redundância KS

Cooperative (COOP) estabelece uma sessão IKE para proteger a comunicação entre KSs, portanto a técnica de solução de problemas descrita anteriormente para o estabelecimento IKE também é aplicável aqui.

A solução de problemas específicos de COOP inclui verificações de saída desse comando em todos os KS envolvidos:

ks# show crypto gdoi ks coop

Note: O erro mais comum cometido com a implantação de KSs COOP é esquecer de importar a mesma chave RSA (privada e pública) para o grupo em todos os KSs. Isso causa problemas durante os rechaveamentos. Para verificar e comparar chaves públicas entre KSs, compare a saída do comando show crypto key mypubkey rsa de cada KS.

Se a solução de problemas em nível de protocolo for necessária, ative essa depuração em todos os KS envolvidos:

ks# debug crypto gdoi ks coop packet

FAQ

Por que você vê esta mensagem de erro "% Configurando a autenticação de chave rejeitada"?

Esta mensagem de erro é exibida quando você configura o KS depois que esta linha é adicionada:

KS(gdoi-local-server)#rekey authentication mypubkey rsa GETVPN_KEYS
% Setting rekey authentication rejected.

A razão para esta mensagem de erro geralmente é porque a chave GETVPN_KEYS não existe. Para corrigir isso, crie uma chave com o rótulo correto usando o comando:

crypto key generate rsa mod <modulus> label <label_name> 

Note: Adicione a palavra-chave exportável no final se esta for uma implantação COOP e importe a mesma chave no outro KS

Um roteador configurado como KS para um grupo GETVPN também pode funcionar como um GM para o mesmo grupo?

Não. Todas as implantações de GETVPN exigem um KS dedicado que não pode participar como um GM para os mesmos grupos. Este recurso não é suportado, porque a adição da funcionalidade GM ao KS com todas as interações possíveis, como criptografia, roteamento, QoS, etc., não é ideal para a integridade deste dispositivo de rede crucial. Ele deve estar sempre disponível para que toda a implantação de GETVPN funcione.

Informações Relacionadas

• Group Encrypted Transport VPN (GET VPN) - Cisco Systems
• Suporte Técnico e Documentação - Cisco Systems