Guia de solução de problemas de GETVPN

Introduction

O objetivo deste documento é apresentar uma metodologia de solução de problemas estruturada e ferramentas úteis para ajudar a identificar e isolar problemas de VPN de transporte criptografado por grupo (GETVPN) e fornecer possíveis soluções.

Prerequisites

Requirements

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

• GETVPN
  Guia de configuração de GETVPN oficial
  Guia oficial de projeto e implementação da 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.

Metodologia de solução de problemas de GETVPN

Assim como a maioria dos problemas de tecnologia complexa, a chave é poder isolar o problema em um recurso específico, subsistema ou componente. A solução GETVPN é composta por vários componentes de recursos, especificamente:

• Internet Key Exchange (IKE) - Usado entre membro do grupo (GM) e servidor chave (KS), e entre KSs de protocolo cooperativo (COOP) para autenticar e proteger o plano de controle.
• Group Domain of Interpretation (GDOI) - Protocolo usado para o KS a fim de distribuir chaves de grupo e fornecer serviços-chave como a chave para todos os GMs.
• COOP - Protocolo usado para os KSs a fim de se comunicar e fornecer redundância.
• Preservação de cabeçalho - IPsec no modo de túnel que preserva o cabeçalho do pacote de dados original para a entrega de tráfego fim-a-fim.
• TBAR (Time-Based Anti-Replay) - Mecanismo de detecção de repetição usado em um ambiente de chave de grupo.

Ele também 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. A chave para essa solução de problemas estruturada é poder dividir o problema em um problema de controle ou plano de dados. Você pode fazer isso se seguir o protocolo ou o fluxo de dados e usar as várias ferramentas apresentadas aqui para fazer a verificação.

Topologia de referência

Essa topologia e esquema de endereçamento GETVPN são usados no restante deste documento de solução de problemas.

Configurações de referência

• KS1
  
  

  crypto gdoi group G1
   identity number 3333
   server local
    rekey authenmypubkeyrsa get
    rekey transport unicast
    sa ipsec 1
     profile gdoi-p
     match address ipv4ENCPOL
    address ipv4 10.1.11.2
    redundancy
     local priority 10
     peer address ipv4 10.1.12.2

• GM1
  
  

  crypto gdoi group G1
   identity number 3333
   server address ipv4 10.1.11.2
   server address ipv4 10.1.12.2
  !
  crypto map gm_map 10 gdoi
   set group G1
  !
  interface Serial1/0
   crypto map gm_map

Note: As configurações de KS2 e GM2 não estão incluídas aqui para brevidade.

Terminology

• KS - Servidor de chaves
• GM - Membro do grupo
• COOP - Protocolo de Cooperação
• TBAR - Antirrepetição baseada em tempo
• KEK - Chave de criptografia
• TEK - Chave de criptografia de tráfego

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 GMs e KSs afetados e examine a saída do comando show ip route em 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.

Solucionar problemas do plano de controle GETVPN

Plano de controle significa todos os eventos de protocolo que levaram à criação da Associação de Segurança (SA) e da política no GM para que eles estejam prontos para criptografar e descriptografar o tráfego do plano de dados. Alguns dos principais pontos de verificação no plano de controle GETVPN são:

Práticas recomendadas de depuração do plano de controle

Essas práticas recomendadas de solução de problemas não são específicas de GETVPN; aplicam-se a quase todos os debugging do plano de controle. É fundamental seguir essas práticas recomendadas para garantir a solução de problemas mais eficaz:

• Desative o registro do console e use o buffer de registro ou syslog para coletar as depurações.
• Use o NTP para sincronizar os relógios dos roteadores em todos os dispositivos que são depurados.
• Habilitar o timestamping msec para mensagens de depuração e log:
  

  service timestamp debug datetime msec
  service timestamp log datetime msec

• Certifique-se de que as saídas do comando show estejam marcadas com o tempo para que possam ser correlacionadas com a saída do comando debug:
  

   terminal exec prompt timestamp

• Use a depuração condicional em um ambiente de escala, se possível.

Ferramentas de identificação e solução de problemas do plano de controle GETVPN

Comandos show do GETVPN

Como regra geral, essas são as saídas de comando que você deve coletar para quase todos os problemas de GETVPN.

KS

show crypto gdoi
show crypto gdoi ks coop
show crypto gdoi ks members
show crypto gdoi ks rekey
show crypto gdoi ks policy

GM

show crypto eli
show crypto gdoi rekey sa
show crypto gdoi
show crypto gdoi gm
show crypto gdoi gm rekey

Mensagens de Syslog GETVPN

O GETVPN fornece um amplo conjunto de mensagens de syslog para eventos de protocolo significativos e condições de erro. O syslog deve ser sempre o primeiro lugar a ser observado ao executar a solução de problemas de GETVPN.

Mensagens de syslog KS comuns

Mensagens de syslog	Explicação
COOP_CONFIG_MISMATCH	A configuração entre o servidor de chave primária e o servidor de chave secundária não tem correspondência.
COOP_KS_ELECTION	O servidor de chaves local entrou no processo de eleição em um grupo.
COOP_KS_REACH	A acessibilidade entre os servidores de chave cooperativa configurados é restaurada.
COOP_KS_TRANS_TO_PRI	O servidor de chaves local fez a transição para uma função primária de ser um servidor secundário em um grupo.
COOP_KS_UNAUTH	Um servidor remoto autorizado tentou entrar em contato com o servidor de chaves local em um grupo, o que pode ser considerado um evento hostil.
COOP_KS_UNREACH	A acessibilidade entre os servidores de chave cooperativa configurados é perdida, o que pode ser considerado um evento hostil.
KS_GM_REVOKED	Durante o protocolo de rechaveamento, um membro não autorizado tentou ingressar em um grupo, o que pode ser considerado um evento hostil.
KS_SEND_MCAST_REKEY	Enviando chave multicast.
KS_SEND_UNICAST_REKEY	Enviando chave unicast.
KS_NÃO AUTORIZADO	Durante o protocolo de registro GDOI, um membro não autorizado tentou ingressar em um grupo, o que pode ser considerado um evento hostil.
UNAUTHORIZED_IPADDR	A solicitação de registro foi removida porque o dispositivo solicitante não estava autorizado a ingressar no grupo.

   

Mensagens Syslog GM comuns

Mensagens de syslog	Explicação
GM_CLEAR_REGISTER	O comando clear crypto gdoi foi executado pelo membro do grupo local.
GM_CM_ATTACH	Um mapa de criptografia foi anexado para o membro do grupo local.
GM_CM_DETACH	Um mapa de criptografia foi desanexado para o membro do grupo local.&
GM_RE_REGISTER	SA IPsec criada para um grupo pode ter expirado ou sido apagada. É necessário registrar novamente no servidor de chaves.
GM_RECV_REKEY	Recriação recebida.
GM_REGS_COMPL	Registro concluído.
GM_REKEY_TRANS_2_MULTI	O membro do grupo passou do uso de um mecanismo de chave de unicast para o uso de um mecanismo de multicast.
GM_REKEY_TRANS_2_UNI	O membro do grupo passou do uso de um mecanismo de chave de transmissão múltipla para o uso de um mecanismo de unicast.
PSEUDO_TIME_LARGE	Um membro do grupo recebeu um pseudotempo com um valor que é amplamente diferente de seu próprio pseudotempo.
REPARAR_FALHADO	Um membro do grupo ou servidor de chaves falhou em uma verificação antirepetição.

Note: As mensagens destacadas em vermelho são as mais comuns ou significativas vistas em um ambiente GETVPN.

Depurações globais de criptografia e GDOI

As depurações de GETVPN são divididas:

