Solución de Problemas de Evaluación de Reglas de Red

Visión general

Asegurar una evaluación precisa de las reglas de red es crucial para tomar decisiones informadas sobre el enrutamiento. Esta guía de solución de problemas tiene como objetivo abordar de manera integral varios síntomas comunes, explorar posibles causas y ofrecer pasos sistemáticos para resolver problemas relacionados con la evaluación de reglas de red.

Síntomas

Un fallo al evaluar el tráfico contra las reglas de red puede manifestarse de diversas formas. Un administrador puede notar los siguientes síntomas:

  • Dirección IP de Fuente Pública Incorrecta
  • Desajuste de Regla de Red
  • Interfaz WAN Incorrecta Seleccionada
  • Aceleración TCP Se Está Aplicando o Evitando
  • Desajuste de Prioridad QoS
  • Off-Cloud o Alt-WAN Rompen Conexiones de Tráfico

Causas Posibles

  • Desajuste de Aplicación Personalizada o Incorporada
  • Desajuste de dominio
  • PoP de Egreso Incorrecto Elegido
  • Conexiones WAN No Saludables
  • Aplicación bloqueada o no identificada lleva a una prioridad de QoS fija
  • Orden Incorrecto de la Regla de Red

Evaluación Inicial

Nota

Nota: Asegúrese de tener una Regla de Firewall (incluso temporalmente creada para propósitos de solución de problemas) con seguimiento de eventos activado que incluirá el tráfico esperado para coincidir con la Regla de Red configurada.

Revisa los Eventos de Firewall seleccionando los preajustes de Firewall de Internet o Firewall WAN en CMA. Establece filtros para reducir el tráfico de interés. Analiza campos relevantes como Aplicaciones Relacionadas, Aplicación, App de Cato, Nombre del PoP de Egreso, IP de Fuente Pública, IP de Destino, Nombre de Dominio, Regla de Red, y Aceleración TCP que te ayudarán a identificar la posible causa raíz del problema.

Asegúrate de revisar la sección de solución de problemas apropiada identificando los síntomas reportados por los usuarios:

Solución de Problemas del Problema

Solución de Problemas de Dirección IP de Fuente Pública Incorrecta

Hay casos donde es necesario definir una IP pública de fuente específica para acceder a un servicio restringido en internet como se explica en Cómo Configurar una Regla de Egreso. Si el servicio informa una IP de fuente pública inesperada, sigue los pasos a continuación.

Revisando múltiples IPs de Egreso

Para reglas de red con múltiples direcciones IP de egreso, el Cato Cloud usa la dirección IP de egreso para el PoP que está geográficamente más cercano a la fuente. Si la primera dirección IP de salida no está disponible, Cato Cloud se mueve automáticamente a la segunda dirección IP de salida. La siguiente captura de pantalla muestra un ejemplo de una regla de red con dos direcciones IP de egreso.

En este ejemplo, una regla de red puede egresar el tráfico desde el PoP de Nueva York o el PoP de Chicago. Si la fuente está físicamente más cerca del PoP de Nueva York, Cato intentará egresar el tráfico específico desde el PoP en Nueva York. Si el destino no es accesible desde el PoP de Nueva York, entonces Cato egresa el tráfico desde el PoP de Chicago.

Para cambiar este comportamiento, consulta Cambio de Selección de PoP de Egreso.

IPs de Egreso No Disponibles

Puede ser posible que una regla de red que contiene una sola IP de egreso egresa tráfico usando una IP pública de Cato diferente de la configurada. Esto puede ser posible cuando el PoP asociado con la IP de egreso está temporalmente no disponible durante una ventana de mantenimiento. Esta situación puede ser crítica, especialmente para aplicaciones VoIP.

Para cambiar este comportamiento, consulta Cambio de Selección de PoP de Egreso.

Verificando Cambios en la Regla de Red

Si la regla de red fue recientemente editada con una dirección IP de egreso. Ten en cuenta que solo los nuevos flujos de tráfico generados usarán la nueva IP de egreso. Los flujos de tráfico existentes mantendrán la IP de egreso asociada en el momento en que se creó el flujo.

