Solução de Problemas de Avaliação de Regra de Rede

Visão Geral

Garantir uma avaliação precisa da regra de rede é crucial para tomar decisões informadas de roteamento. Este guia de solução de problemas visa abordar de forma abrangente vários sintomas comuns, explorar causas potenciais e oferecer etapas sistemáticas para resolver problemas relacionados à avaliação de rega de rede.

Sintomas

Falhas ao avaliar o tráfego contra as regras de rede podem se manifestar de várias maneiras. Um administrador pode notar os seguintes sintomas:

  • IP de Origem Público Incorreto
  • Incompatibilidade de Regra de Rede
  • Interface WAN Incorreta Selecionada
  • Aceleração TCP Está Sendo Imposta ou Ignorada
  • Incompatibilidade de Prioridade QoS
  • Tráfego Desconectado Fora da Nuvem ou Alt-WAN

Possíveis Causas

  • Incompatibilidade de Aplicação Personalizada ou Integrada
  • Domínio incompatível
  • PoP de Saída Incorreto Escolhido
  • Conexões WAN Não Saudáveis
  • Aplicativo Bloqueado ou Não Identificado leva a Prioridade de QoS Fixa
  • Ordenação de Regra de Rede Incorreta

Avaliação Inicial

Nota

Nota: Certifique-se de ter uma Regra de Firewall (mesmo criada temporariamente para fins de solução de problemas) com Rastreamento de eventos ativado que incluirá o Tráfego esperado para corresponder à Regra de Rede configurada.

Revise os Eventos de Firewall selecionando os predefinidos Firewall de Internet ou Firewall WAN no CMA. Defina filtros para restringir o tráfego de interesse. Analise campos relevantes como Aplicativos Relacionados, Aplicativo, Aplicativo Cato, Nome do PoP de Saída, IP de Origem Público, IP de Destino, Nome do Domínio, Regra de Rede e Aceleração TCP que o ajudarão a identificar a possível causa raiz do problema.

Certifique-se de revisar a seção de solução de problemas apropriada identificando os sintomas relatados pelos usuários:

Resolução de Problemas da Questão

Solução de Problemas de IP de Origem Público Incorreto

Existem casos onde é necessário definir um IP de origem público específico para acessar serviço de internet restrito, conforme explicado em Como Configurar uma Regra de Saída. Se o serviço relatar um endereço IP de origem público inesperado, siga os passos abaixo.

Revisão de Múltiplos IPs de Saída

Para regras de rede com múltiplos endereços IP de saída, a Cato Cloud usa o endereço IP de saída para o PoP que é geograficamente mais próximo da fonte. Se o primeiro endereço IP de saída estiver indisponível, a Cato Cloud move automaticamente para o segundo endereço IP de saída. A captura de tela a seguir mostra um exemplo de uma regra de rede com dois endereços IP de saída.

Neste exemplo, uma regra de rede pode fazer o tráfego sair do PoP de Nova York ou do PoP de Chicago. Se a fonte estiver fisicamente mais próxima do PoP de Nova York, a Cato tentará fazer o tráfego específico sair do PoP em Nova York. Se o destino não for acessível a partir do PoP de Nova York, então a Cato faz o tráfego sair do PoP de Chicago.

Para mudar esse comportamento, veja Alteração na Seleção do PoP de Saída.

IPs de Saída Indisponíveis

Pode ser possível que uma regra de rede contendo um único IP de saída faça o tráfego sair usando um IP público da Cato diferente do configurado. Isso pode ser possível quando o PoP associado ao IP de saída está temporariamente indisponível durante uma janela de manutenção. Essa situação pode ser crítica, especialmente para aplicações VoIP.

Para mudar esse comportamento, veja Alteração na Seleção do PoP de Saída.

Verificando Alterações na Regra de Rede

Se a Regra de Rede foi recentemente editada com um endereço IP de saída. Lembre-se de que apenas os fluxos de tráfego recém-gerados usarão o novo IP de Saída. Os fluxos de tráfego existentes manterão o IP de Saída associado no momento em que o fluxo foi criado.