1. Primeiro pelo dispositivo no qual você está solucionando problemas.

   F340.06.15-2900-18#debug cry gdoi ?
     all-features  All features in GDOI
     condition     GDOI Conditional Debugging
     gm            Group Member
     ks            Key Server

2. Segundo pelo tipo de problema que você está solucionando.

   GM1#debug cry gdoi gm ?
     all-features    All Group Member features
     infrastructure  GM Infrastructure
     registration    GM messages related to registration
     rekey           GM messagese related to Re-Key
     replay          Anti Replay

3. Terceiro pelo nível de depuração que precisa ser ativado. Na versão 15.1(3)T e posterior, todas as depurações de recursos GDOI foram padronizadas para ter esses níveis de depuração. Isso foi projetado para ajudar a solucionar problemas de ambientes GETVPN de grande escala com granularidade de depuração suficiente. Ao depurar problemas de GETVPN, é importante usar o nível de depuração apropriado. Como regra geral, comece com o nível de depuração mais baixo, que é o nível de erro, e aumente a granularidade da depuração quando necessário.

   GM1#debug cry gdoi gm all-features ?
     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

Depuração Condicional GDOI

No Cisco IOS^® versão 15.1(3)T e posterior, a depuração condicional de GDOI foi adicionada para ajudar a solucionar problemas de GETVPN em um ambiente de grande escala. Assim, todas as depurações de Internet Security Association and Key Management Protocol (ISAKMP) e GDOI podem agora ser disparadas com um filtro condicional baseado no endereço IP do grupo ou do peer. Para a maioria dos problemas de GETVPN, é bom habilitar as depurações de ISAKMP e GDOI com o filtro condicional apropriado, já que as depurações de GDOI mostram apenas operações específicas de GDOI. Para usar as depurações condicionais ISAKMP e GDOI, faça o seguinte:

1. Defina o filtro condicional.
2. Ative o ISAKMP e o GDOI relevantes como de costume.

Por exemplo:

KS1# debug crypto gdoi condition peer add ipv4 10.1.20.2
% GDOI Debug Condition added.

KS1#
KS1# show crypto gdoi debug-condition 
GDOI Conditional Filters:
Peer Address 10.1.20.2
Unmatched NOT set

KS1#debug crypto gdoi ks registration all-levels 
GDOI Key Server Registration Debug level: (Packet, Detail, Event, Terse, Error)

Note: Com depurações condicionais de ISAKMP e GDOI, para capturar mensagens de depuração que talvez não tenham informações de filtro condicional, por exemplo, o endereço IP no caminho de depuração, o sinalizador incomparável pode ser ativado. No entanto, isso deve ser usado com cuidado, pois pode produzir uma grande quantidade de informações de depuração.

Rastreamentos de eventos GDOI

Isso 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. Os rastreamentos de eventos podem fornecer mais informações de histórico de eventos de GETVPN do que os syslogs tradicionais.

Os rastreamentos de eventos GDOI são ativados por padrão e podem ser recuperados do buffer de rastreamento com o comando show monitor even-trace. 

GM1#show monitor event-trace gdoi ?
  all           Show all the traces in current buffer
  back          Show trace from this far back in the past
  clock         Show trace from a specific clock time/date
  coop          GDOI COOP Event Traces
  exit          GDOI Exit Traces
  from-boot     Show trace from this many seconds after booting
  infra         GDOI INFRA Event Traces
  latest        Show latest trace events since last display
  merged        Show entries in all event traces sorted by time
  registration  GDOI Registration event Traces
  rekey         GDOI Rekey event Traces

GM1#show monitor event-trace gdoi rekey all
*Nov  6 15:55:16.117: GDOI_REKEY_EVENT: ACK_SENT: From 10.1.12.2 to 10.1.13.2 
                      with seq no 1 for the group G1
*Nov  6 15:55:16.117: GDOI_REKEY_EVENT: REKEY_RCVD: From 10.1.12.2 to 10.1.13.2 
                      with seq no 1 for the group G1
*Nov  6 16:11:01.125: GDOI_REKEY_EVENT: ACK_SENT: From 10.1.12.2 to 10.1.13.2 
                      with seq no 1 for the group G1
*Nov  6 16:11:01.125: GDOI_REKEY_EVENT: REKEY_RCVD: From 10.1.12.2 to 10.1.13.2 
                      with seq no 1 for the group G1

O rastreamento do caminho de saída fornece informações detalhadas sobre o caminho de saída, ou seja, exceções e condições de erro, com a opção de rastreamento ativada por padrão. Os rastreamentos podem ser usados para decodificar a sequência exata de código que levou à condição do caminho de saída. Use a opção detail para recuperar os rastreamentos do buffer de rastreamento:

GM1#show monitor event-trace gdoi exit all detail
*Nov  6 15:15:25.611: NULL_VALUE_FOUND:Invalid GROUP Name
-Traceback= 0xCA51318z  0xCA1F4DBz  0xC9B2707z  0xCA1ED4Ez  0x97EB018z
0x97EA960z  0x97E8D62z  0x97F3706z  0x97F3361z  0xA02684Ez  
*Nov  6 15:15:25.611: MAP_NOT_APPLIED_IN_ANY_INTERFACE: 
-Traceback= 0xCA51318z  0xCA46718z  0xCA1EF79z  0x97EB018z  0x97EA960z
0x97E8D62z  0x97F3706z  0x97F3361z  0xA02684Ez  0xA01FD52z  
*Nov  6 15:15:25.650: NULL_VALUE_FOUND:NULL Parameters passed idb or ipaddress 
                      when idb ipaddress is changed
-Traceback= 0xCA51318z  0xCA22430z  0xA09A8DCz  0xA09D8F6z  0xA0F280Fz
0xBA1D1F4z  0xBA1CACCz  0xBA1C881z  0xBA1C5BBz  0xA0F494Az

O tamanho padrão do buffer de rastreamento é de 512 entradas, e isso pode não ser suficiente se o problema for intermitente. Para aumentar esse tamanho de entrada de rastreamento padrão, os parâmetros de configuração de rastreamento de evento podem ser alterados como mostrado aqui:

GM1#show monitor event-trace gdoi rekey parameters 
Trace has 512 entries
Stacktrace is disabled by default

GM1#
GM1#config t
Enter configuration commands, one per line.  End with CNTL/Z.
GM1(config)#monitor event-trace gdoi rekey size ?
  <1-1000000>  Number of entries in trace

Pontos de verificação do plano de controle GETVPN e problemas comuns

Aqui estão alguns dos problemas comuns do plano de controle para GETVPN. Para repetir, o plano de controle é definido como todos os componentes do recurso GETVPN necessários para habilitar a criptografia e descriptografia do dataplane nos GMs. Em um nível alto, isso requer registro GM bem-sucedido, política de segurança e download/instalação de SA, além de chave KEK/TEK subsequente.

Configuração do COOP e criação de políticas

Para verificar e verificar se o KS criou com êxito a política de segurança e o KEK/TEK associado, insira:

KS1#show crypto gdoi ks policy 
Key Server Policy:
For group G1 (handle: 2147483650) server 10.1.11.2 (handle: 2147483650):

For group G1 (handle: 2147483650) server 10.1.12.2 (handle: 2147483651):

  # of teks : 1  Seq num : 10
  KEK POLICY (transport type : Unicast)
    spi : 0x18864836BA888BCD1126671EEAFEB4C7
    management alg     : disabled    encrypt alg       : 3DES      
    crypto iv length   : 8           key size          : 24      
    orig life(sec): 1200        remaining life(sec): 528       
    sig hash algorithm : enabled     sig key length    : 162     
    sig size           : 128       
    sig key name       : key1

  TEK POLICY (encaps : ENCAPS_TUNNEL)
    spi                : 0x91E3985A
    access-list        : ENCPOL
    transform          : esp-null esp-sha-hmac 
    alg key size       : 0             sig key size          : 20        
    orig life(sec)     : 900           remaining life(sec)   : 796       
    tek life(sec)      : 2203          elapsed time(sec)     : 1407      
    override life (sec): 0             antireplay window size: 4         
          
  Replay Value 442843.29 secs

