Solución de problemas de acceso a los recursos internos

Visión general

Garantizar un acceso fluido a los recursos internos es fundamental para mantener la productividad y la seguridad en la red. Sin embargo, diversos factores pueden interrumpir el acceso, lo que lleva a una mala experiencia de usuario y a un flujo de trabajo obstaculizado. Este libro de estrategias tiene como objetivo proporcionar una guía integral para solucionar problemas de acceso WAN a los recursos internos dentro de Cato Cloud.

Síntomas

Una falla para acceder a los recursos internos puede manifestarse de varias maneras. Un administrador puede observar los siguientes síntomas:

  • No se puede resolver el nombre de dominio del servidor interno
  • No se puede alcanzar el servidor interno
  • Desajuste de regla de firewall WAN
  • Los clientes SDP no pueden acceder a los recursos internos
  • No se puede alcanzar el recurso de Reenvío de Puertos Remotos (RPF)
  • El host de monitoreo LAN es inalcanzable

Posibles causas

  • Problemas de enrutamiento
  • Mala configuración de reenvío DNS
  • Mala configuración del firewall WAN
  • Superposición con la red del cliente SDP
  • Intervención de seguridad
  • Problemas de conectividad del host de destino

Evaluación inicial

Nota

Nota: Asegúrese de tener una Regla de Firewall WAN (incluso creada temporalmente para propósitos de solución de problemas) con seguimiento de eventos habilitado.

Para problemas relacionados con el acceso al servidor interno a través del acceso del navegador, consulte Solución de problemas de acceso del navegador

Revise eventos de firewall WAN, IPS y Anti-malware seleccionando el preajuste respectivo en CMA. Configure filtros para restringir el tráfico interesante y verifique si el flujo fue bloqueado por el firewall WAN o los motores IPS/AM. El campo regla mostrará la regla respectiva que coincide con el tráfico.

Asegúrese de revisar la sección de solución de problemas adecuada siguiendo estos pasos de evaluación inicial:

Solución de problemas del problema

Los pasos para solucionar los síntomas que un administrador puede encontrar se enumeran 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 libro de estrategias.

Comprobación de los registros del rastro de auditoría

Verifique el rastro de auditoría para cualquier registro modificado que pueda haber afectado el acceso a los recursos internos. Esto incluye reglas de firewall WAN, configuraciones de AM/IPS e inspección TLS.

Solución de problemas de resolución de nombres de dominio del servidor

Verificación de resolución DNS

Si el recurso interno debe ser alcanzable usando su nombre de dominio, confirme si se puede resolver el nombre de dominio del servidor interno, utilizando los comandos nslookup o dig desde la línea de comandos.

Podría haber dos situaciones para la resolución DNS interna en su cuenta:

  • Si se utiliza una dirección IP de servidor DNS privado en la organización, confirme si los usuarios afectados pueden alcanzar el servidor DNS internamente. Si no es así, solucione la conectividad al servidor DNS, similar a Solucionar problemas con el servidor interno inalcanzable
  • Si se utilizan en la cuenta el servidor DNS predeterminado de Cato 10.254.254.1, servidor DNS definido por cuenta o DNS público conocido (8.8.8.8, 1.1.1.1 o 9.9.9.9), solucione el reenvío DNS en el siguiente paso.

Verificación de reenvío DNS

Los flujos de tráfico que dependen de nombres de dominio internos (por ejemplo, pc1.dominio.net) deben tener reenvío DNS correctamente configurado en CMA. También es crucial que Cato intercepte los flujos DNS para poder resolver los nombres de dominio correctamente.

El reenvío DNS solo puede funcionar si las consultas DNS están destinadas a servidores DNS específicos como se explica en Resolución de problemas de reenvío DNS.

Solución de problemas con el servidor interno inalcanzable

Comprobación de la tabla de enrutamiento de Cato

