Solución de problemas de conectividad del IPsec Site

Visión general

La conectividad es primordial para el acceso a la WAN a través del Cato Cloud para las redes detrás de un IPsec. La falta de conectividad de un IPsec Site puede interrumpir las funciones empresariales. Este manual busca guiar la solución de problemas en este escenario.

Síntomas

Una falla en la conectividad IPsec puede determinarse de las siguientes maneras. Un administrador puede notar los siguientes síntomas:

• El sitio IPsec está desconectado en CMA 
  
• Historial de inestabilidad en la conexión
• Rendimiento deficiente para el tráfico que atraviesa la conexión IPsec

Causas posibles

Las siguientes son posibles causas que se pueden identificar durante la resolución de problemas.

• Conectividad de pares
  • Esto incluye la capacidad de los pares para alcanzarse continuamente sobre la base L3.
• Desajuste de configuración IPsec
  • Los desajustes en conjuntos de transformación o autenticación pueden causar que los túneles no se formen en absoluto o que fallen antes de que se complete una reconexión
• Rendimiento del subyacente
  • IPsec se basa en una conexión subyacente estable para un rendimiento satisfactorio dentro del túnel.

Solucionar el problema

Los pasos para resolver los síntomas que un administrador puede encontrar se listan a continuación. Estos pasos están destinados a identificar posibles causas de los problemas enfrentados. Los pasos de resolución se destacarán más adelante en el manual.

Solución de problemas de IPsec Site desconectado o inestable en CMA

Reunir Información de los Eventos

Usando la página de Inicio > Eventos en CMA, un administrador puede obtener rápidamente un historial de eventos de conectividad para sitios IPsec dentro de una cuenta. Los eventos se pueden filtrar hasta los eventos relevantes seleccionando el ajuste preestablecido 'Estado de conectividad de Sites' o filtrando por tipo de evento 'Conectividad' y subtipo 'Desconectado'. Puede filtrar además por el nombre del Site en cuestión con el campo 'Site de origen' o bien usar el valor del protocolo de túnel 'IPSEC' para filtrar todos los IPsec Sites.

Ver la marca de tiempo del evento de desconexión relevante desde el Site en cuestión puede ayudar a enfocar la investigación. ¿Hubo otros eventos de redes más amplios o eventos de energía local conocidos que ocurrieron en esta marca de tiempo? ¿Hay algún cambio en el historial de auditoría que preceda esto y pueda estar correlacionado?

Si no se encuentra un evento de desconexión y el túnel aún se informa como inestable, es posible que el problema ocurra en el momento de un proceso de reconexión debido a parámetros desajustados entre Cato y el par remoto. Continúe con los pasos a continuación para un análisis más detallado.

Ver el historial de conexión IPsec del Site

La línea de tiempo disponible en Red > Sitio > Configuración de Sitio > IPsec es esencial para solucionar problemas de sitios IPsec desconectados.

El CSV proporcionado por el botón Línea de tiempo dará un historial de registros de túneles relevantes. Estos registros pueden proporcionar indicaciones claras de los problemas que pueden estar causando la falta de conectividad en la conexión IPsec. A continuación se presentan ejemplos comunes de mensajes indicativos:

Los mensajes que sugieren que los selectores de tráfico no coinciden son evidencia de un desajuste de configuración entre las configuraciones de fase 2 de los pares, específicamente respecto a las subredes que estarán disponibles en cada lado del emparejamiento IPsec. Si ve errores que sugieren que este es el caso, navegue a Resolver desajuste de configuración IPsec.

Los mensajes anteriores también indican un desajuste de configuración, esta vez con las cargas de autenticación. Por supuesto, el PSK necesita coincidir con estas cargas para que la conexión sea exitosa. Si esto es evidente en cualquier intento de conexión, navegue a Resolver desajuste de configuración IPsec.

La línea de tiempo anterior muestra un intento de conexión con un par configurado, el cual no recibió respuesta. Se puede ver en esta línea de tiempo que no ocurrió ninguna interacción con el par, y el SA fue cerrado debido a inactividad. Esto suele ser el caso cuando no hay alcance L3 al par remoto. En estos casos, vea el Resolver conectividad de pares.

Puede encontrar una lista completa de posibles mensajes de error de línea de tiempo para IKEv1 e IKEv2 aquí.

Uso de capturas de paquetes para solucionar problemas

Además, en la página de Red > Sitio > Configuración del Sitio > IPsec se encuentra la herramienta de captura de paquetes. Esto ayudará a proporcionar rastreos de paquetes del tráfico de control entre los pares. Los problemas destacados anteriormente también están representados en estas capturas de paquetes.

TS_UNACCEPTABLE

Para subconjuntos discordantes dentro de un conjunto de transformación, los paquetes informativos indicarán un error. En este ejemplo de IKEv2, el mensaje informativo TS_UNACCEPTABLE es sintomático de una discordancia en la configuración dentro del conjunto de transformación. Para solucionar este problema, navegue a Resolviendo la discordancia de configuración de IPsec.

NO_PROPOSAL_CHOSEN

Para parámetros desajustados dentro de la asociación de seguridad, cualquiera de los pares incluirá un error dentro de la carga útil. En este ejemplo de IKEv2, el error NO-PROPOSAL-CHOSEN indica claramente que uno de los algoritmos o grupos DH configurados en CMA no coincide con la configuración del par remoto. Esto puede ocurrir durante el establecimiento inicial del túnel o el proceso de reconexión.

AUTHENTICATION_FAILED

La captura a continuación muestra otro ejemplo de IKEv2, esta vez uno en el que la PSK utilizada para la autenticación no coincidió:

Paquetes Unidireccionales