El comportamiento anterior es usualmente común con el tráfico VoIP donde el flujo SIP permanece activo por un largo tiempo. Para resolver este problema, el teléfono VoIP puede ser reiniciado, lo que desencadenará la creación de un nuevo flujo SIP que será enrutado según la IP de egreso actualizada de la regla de red.

Solución de Problemas de Desajuste de Regla de Red

Al configurar una regla de red, puede ser posible que el tráfico se evalúe contra la regla de red incorrecta. Esta sección cubre todos los posibles escenarios de desajuste y cómo solucionar este problema.

Análisis de Eventos de Firewall

Identifica campos relevantes como Aplicaciones Relacionadas, Aplicación, App de Cato, IP de Destino, Nombre de Dominio, y Regla de Red del Evento de Firewall. Esta información te ayudará a solucionar la razón del desajuste de regla de red.

Verificando Excepciones de Regla de Red

Identifica cualquier excepción añadida a la regla de red. Si el flujo de tráfico coincide con la excepción añadida, la regla de red será ignorada y la búsqueda de reglas continuará con el resto de la base de reglas hasta que se encuentre una coincidencia.

Verificando Aplicación Personalizada

Si se espera que el tráfico de interés coincida con una aplicación personalizada y el campo Aplicación encontrado en el evento del FW no coincide, confirma que la aplicación personalizada está correctamente configurada. Ten en cuenta que cuando existen aplicaciones personalizadas superpuestas, Cato solo identifica el tráfico como una de las aplicaciones personalizadas. 

Para prevenir este problema, por favor consulta la sección Resolución de Aplicación Personalizada Superpuesta.

Verificando Aplicación Incorporada

Si se espera que el tráfico de interés coincida con una Aplicación Incorporada y el tráfico está coincidiendo con la regla de red incorrecta, verifica lo siguiente:

  • Qué aplicaciones están configuradas en la regla de red 'incorrecta'.
  • Si alguna de estas aplicaciones está listada en el campo Aplicaciones Relacionadas del evento del FW.

La identificación de la aplicación es un proceso de varios pasos que comienza con la identificación del protocolo y luego con todas las posibles aplicaciones emparejables que se incluyen en el campo Aplicaciones Relacionadas. Cualquier aplicación 'relacionada' identificada en un flujo independientemente de la decisión de la aplicación final (campo Aplicación) coincidirá con una regla de red.

En el ejemplo a continuación, el acceso a portal.azure.com coincide con la Regla #7 en lugar de la Regla #8. Esto se debe a que la Regla #7 incluye la aplicación Microsoft Azure (incluida en Aplicaciones Relacionadas) a pesar de que la aplicación final (campo Aplicación) es Azure Front Door.

Para resolver este comportamiento esperado, consulta Ordenamiento de Reglas de Red

Verificando el Nombre de Dominio

Si una Regla de Red contiene un objeto de Dominio o FQDN, verifica cuál es el campo Nombre de Dominio en el evento del FW. El objeto de Dominio/FQDN en la regla de red debe ser el mismo que este campo.

Ten en cuenta que un FQDN es una coincidencia exacta del dominio completamente calificado. Por ejemplo, el FQDN example.com solo coincide con example.com.

Por otro lado, un Dominio es un dominio de nivel superior (TLD) o de segundo nivel (SLD) que coincide con todos los subdominios. Por ejemplo, el Dominio example.com coincide con www.example.com y host.example.com.

Podría haber casos donde Cato no pueda determinar el Nombre de Dominio correcto de los flujos HTTP, TLS o DNS. Para resolver estos tipos de problemas, consulta Resolución de Problemas de Nombre de Dominio

Solución de Problemas de Interfaz WAN Incorrecta Seleccionada

Esta sección aborda el escenario donde Cato es seleccionado como el transporte con ambas interfaces WAN configuradas en un despliegue Activo/Activo. Para más información sobre enrutamiento basado en políticas, consulta Cómo Selecciona Cato el Mejor Transporte o Enlace