Um problema comum com a configuração da política KS é quando há diferentes políticas configuradas entre os KSs principal e secundário. Isso pode resultar em comportamento de KS imprevisível e esse erro será relatado:

%GDOI-3-COOP_CONFIG_MISMATCH: WARNNING: replay method configuration between
Primary KS and Secondary KS are mismatched

Atualmente, não há sincronização automática de configuração entre KSs primários e secundários, portanto eles devem ser corrigidos manualmente.

Como o COOP é uma configuração crítica (e quase sempre obrigatória) do GETVPN, é importante garantir que o COOP funcione corretamente e que as funções do COOP KS estejam corretas:

KS1#show crypto gdoi ks coop 
Crypto Gdoi Group Name :G1 
        Group handle: 2147483650, Local Key Server handle: 2147483650

        Local Address: 10.1.11.2 
        Local Priority: 200      
        Local KS Role: Primary   , Local KS Status: Alive     
        Local KS version: 1.0.4 
        Primary Timers: 
                Primary Refresh Policy Time: 20 
                Remaining Time: 10
                Antireplay Sequence Number: 40

        Peer Sessions:
        Session 1:
                Server handle: 2147483651
                Peer Address: 10.1.12.2
                Peer Version: 1.0.4 
                Peer Priority: 100             
                Peer KS Role: Secondary , Peer KS Status: Alive     
                Antireplay Sequence Number: 0

                IKE status: Established
                Counters:
                    Ann msgs sent: 31
                    Ann msgs sent with reply request: 2
                    Ann msgs recv: 64 
                    Ann msgs recv with reply request: 1
                    Packet sent drops: 7 
                    Packet Recv drops: 0 
                    Total bytes sent: 20887 
                    Total bytes recv: 40244

Em uma configuração de COOP funcional, esse fluxo de protocolo deve ser observado:

IKE Exchange > ANN com prioridades COOP trocadas > COOP Election > ANN do KS primário ao secundário (política, banco de dados GM e chaves)

Quando o COOP não funciona corretamente ou se há uma divisão de COOP, como vários KSs se tornam o KS principal, essas depurações devem ser coletadas para a solução de problemas:

debug crypto isakmp
debug crypto gdoi ks coop all-levels 
show crypto isakmp sa
show crypto gdoi ks coop

Configuração de IKE

A troca de IKE bem-sucedida é necessária para a GETVPN para proteger o canal de controle para a política subsequente e o download de SA. No final da troca bem-sucedida de IKE, uma porta GDOI_REKEY é criada.

Em versões anteriores ao Cisco IOS 15.4(1)T, o GDOI_REKEY pode ser mostrado com o comando show crypto isakmp sa:

GM1#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
10.1.13.2       10.1.11.2       GDOI_REKEY        1075 ACTIVE
10.1.11.2       10.1.13.2       GDOI_IDLE         1074 ACTIVE

IPv6 Crypto ISAKMP SA

GM1#

No Cisco IOS 15.4(1)T e posterior, esta porta GDOI_REKEY é mostrada com o comando show crypto gdoi rekey sa:

GM1#show crypto gdoi rekey sa
GETVPN REKEY SA
dst             src             conn-id         status
10.1.13.2       10.1.11.2       1114            ACTIVE

Note: Quando a troca inicial de IKE for concluída, as políticas e chaves subsequentes serão enviadas do KS para o GM com o uso da SA GDOI_REKEY. Portanto, não há uma chave para o GDOI_IDLE SA quando eles expiram; eles desaparecem quando suas vidas expiram. No entanto, deve sempre haver GDOI_REKEY SA no GM para que ele receba chaves de retorno.

A troca de IKE para GETVPN não é diferente do IKE usado em túneis IPsec ponto a ponto tradicionais, portanto, o método de solução de problemas permanece o mesmo. Essas depurações devem ser coletadas para solucionar problemas de autenticação de IKE:

debug crypto isakmp 
debug crypto isakmp error
debug crypto isakmp detail (hidden command, if detailed isakmp exchange information
is needed)
debug crypto isakmp packet (hidden command, if packet level isakmp information is needed)

Registro, download de política e instalação de SA

Depois que a autenticação IKE for bem-sucedida, o GM é registrado com o KS. Espera-se que essas mensagens de syslog sejam vistas quando isso ocorrer corretamente:

%GDOI-5-GM_REKEY_TRANS_2_UNI: Group G1 transitioned to Unicast Rekey.
%GDOI-5-SA_KEK_UPDATED: SA KEK was updated
%GDOI-5-SA_TEK_UPDATED: SA TEK was updated
%GDOI-5-GM_REGS_COMPL: Registration to KS 10.1.12.2 complete for group G1 using
address 10.1.13.2
%GDOI-5-GM_INSTALL_POLICIES_SUCCESS: SUCCESS: Installation of Reg/Rekey policies
from KS 10.1.12.2 for group G1 & gm identity  10.1.13.2

A política e as chaves podem ser verificadas com este comando:

GM1#show crypto gdoi    
GROUP INFORMATION

    Group Name               : G1
    Group Identity           : 3333
    Crypto Path              : ipv4
    Key Management Path      : ipv4
    Rekeys received          : 1
    IPSec SA Direction       : Both

     Group Server list       : 10.1.11.2
                               10.1.12.2
                               
    Group member             : 10.1.13.2        vrf: None
       Version               : 1.0.4 
       Registration status   : Registered
       Registered with       : 10.1.12.2
       Re-registers in       : 139 sec
       Succeeded registration: 1
       Attempted registration: 1
       Last rekey from       : 10.1.11.2
       Last rekey seq num    : 0
       Unicast rekey received: 1
       Rekey ACKs sent       : 1
       Rekey Rcvd(hh:mm:ss)  : 00:05:20
       allowable rekey cipher: any
       allowable rekey hash  : any
       allowable transformtag: any ESP

    Rekeys cumulative
       Total received        : 1
       After latest register : 1
       Rekey Acks sents      : 1

 ACL Downloaded From KS 10.1.11.2:
   access-list   deny icmp any any
   access-list   deny eigrp any any
   access-list   deny ip any 224.0.0.0 0.255.255.255
   access-list   deny ip 224.0.0.0 0.255.255.255 any
   access-list   deny udp any port = 848 any port = 848
   access-list   permit ip any any

KEK POLICY:
    Rekey Transport Type     : Unicast
    Lifetime (secs)          : 878
    Encrypt Algorithm        : 3DES
    Key Size                 : 192     
    Sig Hash Algorithm       : HMAC_AUTH_SHA
    Sig Key Length (bits)    : 1024    

TEK POLICY for the current KS-Policy ACEs Downloaded:
  Serial1/0:
    IPsec SA:
        spi: 0x8BF147EF(2347845615)
        transform: esp-3des esp-sha-hmac 
        sa timing:remaining key lifetime (sec): (200)
        Anti-Replay(Time Based) : 4 sec interval


GM1#
GM1#
GM1#show crypto ipsec sa