Las capturas de paquetes también pueden ayudar a identificar problemas de conectividad a nivel IP con pares. En el ejemplo a continuación, la captura de paquetes solo muestra tráfico saliente unidireccional, lo que sugiere que el par es inaccesible. Si un administrador en solución de problemas ve un par inaccesible, navegue a Resolver conectividad de pares.

En cualquiera de los casos anteriores u otros indicadores de desajuste de configuración entre pares en IKEv1 o IKEv2, navegue a Resolver desajuste de configuración IPsec.

Resolución de problemas de rendimiento deficiente sobre VPN

Si se observa un rendimiento deficiente sobre la VPN, generalmente se manifiesta en forma de pérdida de paquetes, alta latencia o desconexiones frecuentes.

La pérdida de paquetes se verá en el tráfico que pasa por el túnel a través de las aplicaciones que se vean afectadas y puede confirmarse probando con sondeos ICMP de un host a otro a través de la conexión IPsec.

La latencia y las desconexiones de túnel también serán evidentes en el rendimiento de la aplicación y también pueden determinarse a través de la página Red > Monitoreo de Sitio > Analíticas de Red para el sitio en cuestión.

Si se identifican problemas de rendimiento, navegue a Resolver rendimiento del subyacente.

Caída de paquetes en Azure IPsec

Al configurar IPsec con Azure, el rendimiento del túnel y los paquetes por segundo (PPS) están determinados por el SKU del gateway VPN y los algoritmos de encriptación empleados. Por ejemplo, según la documentación de Microsoft, el gateway VpnGw3 Generation2, al usar GCMAES256, puede manejar hasta 140.000 paquetes por segundo (PPS).

Si el tráfico supera estos umbrales, Azure descartará automáticamente los paquetes excedentes, lo que puede causar una degradación notable del rendimiento. Un síntoma común es la reducción en el rendimiento, que puede aparecer en CMA's Network Analytics como una caída en el volumen de tráfico. Sin embargo, una forma más precisa de diagnosticar esto es monitoreando métricas del gateway VPN directamente dentro del portal de Azure, que proporciona información en tiempo real sobre el rendimiento del túnel y los valores de PPS para la conexión VPN afectada.

Para mitigar este problema, puede considerar actualizar a un SKU de IPsec más alto o implementar un Azure vSocket, ambos pueden mejorar la capacidad de su túnel VPN y prevenir caídas de paquetes debido a sobrecarga de tráfico.

Resolución de problemas descubiertos

Resolución de conectividad de pares

Para escenarios en los cuales el par IPsec no está enviando paquetes al PoP, mostrado a través de entradas de línea de tiempo o capturas de paquetes, asegúrese de que se haya configurado al par remoto para conectar a la misma dirección IP asignada al túnel en CMA.

Si esta configuración está confirmada, asegúrese de que el par remoto pueda atravesar conexiones limitadas por NAT respondiendo al tráfico en el puerto 4500 así como en el puerto 500. NAT-T (NAT Traversal) debería estar habilitado en el par remoto.

Si el dispositivo del par remoto está configurado para responder a solicitudes ICMP sobre internet, también puede probar su accesibilidad general probando solicitudes ICMP a la IP pública del dispositivo.

Verifique si hay cambios recientes en el estado de la página de salud: Si el PoP está experimentando problemas, esto puede afectar el túnel IPsec (cada túnel está conectado a una ubicación de Cato PoP). Puede monitorear la salud de Cato PoP en la página de estado.

Si el par remoto es un proveedor de nube como Azure o AWS, también puede verificar sus páginas de estado.

Si el dispositivo del par sigue inaccesible para esta conexión IPsec, comuníquese con el administrador para asegurarse de que sea accesible públicamente para las conexiones IPsec.

Resolución de desajuste de configuración IPsec

Asegúrese de que la configuración del par para el conjunto de transformación coincida con la configuración en la página de Sitio > IPsec.

Para configurar el lado de Cato del emparejamiento para que coincida con un conjunto de transformación específico del par, edite la configuración como se describe en la documentación enlazada para IKEv1 y IKEv2.

Los rangos de IP (selectores) en ambos lados del túnel deben coincidir. En el CMA, asegúrese de que los rangos de IP estén configurados de la siguiente manera:

• Rangos de IP Locales (Lado del Par): Navegue a Configuración del Sitio > Redes y defina las subredes ubicadas detrás del par IPsec (por ejemplo, firewall o enrutador).
• Rangos de IP Remotas (Lado de Cato): Navegue a Configuración del Sitio > IPsec > Enrutamiento y defina los rangos de IP locales permitidos para atravesar el túnel (típicamente redes de otros sitios). Si este campo no está configurado, el túnel se considera un VPN basado en rutas con selectores implícitos 0.0.0.0 <> 0.0.0.0.

Algunos proveedores requieren que todas las subredes incluidas en el conjunto de transformación se incluyan en un solo mensaje de conjunto de transformación. Si este es el caso para un par, un administrador debería utilizar la opción de configuración avanzada 'IKEv2 Enviar Mensaje Único TS por carga' en Site > Advanced Configuration. 

Resolución del Rendimiento del Subyacente

El enfoque para resolver el rendimiento del subyacente es aislar el rendimiento contra el par remoto.

Pruebe la capacidad del par remoto para hacer ping a servidores web públicos como 8.8.8.8. Si el retraso o la pérdida de paquetes es consistente con el túnel, se puede concluir que el problema existe dentro del entorno del par remoto.

Presentación de casos a Soporte de Cato

Envíe un ticket de Soporte con los resultados de los pasos de solución de problemas anteriores. Incluya la siguiente información en el ticket:

• Entradas de línea de tiempo relevantes con marcas de tiempo
• Capturas de paquetes relevantes
• Confirmación de conjuntos de transformación coincidentes, incluidas asociaciones de subred y parámetros de autenticación/encriptación