O comportamento acima é geralmente comum com o tráfego VoIP onde o fluxo SIP permanece ativo por um longo tempo. Para resolver este problema, o telefone VoIP pode ser reiniciado, o que acionará a criação de um novo fluxo SIP que será roteado de acordo com o IP de Saída da Regra de Rede atualizada.

Solução de Problemas de Desajuste de Regra de Rede

Ao configurar uma Regra de Rede, pode ser possível que o tráfego seja avaliado contra a Regra de Rede errada. Esta seção cobre todos os possíveis cenários de desajuste e como resolver este problema.

Análise de Eventos de Firewall

Identifique campos relevantes como Aplicativos Relacionados, Aplicação, Aplicativo Cato, IP de Destino, Nome do Domínio, e Regra de Rede do Evento de Firewall. Esta informação ajudará a solucionar a razão do desajuste de Regra de Rede.

Verificando Exceções da Regra de Rede

Identifique quaisquer exceções adicionadas à Regra de Rede. Se o fluxo de tráfego corresponder à exceção adicionada, a Regra de Rede será ignorada e a pesquisa da regra continuará com o restante da base de regras até que uma correspondência seja encontrada.

Verificando Aplicação Personalizada

Se o tráfego interessante estiver previsto para corresponder a uma aplicação personalizada e o campo Aplicação encontrado no evento FW não corresponder, confirme se o aplicativo personalizado está configurado corretamente. Lembre-se de que quando existem aplicativos personalizados sobrepostos, Cato somente identifica o tráfego como um dos aplicativos personalizados. 

Para evitar este problema, por favor veja a seção Resolvendo Aplicação Personalizada Sobreposta.

Verificando Aplicação Integrada

Se o tráfego interessante estiver previsto para corresponder a uma Aplicação Integrada e o tráfego estiver correspondendo à regra de rede errada, verifique o seguinte:

  • Quais aplicativos estão configurados na regra de rede 'incorreta'.
  • Se algum destes aplicativos está listado no campo Aplicativos Relacionados do evento FW.

A identificação de aplicativos é um processo de múltiplas etapas que começa com a identificação do protocolo e, em seguida, todas as Aplicações possíveis que são incluídas no campo Aplicativos Relacionados. Qualquer aplicativo 'relacionado' identificado em um fluxo, independentemente da decisão da aplicação final (campo Aplicação), corresponderá a uma Regra de Rede.

No exemplo abaixo, o acesso a portal.azure.com corresponde à Regra #7 em vez da Regra #8. Isso ocorre porque a Regra #7 inclui o aplicativo Microsoft Azure (incluído em Aplicativos Relacionados) mesmo que a aplicação final (campo Aplicação) seja Azure Front Door.

Para resolver este comportamento esperado veja Ordenação de Regras de Rede

Verificando o Nome do Domínio

Se uma Regra de Rede contém um objeto de Domínio ou FQDN, verifique qual é o campo Nome do Domínio no evento FW. O objeto de Domínio/FQDN na Regra de Rede deve ser o mesmo que este campo.

Tenha em mente que um FQDN é uma correspondência exata do domínio totalmente qualificado. Por exemplo, o Nome de domínio totalmente qualificado (FQDN) example.com só corresponde a example.com.

Por outro lado, um Domínio é um domínio de nível superior (TLD) ou de segundo nível (SLD) que corresponde a todos os subdomínios. Por exemplo, o Domínio example.com corresponde a www.example.com e host.example.com.

Pode haver casos em que Cato não consegue determinar o Nome do Domínio correto a partir de fluxos HTTP, TLS, ou DNS. Para resolver esses tipos de problemas veja Resolvendo Problemas de Nome de Domínio

Solução de Problemas de Interface WAN Incorreta Selecionada

Esta seção aborda o cenário em que Cato é selecionado como o transporte com ambas as interfaces WAN configuradas em uma implantação Ativa/Ativa. Para mais informações sobre roteamento baseado em política, veja Como o Cato Seleciona o Melhor Transporte ou Link

