Guía de Troubleshooting de GETVPN
Contenido
Introducción
Este documento pretende presentar una metodología estructurada de solución de problemas y herramientas útiles para ayudar a identificar y aislar los problemas de Group Encrypted Transport VPN (GETVPN) y para proporcionar posibles soluciones.
Prerequisites
Requirements
Cisco recomienda que tenga conocimiento sobre estos temas:
- GETVPN
Guía Oficial de Configuración de GETVPN
Guía oficial de diseño e implementación de GETVPN - Uso del servidor Syslog
Componentes Utilizados
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
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.
Metodología de Troubleshooting de GETVPN
Como ocurre con la mayoría de los problemas de tecnología complejos, la clave es poder aislar el problema a una función, subsistema o componente específico. La solución GETVPN consta de varios componentes de funciones, concretamente:
- Intercambio de claves de Internet (IKE): se utiliza entre miembros del grupo (GM) y servidores clave (KS), y entre KS de protocolo cooperativo (COOP) para autenticar y proteger el plano de control.
- Dominio de interpretación de grupo (GDOI): protocolo utilizado para el KS a fin de distribuir claves de grupo y proporcionar servicios clave como la clave para todos los GM.
- COOP - Protocolo utilizado para los KS para comunicarse entre sí y proporcionar redundancia.
- Preservación de encabezados: IPSec en modo túnel que conserva el encabezado del paquete de datos original para la entrega de tráfico de extremo a extremo.
- Time Based Anti-Replay (TBAR): mecanismo de detección de repetición utilizado en un entorno de clave de grupo.
También proporciona un amplio conjunto de herramientas de resolución de problemas para facilitar el proceso de resolución de problemas. Es importante comprender cuáles de estas herramientas están disponibles y cuándo son adecuadas para cada tarea de resolución de problemas. Al solucionar problemas, siempre es una buena idea comenzar con los métodos menos intrusivos para que el entorno de producción no se vea afectado negativamente. La clave para esta solución de problemas estructurada es poder dividir el problema en un problema de plano de datos o de control. Puede hacerlo si sigue el protocolo o el flujo de datos y utiliza las diversas herramientas presentadas aquí para verificarlas.
Topología de referencia
Este esquema de direccionamiento y topología GETVPN se utiliza en el resto de este documento de troubleshooting.
Configuraciones de referencia
- 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
Terminology
- KS: servidor de claves
- MM - Miembro del grupo
- COOP - Protocolo de cooperación
- TBAR - Anti-Reproducción Basada en Tiempo
- KEK - Clave de cifrado
- TEK - Clave de cifrado del tráfico
Preparación de la instalación de registro y otras prácticas recomendadas
Antes de comenzar a solucionar problemas, asegúrese de haber preparado la función de registro como se describe aquí. A continuación se enumeran algunas prácticas recomendadas:
- Verifique la cantidad de memoria libre del router y configure el debugging almacenado en buffer a un valor grande (10 MB o más si es posible).
- Inhabilite el registro en los servidores de consola, monitor y syslog.
- Recupere el contenido del buffer de registro con el comando show log a intervalos regulares, cada 20 minutos a una hora, para evitar la pérdida de registros debido a la reutilización del buffer.
- Pase lo que pase, ingrese el comando show tech de los GM y KS afectados, y examine el resultado del comando show ip route en global y cada Virtual Routing and Forwarding (VRF) involucrado, si es necesario.
- Utilice el protocolo de tiempo de red (NTP) para sincronizar el reloj entre todos los dispositivos que se depuran. Habilite las marcas de tiempo en milisegundos (msec) para los mensajes de depuración y registro:
service timestamps debug datetime msec
service timestamps log datetime msec - Asegúrese de que los resultados del comando show estén marcados con el tiempo.
Router#terminal exec prompt timestamp
- Cuando recopila los resultados del comando show para los eventos del plano de control o los contadores del plano de datos, recopila siempre varias iteraciones del mismo resultado.
Resolución de Problemas del Plano de Control GETVPN
Plano de control significa todos los eventos de protocolo que condujeron a la creación de la política y la Asociación de seguridad (SA) en el GM para que estén listos para cifrar y descifrar el tráfico del plano de datos. Algunos de los puntos de control clave en el plano de control de GETVPN son:
Prácticas recomendadas de depuración del plano de control
Estas prácticas recomendadas de resolución de problemas no son específicas de GETVPN; se aplican a casi cualquier depuración del plano de control. Es fundamental seguir estas prácticas recomendadas para garantizar la resolución de problemas más eficaz:
- Desactive el registro de la consola y utilice el búfer de registro o syslog para recopilar las depuraciones.
- Utilice NTP para sincronizar los relojes del router en todos los dispositivos que se depuran.
- Habilite la marca de tiempo msec para los mensajes de depuración y registro:
service timestamp debug datetime msec
service timestamp log datetime msec - Asegúrese de que las salidas del comando show estén marcadas por el tiempo para que se puedan correlacionar con el resultado de la depuración:
terminal exec prompt timestamp
- Utilice la depuración condicional en un entorno de escala si es posible.
Herramientas de resolución de problemas del plano de control GETVPN
Comandos show GETVPN
Como regla general, estos son los resultados de comandos que debe recopilar para casi todos los 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
Mensajes de Syslog GETVPN
GETVPN proporciona un amplio conjunto de mensajes syslog para eventos de protocolo significativos y condiciones de error. El syslog siempre debe ser el primer lugar para buscar cuando realice la resolución de problemas de GETVPN.
Mensajes de Syslog de KS comunes
| Mensajes de Syslog | Explicación |
|---|---|
| COOP_CONFIG_MISMATCH | La configuración entre el servidor de clave principal y el servidor de clave secundaria no coincide. |
| COOP_KS_ELECTION |
El servidor de claves local ha entrado en el proceso electoral de un grupo. |
| COOP_KS_REACH | Se restablece la disponibilidad entre los servidores de claves cooperativos configurados. |
| COOP_KS_TRANS_TO_PRI | El servidor de claves local pasó a una función principal de ser un servidor secundario en un grupo. |
| COOP_KS_UNAUTH | Un servidor remoto autorizado intentó ponerse en contacto con el servidor de claves local de un grupo, lo que podría considerarse un evento hostil. |
| COOP_KS_UNREACH | Se pierde el alcance entre los servidores de claves cooperativos configurados, lo que podría considerarse un evento hostil. |
| KS_GM_REVOKED | Durante el protocolo rekey, un miembro no autorizado intentó unirse a un grupo, lo que podría considerarse un evento hostil. |
| KS_SEND_MCAST_REKEY | Enviando reclave multicast. |
| KS_SEND_UNICAST_REKEY | Enviando la clave de unidifusión. |
| KS_UNAUTHORIZED | Durante el protocolo de registro GDOI, un miembro no autorizado intentó unirse a un grupo, lo que podría considerarse un evento hostil. |
| UNAUTHORIZED_IPADDR | La solicitud de registro se descartó porque el dispositivo solicitante no estaba autorizado para unirse al grupo. |
Mensajes comunes de Syslog GM
| Mensajes de Syslog | Explicación |
|---|---|
| GM_CLEAR_REGISTER | El miembro del grupo local ha ejecutado el comando clear crypto gdoi. |
| GM_CM_ATTACH | Se ha adjuntado un mapa criptográfico para el miembro del grupo local. |
| GM_CM_DETACH | Se ha desagregado un mapa criptográfico para el miembro del grupo local.& |
| GM_RE_REGISTER | La SA IPsec creada para un grupo puede haber caducado o borrado. Debe volver a registrarse en el servidor de claves. |
| GM_RECV_REKEY | Se ha recibido la nueva clave. |
| GM_REGS_COMPL | Registro completado. |
| GM_REKEY_TRANS_2_MULTI | El miembro del grupo ha pasado de utilizar un mecanismo de reclave de unidifusión a utilizar un mecanismo de multidifusión. |
| GM_REKEY_TRANS_2_UNI | El miembro del grupo ha pasado de utilizar un mecanismo de reclave multidifusión a utilizar un mecanismo de unidifusión. |
| PSEUDO_TIME_LARGE | Un miembro del grupo ha recibido un pseudotime con un valor que es en gran medida diferente a su propio pseudotime. |
| REPLAY_FAILED | Un miembro del grupo o un servidor de claves ha fallado una verificación anti-repetición. |
Depuraciones globales de cifrado y GDOI
Las depuraciones de GETVPN se dividen:
- Primero por el dispositivo en el que está resolviendo 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 - En segundo lugar, por el tipo de problema que 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 - En tercer lugar, por el nivel de depuración que debe habilitarse. En la versión 15.1(3)T y posteriores, todas las depuraciones de características GDOI se estandarizaron para tener estos niveles de depuración. Esto fue diseñado para ayudar a resolver problemas de entornos GETVPN a gran escala con suficiente granularidad de depuración. Cuando depura problemas de GETVPN, es importante utilizar el nivel de depuración adecuado. Como regla general, comience con el nivel de depuración más bajo, es decir, el nivel de error, y aumente la granularidad de depuración cuando sea necesario.
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 levelNivel de depuración Lo que obtendrá Error Condiciones de error Terse Mensajes importantes para el usuario y problemas de protocolo Evento Transiciones de estado y eventos como enviar y recibir claves Detalle Información más detallada del mensaje de depuración Paquete Incluye volcado de información detallada del paquete Todos Todo lo anterior
Depuración condicional GDOI
En Cisco IOS® versión 15.1(3)T y posteriores, se agregó debugging condicional GDOI para ayudar a resolver problemas de GETVPN en un entorno a gran escala. Por lo tanto, todas las depuraciones de la Asociación de seguridad de Internet y del protocolo de administración de claves (ISAKMP) y GDOI se pueden activar ahora con un filtro condicional basado en la dirección IP del grupo o del par. Para la mayoría de los problemas de GETVPN, es bueno habilitar las depuraciones ISAKMP y GDOI con el filtro condicional apropiado, ya que las depuraciones GDOI sólo muestran operaciones específicas de GDOI. Para utilizar las depuraciones condicionales ISAKMP y GDOI, complete estos dos sencillos pasos:
- Establezca el filtro condicional.
- Habilite el ISAKMP y el GDOI relevantes como siempre.
Por ejemplo:
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)
Seguimiento de eventos GDOI
Esto se agregó en la versión 15.1(3)T. El seguimiento de eventos ofrece un seguimiento ligero y siempre activo para eventos y errores GDOI significativos. También hay un seguimiento de trayectoria de salida con seguimiento habilitado para las condiciones de excepción. Los seguimientos de eventos pueden proporcionar más información del historial de eventos GETVPN que los syslogs tradicionales.
Los seguimientos de eventos GDOI se habilitan de forma predeterminada y se pueden recuperar del búfer de seguimiento con el 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
El seguimiento del trayecto de salida proporciona información detallada sobre el trayecto de salida, es decir, las condiciones de excepción y error, con la opción de seguimiento activada de forma predeterminada. A continuación, se pueden utilizar las pistas para decodificar la secuencia de código exacta que ha conducido a la condición de ruta de salida. Utilice la opción detail para recuperar las pistas del búfer de seguimiento:
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
El tamaño predeterminado del búfer de seguimiento es 512 entradas, y esto podría no ser suficiente si el problema es intermitente. Para aumentar este tamaño de entrada de seguimiento predeterminado, los parámetros de configuración de seguimiento de eventos se pueden cambiar como se muestra aquí:
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
Puntos de control del plano de control GETVPN y problemas comunes
Estos son algunos de los problemas comunes del plano de control para GETVPN. Para volver a iterar, el plano de control se define como todos los componentes de la función GETVPN necesarios para habilitar el cifrado y el descifrado del plano de datos en los GM. A un nivel superior, esto requiere un registro GM exitoso, políticas de seguridad y descarga/instalación de SA, y la clave KEK/TEK posterior.
Configuración y creación de políticas de COOP
Para verificar y verificar que el KS ha creado correctamente la política de seguridad y el KEK/TEK asociado, ingrese:
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
Un problema común con la configuración de la política de KS es cuando hay diferentes políticas configuradas entre los KS primarios y los secundarios. Esto puede dar lugar a un comportamiento de KS impredecible y se informará de este error:
%GDOI-3-COOP_CONFIG_MISMATCH: WARNNING: replay method configuration between
Primary KS and Secondary KS are mismatched
Actualmente no hay sincronización de configuración automática entre los KS primarios y secundarios, por lo que se deben rectificar manualmente.
Debido a que COOP es una configuración crítica (y casi siempre obligatoria) para GETVPN, es fundamental asegurarse de que COOP funcione correctamente y de que las funciones de COOP KS sean correctas:
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
En una configuración de COOP funcional, se debe observar este flujo de protocolo:
Intercambio IKE > ANN con prioridades COOP intercambiadas > Elección COOP > ANN de KS primario a secundario (políticas, bases de datos GM y claves)
Cuando COOP no funciona correctamente, o si hay una división COOP, como que varios KS se conviertan en el KS principal, estos debugs se deben recopilar para la resolución de problemas:
debug crypto isakmp
debug crypto gdoi ks coop all-levels
show crypto isakmp sa
show crypto gdoi ks coop
Configuración IKE
Se requiere un intercambio IKE exitoso para GETVPN para asegurar el canal de control para la política posterior y la descarga SA. Al final del intercambio IKE exitoso, se crea un GDOI_REKEY sa.
En las versiones anteriores a Cisco IOS 15.4(1)T, GDOI_REKEY se puede mostrar con el 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#
En Cisco IOS 15.4(1)T y versiones posteriores, este GDOI_REKEY como se muestra con el 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
El intercambio IKE para GETVPN no es diferente del IKE utilizado en los túneles IPsec punto a punto tradicionales, por lo que el método de solución de problemas sigue siendo el mismo. Estos debugs se deben recopilar para resolver problemas de autenticación 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, descarga de políticas e instalación de SA
Una vez que la autenticación IKE se realiza correctamente, GM se registra con el KS. Se espera que estos mensajes de syslog se vean cuando esto ocurre correctamente:
%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
La política y las claves se pueden verificar con 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#
Con el registro de GETVPN y el tipo de instalación de políticas, estos debugs son necesarios para resolver 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)
Dado que el registro de GETVPN normalmente ocurre inmediatamente después de la recarga GM, este script EEM podría ser útil para recopilar estos debugs:
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
Una vez que los GM se registran en el KS y la red GETVPN está configurada correctamente, el KS primario es responsable de enviar mensajes de clave nueva a todos los GM registrados en él. Los mensajes de nueva clave se utilizan para sincronizar todas las políticas, claves y pseudotimes en los GM. Los mensajes de nueva clave se pueden enviar a través de un método unicast o multicast.
Este mensaje de syslog se ve en el KS cuando se envía el mensaje rekey:
%GDOI-5-KS_SEND_UNICAST_REKEY: Sending Unicast Rekey for group G1 from address
10.1.11.2 with seq # 11
En los GM, este es el syslog que se ve cuando recibe la clave de nuevo:
%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 claves RSA para la clave de nuevo en KS
La funcionalidad Rekey requiere la presencia de claves RSA en el KS. El KS proporciona la clave pública del par de claves RSA al GM a través de este canal seguro durante el registro. A continuación, el KS firma los mensajes GDOI enviados al GM con la clave RSA privada en la carga útil GDOI SIG. El MM recibe los mensajes GDOI y utiliza la clave RSA pública para verificar el mensaje. Los mensajes entre el SK y el MM se cifran con el KEK, que también se distribuye al MM durante el registro. Una vez que se complete el registro, las llaves posteriores se cifran con el KEK y se firman con la clave RSA privada.
Si la clave RSA no está presente en el KS durante el registro GM, este mensaje aparece en el syslog:
%GDOI-1-KS_NO_RSA_KEYS: RSA Key - get : Not found, Required for group G1
Cuando las claves no están presentes en el KS, el GM se registra por primera vez, pero la próxima clave falla del KS. Con el tiempo, caducan las claves existentes del MM y vuelve a registrarse.
%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.
Dado que el par de llaves RSA se utiliza para firmar los mensajes de rekey, DEBEN ser los mismos entre el KS primario y todos los KS secundarios. Esto asegura que durante una falla primaria de KS, las llaves enviadas por un KS secundario (el nuevo KS primario) aún puedan ser validadas adecuadamente por los GM. Cuando genera el par de claves RSA en el KS primario, el par de claves debe crearse con la opción exportable para que puedan exportarse a todos los KS secundarios para cumplir este requisito.
Resolución de problemas de reclave
La falla de reclave KEK/TEK es uno de los problemas de GETVPN más comunes que se producen en las implementaciones de los clientes. La resolución de problemas de reclave debe seguir los pasos clave descritos a continuación:
- ¿Las llaves fueron enviadas por el KS?
Esto se puede verificar con una observación del mensaje de syslog %GDOI-5-KS_SEND_UNICAST_REKEY o más exactamente con 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
El número de llaves retransmitidas es indicativo de paquetes de reconocimiento de reclave que no recibe el KS y, por lo tanto, posibles problemas de reclave. Tenga en cuenta que el GDOI vuelve a utilizar el UDP como un mecanismo de transporte poco fiable, por lo que se podrían esperar algunas caídas de clave en función de la fiabilidad de la red de transporte subyacente, pero siempre debería investigarse una tendencia al aumento de las retransmisiones de clave nueva.
También se pueden obtener estadísticas más detalladas sobre las claves modificadas por MM. Este suele ser el primer lugar en el que buscar posibles problemas clave.
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 - ¿Se entregaron los paquetes de nueva clave en la red de infraestructura subyacente?
Se debe seguir la resolución de problemas de IP estándar a lo largo de la trayectoria de reenvío de llaves para asegurarse de que los paquetes de nueva llave no se descarten en la red de tránsito entre KS y GM. Algunas de las herramientas de solución de problemas más comunes que se utilizan aquí son las listas de control de acceso (ACL) de entrada/salida, Netflow y captura de paquetes en la red de tránsito. - ¿Los paquetes de nueva clave alcanzaron el proceso GDOI para el procesamiento de nueva clave?
Consulte las estadísticas de reclave 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 - ¿El paquete de reconocimiento de nueva clave regresó al KS?
Siga los pasos 1 a 3 para rastrear el paquete de reconocimiento de nueva clave desde el GM de vuelta al KS.
Clave de multidifusión
La clave de multidifusión es diferente de la clave de unidifusión en estos aspectos:
- Debido a que multicast se utiliza para transportar estos paquetes de nueva clave del KS a los GMs, el KS no necesita replicar los paquetes de nueva clave en sí. El KS sólo envía una copia del paquete de nueva clave y se replican en la red habilitada para multicast.
- No hay un mecanismo de reconocimiento para la reclave multicast, así que si un GM no recibiera el paquete de reclave, el KS no tendría conocimiento de él, y por lo tanto nunca eliminará un GM de su base de datos GM. Y debido a que no hay reconocimiento, el KS siempre retransmitirá los paquetes de retransmisión en función de su configuración de retransmisión de retransmisión de clave.
El problema de reclave multicast más visto es cuando la nueva clave no se recibe en el GM. Podría haber varias causas posibles para ello, como las siguientes:
- Problema de entrega de paquetes dentro de la infraestructura de ruteo multicast
- El ruteo de multidifusión de extremo a extremo no está habilitado en la red
El primer paso para resolver un problema con la reclave multicast es ver si la reclave funciona cuando se conmuta del método multicast al método unicast.
Una vez que identifique que el problema es específico de la reclave multicast, verifique que el KS envíe la nueva clave a la dirección multicast especificada.
%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
Pruebe la conectividad de multidifusión entre el KS y el GM con una solicitud de protocolo de mensajes de control de Internet (ICMP) a la dirección de multidifusión. Todos los GM que forman parte del grupo multicast deben responder al ping. Asegúrese de que el ICMP esté excluido de la política de encripción de KS para esta prueba.
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
Si la prueba de ping multicast falla, se debe realizar la resolución de problemas de multidifusión, que está fuera del alcance de este documento.
Comprobación del relé del plano de control
Síntoma
Cuando los clientes actualizan su GM a una nueva versión de Cisco IOS, podrían experimentar fallas de clave de KEK con este mensaje observado en 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
Este comportamiento se debe a un problema de interoperabilidad introducido con la verificación anti-repetición que se agrega para los mensajes del plano de control. Específicamente, un KS que ejecute el código más antiguo restablecerá el número de secuencia de reclave KEK en 1, y esto será descartado por el GM que ejecuta el nuevo código cuando lo interpreta como un paquete de nueva clave reproducido. Para obtener más detalles, vea Cisco bug ID CSCta05809 (GETVPN: Plano de control GETVPN sensible a la repetición), y Restricciones de Configuración de GETVPN.
Background
Con GETVPN, los mensajes del Plano de control pueden transportar información que distingue el tiempo para proporcionar el servicio de verificación anti-repetición basado en el tiempo. Por lo tanto, estos mensajes requieren protección anti-repetición por sí mismos para garantizar la precisión del tiempo. Estos mensajes son:
- Volver a introducir mensajes de KS a GM
- Mensajes de anuncio de COOP entre KS
Como parte de esta implementación de protección anti-reproducción, se agregaron verificaciones de número de secuencia para proteger los mensajes reproducidos, así como una verificación pseudotime cuando TBAR está habilitado.
Solución
Para resolver este problema, tanto el GM como el KS deben actualizarse a las versiones de Cisco IOS después de la función de verificación de la repetición del plano de control. Con el nuevo código de Cisco IOS, KS no reinicia el número de secuencia nuevamente a 1 para una nueva clave KEK, sino que continúa usando el número de secuencia actual y sólo restablece el número de secuencia para las nuevas claves TEK.
Estas versiones de Cisco IOS tienen las funciones Replay Check:
- 12.4(15)T10
- 12.4(22)T3
- 12.4(24)T2
- 15.0(1)M y posteriores
Otros problemas relacionados con la reproducción
- Falla de COOP debido a que los mensajes ANN fallan en la verificación de la repetición (Id. de bug Cisco CSCtc52655)
Fallas de reproducción del plano de control de depuración
Para otros errores de Reproducción del Plano de Control, recopile esta información y asegúrese de que los tiempos se sincronizan entre el KS y el GM.
- Syslog de GM y KS
- Depuraciones ISAKMP
- Depuraciones de GDOI (reclave y reproducción) tanto de KS como de GM
Problemas de fragmentación de paquetes del plano de control
Con GETVPN, la fragmentación de paquetes del plano de control es un problema común y puede manifestarse en uno de estos dos escenarios cuando los paquetes del plano de control son lo suficientemente grandes como para requerir la fragmentación de IP:
- Paquetes de anuncio GETVPN COOP
- GETVPN rekey packets
Paquetes de anuncio de COOP
Los paquetes de anuncio COOP llevan la información de la base de datos GM y, por lo tanto, pueden crecer en una implementación GETVPN de gran tamaño. A partir de la experiencia anterior, una red GETVPN que consta de más de 1500 GM producirá paquetes de anuncio de más de 18024 bytes, que es el tamaño de búfer Enorme predeterminado de Cisco IOS. Cuando esto sucede, el KS no puede asignar un búfer lo suficientemente grande como para transmitir los paquetes ANN con este error:
%SYS-2-GETBUF: Bad getbuffer, bytes= 18872 -Process= "Crypto IKMP", ipl= 0, pid= 183
Para rectificar esta condición, se recomienda este ajuste del búfer:
buffers huge permanent 10
buffers huge size 65535
Volver a Teclar Paquetes
Los paquetes de nueva clave GETVPN también pueden superar el tamaño típico de la unidad de transición máxima (MTU) de IP 1500 cuando la política de cifrado es grande, como una política que consta de más de 8 líneas de entradas de control de acceso (ACE) en la ACL de cifrado.
Problema de fragmentación e identificación
En ambos escenarios anteriores, GETVPN debe poder transmitir y recibir correctamente los paquetes UDP fragmentados para que COOP o GDOI vuelvan a funcionar correctamente. La fragmentación de IP puede ser un problema en algunos entornos de red. Por ejemplo, una red que consta de un plano de reenvío de ruta múltiple de igual coste (ECMP) y algunos dispositivos del plano de reenvío requieren un reensamblado virtual de los paquetes IP fragmentados, como el reensamblado de fragmentación virtual (VFR).
Para identificar el problema, verifique los errores de reensamblado en el dispositivo donde se sospecha que los paquetes UDP 848 fragmentados no se reciben correctamente:
KS1#show ip traffic | section Frags
Frags: 10 reassembled, 3 timeouts, 0 couldn't reassemble
0 fragmented, 0 fragments, 0 couldn't fragment
Si los tiempos de espera de reensamblado continúan aumentando, utilice el comando debug ip error para confirmar si la caída es parte del flujo de paquetes de rekey/COOP. Una vez confirmada, se debe realizar la resolución de problemas de reenvío IP normal para aislar el dispositivo exacto en el plano de reenvío que podría haber descartado los paquetes. Algunas de las herramientas más utilizadas son:
- Captura de paquete
- Estadísticas de reenvío de tráfico
- Estadísticas de funciones de seguridad (Firewall, IPS)
- estadísticas VFR
Problemas de Interoperabilidad de GDOI
A lo largo de los años se han encontrado varios problemas de interoperabilidad con GETVPN, y es fundamental observar las versiones de Cisco IOS entre KS y GM y entre los KS para los problemas de interoperabilidad.
Otros problemas conocidos de interoperabilidad con GETVPN son:
- Comprobación del relé del plano de control
- Cambio de comportamiento de clave nueva de KEK de GETVPN
- Id. de bug Cisco CSCub42920 (GETVPN: KS no puede validar el hash en ACK de nueva clave de versiones GM anteriores)
- El Id. de bug Cisco CSCuw48400 (GetVPN GM no puede registrarse o falla la clave - sig-hash > SHA-1 predeterminado)
- Id. de error de Cisco CSCvg19281 ( Múltiples caídas de GETVPN GM después de la migración al nuevo par KS ; si una versión GM es anterior a 3.16 y KS se actualiza de un código anterior a 3.16 o posterior, este problema puede ocurrir)
Procedimiento de actualización de GETVPN IOS
Este procedimiento de actualización de Cisco IOS debe seguirse cuando se necesita realizar una actualización de código de Cisco IOS en un entorno GETVPN:
- Actualice primero un KS secundario y espere hasta que se complete la elección de COOP KS.
- Repita el paso 1 para todos los KS secundarios.
- Actualice el KS primario.
- Actualizar los GM.
Solución de problemas del plano de datos GETVPN
En comparación con los problemas del plano de control, los problemas del plano de datos GETVPN son problemas en los que el GM tiene la política y las claves para realizar el cifrado y el descifrado del plano de datos, pero por alguna razón el flujo de tráfico de extremo a extremo no funciona. La mayoría de los problemas del plano de datos para GETVPN se relacionan con el reenvío de IPSec genérico y no son específicos de GETVPN. Por lo tanto, la mayor parte del enfoque de solución de problemas descrito aquí se aplica también a los problemas genéricos del plano de datos IPsec.
Con los problemas de cifrado (tanto en túneles basados en grupo como en túneles de par), es importante solucionar el problema y aislar el problema en una parte determinada del datapath. Específicamente, el enfoque de solución de problemas que se describe aquí tiene como objetivo ayudarle a responder a estas preguntas:
- ¿Qué dispositivo es el culpable: el router de cifrado o el router de descifrado?
- ¿En qué dirección está ocurriendo el problema: el ingreso o la salida?
Herramientas de resolución de problemas del plano de datos GETVPN
La resolución de problemas del plano de datos IPSec es muy diferente de la del plano de control. Con el plano de datos, normalmente no hay depuraciones que pueda ejecutar o, al menos, ejecutar de forma segura en un entorno de producción. Por lo tanto, la resolución de problemas depende en gran medida de diferentes contadores y estadísticas de tráfico que pueden ayudar a rastrear el paquete a lo largo de una trayectoria de reenvío. La idea es ser capaz de desarrollar un conjunto de puntos de control para ayudar a aislar donde los paquetes pueden ser descartados, como se muestra aquí:
Estas son algunas de las herramientas de depuración del plano de datos:
- Listas de acceso
- Contabilización de Precedencia de IP
- Netflow
- Contadores de interfaz
- Contadores criptográficos
- Contadores de caídas globales y por función de IP Cisco Express Forwarding (CEF)
- Captura de paquetes integrada (EPC)
- Depuraciones del plano de datos (depuraciones de CEF y paquetes IP)
Los puntos de control de la ruta de datos de la imagen anterior se pueden validar con estas herramientas:
Cifrado de GM
- Interfaz LAN de ingreso
ACL de entrada
NetFlow de ingreso
Captura de paquetes integrada
Contabilidad de precedencia de entrada - Motor criptográfico
show crypto ipsec sa
show crypto ipsec sa detail
show crypto engine Accelerator statistics - Interfaz WAN de salida
NetFlow de salida
Captura de paquetes integrada
Contabilidad de precedencia de salida
Descifrado de GM
- Interfaz WAN de entrada
ACL de entrada
NetFlow de ingreso
Captura de paquetes integrada
Contabilidad de precedencia de entrada - Motor criptográfico
show crypto ipsec sa
show crypto ipsec sa detail
show crypto engine Accelerator statistics - Interfaz LAN de salida
NetFlow de salida
Captura de paquetes integrada
El trayecto de retorno sigue el mismo flujo de tráfico. Las secciones siguientes tienen algunos ejemplos de estas herramientas de plano de datos en uso.
Contadores de cifrado/descifrado
Los contadores de cifrado/descifrado en un router se basan en un flujo IPsec. Desafortunadamente, esto no funciona bien con GETVPN, ya que GETVPN normalmente implementa una política de cifrado "permit ip any any" que cifra todo. Por lo tanto, si el problema sólo ocurre para algunos de los flujos y no todos, estos contadores pueden ser algo difíciles de usar para evaluar correctamente si los paquetes están cifrados o descifrados cuando hay suficiente tráfico de fondo significativo que funcione.
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
Netflow se puede utilizar para monitorear tanto el tráfico de entrada como de salida en ambos GM. Tenga en cuenta que con GETVPN permit ip any any policy, el tráfico cifrado se agregará y no proporciona la información por flujo. La información por flujo entonces deberá recopilarse con el marcado DSCP/precedencia descrito más adelante.
En este ejemplo, el netflow para un ping de recuento de 100 de un host detrás de GM1 a un host detrás de GM2 se muestra en los diversos puntos de control.
Cifrado de GM
Configuración de 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
Salida de 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#
Descifrado de GM
Configuración:
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
Salida de 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#
Marcación de precedencia DSCP/IP
El desafío de solucionar un problema de cifrado es que una vez que el paquete se cifra, se pierde visibilidad en la carga útil, que es lo que se supone que debe hacer el cifrado, y eso dificulta el seguimiento del paquete para un flujo IP determinado. Hay dos maneras de abordar esta limitación cuando se trata de resolver un problema de IPSec:
- Utilice ESP-NULL como transformación IPsec. IPSec todavía realiza la encapsulación ESP pero no se aplica ningún cifrado a la carga útil, por lo que son visibles en una captura de paquetes.
- Marque un flujo IP con un único punto de código de servicios diferenciados (DSCP)/marcado de precedencia basado en sus características de L3/L4.
ESP-NULL requiere cambios en ambos puntos finales del túnel y a menudo no se permite según la política de seguridad del cliente. Por lo tanto, Cisco normalmente recomienda el uso de marcado DSCP/precedencia en su lugar.
Tabla de referencia de DSCP/Precedencia
| ToS (hexadecimal) | ToS(Decimal) | Precedencia IP | DSCP | Binario |
|---|---|---|---|---|
| 0xE0 | 224 | 7 Control de red | 56 CS7 | 11100000 |
| 0xC0 | 192 | 6 Control entre redes | 48 CS6 | 11000000 |
| 0xB8 | 184 | 5 Críticos | 46 EF | 10111000 |
| 0xA0 | 160 | 40 CS5 | 10100000 | |
| 0x88 | 136 | 4 anulación de Flash | 34 AF41 | 10001000 |
| 0x80 | 128 | 32 CS4 | 10000000 | |
| 0x68 | 104 | 3 Flash | 26 AF31 | 01101000 |
| 0x60 | 96 | 24 CS3 | 01100000 | |
| 0x48 | 72 | 2 Inmediato | 18 AF21 | 01001000 |
| 0x40 | 64 | 16 CS2 | 01000000 | |
| 0x20 | 32 | 1 prioridad | 8 CS1 | 00100000 |
| 0x00 | 0 | 0 Rutina | 0 Dflt | 00000000 |
Marcar paquetes con DSCP/precedencia
Estos métodos se utilizan normalmente para marcar los paquetes con las marcas de DSCP/precedencia específicas.
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 del router
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>
Supervisar paquetes marcados
Contabilización de Precedencia 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
ACL de interfaz
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 paquetes integrada
La captura de paquetes integrada (EPC) es una herramienta útil para capturar paquetes en el nivel de interfaz con el fin de identificar si un paquete ha alcanzado un dispositivo específico. Recuerde que EPC funciona bien para el tráfico de texto sin cifrar, pero puede ser un desafío cuando los paquetes capturados se cifran. Por lo tanto, las técnicas como el marcado de precedencia/DSCP discutidas anteriormente u otros caracteres IP, como la longitud del paquete IP, deben utilizarse junto con EPC para que la resolución de problemas sea más eficaz.
Seguimiento de paquetes Cisco IOS-XE
Esta es una función útil para rastrear la trayectoria de reenvío de funciones en todas las plataformas que ejecutan Cisco IOS-XE, como CSR1000v, ASR1000 e ISR4451-X.
Problemas comunes del plano de datos GETVPN
La resolución de problemas del plano de datos IPsec para GETVPN no difiere en gran medida de la resolución de problemas tradicionales del plano de datos IPsec punto a punto, con dos excepciones debido a estas propiedades únicas del plano de datos de GETVPN.
Falla Anti-Replay Basada en Tiempo
En una red GETVPN, las fallas de TBAR a menudo pueden ser difíciles de resolver, ya que ya no hay túneles por pares. Para resolver problemas de fallas de GETVPN TBAR, complete estos pasos:
- Identifique qué paquete se descarta debido a una falla de TBAR y posteriormente identifique el GM de cifrado.
Antes de la versión 15.3(2)T, el syslog de falla TBAR no imprimió la dirección de origen del paquete fallido, por lo que esto hace muy difícil identificar qué paquete falló. Esto se ha mejorado significativamente en la versión 15.3(2)T y posteriores, donde Cisco IOS imprime esto:
%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
También se implementó un historial TBAR en esta versión:
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
Para las versiones de Cisco IOS que no tienen esta función, debug crypto gdoi gm replay detail también puede proporcionar esta información, aunque este debug imprime la información TBAR para todo el tráfico (no sólo los paquetes descartados debido a una falla de TBAR), por lo que puede que no sea factible ejecutarse en un entorno de producción.
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 - Una vez que se identifica el origen del paquete, debería poder encontrar el GM de cifrado. A continuación, se debe supervisar la indicación de pseudotimestamp tanto en los GM de cifrado como de descifrado para detectar cualquier posible desviación de pseudotime. La mejor manera de hacerlo sería sincronizar tanto los GM como los KS con los NTP y recopilar periódicamente la información sobre el pseudotime con un reloj del sistema de referencia en todos ellos para determinar si el problema es causado por la desviación del reloj en los GM.
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
En el ejemplo anterior, si el pseudotime (como indica Replay Value) es significativamente diferente entre los GM cuando los resultados se capturan con el mismo tiempo de referencia, el problema puede atribuirse a la desviación del reloj.
PMTUD y Preservación del encabezado GETVPN
Con GETVPN, Path MTU Discovery (PMTUD) no funciona entre los GM de cifrado y descifrado, y los paquetes grandes con el conjunto de bits Don't Fragment (DF) pueden quedar en la lista negra. La razón por la que esto no funciona se debe a la Preservación del encabezado GETVPN, donde las direcciones de origen/destino de datos se conservan en el encabezado de encapsulación ESP. Esto se ilustra en esta imagen:
Como muestra la imagen, PMTUD se rompe con GETVPN con este flujo:
- El paquete de datos de gran tamaño llega con el GM1 de cifrado.
- El paquete ESP post-encripción se reenvía fuera de GM1 y se entrega hacia el destino.
- Si hay un link de tránsito con una MTU IP de 1400 bytes, el paquete ESP se descartará y se enviará un mensaje de paquete ICMP 3/4 demasiado grande hacia el origen del paquete, que es el origen del paquete de datos.
- El paquete ICMP3/4 se descarta debido a que el ICMP no se excluye de la política de encripción de GETVPN, o bien es descartado por el host final ya que no sabe nada acerca del paquete ESP (carga útil no autenticada).
En resumen, PMTUD no funciona con GETVPN hoy. Para solucionar este problema, Cisco recomienda estos pasos:
- Implemente "ip tcp adjust-mss" para reducir el tamaño del segmento de paquete TCP para acomodar la sobrecarga de cifrado y la MTU de trayectoria mínima en la red de tránsito.
- Borre el bit DF en el paquete de datos a medida que llegan en el GM de cifrado para evitar PMTUD.
Problemas genéricos del plano de datos IPsec
La mayor parte de la solución de problemas del plano de datos IPsec es como la solución de problemas de túneles IPsec punto a punto tradicionales. Uno de los problemas comunes es %CRYPTO-4-RECVD_PKT_MAC_ERR. Consulte Mensaje de Error de Syslog "%CRYPTO-4-RECVD_PKT_MAC_ERR:" Resolución de Problemas de Ping Loss Over IPsec Tunnel para obtener más detalles de troubleshooting.
Problemas conocidos
Este mensaje se puede generar cuando se recibe un paquete IPSec que no coincide con un SPI en la SADB. Consulte Cisco bug ID CSCtd47420 - GETVPN - CRYPTO-4-RECVD_PKT_NOT_IPSEC informado para pkt que no coincide con el flujo. Se presenta un ejemplo a continuación:
%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
Este mensaje debe ser %CRYPTO-4-RECVD_PKT_INV_SPI, que es lo que se informa para IPsec tradicional así como en algunas plataformas de hardware como ASR. Este problema superficial fue corregido por el ID de bug de Cisco CSCup80547: Error al informar de CRYPTO-4-RECVD_PKT_NOT_IPSEC para el PAK ESP.
En este caso, el GM no puede descifrar el tráfico GETVPN, aunque tiene una SA IPsec válida en la SADB (se reescribe la SA). El problema desaparece tan pronto como caduca la SA y se elimina de la SADB. Este problema provoca una interrupción significativa, porque la reclave TEK se realiza por adelantado. Por ejemplo, la interrupción puede ser de 22 minutos en el caso de una duración TEK de 7200 segundos. Consulte la descripción del bug para ver la condición exacta que debe cumplirse para encontrar este bug.
Resolución de Problemas de GETVPN en Plataformas que Ejecutan Cisco IOS-XE
Comandos para resolución de problemas
Las plataformas que ejecutan Cisco IOS-XE tienen implementaciones específicas de la plataforma y a menudo requieren depuración específica de la plataforma para problemas de GETVPN. A continuación se muestra una lista de comandos que se utilizan habitualmente para resolver problemas de GETVPN en estas plataformas:
show crypto eli all
show platform software ipsec policy statistics
show platform software ipsec fp active Inventory
show platform hardware qfp active feature ipsec spd all
show platform hardware qfp active statistics drop clear
show platform hardware qfp active 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 state
debug crypto ipsec message
debug crypto ipsec hw-req
debug crypto gdoi gm infra detail
debug crypto gdoi gm rekey detail
Problemas comunes de ASR1000
Falla de instalación de la política IPsec (registro continuo)
Un GM ASR1000 podría continuar registrándose en el Servidor de claves si el motor de criptografía no soporta la política o el algoritmo IPsec recibidos. Por ejemplo, en las plataformas ASR basadas en Nitrox (como ASR1002), las políticas Suite-B o SHA2 no se soportan y esto puede causar los síntomas de reregistro continuo.
Problemas comunes de migración/actualización
Limitación del TBAR ASR 1000
En la plataforma ASR1000, el ID de bug de Cisco CSCum37911 corrección introdujo una limitación en esta plataforma donde el tiempo TBAR de menos de 20 segundos no es soportado. Vea Restricciones para GETVPN en IOS-XE.
Este error de mejora se ha abierto para levantar esta restricción, Id. de bug Cisco CSCuq25476 - ASR1k necesita soportar un tamaño de ventana TBAR GETVPN de menos de 20 segundos.
Actualización: Esta restricción se ha levantado con la corrección para el Id. de bug Cisco CSCur57558 y ya no es una limitación en el código XE3.10.5, XE3.13.2 y posterior.
Tenga en cuenta que, para un GM que se ejecute en plataformas Cisco IOS-XE (ASR1k o ISR4k), se recomienda encarecidamente que el dispositivo ejecute una versión con la corrección para este problema si TBAR está habilitado; Id. de bug Cisco CSCut91647 - GETVPN en IOS-XE: GM descarta los paquetes incorrectamente debido a una falla de TBAR.
Problema de clasificación de ISR4x00
Se encontró una regresión en la plataforma ISR4x00 donde se ignoran las políticas de negación. Para obtener más información, vea Cisco bug ID CSCut14355 - GETVPN - ISR4300 GM ignora la política de negación.
Información Relacionada
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)