interface: Serial1/0
    Crypto map tag: gm1map, local addr 10.1.13.2

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   current_peer 0.0.0.0 port 848
     PERMIT, flags={}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 10.1.13.2, remote crypto endpt.: 0.0.0.0
     path mtu 1500, ip mtu 1500, ip mtu idb Serial1/0
     current outbound spi: 0x0(0)
     PFS (Y/N): N, DH group: none

     local crypto endpt.: 10.1.13.2, remote crypto endpt.: 0.0.0.0
     path mtu 1500, ip mtu 1500, ip mtu idb Serial1/0
     current outbound spi: 0x8BF147EF(2347845615)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0x8BF147EF(2347845615)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 1, flow_id: SW:1, sibling_flags 80000040, crypto map: gm1map
        sa timing: remaining key lifetime (sec): (192)
        Kilobyte Volume Rekey has been disabled
        IV size: 8 bytes
        replay detection support: Y  replay window size: 4
        Status: ACTIVE(ACTIVE)

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x8BF147EF(2347845615)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2, flow_id: SW:2, sibling_flags 80000040, crypto map: gm1map
        sa timing: remaining key lifetime (sec): (192)
        Kilobyte Volume Rekey has been disabled
        IV size: 8 bytes
        replay detection support: Y  replay window size: 4
        Status: ACTIVE(ACTIVE)

     outbound ah sas:

     outbound pcp sas:
GM1#

Note: Com o GETVPN, as SAs de entrada e saída usam o mesmo SPI.

Com o registro de GETVPN e o tipo de instalação de política, essas depurações são necessárias para solucionar problemas:

debug crypto isakmp (KS and GM)
debug crypto gdoi ks registration all-levels (KS)
debug crypto gdoi gm registration all-level (GM)
debug crypto engine (GM only)
show crypto eli detail (multiple iterations on GM)

Note: Depurações adicionais podem ser necessárias dependendo do resultado dessas saídas.

Como o registro de GETVPN geralmente ocorre imediatamente após o recarregamento GM, este script de EEM pode ser útil para coletar estas depurações:

event manager applet debug
 event syslog pattern "RESTART"
 action 1.0 cli command "enable"
 action 2.0 cli command "debug crypto gdoi all all"

Rekey

Quando os GMs são registrados no KS e a rede GETVPN é configurada corretamente, o KS principal é responsável por enviar mensagens de rechaveamento a todos os GMs registrados nele. As mensagens de rechaveamento são usadas para sincronizar todas as políticas, chaves e pseudovezes nos GMs. As mensagens de rechaveamento podem ser enviadas por um método unicast ou multicast.

Esta mensagem de syslog é vista no KS quando a mensagem de rechaveamento é enviada:

%GDOI-5-KS_SEND_UNICAST_REKEY: Sending Unicast Rekey for group G1 from address
10.1.11.2 with seq # 11 

Nos GMs, esse é o syslog visto quando ele recebe o rechaveamento:

%GDOI-5-GM_RECV_REKEY: Received Rekey for group G1 from 10.1.11.2 to 10.1.20.2
with seq # 11

Requisito de par de chaves RSA para chave de chave no KS

A funcionalidade de rechaveamento exige a presença de chaves RSA no KS. O KS fornece a chave pública do par de chaves RSA ao GM por meio desse canal seguro durante o registro. O KS assina as mensagens GDOI enviadas ao GM com a chave RSA privada no payload do GDOI SIG. O GM recebe as mensagens GDOI e usa a chave RSA pública para verificar a mensagem. As mensagens entre o KS e a GM são codificadas com a KEK, que também é distribuída à GM durante o registro. Quando o registro for concluído, as chaves subsequentes serão criptografadas com o KEK e assinadas com a chave RSA privada.

Se a chave RSA não estiver presente no KS durante o registro GM, esta mensagem será exibida no syslog:

%GDOI-1-KS_NO_RSA_KEYS: RSA Key - get : Not found, Required for group G1 

Quando as chaves não estão presentes no KS, o GM é registrado pela primeira vez, mas o próximo rechaveiro falha do KS. Eventualmente, as chaves existentes no GM expirarão e ele registrará novamente.

%GDOI-4-GM_RE_REGISTER: The IPSec SA created for group G1 may have expired/been
cleared, or didn't go through. Re-register to KS.

Como o par de chaves RSA é usado para assinar as mensagens de rechaveamento, elas DEVEM ser iguais entre os KSs principal e secundário. Isso garante que durante uma falha principal do KS, os rechaveamentos enviados por um KS secundário (o novo KS principal) ainda possam ser validados corretamente pelos GMs. Quando ele gera o par de chaves RSA no KS principal, o par de chaves deve ser criado com a opção exportável para que possa ser exportado para todos os KS secundários para atender a esse requisito.

Redirecionar solução de problemas

A falha de chave KEK/TEK é um dos problemas de GETVPN mais comuns encontrados nas implantações de clientes. A solução de problemas de rechaveamento deve seguir as etapas de rechaveamento conforme descrito aqui:

1. As chaves foram enviadas pelo KS?
   
   Isso pode ser verificado por uma observação da mensagem de syslog %GDOI-5-KS_SEND_UNICAST_REKEY ou mais precisamente com este comando:
   
   

   KS1#show crypto gdoi ks rekey
   Group G1 (Unicast)
       Number of Rekeys sent               : 341
       Number of Rekeys retransmitted      : 0
       KEK rekey lifetime (sec)            : 1200
           Remaining lifetime (sec)        : 894
       Retransmit period                   : 10
       Number of retransmissions           : 5
       IPSec SA 1  lifetime (sec)          : 900
           Remaining lifetime (sec)        : 405

   
   O número de rechaves retransmitidas é indicativo de pacotes de confirmação de chave não recebidos pelo KS e, portanto, possíveis problemas de rechaveamento. Lembre-se de que a chave GDOI usa o UDP como um mecanismo de transporte não confiável, então algumas quedas de chave podem ser esperadas dependendo da confiabilidade da rede de transporte subjacente, mas uma tendência de aumento das retransmissões de chaves deve sempre ser investigada.
   
   Também é possível obter estatísticas mais detalhadas de chave de rechaveamento por GM. Normalmente, esse é o primeiro lugar a buscar possíveis problemas de rechaveamento.
   
   

   KS1#show crypto gdoi ks members 
   
   Group Member Information : 
   
   Number of rekeys sent for group G1 : 346
   
   Group Member ID    : 10.1.14.2   GM Version: 1.0.4 
    Group ID          : 3333
    Group Name        : G1
    Key Server ID     : 10.1.11.2
    Rekeys sent       : 346
    Rekeys retries    : 0
    Rekey Acks Rcvd   : 346
    Rekey Acks missed : 0
   
    Sent seq num : 2       1       2       1
   Rcvd seq num :  2       1       2       1
   
   Group Member ID    : 10.1.13.2   GM Version: 1.0.4 
    Group ID          : 3333
    Group Name        : G1
    Key Server ID     : 10.1.12.2
    Rekeys sent       : 340
    Rekeys retries    : 0
    Rekey Acks Rcvd   : 340
    Rekey Acks missed : 0
   
    Sent seq num : 2       1       2       1
   Rcvd seq num :  2       1       2       1

2. Os pacotes de rechaveamento foram entregues na rede de infraestrutura subjacente?
   
   A solução de problemas de IP padrão ao longo do caminho de encaminhamento de chave deve ser seguida para garantir que os pacotes de chave de rechaveamento não sejam descartados na rede de trânsito entre KS e GM. Algumas ferramentas comuns de identificação e solução de problemas usadas aqui são ACLs (Access Control Lists, listas de controle de acesso) de entrada/saída, Netflow e captura de pacotes na rede de trânsito.
   
   
3. Os pacotes de rechaveamento chegaram ao processo GDOI para processamento de rechaveamento?
   
   Verifique as estatísticas da chave GM:
   
   

   GM1#show crypto gdoi gm rekey
   Group G1 (Unicast)
       Number of Rekeys received (cumulative)       : 340
       Number of Rekeys received after registration : 340
       Number of Rekey Acks sent                    : 340