Nota

Nota: Los campos Nombre del ISP y IP de Fuente ISP en la regla de FW pueden no ser una buena indicación para determinar qué enlace WAN es utilizado por el tráfico. Esto se debe a que el flujo de tráfico puede cambiar de túneles múltiples veces durante su vida útil.

Revisando Configuración de Transporte de Reglas de Red

Si se va a lograr un despliegue Activo/Activo, el rol de la interfaz principal debe configurarse como Automático o ambos roles de interfaz principal y secundaria deben configurarse como se muestra en la captura de pantalla a continuación. Configurando el rol de la interfaz secundaria como Ninguno resultará en que no haya conmutación por error de tráfico cuando la interfaz principal se vuelva no disponible. Consulta Enrutamiento de Tráfico sobre las Interfaces Socket

Revisando Analítica de Red

El widget Avg Throughput mostrará la utilización promedio de ancho de banda para cada enlace WAN. Esto puede servir como un indicador para confirmar que la Regla de Red está seleccionando la conexión WAN correcta o equilibrando el tráfico adecuadamente. En la captura de pantalla a continuación, la Regla de Red fue modificada para seleccionar WAN2 como el transporte principal.

Es importante monitorear el rendimiento del enlace WAN, en particular para la pérdida de paquetes, jitter y distancia. Como se explica en Distribución de Tráfico Activo/Activo, si un enlace no cumple con los umbrales mínimos de calidad de enlace, se considerará no saludable y no será seleccionado para la distribución de tráfico, incluso si el enlace WAN está seleccionado como el transporte principal.

Revisando la WebUI del Socket

Una manera fácil de encontrar si el Socket considera un enlace como no saludable es la página de Monitoreo en la WebUI del Socket. Si las métricas de latencia, jitter o pérdida de paquetes no cumplen los requisitos mínimos, el valor de no saludable se marcará en rojo.

En el ejemplo a continuación, WAN1 tiene una latencia bastante alta, lo que lleva a que el Socket considere el enlace no saludable. Este problema debe plantearse con tu ISP.

Verificando la Configuración del Enlace WAN

Si todos los enlaces activo/activo están saludables, verifica la configuración de ancho de banda para cada enlace WAN en CMA. En el ejemplo a continuación, el enlace WAN1 está configurado con un ancho de banda de 100 Mbps de bajada/subida, y el enlace WAN2 está configurado con 20 Mbps de bajada/subida. Esto resultará en enviar más tráfico a WAN1 en una proporción de 100:20 o 5:1 para ambas direcciones ascendente y descendente.

Solución de Problemas de Aceleración TCP Siendo Aplicada o Evitada

Como se discute en Explicación de la Aceleración TCP de Cato, la Aceleración TCP puede habilitarse en una Regla de Red para acelerar conexiones TCP sobre el WAN. Esta función normalmente se aplica en ciertos escenarios y el administrador no podrá desactivarla incluso si la opción Aceleración TCP Activa en la regla está desmarcada. Esta sección aborda esos escenarios y cómo desactivar la función cuando sea necesario.

Cuando la Aceleración TCP es Enforced

La Aceleración TCP será aplicada cuando la regla de red use una IP de egreso o una ubicación de egreso. Esto obliga al PoP a actuar como un proxy lo que a su vez aplica la aceleración TCP a todos los flujos de tráfico que coinciden con la regla. La casilla de verificación en la regla de red estará deshabilitada.

Desactivar la Aceleración TCP en una regla de red no desactivará la función cuando:

  • La inspección TLS está habilitada para la cuenta, lo que activará la aceleración TCP para todo el tráfico TLS incluso si es TLS pasado por alto. Esto se debe a que el PoP necesita actuar como un proxy para inspeccionar el tráfico en busca de archivos maliciosos y amenazas.
  • Existe una regla de red compleja por encima de la regla de red coincidente con la Aceleración TCP desactivada
  • La regla de red que tiene la Aceleración TCP desactivada es en sí misma compleja.