La tabla de enrutamiento se puede usar para verificar la disponibilidad de rutas, las métricas y más:

  • Busque la dirección IP del recurso en la cadena de búsqueda y confirme que hay una ruta coincidente existente a través del sitio correcto.
  • Si no se encuentra ninguna ruta, esto significa que Cato no está al tanto de esta ruta, por lo tanto, no puede enrutar a este destino. Para resolver este problema vea Resolución de problemas de enrutamiento
  • Si hay rutas a la misma destino, verifique que los rangos dinámicos de BGP no se superpongan con otras rutas estáticas. Las rutas con métrica más baja son preferidas.
  • BGP también puede anunciar rutas redundantes desde diferentes sitios. La ruta con la métrica más baja incluyendo Peso, longitud de AS o MED es preferida. Vea Entendiendo los campos de la tabla de enrutamiento.
  • Para resolver problemas de métrica, vea Resolución de problemas de enrutamiento

Comprobación de enrutamiento basado en política IPSec

Si el recurso interno es alcanzable a través de IPSec, confirme que los rangos correctos estén definidos en las secciones de IPSec y Redes del sitio como se explica en el manual de solución de problemas de IPSEC.

Si el enrutamiento basado en política está configurado, todos los selectores de tráfico deben coincidir en Cato y en el firewall/enrutador IPSec para asegurar conectividad a los recursos internos.

Comprobación del estado del recurso interno

Si el recurso interno se encuentra detrás de un socket o vSocket, verifique el valor de Última actividad del anfitrión desde la página de Anfitriones conocidos en el sitio. Vea Mostrando anfitriones conocidos para un sitio

Los anfitriones que no han sido vistos recientemente por el sitio podrían estar apagados o no conectados a la red.

Ejecute una captura de tráfico en el socket desde el WebUI e identifique cualquier posible problema dentro de la LAN.

Comprobación de flujos TLS

Si el tráfico interesante es TLS y ha verificado que los pasos anteriores permiten el tráfico. Verifique si el flujo de tráfico está siendo inspeccionado TLS por Cato. Esto se puede encontrar en la regla FW con el campo de inspección TLS configurado en 1.

De ser así, el certificado raíz de Cato debe estar instalado en el dispositivo fuente como se explica en configuración de la política de inspección TLS. De lo contrario, omita la inspección TLS para evitar cualquier error de certificado y posibles problemas de acceso al recurso.

Solución de problemas de desajuste de regla de firewall WAN

Al configurar una regla de firewall, puede ser posible que el tráfico sea evaluado contra la regla equivocada. Esta sección cubre todos los posibles escenarios de desajuste y cómo solucionar este problema.

Verificación de aplicación personalizada

Si el tráfico interesante se espera que coincida con una aplicación personalizada y el campo de aplicación encontrado en el evento FW no coincide, confirme que la aplicación personalizada esté configurada correctamente. Tenga en cuenta que cuando existan aplicaciones personalizadas superpuestas, Cato solo identifica el tráfico como una de las aplicaciones personalizadas. 

Para evitar este problema, consulte la sección Resolución de aplicaciones personalizadas superpuestas.

Verificación de aplicación/servicio incorporado

Si el tráfico interesante se espera que coincida con una aplicación o servicio incorporado y el tráfico está coincidiendo con la regla de firewall equivocada, revise lo siguiente:

  • Qué aplicaciones o servicios están configurados en la regla de firewall "equivocada" coincidente.
  • Si alguna de estas aplicaciones/servicios está listado en el campo de aplicaciones relacionadas del evento FW.

La identificación de la aplicación/servicio es un proceso de varios pasos que comienza con la identificación del protocolo y luego todas las posibles aplicaciones coincidibles que están incluidas en el campo de 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 firewall.

En el ejemplo a continuación, el tráfico SMB coincide con la regla #1 en lugar de la regla #2. Esto se debe a que la regla #1 incluye el servicio TCP (incluido en aplicaciones relacionadas) a pesar de que la aplicación final (campo aplicación) es SMB.

Para resolver este comportamiento esperado, vea Orden de reglas de firewall

Verificación del nombre de dominio configurado

Si una regla de firewall contiene un objeto de dominio o FQDN, verifique qué es el campo de nombre de dominio en el evento FW. El objeto de dominio/FQDN en la regla de firewall debe ser el mismo que este campo.

Tenga 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 en los que Cato no pueda determinar correctamente el nombre de dominio a partir de flujos HTTP, TLS o DNS. Para resolver estos tipos de problemas, vea Resolución de problemas de desajuste de nombre de dominio

Solución de problemas del cliente SDP que no alcanza recursos internos

Esta sección aborda problemas exclusivos de los clientes SDP que no alcanzan los recursos internos.