4. O pacote de confirmação de chave retornou ao KS? 
   
   Siga as etapas de 1 a 3 para rastrear o pacote de confirmação de rechaveamento do GM de volta ao KS.

Muticast Rekey

A chave multicast é diferente da chave unicast nestes aspectos:

• Como o multicast é usado para transportar esses pacotes de rechaveamento do KS para os GMs, o KS não precisa replicar os próprios pacotes de rechaveamento. O KS envia apenas uma cópia do pacote de rechaveamento e eles são replicados na rede habilitada para multicast.
• Não há mecanismo de reconhecimento para a chave de transmissão múltipla, portanto, se um GM não receberia o pacote de chave, o KS não teria conhecimento dele e, portanto, nunca removerá um GM da sua base de dados GM. E como não há confirmação, o KS sempre retransmitirá os pacotes de rechaveamento com base em sua configuração de retransmissão de chave.

O problema de chave de rechaveamento multicast mais comumente visto é quando a chave de rechaveamento não é recebida no GM. Pode haver várias causas possíveis para isso, como:

• Problema de entrega de pacotes dentro da infraestrutura de roteamento multicast
• O roteamento multicast de ponta a ponta não está ativado na rede 

A primeira etapa para solucionar um problema com a chave de transmissão múltipla é verificar se a tecla rekey funciona quando é comutada do multicast para o método unicast.

Depois de identificar que o problema é específico para a chave de transmissão múltipla, verifique se o KS envia a chave de rechaveamento para o endereço de transmissão múltipla especificado.

%GDOI-5-KS_SEND_MCAST_REKEY: Sending Multicast Rekey for group G1 from address
10.1.11.2 to 226.1.1.1  with seq # 6 

Teste a conectividade multicast entre o KS e o GM com uma solicitação ICMP (Internet Control Message Protocol) para o endereço multicast. Todos os GMs que fazem parte do grupo multicast devem responder ao ping. Certifique-se de que o ICMP esteja excluído da política de criptografia KS para este teste.

KS1#ping 226.1.1.1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 226.1.1.1, timeout is 2 seconds:

Reply to request 0 from 10.1.21.2, 44 ms

Se o teste de ping multicast falhar, a solução de problemas multicast deve ser executada, o que está fora do escopo deste documento.

Verificação de relé do plano de controle

Sintoma

Quando os clientes atualizam seu GM para uma nova versão do Cisco IOS, eles podem experimentar falhas de chave KEK com esta mensagem observada no syslog:

%GDOI-3-GDOI_REKEY_SEQ_FAILURE: Failed to process rekey seq # 1 in seq payload for
group G1, last seq # 11
%GDOI-3-GDOI_REKEY_FAILURE: Processing of REKEY payloads failed on GM 10.1.13.2 in the group G1,
with peer at 10.1.11.2
%CRYPTO-6-IKMP_MODE_FAILURE: Processing of GDOI mode failed with peer at 10.1.11.2

Esse comportamento é causado por um problema de interoperabilidade introduzido com a verificação antirreprodução que é adicionada para mensagens do plano de controle. Especificamente, um KS que executa o código mais antigo redefinirá o número de sequência de chave KEK como 1, e isso será descartado pelo GM que executa o novo código quando interpreta isso como um pacote de chave reproduzida. Para obter mais detalhes, consulte o bug da Cisco ID CSCta05809 (GETVPN: Plano de controle de GETVPN sensível a repetição) e Restrições de Configuração de GETVPN.

Background

Com a GETVPN, as mensagens do plano de controle podem transportar informações sensíveis ao tempo para fornecer o serviço de verificação antirepetição baseado em tempo. Portanto, essas mensagens exigem proteção antirreprodução para garantir a precisão do tempo. Essas mensagens são:

• Redirecionar mensagens de KS para GM
• Mensagens de anúncio COOP entre KSs

Como parte desta implementação de proteção antirreprodução, foram adicionadas verificações de número de sequência para proteger mensagens reproduzidas, bem como uma verificação de pseudotempo quando o TBAR está ativado.

Solução

Para resolver esse problema, o GM e o KS devem ser atualizados para as versões do Cisco IOS após o recurso de verificação de repetição do plano de controle. Com o novo código do Cisco IOS, o KS não redefine o número de sequência de volta para 1 para uma chave KEK, mas, em vez disso, continua a usar o número de sequência atual e só redefine o número de sequência para chaves TEK.

Essas versões do Cisco IOS têm os recursos de Verificação de repetição:

• 12.4(15)T10
• 12,4(22)T3
• 12.4(24)T2
• 15.0(1)M e posterior 

Outros problemas relacionados à repetição

• Falha de COOP devido à falha na verificação de repetição de mensagens ANN (ID de bug da Cisco CSCtc52655)

Falhas de repetição do plano de controle de depuração

Para outras falhas de repetição de plano de controle, colete essas informações e certifique-se de que os horários estejam sincronizados entre o KS e o GM.

• Syslog da GM e KS
• depurações ISAKMP
• Depurações de GDOI (rekey and replay) do KS e do GM

Problemas de fragmentação de pacote do plano de controle

Com o GETVPN, a fragmentação do pacote do plano de controle é um problema comum e pode se manifestar em um desses dois cenários quando os pacotes do plano de controle são grandes o suficiente para que eles precisem de fragmentação de IP:

• Pacotes de anúncio de COOP de GETVPN
• Pacotes de chave de GETVPN

Pacotes de anúncio COOP

Os pacotes de Anúncio COOP carregam as informações do banco de dados GM e, portanto, podem crescer em uma grande implantação de GETVPN. Da experiência passada, uma rede GETVPN que consiste em mais de 1500 GMs produzirá pacotes de Anúncio maiores que 18024 bytes, que é o tamanho de buffer Enorme padrão do Cisco IOS. Quando isso acontece, o KS não aloca um buffer grande o suficiente para transmitir os pacotes ANN com este erro:

%SYS-2-GETBUF: Bad getbuffer, bytes= 18872 -Process= "Crypto IKMP", ipl= 0, pid= 183

Para corrigir essa condição, esse ajuste de buffer é recomendado:

buffers huge permanent 10
buffers huge size 65535

Redirecionar pacotes

Os pacotes de chave GETVPN também podem exceder o tamanho típico de MTU (Maximum Transition Unit) de 1500 IP quando a política de criptografia é grande, como uma política que consiste em mais de 8 linhas de entradas de controle de acesso (ACEs) na ACL de criptografia.

Problema de fragmentação e identificação

Em ambos os cenários anteriores, o GETVPN deve ser capaz de transmitir e receber corretamente os pacotes de UDP fragmentados para que o COOP ou a chave GDOI funcione corretamente. A fragmentação de IP pode ser um problema em alguns ambientes de rede. Por exemplo, uma rede que consiste em um plano de encaminhamento ECMP (Equal Cost Multi Path) e alguns dispositivos no plano de encaminhamento exigem a remontagem virtual dos pacotes IP fragmentados, como VFR (Virtual Fragmentation Reassembly, remontagem de fragmentação virtual).

Para identificar o problema, verifique os erros de remontagem no dispositivo em que se suspeita que os pacotes UDP 848 fragmentados não foram recebidos corretamente:

KS1#show ip traffic | section Frags
  Frags: 10 reassembled, 3 timeouts, 0 couldn't reassemble
         0 fragmented, 0 fragments, 0 couldn't fragment

