El tráfico no coincide intermitentemente con las reglas del firewall

Problema

Este artículo describe la razón por la cual, a pesar de ir al mismo destino, ciertas conexiones son bloqueadas por Cato mientras que otras son permitidas.

Por ejemplo, el descubrimiento de eventos a continuación ilustra instancias donde la misma fuente intentó conectarse a la misma dirección IP de destino en el mismo protocolo. Sin embargo, mientras que una conexión fue bloqueada, la otra fue permitida.

Solución de problemas

En esta sección, exploraremos varios escenarios comunes que pueden causar que la conexión sea tratada de manera diferente por Cato. Comprender estos escenarios es esencial para optimizar y solucionar eficazmente la conexión. Vamos a profundizar en cada uno de ellos a continuación.

1. Enrutamiento asimétrico

Cuando Cato no tiene visibilidad en el flujo completo, podría carecer de información suficiente para categorizar los datos correctamente en la aplicación apropiada. En consecuencia, incluso si hay una regla de firewall que permite un protocolo específico como HTTPS, el enrutamiento asimétrico podría llevar a que el flujo sea clasificado erróneamente como TCP. Desafortunadamente, esta clasificación incorrecta puede resultar en que la conexión sea bloqueada ya que no se alinea con la regla de firewall permitida. Para investigar más a fondo, se recomienda realizar un traceroute tanto desde la fuente al destino como viceversa cuando ocurre el problema. Al comparar los caminos de ida y vuelta, podemos validar si este es efectivamente el motivo del problema.

2. Aplicación personalizada superpuesta

Cuando se trata de una conexión afectada que involucra una aplicación personalizada, es crucial llevar a cabo un examen minucioso de su definición. Una definición excesivamente simplificada de una aplicación personalizada podría causar que Cato identifique la aplicación de manera inconsistente. Si hay una regla de firewall que permite conexiones a la aplicación personalizada, pero debido a la forma en que se definió la aplicación personalizada, su identificación se vuelve inconsistente, resultando en bloqueos intermitentes de la conexión. Por lo tanto, cuando se trata de conexiones destinadas a aplicaciones personalizadas, recomendamos seguir las mejores prácticas descritas en Trabajando-con-Aplicaciones-Personalizadas para asegurar un comportamiento consistente.

3. Retraso en la concienciación del usuario

Cuando un usuario conecta inicialmente con la Red Cato, los mecanismos de concienciación del usuario basados en AD y en Identity-Agent requieren unos segundos para mapear la dirección IP fuente al nombre de usuario correspondiente. Durante este breve período, el tráfico inicial del usuario puede procesarse bajo una regla de firewall inesperada. Sin embargo, una vez que la concienciación del usuario identifica exitosamente el nombre de usuario, se aplicará la regla de firewall apropiada.

4. FQDN en la regla

Otro escenario común donde conexiones aparentemente similares son tratadas de manera diferente por Cato (bloqueadas o permitidas) es cuando se utilizan Nombres de Dominio Completamente Calificados (FQDN) en las Reglas de Firewall o en una categoría/aplicación personalizada. Antes de profundizar en los detalles, examinemos dos eventos, ambos procedentes de la misma dirección IP de origen y destinados a la misma dirección IP y puerto, pero con resultados diferentes: uno permitido y el otro bloqueado.

Revisar las reglas del firewall

En el ejemplo dado, la conexión se bloquea o permite según la regla del firewall WAN.

Para investigar más a fondo, siga estos pasos:

• Navegue a la sección del firewall WAN dentro de CMA y busque las reglas relevantes.

• Se hace evidente que la regla 1 corresponde al evento de Monitor (Permitir). Esta regla permite específicamente conexiones categorizadas bajo "Servidores Web Internos". Al hacer clic en la regla se revela que "Servidores Web Internos" es de la Categoría Personalizada.

• Por el contrario, la regla 5 se alinea con el evento de Bloqueo. Está diseñada para bloquear el tráfico HTTP(s) junto a otros servicios.

Revisar la app/categoría

• Navegue a Recursos > Categorías > Categorías Personalizadas

• En la lista de categorías personalizadas, localice y seleccione la categoría "Servidores Web Internos".

• Dentro de los detalles de la categoría, se observa que el miembro de la categoría "Servidores Web Internos" coincide con el Nombre de Dominio Completamente Calificado (FQDN) con webserver.dyow-homelab.com.

• Esto indica que las conexiones que coincidan con el FQDN serán permitidas. (Para que Cato identifique correctamente el nombre de host, necesitamos ver la consulta/respuesta DNS)
  

• Cualquier conexión que no corresponda exactamente al FQDN será denegada. Por ejemplo, si el sitio web visitado incluye "www", es www.webserver.dyow-homelab.com (según la consulta DNS), no coincidirá con el FQDN definido en CMA. Para resolver este problema, se puede definir un objeto de Dominio en su lugar. Esto permitirá coincidencias con todos los subdominios que incluyan el Dominio definido. Vea Cato WAN Firewall.
  
• En el ejemplo de conexión bloqueada mencionado, el usuario intentó acceder al servidor utilizando su dirección IP de destino en lugar del FQDN. En este caso, como no hay ninguna consulta/respuesta DNS, Cato no pudo identificar el nombre de host, y la regla no fue cumplida.
• En situaciones donde el acceso directo a IP ocurre sin una solicitud de DNS anterior, Cato utiliza su caché DNS para intentar hacer coincidir un dominio con la IP dada. Si la caché no contiene ningún dominio, Cato será incapaz de asociarlo con un nombre de host o FQDN. Como resultado, la conexión en el ejemplo mencionado será bloqueada.
• Por lo tanto, cuando se configura una regla de firewall de permitir para coincidir en función del nombre de dominio completo, el cliente debe acceder al servidor usando su Nombre de Dominio para asegurar la conectividad ininterrumpida.
  
  Nota: Si está usando un servidor DNS interno, asegúrese de que todas sus consultas DNS se enrutadas a través de la Nube de Cato, independientemente del servidor DNS de destino configurado. Para las mejores prácticas de DNS, consulte Mejores-Prácticas-para-DNS-y-su-Cuenta-Cato 

Soluciones alternativas

En caso de que los desajustes de la regla del firewall continúen ocurriendo, incluso después de acceder al sitio utilizando su nombre de dominio y las consultas/respuestas DNS pasan efectivamente por Cato, se pueden implementar las siguientes soluciones:

• La caché DNS en la PC del usuario puede ser diferente a la caché DNS en el PoP, lo que llevará a que Cato no asocie la IP del servidor con el FQDN. En casos donde se utiliza un servidor DNS interno, el TTL (tiempo de vida) del DNS se puede acortar y así forzar a la PC a generar consultas DNS con más frecuencia.
• Utilice una combinación de IP/puerto en la aplicación/categoría personalizada utilizada en la regla del firewall que coincide con el servidor. En el ejemplo anterior, configure la aplicación personalizada a la dirección IP 192.168.2.25 y puerto 8080. Esto forzará a la coincidencia de reglas incluso si hay desajustes en la caché DNS o consultas DNS faltantes sobre el Cato Cloud.