Comprobación de superposición de subred de la red doméstica del usuario

Si el cliente SDP no puede conectarse a recursos internos, incluido hacer ping al servidor, verifique si hay una superposición de direcciones IP entre la red doméstica del usuario y el sitio con los recursos internos. Si ese es el caso, la tabla de enrutamiento del cliente apuntará a la NIC local al intentar conectarse al servidor interno ubicado detrás del sitio remoto de Cato, resultando en una falla de conexión.

Los sitios remotos con un rango de IP de 192.168.0.0/24, 192.168.1.0/24 o 10.0.0.0/24, pueden superponerse fácilmente con el rango de IP para enrutadores inalámbricos domésticos, que a menudo utilizan este rango de IP como la configuración DHCP predeterminada.

Para resolver este problema, siga los pasos descritos en el cliente SDP no puede conectarse a los recursos WAN remotos.

Usuarios de macOS y iOS no resuelven dominios internos

Como se explica en Usuarios de macOS Ventura y iOS que no pueden alcanzar recursos internos vía Cato, si el Cliente SDP no puede conectarse a recursos internos usando su nombre de dominio pero pueden alcanzarlo usando su dirección IP, es posible que el Reenvío de DNS esté fallando debido a que se utilice DoH (DNS sobre HTTPS) o DoT (DNS sobre TLS) en el endpoint. Cato actualmente no soporta DoH/DoT.

Para resolver este problema, vea Resolución de problemas de reenvío DNS. Alternativamente, el Servidor DNS de Cato (10.254.254.1) puede definirse en CMA como el único servidor DNS para el endpoint.

Usuarios de Android que no resuelven dominios internos

Como se explica en Dispositivos Android que no pueden alcanzar recursos internos vía Cato, si el Cliente SDP no puede conectarse a recursos internos usando su nombre de dominio pero pueden alcanzarlo usando su dirección IP, es posible que el Reenvío de DNS esté fallando debido al DNS Privado Automático utilizado por el dispositivo (comportamiento predeterminado), lo que aplica DoH/DoT para la resolución de DNS. Actualmente, esto no es compatible con Cato.

Para resolver este problema, consulte Resolviendo Problemas de Reenvío de DNS. Alternativamente, el DNS Privado puede ser deshabilitado en el dispositivo.

Solución de problemas de recursos internos RPF

Análisis de eventos RPF

Revise los eventos de RPF seleccionando el preajuste RPF en CMA.  Confirme que se genera el evento lo que confirmará que la IP externa de Cato está disponible. Tenga en cuenta que la dirección IP de destino es la IP pública externa configurada en la regla RPF.

Nota: Los eventos RPF entrantes pueden a veces mostrar un Nombre para mostrar del usuario, aunque el tráfico no sea iniciado por el usuario. Este es comportamiento esperado.

Los campos de eventos en la plataforma Cato extraen metadatos del túnel, host y agente de usuario, no solo del flujo de tráfico. Entonces, si un usuario está asignado en un dispositivo detrás del socket o túnel, su nombre puede aparecer en el evento—even para tráfico entrante.

Esto difiere de cómo las políticas de cortafuegos o enrutamiento interpretan el tráfico (que son conscientes de la dirección), pero es normal para la correlación de eventos. 

 

Análisis de eventos por bloqueo geográfico

Revise cualquier evento destinado a la dirección IP interna del servidor interno. Confirme que ninguna restricción de bloqueo geográfico esté impidiendo la conexión al servidor interno. De ser así, edite la política de restricción geográfica para la dirección entrante para permitir el país de origen.

Comprobación de la vitalidad del recurso interno

Verifique el valor de Última Actividad Conocida de la página de Hosts Conocidos en el sitio. Consulte Mostrando Hosts Conocidos para un Sitio

Los hosts que no han sido vistos recientemente por el sitio pueden estar apagados o no conectados a la red.

Ejecute una captura de paquetes desde la WebUI e identifique cualquier posible problema dentro del LAN.

Solución de problemas de hosts de monitoreo LAN inalcanzables

Análisis de eventos de conectividad

Revise los eventos de conectividad seleccionando el preajuste hosts LAN inalcanzables en CMA. Los eventos de Host Inalcanzable se generarán cuando el host LAN definido ya no sea alcanzable.

Comprobación de la alcanzabilidad del host local