Se os tempos limites de remontagem continuarem a aumentar, use o comando debug ip error para confirmar se a queda faz parte do fluxo do pacote rekey/COOP. Depois de confirmada, a solução de problemas de encaminhamento IP normal deve ser executada para isolar o dispositivo exato no plano de encaminhamento que pode ter descartado os pacotes. Algumas ferramentas comumente usadas incluem:

• Captura do pacote
• Estatísticas de encaminhamento de tráfego
• Estatísticas de recursos de segurança (Firewall, IPS)
• estatísticas de VFR

Problemas de interoperabilidade do GDOI

Vários problemas de interoperabilidade foram encontrados com o GETVPN ao longo dos anos, e é fundamental observar as versões do Cisco IOS entre o KS e o GM e entre os KSs para problemas de interoperabilidade.

Outros problemas conhecidos de interoperabilidade de GETVPN são:

• Verificação de relé do plano de controle
• Mudança no comportamento da chave GETVPN KEK
• ID de bug da Cisco CSCub42920 (GETVPN: KS não consegue validar o hash no rekey ACK das versões GM anteriores) 
• ID de bug da Cisco CSCuw48400 (GetVPN GM impossível de registrar ou rekey falha - sig-hash > SHA-1 padrão)
• ID de bug da Cisco CSCvg19281 ( vários travamentos GETVPN GM após a migração para o novo par KS ; se uma versão GM for anterior à 3.16 e o KS for atualizado de um código anterior para a 3.16 ou posterior, esse problema poderá ocorrer) 

Procedimento de atualização do IOS GETVPN

Este procedimento de atualização do Cisco IOS deve ser seguido quando uma atualização de código do Cisco IOS precisa ser executada em um ambiente GETVPN:

1. Atualize um KS secundário primeiro e aguarde até que a eleição do COOP KS seja concluída.
2. Repita a Etapa 1 para todos os KSs secundários.
3. Atualize o KS principal.
4. Atualizar GMs.

Solucionar problemas do plano de dados GETVPN 

Comparado aos problemas do plano de controle, os problemas do plano de dados GETVPN são problemas em que o GM tem a política e as chaves para executar a criptografia e a descriptografia do plano de dados, mas, por alguma razão, o fluxo de tráfego de ponta a ponta não funciona. A maioria dos problemas de faixa de dados para GETVPN relaciona-se ao encaminhamento genérico de IPsec e não são específicos de GETVPN. Portanto, a maior parte da abordagem de solução de problemas descrita aqui se aplica também a problemas genéricos de dataplane de IPsec.

Com problemas de criptografia (túneis baseados em grupo ou em par), é importante solucionar o problema e isolá-lo a uma parte específica do datapath. Especificamente, a abordagem de solução de problemas descrita aqui tem como objetivo ajudá-lo a responder a estas perguntas:

• Qual dispositivo é o culpado - roteador de criptografia ou roteador de descriptografia?
• Em que direção o problema está acontecendo - ingresso ou saída?

Ferramentas de identificação e solução de problemas do plano de dados GETVPN

A solução de problemas do plano de dados IPsec é muito diferente da do plano de controle. Com o dataplane, geralmente, não há depurações que você possa executar ou, pelo menos, executar com segurança em um ambiente de produção. Assim, a solução de problemas depende muito de contadores e estatísticas de tráfego diferentes que podem ajudar a rastrear o pacote em um caminho de encaminhamento. A ideia é poder desenvolver um conjunto de pontos de verificação para ajudar a isolar onde os pacotes podem ser descartados, como mostrado aqui:

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)

Os pontos de verificação no datapath na imagem anterior podem ser validados com estas ferramentas:

Criptografando GM

• Interface de LAN de entrada
           ACL de entrada
           Netflow de entrada
           Captura de pacote incorporado
           Contabilidade de precedência de entrada
  
  
• Engine de criptografia
           show crypto ipsec sa 
           show crypto ipsec sa detail
           show crypto engine accelerator statistics
  
  
• Interface de WAN de saída
           Netflow de saída
           Captura de pacote incorporado
           Contabilidade de precedência de saída

Descriptografia de GM

• Interface de WAN de entrada
            ACL de entrada
            Netflow de entrada
            Captura de pacote incorporado
            Contabilidade de precedência de entrada
  
  
• Mecanismo de criptografia
           show crypto ipsec sa
           show crypto ipsec sa detail
           show crypto engine accelerator statistics
  
  
• Interface de LAN de saída
           Netflow de saída
           Captura de pacote incorporado

O caminho de retorno segue o mesmo fluxo de tráfego. As próximas seções têm alguns exemplos dessas ferramentas de dataplane em uso.

Contadores de criptografia/descriptografia

Os contadores de criptografia/descriptografia em um roteador são baseados em um fluxo IPsec. Infelizmente, isso não funciona bem com o GETVPN, pois o GETVPN geralmente implanta uma política de criptografia "permit ip any any any" que criptografa tudo. Assim, se o problema ocorrer apenas para alguns dos fluxos e não para todos, esses contadores podem ser um pouco difíceis de usar para avaliar corretamente se os pacotes são criptografados ou descriptografados quando há tráfego de segundo plano significativo suficiente que funciona.

GM1#show crypto ipsec sa | in encrypt|decrypt
    #pkts encaps: 100, #pkts encrypt: 100, #pkts digest: 100
    #pkts decaps: 100, #pkts decrypt: 100, #pkts verify: 100

Netflow

O Netflow pode ser usado para monitorar o tráfego de entrada e saída em ambos os GMs. Observe que com a política permit ip any any, o tráfego criptografado será agregado e não fornecerá as informações por fluxo. As informações por fluxo deverão ser coletadas com a marcação DSCP/precedência descrita posteriormente.

Neste exemplo, o netflow para um ping de contagem de 100 de um host atrás de GM1 para um host atrás de GM2 é mostrado nos vários pontos de verificação.

Criptografando GM

Configuração do Netflow:

interface Ethernet0/0
 description LAN  
 ip address 192.168.13.1 255.255.255.0
 ip flow ingress
 ip pim sparse-dense-mode
!
interface Serial1/0
 description WAN interface
 ip address 10.1.13.2 255.255.255.252
 ip flow egress
 ip pim sparse-dense-mode
 crypto map gm1map

Saída do Netflow:

GM1#show ip cache flow | be SrcIf
SrcIf         SrcIPaddress    DstIf         DstIPaddress    Pr SrcP DstP  Pkts
Et0/0         192.168.13.2    Se1/0*        192.168.14.2    32 8DE1 6523   100 
Et0/0         192.168.13.2    Se1/0         192.168.14.2    01 0000 0800   100 
GM1#

Note: Na saída anterior, * denota tráfego de saída. A primeira linha mostra o tráfego criptografado de saída (com protocolo 0x32 = ESP) da interface WAN e o tráfego ICMP de entrada de segunda linha atingindo a interface LAN.

Descriptografia de GM

Configuração:

interface Ethernet0/0
 description LAN interface
 ip address 192.168.14.1 255.255.255.0
 ip flow egress
 ip pim sparse-dense-mode
!
interface Serial1/0
 description WAN interface
 ip address 10.1.14.2 255.255.255.252
 ip flow ingress
 ip pim sparse-dense-mode
 crypto map gm1map

Saída do Netflow:

GM2#show ip cache flow | be SrcIf
SrcIf         SrcIPaddress    DstIf         DstIPaddress    Pr SrcP DstP  Pkts
Se1/0         192.168.13.2    Et0/0         192.168.14.2    32 8DE1 6523   100 
Se1/0         192.168.13.2    Et0/0*        192.168.14.2    01 0000 0800   100 
GM2#

Marcação de precedência DSCP/IP