Nota

Nota: Os campos Nome do ISP e IP do Provedor de Serviços de Internet na regra FW podem não ser uma boa indicação para determinar qual link WAN é usado pelo tráfego. Isso ocorre porque o fluxo de tráfego pode mudar de túneis várias vezes durante sua vida útil.

Revisão da Configuração de Transporte de Regras de Rede

Se a implantação Ativa/Ativa deve ser alcançada, o papel da interface principal deve ser definido como Automático ou ambas as funções da interface principal e secundária devem ser configuradas conforme mostrado na captura de tela abaixo. Definir a função da interface secundária como Nenhum levará a nenhuma transferência de tráfego quando a interface principal se tornar indisponível. Veja Roteamento de Tráfego sobre as Interfaces Soquete

Revisão da Análise de Rede

O widget Vazão Média mostrará a utilização média de Largura de Banda para cada link WAN. Isso pode servir como um indicador para confirmar que a Regra de Rede está selecionando a conexão WAN correta ou equilibrando o tráfego adequadamente. Na captura de tela abaixo, a Regra de Rede foi modificada para selecionar WAN2 como o transporte principal.

É importante monitorar o desempenho do link WAN, em particular para perda de pacotes, variação e tempo de ida e volta. Conforme explicado em Distribuição de Tráfego Ativa/Ativa, se um link não atender aos limiares mínimos de qualidade do link, ele será considerado não saudável e não será selecionado para a distribuição de tráfego, mesmo se o link WAN for selecionado como o transporte principal.

Revisando a Interface Web do Socket

Uma maneira fácil de descobrir se o Socket considera um link não saudável é a página de Monitoramento na Interface Web do Socket. Se as métricas de latência, variação ou perda de pacotes não atenderem aos requisitos mínimos, o valor não saudável será marcado em vermelho.

No exemplo abaixo, o WAN1 tem uma latência bastante alta, o que leva o Socket a considerar o link não saudável. Esse problema deve ser levantado com o seu ISP.

Verificando a Configuração do Link WAN

Se todos os links ativo/ativo estiverem saudáveis, verifique a configuração de largura de banda para cada link WAN no CMA. No exemplo abaixo, o link WAN1 está configurado com uma largura de banda de 100 Mbps para download/upload, e o link WAN2 está configurado com 20 Mbps para download/upload. Isso resultará no envio de mais tráfego para o WAN1 numa proporção de 100:20 ou 5:1 para ambas as direções de tráfego.

Solução de problemas de Aceleração TCP sendo aplicada ou ignorada

Como discutido em Explicando a Aceleração TCP da Cato, a Aceleração TCP pode ser ativada em uma Regra de Rede para acelerar conexões TCP sobre o WAN. Essa funcionalidade é geralmente aplicada em certos cenários e o administrador pode não conseguir desativá-la mesmo se a opção Aceleração TCP Ativa na regra estiver desmarcada. Esta seção aborda esses cenários e como desativar a funcionalidade quando necessário.

Quando a Aceleração TCP é Aplicada

A Aceleração TCP será aplicada quando a regra de rede usar um IP de saída ou uma localização de saída. Isso força o PoP a agir como um proxy, o que, por sua vez, aplica a aceleração TCP a todos os fluxos de tráfego que correspondem à regra. A caixa de seleção na regra de rede ficará desabilitada.

Desabilitar a Aceleração TCP em uma regra de rede não desabilitará a funcionalidade quando:

  • A inspeção TLS está ativada para a conta, o que ativará a aceleração TCP para todo o tráfego TLS, mesmo se ele for ignorado. Isso ocorre porque o PoP precisa atuar como um proxy para inspecionar o tráfego em busca de arquivos maliciosos e ameaças.
  • Existe uma regra de rede complexa acima da regra de rede correspondente com a Aceleração TCP desativada
  • A regra de rede que tem a Aceleração TCP desativada é ela mesma complexa.