Una regla de red compleja (también conocida como regla NG) es una regla de red que el Socket mismo no puede evaluar. Por lo tanto, el Socket necesita enviar el tráfico al PoP para elegir la regla de red correcta, lo que a su vez permite la aceleración TCP. Puede contener: Aplicaciones, Categorías de Aplicaciones, Servicios, Aplicaciones Personalizadas u objetos de Dominio/FQDN.

Por otro lado, una regla simple puede contener las siguientes entidades que pueden ser evaluadas por el Socket y no necesitan la intervención del PoP:

  • En el campo Origen/Destino: Sitios, direcciones IP, interfaces de red, Rango de IP o Cualquiera.
  • En el campo App/Categoría: Rango de Puertos o un Servicio Personalizado.

Cuando se omite la aceleración TCP

La aceleración TCP se aplicará solo al tráfico TCP. En caso de que la aceleración TCP esté habilitada en la regla de red o sea forzada como se explicó en la sección anterior, pero el campo de Aceleración TCP en el evento CMA es 0, es posible que el enrutamiento asimétrico sobre el Cato Cloud esté causando que el flujo de tráfico sea detectado como Modo Abierto.

Como se explicó en Enrutamiento asimétrico sobre Cato, el Modo Abierto es un modo de conexión en el que el Cato Cloud no es consciente del inicio del flujo TCP (el apretón de manos de 3 vías), lo que impide que se aplique la aceleración TCP. Recomendamos trabajar con el soporte de Cato para determinar la causa raíz de la creación de flujos en Modo Abierto.

Deshabilitando la Aceleración TCP

Para deshabilitar la Aceleración TCP, se puede colocar una regla simple sin IP de Egreso o ubicación en la parte superior de la base de reglas de red como se describe en Orden de Reglas de Red. Como se mencionó anteriormente, si el tráfico es TLS, la inspección TLS debe estar deshabilitada para toda la cuenta.

Solucionando desajustes de prioridad de QoS

Como se explicó en Cuándo se asigna una prioridad de QoS 255 a un flujo, podría haber casos en los que la prioridad de QoS configurada en la regla de red sea diferente a la prioridad mostrada en el evento FW.

La prioridad de QoS 255 se refiere como la prioridad predeterminada para la Gestión de BW. Hay varias razones por las que un flujo puede recibir la prioridad de QoS 255 independientemente de la configuración de prioridad de bw en la regla de red:

  • Cato evalúa el perfil de red de cada flujo, y la prioridad de QoS de 255 se asigna cuando la aplicación específica aún no ha sido identificada.
  • Los primeros paquetes (antes de que se identifique el flujo) son asignados con prioridad de QoS 255.
  • Los flujos bloqueados son asignados con prioridad de QoS 255.

Solucionando las conexiones de tráfico fuera de la nube o Alt-WAN  

Esta sección aborda el escenario en el que las conexiones TLS no logran establecerse entre sitios cuando la Regla de Red WAN está configurada con Off-Cloud o Alt-WAN como el transporte principal. Para solucionar este problema, siga los pasos a continuación.

Análisis de flujo

Cuando el tráfico se enruta correctamente a través de Off-Cloud o Alt-WAN, los flujos de tráfico no generarán eventos FW en CMA porque este tráfico no pasa por el PoP.

Una forma de confirmar que el tráfico se está enrutando exitosamente a través de Off-Cloud o Alt-WAN es desde la pestaña SDWAN en el Socket WebUI. Identifique el flujo de tráfico activo y en NIC Elegido verá el transporte seleccionado para el tráfico de interés. Si el transporte esperado no está seleccionado, confirme que Off-Cloud o Alt-WAN están configurados correctamente.

Verificando el orden de la regla de red

Como se explicó en Fallo de conexión TLS sobre enlaces Off-Cloud o Alt-WAN, cuando el tráfico es TLS y la inspección TLS está habilitada, el orden de las reglas de red es un factor importante para garantizar el flujo de tráfico sobre enlaces Off-Cloud o Alt-WAN.