O desafio da solução de problemas de criptografia é que, uma vez que o pacote é criptografado, você perde a visibilidade do payload, que é o que a criptografia deve fazer, e isso dificulta o rastreamento do pacote para um fluxo IP específico. Há duas maneiras de lidar com essa limitação quando se trata de solucionar um problema de IPsec:

• Use ESP-NULL como a transformação de IPsec. O IPsec ainda executa o encapsulamento ESP, mas nenhuma criptografia é aplicada ao payload, portanto, eles são visíveis em uma captura de pacote.
• Marque um fluxo IP com uma marcação exclusiva de Ponto de Código de Serviços Diferenciados (DSCP - Differentiated Services Code Point)/precedência com base em suas características L3/L4.

O ESP-NULL exige alterações em ambos os pontos finais do túnel e geralmente não é permitido com base na política de segurança do cliente. Portanto, a Cisco geralmente recomenda o uso da marcação DSCP/precedência.

Gráfico de referência DSCP/Precedência

ToS (hexadecimal)	ToS (decimal)	Precedência de IP	DSCP	Binário
0xE0	224	7 Controle de rede	56 CS7	11100000
0xC0	192	6 Controle de internetwork	48 CS6	11000000
0xB8	184	5 Crítico	46 EF	10111000
0xA0	160		40 CS5	10100000
0x88	136	4 Substituição Flash	34 AF41	10001000
0x80	128		32 CS4	10000000
0x68	104	3 Flash	26 AF31	01101000
0x60	96		24 CS3	01100000
0x48	72	2 Imediato	18 AF21	01001000
0x40	64		16 CS2	01000000
0x20	32	1 Prioridade	8 CS1	00100000
0x00	0	0 Rotina	0 Dflt	00000000

Marcar pacotes com DSCP/Precedência

Normalmente, esses métodos são usados para marcar pacotes com as marcas específicas de DSCP/Precedência.

PBR

interface Ethernet1/0
 ip policy route-map mark
!
access-list 150 permit ip host 172.16.1.2 host 172.16.254.2
!
route-map mark permit 10
 match ip address 150
 set ip precedence flash-override

MQC

class-map match-all my_flow
 match access-group 150
!
policy-map marking
 class my_flow
  set ip precedence 4
!
interface Ethernet1/0
 service-policy input marking

Ping do roteador

GM1-host#ping ip
Target IP address: 192.168.14.2
Repeat count [5]:  
Datagram size [100]: 
Timeout in seconds [2]: 
Extended commands [n]: y
Source address or interface: 
Type of service [0]: 136
...
<snip>

Note: É sempre uma boa ideia monitorar o fluxo de tráfego normal e o perfil de DSCP/precedência antes de aplicar a marcação para que o fluxo de tráfego marcado seja exclusivo.

Monitorar pacotes marcados

Contabilidade de precedência de IP

interface Ethernet0/0
 ip address 192.168.1.2 255.255.255.0
 ip accounting precedence input

middle_router#show interface precedence 
Ethernet0/0 
  Input
Precedence 4:  100 packets, 17400 bytes

Interface ACL

middle_router#show access-list 144
Extended IP access list 144
    10 permit ip any any precedence routine
    20 permit ip any any precedence priority
    30 permit ip any any precedence immediate
    40 permit ip any any precedence flash
    50 permit ip any any precedence flash-override (100 matches)
    60 permit ip any any precedence critical
    70 permit ip any any precedence internet (1 match)
    80 permit ip any any precedence network

Captura de pacote incorporado

A Captura de Pacotes Integrados (EPC - Embedded Packet Capture) é uma ferramenta útil para capturar pacotes no nível da interface, a fim de identificar se um pacote atingiu um dispositivo específico. Lembre-se de que o EPC funciona bem para o tráfego de texto claro, mas pode ser um desafio quando os pacotes capturados são criptografados. Portanto, técnicas como DSCP/marcação de precedência discutida anteriormente ou outros caracteres IP, como o comprimento do pacote IP, devem ser usadas juntamente com o EPC para tornar a solução de problemas mais eficaz.

Rastreamento de pacote do Cisco IOS-XE 

Esse é um recurso útil para rastrear o caminho de encaminhamento de recursos em todas as plataformas que executam o Cisco IOS-XE, como CSR1000v, ASR1000 e ISR4451-X.

Problemas comuns do plano de dados GETVPN

A identificação e solução de problemas do dataplane IPsec para GETVPN não é, na maioria das vezes, diferente da identificação e solução de problemas tradicionais do dataplane IPsec ponto a ponto, com duas exceções devido a essas propriedades exclusivas do dataplane de GETVPN.

Falha de antirrepetição baseada em tempo

Em uma rede GETVPN, as falhas de TBAR podem ser difíceis de solucionar, já que não há mais túneis para par. Para solucionar problemas de falhas de TBAR de GETVPN, faça o seguinte:

1. Identifique qual pacote é descartado devido à falha do TBAR e identifique subsequentemente o GM de criptografia.
   
   Antes da versão 15.3(2)T, o syslog de falha do TBAR não imprimia o endereço de origem do pacote com falha, portanto, isso torna muito difícil identificar qual pacote falhou. Isso foi significativamente melhorado na versão 15.3(2)T e posterior, onde o Cisco IOS imprime isto:
   
   

   %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
           connection id=13, sequence number=1
   
   %GDOI-4-TIMEBASED_REPLAY_FAILED: An anti replay check has failed in group G1:
   my_pseudotime = 620051.84 secs, peer_pseudotime = 619767.09 secs, replay_window =
   4 (sec), src_ip = 192.168.13.2, dst_ip = 192.168.14.2

   
   Um histórico do TBAR também foi implementado nesta versão:
   
   

   GM2#show crypto gdoi gm replay 
   Anti-replay Information For Group G1:
     Timebased Replay:
       Replay Value             : 621388.66 secs
       Input Packets            : 0        Output Packets           : 0    
       Input Error Packets      : 2        Output Error Packets     : 0    
       Time Sync Error          : 0        Max time delta           : 0.00 secs
   
   
   TBAR Error History (sampled at 10pak/min):
       19:29:32.081 EST Wed Nov 13 2013: src=192.168.13.2; my_pst=620051.84 secs;
   peer_pst=619767.09 secs; win=4

   
   

   Note: Os aprimoramentos mencionados anteriormente foram implementados no Cisco IOS-XE pela ID de bug da Cisco CSCun49335 e no Cisco IOS pela ID de bug CSCub91811.

   
   Para versões do Cisco IOS que não tinham esse recurso, debug crypto gdoi gm replay detail também pode fornecer essas informações, embora essa depuração imprima as informações do TBAR para todo o tráfego (não apenas os pacotes descartados devido à falha do TBAR), portanto, talvez não seja possível executar em um ambiente de produção.
   
   

   GDOI:GM REPLAY:DET:(0):my_pseudotime is 621602.30 (secs), peer_pseudotime is 621561.14
   (secs), replay_window is 4 (secs), src_addr = 192.168.14.2, dest_addr = 192.168.13.2

2. Depois que a origem do pacote for identificada, você poderá encontrar a criptografia GM. Em seguida, o pseudotimestamp nos GMs de criptografia e descriptografia deve ser monitorado quanto a qualquer possível desvio de pseudônimo. A melhor maneira de fazer isso seria sincronizar os GMs e o KS com o NTP e coletar periodicamente as informações do pseudotempo com um relógio do sistema de referência em todos eles para determinar se o problema é causado pela diferença de clock nos GMs.

GM1

GM1#show crypto gdoi gm replay
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is hardware calendar, *21:06:26.469 EST Wed Nov 13 2013