Uma regra de rede complexa (também conhecida como regra NG) é uma regra de rede que o Socket em si não pode avaliar. Portanto, o Socket precisa enviar o tráfego para o PoP para escolher a regra de rede correta, o que, por sua vez, permite a aceleração TCP. Ele pode conter: Aplicações, Categorias de Aplicações, Serviços, Aplicações Personalizadas ou objetos de Domínio/FQDN.

Por outro lado, uma regra simples pode conter as seguintes entidades que podem ser avaliadas pelo Socket e não precisam de envolvimento do PoP:

  • No campo Origem/Destino: Sites, endereços IP, interfaces de rede, Faixa de IP, ou Qualquer.
  • No campo App/Categoria: Faixa de Portas ou um Serviço Personalizado.

Quando a Aceleração TCP é Ignorada

A Aceleração TCP será aplicada apenas ao tráfego TCP. Caso a Aceleração TCP esteja habilitada na regra de rede ou forçada conforme explicado na seção anterior, mas o campo Aceleração TCP no evento CMA é 0, é possível que o roteamento assimétrico sobre a Cato Cloud esteja causando a detecção do fluxo de tráfego como Modo Aberto.

Conforme explicado em Roteamento Assimétrico sobre Cato, o Modo Aberto é um modo de conexão em que o Cato Cloud não está ciente do início do fluxo TCP (handshake de 3 vias), impedindo que a Aceleração TCP seja aplicada. Recomendamos trabalhar com o Suporte da Cato para determinar a causa raiz para a criação de fluxos em Modo Aberto.

Desativando a Aceleração TCP

Para desativar a Aceleração TCP, uma regra simples sem IP de Saída ou localização pode ser colocada no topo da base de regras de rede como descrito em Ordem da Regra de Rede. Conforme mencionado acima, se o tráfego for TLS, a inspeção TLS deve ser desativada para toda a conta.

Solução de Problemas com Desajuste de Prioridade de QoS

Conforme explicado em Quando um Fluxo é Atribuído a Prioridade de QoS 255, pode haver casos em que a prioridade de QoS configurada na regra de rede, é diferente da prioridade mostrada no evento FW.

A prioridade de QoS 255 é referida como a prioridade padrão para Gerenciamento de Largura de Banda. Existem várias razões pelas quais um fluxo pode receber a prioridade de QoS 255, independentemente da configuração de prioridade de largura de banda na regra de rede:

  • A Cato avalia o perfil da rede para cada fluxo, e a prioridade de QoS de 255 é atribuída quando a aplicação específica ainda não foi identificada.
  • Os primeiros pacotes (antes do fluxo ser identificado) são atribuídos à prioridade de QoS 255.
  • Os fluxos bloqueados são atribuídos com a prioridade de QoS 255.

Solucionando Conexões de Tráfego Fora da Nuvem ou Alt-WAN Interrompidas  

Esta seção aborda o cenário em que as conexões TLS falham ao serem estabelecidas entre sites quando a Regra de Rede WAN é configurada com Off-Cloud ou Alt-WAN como o transporte principal. Para solucionar este problema, siga as etapas abaixo.

Análise de Fluxo

Quando o tráfego é corretamente roteado via Fora da Nuvem ou Alt-WAN, fluxos de tráfego não gerarão eventos de FW no CMA porque este tráfego não passa pelo PoP.

Uma maneira de confirmar que o tráfego está sendo roteado com sucesso via Fora da Nuvem ou Alt-WAN é na aba SDWAN da Interface Web do Socket. Identifique o fluxo de tráfego ativo e sob NIC Escolhido você verá o transporte selecionado para o tráfego de interesse. Se o transporte esperado não estiver selecionado, confirme se Fora da Nuvem ou Alt-WAN estão configurados corretamente.

Verificando a Ordem das Regras de Rede

Conforme explicado em Falha de Conexão TLS em Links Off-Cloud ou Alt-WAN, quando o tráfego é TLS e a inspeção TLS está habilitada, a ordem das regras de rede é um fator importante para garantir o fluxo de tráfego em links Off-Cloud ou Alt-WAN.