Los Sockets no pueden evaluar reglas de red y enrutar paquetes sobre Off Cloud o Alt-WAN cuando la regla de red que impacta el tráfico está debajo de una regla compleja. Para resolver este comportamiento esperado, vea Orden de Reglas de Red

Resolviendo problemas descubiertos

Resolviendo aplicaciones personalizadas superpuestas

Asegúrese de que la aplicación personalizada incluya las direcciones IP correctas, Dominio, Puerto y Protocolo. No hay lógica sobre qué aplicación personalizada se elige para la identificación, por lo que la aplicación personalizada debe definirse de manera única para evitar superposiciones con otra aplicación personalizada. Para más información, vea Trabajar con Aplicaciones Personalizadas

Orden de reglas de red

Tenga en cuenta que las reglas de red se evalúan según su orden, por lo que es importante definir reglas más específicas sobre las reglas más generales. Por ejemplo, las reglas de red que definen una aplicación personalizada, una aplicación integrada, dominio, FQDN o servicio personalizado deben colocarse por encima de las reglas de red que contienen categorías, categorías personalizadas o servicios.

En la captura de pantalla a continuación, la regla #1 contiene un servicio personalizado que incluye rangos IP para twitter.com y está colocada por encima de la regla #2 que contiene Categorías de Aplicaciones. La regla #1 es más específica que la regla #2 y será una mejor coincidencia para el tráfico destinado a twitter.com. Esto desactivará además la aceleración TCP y resolverá cualquier problema de enrutamiento Off-Cloud o Alt-WAN dado que la regla #1 es una regla simple.

Resolviendo problemas de nombres de dominio

Los problemas de coincidencia de regla de red basados en Dominio/FQDN pueden resolverse de la siguiente manera:

  • Para protocolos como HTTP/S, Cato puede determinar el dominio de destino usando las siguientes fuentes:

    • Encabezado de Nombre de Host HTTP (cuando la inspección TLS está habilitada)

    • Campo SNI durante el handshake TLS

    • Resolución DNS, donde el nombre de dominio se aprende de las consultas y respuestas DNS

  • Es importante asegurar que el dominio especificado en la Regla de Red sea consistente en todas estas fuentes. Nota que solo el nombre de dominio mejor coincidente (evaluado de arriba a abajo) se muestra como Nombre de Dominio en los eventos de Firewall. 

  • Para otros protocolos, como SSH o SMB, que no envían un dominio en texto plano, Cato se basa exclusivamente en la intercepción DNS para asociar el tráfico con un dominio o FQDN. Esto es particularmente crítico cuando se utiliza un DNS privado, ya que necesitamos asegurar que las consultas/respuestas DNS pasen por Cato. Consulte Mejores prácticas para DNS y su cuenta de Cato

Cambio de selección de PoP de salida

Si desea enrutar todas las reglas de salida de la cuenta a través del PoP que esté más cercano al destino, en lugar del más cercano a la fuente (comportamiento predeterminado), por favor contacte al soporte de Cato Networks Levantando un caso al soporte de Cato.

Para aplicaciones VoIP que usan el protocolo SIP y que requieren siempre usar la misma IP de Egreso, habilite la opción IP preferida para tráfico SIP en configuraciones avanzadas.

Si un protocolo VoIP diferente o cualquier otra aplicación requiere siempre usar la misma IP de Egreso, por favor contacte al soporte de Cato Networks Levantando un caso al soporte de Cato.

Levantando un caso al soporte de Cato

Envíe un ticket de soporte con los resultados de los pasos de solución de problemas anteriores. Por favor incluya la siguiente información en el ticket:

  • Detalles del problema experimentado y el impacto general en los usuarios.
  • Eventos de Firewall relacionados y configuración de Regla de Red.
  • Reproduzca el problema y ejecute el Portal de Autoservicio de Soporte. Incluya el número de ticket generado por la herramienta.

¿Fue útil este artículo?

Usuarios a los que les pareció útil: 2 de 2

0 comentarios