Anti-replay Information For Group G1:
  Timebased Replay:
    Replay Value             : 625866.26 secs
    Input Packets            : 0        Output Packets           : 0    
    Input Error Packets      : 0        Output Error Packets     : 0    
    Time Sync Error          : 0        Max time delta           : 0.00 secs

GM2

GM2#show crypto gdoi gm replay
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is hardware calendar, *21:06:26.743 EST Wed Nov 13 2013

Anti-replay Information For Group G1:
  Timebased Replay:
    Replay Value             : 625866.51 secs
    Input Packets            : 4        Output Packets           : 4    
    Input Error Packets      : 2        Output Error Packets     : 0    
    Time Sync Error          : 0        Max time delta           : 0.00 secs

No exemplo anterior, se o pseudotime (como indicado pelo Valor da repetição) for significativamente diferente entre os GMs quando as saídas forem capturadas com o mesmo tempo de referência, o problema poderá ser atribuído ao desvio do relógio.

Note: Na plataforma Cisco Aggregated Services Router 1000 Series, devido à arquitetura da plataforma, o datapath no Quantum Flow Processor (QFP) refere-se, na verdade, ao clock da parede para a contagem de pulsos de pseudotempo. Isso criou problemas com o TBAR quando o tempo do relógio da parede muda devido à sincronização do NTP. Esse problema está documentado com a ID de bug da Cisco CSCum37911.

Preservação de cabeçalho PMTUD e GETVPN

Com o GETVPN, o Path MTU Discovery (PMTUD) não funciona entre os GMs de criptografia e descriptografia, e pacotes grandes com o bit Don't Fragment (DF) pode ser bloqueado. O motivo de isso não funcionar é devido à Preservação do cabeçalho GETVPN, onde os endereços de origem/destino de dados são preservados no cabeçalho de encapsulamento ESP. Isso é representado nesta imagem:

Como a imagem mostra, o PMTUD se divide com o GETVPN com este fluxo:

1. Um pacote de dados grande chega na criptografia GM1.
2. O pacote ESP pós-criptografia é encaminhado do GM1 e entregue para o destino.
3. Se houver um link de trânsito com IP MTU de 1.400 bytes, o pacote ESP será descartado e um pacote ICMP 3/4 muito grande será enviado para a origem do pacote, que é a origem do pacote de dados.
4. O pacote ICMP3/4 é descartado devido ao ICMP não excluído da política de criptografia GETVPN ou descartado pelo host final, pois ele não sabe nada sobre o pacote ESP (payload não autenticado).

Em resumo, o PMTUD não funciona com o GETVPN hoje. Para contornar esse problema, a Cisco recomenda estas etapas:

1. Implemente "ip tcp adjust-mss" para reduzir o tamanho do segmento do pacote TCP para acomodar a sobrecarga de criptografia e o caminho mínimo MTU na rede de trânsito.
2. Limpe o bit DF no pacote de dados à medida que eles chegam ao GM de criptografia para evitar o PMTUD.

Problemas Genéricos do Painel de Dados IPsec

A maior parte da solução de problemas do plano de dados IPsec é como a solução de problemas de túneis IPsec ponto a ponto tradicionais. Um dos problemas comuns é %CRYPTO-4-RECVD_PKT_MAC_ERR. Consulte Mensagem de Erro "%CRYPTO-4-RECVD_PKT_MAC_ERR:" do Syslog "%CRYPTO-4-RECVD_PKT_MAC_ERR:" com Solução de Problemas de Perda de Ping sobre Túnel IPsec para obter mais detalhes sobre a solução de problemas.

Problemas conhecidos

Essa mensagem pode ser gerada quando um pacote IPsec é recebido que não corresponde a um SPI no SADB. Consulte o bug da Cisco ID CSCtd47420 - GETVPN - CRYPTO-4-RECVD_PKT_NOT_IPSEC reportado para o pacote sem fluxo correspondente. Um exemplo é:

%CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet. (ip)
 vrf/dest_addr= /192.168.14.2, src_addr= 192.168.13.2, prot= 50

Esta mensagem deve ser %CRYPTO-4-RECVD_PKT_INV_SPI, que é o que é relatado para o IPsec tradicional, bem como em algumas plataformas de hardware, como o ASR. Esse problema superficial foi corrigido pela ID de bug da Cisco CSCup80547: Erro ao relatar CRYPTO-4-RECVD_PKT_NOT_IPSEC para ESP pak.

Note: Essas mensagens podem aparecer às vezes devido a outro bug de GETVPN CSCup34371: O GETVPN GM interrompe a descriptografia do tráfego após o rechaveamento de TEK.

Nesse caso, o GM não pode descriptografar o tráfego de GETVPN, embora tenha uma SA IPsec válida no SADB (a SA sendo rechaveada). O problema desaparece assim que o SA expira e é removido do SADB. Esse problema causa uma interrupção significativa, pois o troco TEK é executado com antecedência. Por exemplo, a interrupção pode ser de 22 minutos no caso de uma duração TEK de 7200 segundos. Consulte a descrição do bug para saber a condição exata que deve ser atendida para encontrar esse bug.

Solucionar problemas de GETVPN em plataformas que executam o Cisco IOS-XE

Comandos para Troubleshooting

As plataformas que executam o Cisco IOS-XE têm implementações específicas da plataforma e frequentemente exigem depuração específica da plataforma para problemas de GETVPN. Aqui está uma lista de comandos usados tipicamente para solucionar problemas de GETVPN nestas plataformas:

show crypto eli all

show platform software ipsec policy statistics

show platform software ipsec fp ative inventário

show platform hardware qfp ative feature ipsec spd all

show platform hardware qfp ative statistics drop clear

show platform hardware qfp ative feature ipsec data drop clear

show crypto ipsec sa

show crypto gdoi

show crypto ipsec internal

debug crypto ipsec

debug crypto ipsec error

debug crypto ipsec states

debug crypto ipsec message

debug crypto ipsec hw-req

debug crypto gdoi gm infra detail

debug crypto gdoi gm rekey detail

Problemas comuns do ASR1000

Falha de instalação da política IPsec (registro contínuo)

Um ASR1000 GM pode continuar a se registrar no Servidor de chaves se o mecanismo de criptografia não suportar a política ou o algoritmo de IPsec recebido. Por exemplo, em plataformas ASR baseadas em Nitrox (como ASR1002), as políticas Suite-B ou SHA2 não são suportadas e isso pode causar sintomas contínuos de reinscrição.

Problemas comuns de migração/atualização

Limitação de TBAR ASR1000

Na plataforma ASR1000, a correção CSCum37911 da ID de bug da Cisco introduziu uma limitação nesta plataforma onde o tempo TBAR inferior a 20 segundos não é suportado. Consulte Restrições para GETVPN no IOS-XE.

Este bug de aprimoramento foi aberto para levantar essa restrição, ID de bug da Cisco CSCuq25476 - ASR1k precisa suportar um tamanho de janela TBAR de GETVPN inferior a 20 segundos.

Atualizar: Essa restrição foi levantada com a correção para o bug da Cisco ID CSCur57558 , e não é mais uma limitação no código XE3.10.5, XE3.13.2 e posterior.

Observe também que, para um GM executado em plataformas Cisco IOS-XE (ASR1k ou ISR4k), é altamente recomendado que o dispositivo execute uma versão com a correção para esse problema se o TBAR estiver ativado; ID de bug da Cisco CSCut91647 - GETVPN no IOS-XE: O GM descarta pacotes incorretamente devido à falha do TBAR.

Problema de classificação ISR4x00

Uma regressão foi encontrada na plataforma ISR4x00 onde as políticas de negação são ignoradas. Para obter detalhes, consulte o bug da Cisco ID CSCut14355 - GETVPN - ISR4300 GM ignora a política de negação.

Informações Relacionadas

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