Confirme que el host local definido se pueda hacer ping desde el Socket WebUI. Si el ping es exitoso, verifique lo siguiente:

  • Las sondas de monitoreo LAN son paquetes ICMP originados desde 10.254.254.1, por lo que es importante confirmar que el host monitoreado tenga una ruta de regreso al gateway LAN Socket para poder responder.
  • Si el dispositivo está ejecutando un firewall local, se debe permitir ICMP desde la dirección IP 10.254.254.1.

Ejecute una captura de paquetes desde la WebUI e identifique cualquier posible problema dentro del LAN.

Resolución de problemas descubiertos

Resolución de problemas de enrutamiento

Si la ruta al recurso interno no se encuentra en la tabla de enrutamiento, verifique y resuelva lo siguiente:

Si la métrica de la ruta vista en la tabla de enrutamiento está causando decisiones erróneas de enrutamiento, verifique y resuelva lo siguiente:

  • Los valores de métrica de túnel generalmente son establecidos por Cato. Las rutas redundantes deben tener la misma métrica de túnel siempre que se originen del mismo tipo de sitio, p. ej. Sitio IPsec o Socket.
  • El valor de peso se puede configurar en CMA, Network > Site > Configuración del Sitio > BGP. El valor de métrica configurado en esta página se verá como peso en la tabla de enrutamiento. Cambiar la métrica para el sitio solucionará decisiones erróneas de enrutamiento para rutas redundantes.
  • Las valores de longitud AS y Métrica Discriminatoria se reciben del router externo. Deben ser modificados en este dispositivo si es necesario.

Resolviendo falsos positivos de bloqueos de IPS/Anti-Malware

Si el tráfico interesante está bloqueado por IPS/AM, puede agregar listas de permitidos con alcance WAN tanto en la configuración de IPS como de Anti-malware.

 

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 estar definida de manera única para evitar superposiciones con otra aplicación personalizada. Para más información, consulte Trabajando con Aplicaciones Personalizadas

Orden de reglas de Firewall

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

En la captura de pantalla de abajo, la Regla #1 contiene un servicio personalizado que incluye rangos de IP para twitter.com y se coloca 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 además desactivará 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 coincidencia de nombres de dominio

Los problemas de coincidencia de reglas de Firewall basados en Dominio/FQDN se pueden resolver 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á activada)

    • Campo SNI durante el intercambio TLS

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

  • Es importante asegurarse de que el dominio especificado en la Regla de Firewall sea consistente en todas estas fuentes. Nota que solo el nombre de dominio mejor evaluado (evaluado de arriba a abajo) se muestra como Nombre de Dominio en los eventos del 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 al usar 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
  • DoH (DNS sobre HTTPS) y DNS sobre TLS no son compatibles para la coincidencia de nombres de dominio/aplicación, por lo tanto, deben ser bloqueados en las reglas de Firewall para forzar el movimiento de consultas DNS a UDP/53.

Resolviendo problemas de Reenvío de DNS

Solo puede usar el reenvío de DNS cuando las consultas DNS están destinadas a los siguientes servidores DNS:

  • Servidor DNS predeterminado de Cato 10.254.254.1
  • Servidores DNS a nivel de cuenta, configurados en Red > Configuración de DNS
  • Servidores DNS bien conocidos como 8.8.8.8, 1.1.1.1, y 9.9.9.9. La lista de servidores DNS bien conocidos puede variar entre PoPs. Por ejemplo, China y Sídney.

DoH (DNS sobre HTTPS) y DNS sobre TLS no son compatibles para el reenvío de DNS, por lo tanto, deben ser bloqueados en las reglas de Firewall para forzar el movimiento de consultas DNS a UDP/53. Esta solución se aplica especialmente a los Clientes SDP de macOS, iOS y Android.

 

Elevando casos al Soporte de Cato

Presente 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 e impacto general en los usuarios.
  • Eventos de Firewall relacionados y configuración de Reglas de Firewall.
  • Reproduzca el problema y ejecute el Portal de Autoservicio de Soporte. Incluya el número de ticket generado por la Herramienta.
  • Si el usuario afectado se conecta a Cato usando el Cliente SDP, por favor Registre el Problema Usando el Cliente SDP
  •  

¿Fue útil este artículo?

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

0 comentarios