O Tráfego Intermitentemente Falha na Correspondência com as Regras do Firewall

Problema

Este artigo descreve o motivo pelo qual, apesar de ir para o mesmo destino, certas conexões são bloqueadas pela Cato enquanto outras são permitidas.

Por exemplo, a descoberta de eventos abaixo ilustra instâncias onde a mesma origem tentou se conectar ao mesmo Endereço IP de Destino no mesmo protocolo. No entanto, enquanto uma conexão foi bloqueada, a outra foi permitida.

Solução de Problemas

Nesta seção, vamos explorar vários cenários comuns que podem levar a Cato a tratar a conexão de maneira diferente. Entender esses cenários é essencial para otimizar e solucionar efetivamente a conexão. Vamos nos aprofundar em cada um deles abaixo.

1. Roteamento Assimétrico

Quando a Cato não tem visibilidade sobre o fluxo completo, pode faltar informações suficientes para categorizar corretamente os dados na aplicação apropriada. Consequentemente, mesmo que exista uma Regra de Firewall permitindo um protocolo específico como HTTPS, o roteamento assimétrico pode levar o fluxo a ser erroneamente categorizado como TCP. Infelizmente, essa classificação incorreta pode resultar na conexão sendo bloqueada, uma vez que não corresponde à Regra de Firewall permitida. Para investigar mais a fundo, é recomendado realizar um rastreamento de rota tanto da fonte para o destino quanto vice-versa quando o problema estiver ocorrendo. Ao comparar os caminhos de ida e volta, podemos validar se este é de fato o motivo do problema.

2. Aplicação Personalizada Sobreposta

Ao lidar com uma conexão afetada que envolve uma Aplicação Personalizada, é crucial realizar um exame minucioso de sua definição. Uma definição excessivamente simplificada de uma Aplicação Personalizada pode levar a Cato a identificar a aplicação de maneira inconsistente. Se houver uma Regra de Firewall permitindo conexões com a aplicação personalizada, mas devido à forma como a aplicação personalizada foi definida, sua identificação torna-se inconsistente, resultando no bloqueio intermitente da conexão. Portanto, ao lidar com conexões destinadas a aplicações personalizadas, recomendamos seguir as melhores práticas descritas em Trabalhando com Aplicações Personalizadas para garantir comportamento consistente.

3. Atraso de Consciência do Usuário

Quando um usuário inicialmente se conecta à Rede Cato, os mecanismos de consciência do usuário baseados em AD e no Agente de Identidade requerem alguns segundos para mapear o endereço IP de origem para o nome de usuário correspondente. Durante este breve período, o tráfego inicial do usuário pode ser processado sob uma regra de firewall inesperada. No entanto, uma vez que a consciência do usuário identifica o nome de usuário com sucesso, a regra de firewall apropriada será aplicada.

4. FQDN na Regra

Outro cenário comum onde conexões aparentemente similares são tratadas de maneira diferente pela Cato (bloqueadas ou permitidas) é quando Nomes de Domínio Totalmente Qualificados (FQDN) são usados nas Regras de Firewall ou em uma Categoria/Aplicação Personalizada. Antes de entrarmos nos detalhes, vamos examinar dois eventos, ambos têm origem no mesmo Endereço IP de Origem e destinam-se ao mesmo Endereço IP e Porta, mas com resultados diferentes — um permitido e outro bloqueado.

Revise as Regras de Firewall

No exemplo dado, a conexão é bloqueada ou permitida com base na regra do Firewall WAN.

Para investigar mais a fundo, siga estas etapas:

• Navegue até a seção de Firewall WAN dentro do CMA e pesquise pelas regras relevantes.

• Torna-se evidente que a regra 1 corresponde ao Evento de Monitorar (Permitir). Essa regra permite especificamente conexões categorizadas em "Servidores Web Internos". Ao clicar na regra, revela-se que "Servidores Web Internos" é da Categoria Personalizada.

• Em contraste, a regra 5 alinha-se com o evento de Bloqueio. Ela é projetada para bloquear tráfego HTTP(s) juntamente com outros serviços.

Revise o App/Categoria

• Navegue até Recursos > Categorias > Categorias Personalizadas

• Na lista de Categorias Personalizadas, localize e selecione a categoria "Servidores Web Internos".

• Dentro dos detalhes da categoria, observa-se que o membro da categoria "Servidores Web Internos" corresponde ao Nome de Domínio Totalmente Qualificado (FQDN) do webserver.dyow-homelab.com.

• Isso indica que a correspondência de conexão com o FQDN será permitida. (Para que a Cato identifique corretamente o Nome do Host, precisamos ver a consulta/resposta DNS)
  

• Qualquer conexão que não corresponda exatamente ao FQDN será negada. Por exemplo, se o website visitado incluir "www", que é www.webserver.dyow-homelab.com (conforme a consulta DNS), não corresponderá ao Nome de domínio totalmente qualificado (FQDN) definido na CMA. Para resolver esse problema, um objeto de Domínio pode ser definido em vez disso. Isso permitirá correspondências com todos os subdomínios que incluam o Domínio definido. Veja Firewall WAN da Cato.
  
• No exemplo de conexão bloqueada acima, o usuário tentou acessar o servidor usando seu Endereço IP de Destino em vez do FQDN. Nesse caso, como não há consulta/resposta DNS, a Cato não conseguiu identificar o Nome do Host, e a regra não foi correspondida.
• Em situações onde o acesso Direto ao IP ocorre sem uma consulta DNS anterior, a Cato utiliza seu cache DNS para tentar corresponder um Domínio ao IP dado. Se o cache não contiver qualquer Domínio, a Cato será incapaz de associá-lo a um Nome do Host ou FQDN. Como resultado, a conexão no exemplo mencionado será bloqueada.
• Portanto, quando uma Regra de Firewall Permitir é configurada para corresponder com base no Nome de domínio totalmente qualificado (FQDN), o Cliente deve acessar o Servidor usando seu Nome de Domínio para garantir a Conectividade ininterrupta.
  
  Nota: Se você estiver usando um Servidor DNS Interno, certifique-se de que todas as suas consultas DNS sejam roteadas através do Cato Cloud, independentemente do Servidor DNS de Destino configurado. Para as Melhores Práticas para DNS e Sua Conta Cato, consulte 

Soluções alternativas

Caso os desajustes de regras de Firewall continuem a ocorrer, mesmo após acessar o site usando seu nome de domínio e as consultas/respostas DNS estejam efetivamente passando pela Cato, as seguintes soluções podem ser implementadas:

• O cache DNS no PC do usuário pode ser diferente do cache DNS no PoP, o que levará a Cato a não associar o IP do servidor com o Nome de domínio totalmente qualificado (FQDN). Nos casos em que um servidor DNS Interno é usado, o tempo de vida (TTL) do DNS pode ser encurtado e, portanto, forçar o PC a gerar consultas DNS com mais frequência.
• Use uma combinação de IP/porta na Aplicação/Categoria personalizada usada na regra de Firewall que corresponde ao Servidor. No exemplo acima, defina o aplicativo personalizado para o Endereço IP 192.168.2.25 e porta 8080. Isso forçará a correspondência de regras, mesmo que existam discordâncias de cache DNS ou consultas DNS ausentes na Nuvem Cato.