Sockets não podem avaliar regras de rede e rotear pacotes via Off Cloud ou Alt-WAN quando a regra de rede que o tráfego atinge está abaixo de uma regra complexa. Para resolver este comportamento esperado, veja Ordem da Regra de Rede

Resolução de Problemas Descobertos

Resolvendo Aplicativo Personalizado Sobreposto

Certifique-se de que o aplicativo personalizado inclua os endereços IP corretos, Domínio, Porta e Protocolo. Não há lógica para qual aplicativo personalizado é escolhido para identificação, portanto, o aplicativo customizado deve ser definido de maneira única para evitar sobreposição com outro aplicativo personalizado. Para mais informações, consulte Trabalhando com Aplicações Personalizadas

Ordem da Regra de Rede

Lembre-se de que as Regras de Rede são avaliadas conforme sua ordem, então é importante definir regras mais específicas acima de regras mais gerais. Por exemplo, Regras de Rede que definem um aplicativo personalizado, aplicativo embutido, domínio, FQDN ou serviço personalizado devem ser colocadas acima das Regras de Rede que contêm categorias, categorias personalizadas ou serviços.

Na captura de tela abaixo, a Regra #1 contém um serviço personalizado que inclui intervalos de IP para twitter.com e está colocada acima da Regra #2 que contém Categorias de Aplicações. A Regra #1 é mais específica do que a Regra #2 e será uma melhor correspondência para o tráfego destinado a twitter.com. Isso irá desativar a aceleração TCP e resolver quaisquer problemas de roteamento Fora da Nuvem ou Alt-WAN, dado que a Regra #1 é uma regra simples.

Resolvendo Problemas de Nome de Domínio

Problemas de correspondência de Regra de Rede baseados em Domínio/FQDN podem ser resolvidos da seguinte forma:

  • Para protocolos como HTTP/S, Cato pode determinar o Domínio de destino usando as seguintes Fontes:

    • Cabeçalho do Nome do Host do HTTP (quando Inspeção TLS está ativada)

    • Campo SNI durante o handshake TLS

    • Resolução de DNS, onde o Nome do Domínio é aprendido a partir de consultas e respostas DNS

  • É importante garantir que o Domínio especificado na Regra de Rede seja consistente em todas essas Fontes. Note que apenas o Nome do Domínio melhor correspondido (avaliado de cima para baixo) é exibido como Nome do Domínio em eventos de Firewall. 

  • Para outros Protocolos, como SSH ou SMB, que não enviam um Domínio em texto claro, Cato se baseia exclusivamente na Interceptação de DNS para associar Tráfego a um Domínio ou Nome de domínio totalmente qualificado (FQDN). Isso é particularmente crítico ao usar um DNS Privado, pois precisamos garantir que as consultas/respostas de DNS passem pelo Cato. Consulte Melhores Práticas para DNS e sua Conta Cato

Alteração na Seleção de Saída PoP

Se você deseja rotear todas as regras de saída para a conta através do PoP que está mais próximo do destino, em vez do mais próximo da fonte (comportamento padrão), entre em contato com Suporte Cato Networks Abrindo um caso para o Suporte Cato.

Para aplicações VoIP usando o protocolo SIP que requerem sempre usar o mesmo IP de Saída, ative a opção IP Preferido para Tráfego SIP nas configurações avançadas.

Se um protocolo VoIP diferente ou qualquer outro Aplicativo requer sempre usar o mesmo IP de Saída, entre em contato com o Suporte Cato Networks Abrindo um caso para o Suporte Cato.

Abrindo um Caso para o Suporte Cato

Submeta um Ticket de Suporte com os resultados das etapas de solução de problemas acima. Por favor, inclua as seguintes informações no ticket:

  • Detalhes do problema experimentado e impacto geral nos usuários.
  • Eventos de firewall relacionados e configuração da Regra de Rede.
  • Reproduza o problema e execute o Suporte Autoatendimento. Inclua o número do ticket gerado pela Ferramenta.

Esse artigo foi útil?

Usuários que acharam isso útil: 2 de 2

0 comentário