Resolução de Problemas de Acesso a Recursos Internos

Visão Geral

Garantir o acesso contínuo aos recursos internos é fundamental para manter a produtividade e a segurança na rede. No entanto, vários fatores podem interromper o acesso, levando a uma má experiência do usuário e dificultando o fluxo de trabalho. Este manual visa fornecer um guia abrangente para solução de problemas de acesso WAN a recursos internos dentro da Cato Cloud.

Sintomas

Uma falha ao acessar recursos internos pode se manifestar de várias maneiras. Um administrador pode notar os seguintes sintomas:

  • O nome de domínio do servidor interno não pode ser resolvido
  • O servidor interno não pode ser alcançado
  • Desajuste de regra de firewall WAN
  • Clientes SDP não conseguem acessar Recursos Internos
  • Recurso de Encaminhamento de Porta Remota (RPF) não pode ser alcançado
  • O host de monitoramento LAN é inacessível

Possíveis Causas

  • Problemas de roteamento
  • Configuração incorreta de encaminhamento DNS
  • Configuração incorreta do firewall WAN
  • Sobreposição com a Rede do Cliente SDP
  • Intervenção de Segurança
  • Problemas de conectividade do host de destino

Avaliação Inicial

Nota

Nota: Certifique-se de que você tem uma Regra de Firewall WAN (mesmo criada temporariamente para fins de solução de problemas) com rastreamento de eventos habilitado.

Para problemas relacionados ao acesso a servidores internos via Acesso ao Navegador, veja Solução de Problemas de Acesso ao Navegador

Revise eventos de firewall WAN, IPS e Anti-malware selecionando a predefinição respectiva no CMA. Defina filtros para restringir o tráfego interessante e verifique se o fluxo foi bloqueado pelo firewall WAN ou pelos motores IPS/AM. O campo regra mostrará a respectiva regra que corresponde ao tráfego.

Certifique-se de revisar a seção de solução de problemas apropriada seguindo estas etapas de avaliação inicial:

Resolução de Problemas da Questão

As etapas para solucionar os sintomas que um Administrador pode encontrar estão listadas abaixo. Essas etapas destinam-se a identificar possíveis causas para os problemas enfrentados. As etapas de resolução serão destacadas mais tarde no manual.

Verificando Logs de Trilha de Auditoria

Verifique a Trilha de Auditoria para quaisquer logs modificados que possam ter impactado o acesso aos recursos internos. Isso inclui regras de firewall WAN, configurações de AM/IPS e inspeção TLS.

Resolução de Problemas de Resolução de Nome de Domínio do Servidor

Verificando Resolução DNS

Se o recurso interno deve ser alcançado usando seu nome de domínio, confirme se o nome de domínio do servidor interno pode ser resolvido, utilizando os comandos nslookup ou dig da linha de comando.

Pode haver dois cenários para resolução de DNS interna em sua conta:

  • Se um endereço IP de servidor DNS privado for usado na organização, confirme se os usuários afetados podem alcançar o servidor DNS internamente. Caso contrário, solucione conectividade ao servidor DNS, similar à Solução de Problemas de Servidor Interno Inacessível
  • Se o servidor DNS padrão da Cato 10.254.254.1, servidor DNS definido pela conta, ou DNS público conhecido (8.8.8.8, 1.1.1.1 ou 9.9.9.9) forem usados na conta, solucione o encaminhamento DNS no próximo passo.

Verificando o encaminhamento DNS

Fluxos de tráfego que dependem de nomes de domínio internos (por exemplo, pc1.domain.net) devem ter o encaminhamento DNS corretamente configurado no CMA. Também é crucial que a Cato intercepte os fluxos DNS para poder resolver os nomes de domínio corretamente.

O encaminhamento de DNS pode funcionar apenas se as consultas DNS forem direcionadas para servidores DNS específicos, conforme explicado em Resolvendo Problemas de Encaminhamento de DNS.

Solução de Problemas de Servidor Interno Inacessível

Verificando a Tabela de Roteamento da Cato

A tabela de roteamento pode ser usada para verificar disponibilidade de rotas, métricas e mais:

  • Pesquise o endereço IP do recurso na string de pesquisa e confirme se há uma rota correspondente existente via o Site correto.
  • Se nenhuma rota for encontrada, isso significa que a Cato não está ciente dessa rota, portanto, não pode roteá-la para este destino. Para resolver este problema, veja Resolvendo Problemas de Roteamento
  • Se houver rotas para o mesmo destino, verifique se as faixas dinâmicas do BGP não se sobrepõem com outras rotas estáticas. Rotas com métricas inferiores são preferidas.
  • BGP também pode anúnciar rotas redundantes de diferentes sites. A rota com métrica inferior, incluindo Peso, Comprimento AS, ou MED é preferida. Veja Entendendo os Campos da Tabela de Roteamento.
  • Para resolver problemas de métrica, veja Resolvendo Problemas de Roteamento

Verificando o Roteamento Baseado em Política do IPSec

Se o recurso interno for alcançável via IPSec, confirme que os intervalos corretos estão definidos nas seções de IPSec e Redes do Site como explicado no Manual de Solução de Problemas de IPSec.

Se o roteamento baseado em política estiver configurado, todos os seletivos de tráfego devem corresponder tanto na Cato quanto no firewall/roteador IPSec para garantir conectividade com os recursos internos.

Verificando a Atividade do Recurso Interno

Se o recurso interno estiver localizado atrás de um socket ou vSocket, verifique o valor de Última Atividade do Host na página de Hosts Conhecidos no site. Veja Mostrando Hosts Conhecidos para um Site

Hosts que não foram vistos recentemente pelo Site podem estar desligados ou não conectados à rede.

Execute uma captura de pacotes a partir do WebUI e identifique quaisquer possíveis problemas dentro da LAN.

Verificando fluxos TLS

Se o tráfego interessante for TLS e você tiver verificado que as etapas anteriores permitem o tráfego. Verifique se o fluxo de tráfego está sendo inspecionado por TLS pela Cato. Isso pode ser encontrado na regra de FW com o campo de Inspeção TLS configurado para 1.

Se assim for, o certificado raiz da Cato deve ser instalado no dispositivo de origem conforme explicado em Configurando a Política de Inspeção TLS. Caso contrário, ignore a inspeção TLS para evitar qualquer erro de certificado e possíveis problemas de acesso ao recurso.

Solução de Problemas de Incompatibilidade de Regras de Firewall WAN

Ao configurar uma regra de firewall, pode ser que o tráfego seja avaliado contra a regra errada. Esta seção cobre todos os possíveis cenários de incompatibilidade e como solucionar este problema.

Verificando Aplicação Personalizada

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

Para prevenir este problema, consulte a seção Resolvendo Aplicações Personalizadas Sobrepostas.

Verificando Aplicação/Serviço Incorporado

Se o tráfego interessante for esperado para corresponder a uma Aplicação ou Serviço incorporado e o tráfego estiver correspondendo à regra de firewall errada, verifique o seguinte:

  • Quais aplicações ou serviços estão configurados na "regra de firewall" coincidente errada.
  • Se algum desses aplicativos/serviços está listado no campo de Aplicações Relacionadas do evento FW.

A identificação de Aplicação/Serviço é um processo de múltiplas etapas que começa com a identificação do protocolo e depois todas as possíveis Aplicações correspondentes que estão incluídas no campo de Aplicações Relacionadas. Qualquer aplicação "relacionada" identificada em um fluxo, independentemente da decisão da aplicação final (campo Aplicação), corresponderá a uma regra de firewall.

No exemplo abaixo, o tráfego SMB coincide com a Regra #1 ao invés da Regra #2. Isso ocorre porque a Regra #1 inclui o serviço TCP (incluído em Aplicações Relacionadas) mesmo que a aplicação final (campo Aplicação) seja SMB.

Para resolver este comportamento esperado, consulte Ordem da Regra de Firewall

Verificando o Nome do Domínio Configurado

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

Lembre-se de que um FQDN é uma correspondência exata do nome de domínio totalmente qualificado. Por exemplo, o 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 a Cato não possa determinar o Nome do Domínio correto a partir de fluxos HTTP, TLS ou DNS. Para resolver esses tipos de problemas, veja Resolução de Problemas de Incompatibilidade de Nome de Domínio

Solução de Problemas de Cliente SDP Não Conectando a Recursos Internos

Esta seção trata de problemas exclusivos para Clientes SDP que não alcançam recursos internos.

Verificando Sobreposição de Subrede da Rede Doméstica do Usuário

Se o Cliente SDP não puder se conectar a recursos internos, incluindo pingar o servidor, verifique se há uma sobreposição de endereço IP entre a rede doméstica do usuário e o local com os recursos internos. Se for esse o caso, a tabela de roteamento do cliente apontará para a NIC local ao tentar se conectar ao servidor interno localizado atrás do site remoto da Cato, resultando em uma falha de conexão.

Locais remotos com um intervalo de IP de 192.168.0.0/24, 192.168.1.0/24 ou 10.0.0.0/24 podem facilmente se sobrepor ao intervalo de IP dos roteadores sem fio domésticos, que frequentemente usam esse intervalo de IP como configuração DHCP padrão.

Para resolver este problema, siga os passos descritos em SDP Cliente Não Consegue Conectar-se a Recursos WAN Remotos.

Usuários macOS e iOS não resolvem domínios internos

Como explicado em Usuários macOS Ventura e iOS Incapazes de Alcançar Recursos Internos Via Cato, se o Cliente SDP não puder se conectar a recursos internos usando seu Nome do Domínio, mas puder alcançá-los usando seu Endereço IP, é possível que o Encaminhamento DNS esteja falhando devido ao DoH (DNS sobre HTTPS) ou DoT (DNS sobre TLS) sendo usado pelo endpoint. Cato atualmente não suporta DoH/DoT.

Para resolver este problema, consulte Resolução de Problemas de Encaminhamento DNS. Alternativamente, o Servidor DNS da Cato (10.254.254.1) pode ser definido no CMA como o único servidor DNS para o endpoint.

Usuários Android Não Resolvem Domínios Internos

Como explicado em Dispositivos Android Incapazes de Alcançar Recursos Internos Via Cato, se o Cliente SDP não puder se conectar a recursos internos usando seu Nome do Domínio, mas puder alcançá-los usando seu Endereço IP, é possível que o Encaminhamento DNS esteja falhando devido ao DNS Privado Automático utilizado pelo dispositivo (comportamento padrão), que impõe DoH/DoT para resolução de DNS. Isso atualmente não é suportado pela Cato.

Para resolver este problema, consulte Resolução de Problemas de Encaminhamento DNS. Alternativamente, o DNS Privado pode ser desativado no dispositivo.

Solução de Problemas de Recursos Internos RPF

Análise de Eventos RPF

Revise os eventos RPF selecionando o predefinido RPF no CMA. Confirme que o evento é gerado, o que confirmará que o IP externo da Cato está disponível. Observe que o endereço IP de destino é o IP público externo configurado na regra RPF.

Nota: Eventos RPF de entrada podem às vezes exibir um Nome de Exibição de Usuário, mesmo que o tráfego não seja iniciado pelo usuário. Este é o comportamento esperado.

Campos de evento na plataforma Cato obtêm metadados do túnel, host, e agente do usuário, não apenas do fluxo de tráfego. Portanto, se um usuário estiver mapeado em um dispositivo atrás de socket ou túnel, o nome dele pode aparecer no evento—mesmo para tráfego de entrada.

Isso difere de como políticas de firewall ou de roteamento interpretam o tráfego (que são conscientes da direção), mas é normal para correlação de eventos. 

 

Análise de Eventos de Bloqueio Geográfico

Revise quaisquer eventos destinados ao endereço IP interno do servidor interno. Confirme que nenhuma restrição de Bloqueio Geográfico está impedindo a conexão com o servidor interno. Se sim, edite a política de Restrição Geográfica para a direção de entrada para permitir o país de origem.

Verificando a Vivacidade do Recurso Interno

Verifique o valor de Última Atividade Conhecida na página Hosts Conhecidos no site. Veja Mostrando Hosts Conhecidos para um Site

Hosts que não foram vistos recentemente pelo Site podem estar desligados ou não conectados à rede.

Execute uma captura de pacote do WebUI e identifique quaisquer possíveis problemas dentro da LAN.

Solução de Problemas de Host de Monitoramento LAN Inacessível

Análise de Eventos de Conectividade

Revise os eventos de Conectividade selecionando o predefinido Hosts LAN inacessíveis no CMA. Eventos de Host Inacessível serão gerados quando o host LAN definido não for mais acessível.

Verificando a Acessibilidade do Host Local

Confirme que o host local definido pode ser pingado a partir da Interface Web do Socket. Se o ping for bem-sucedido, verifique o seguinte:

  • As sondas de monitoramento LAN são pacotes ICMP originados de 10.254.254.1, por isso é importante confirmar que o host monitorado tem uma rota de volta para o Gateway LAN do Socket para poder responder.
  • Se o dispositivo estiver executando um firewall local, o ICMP deve ser permitido a partir do endereço IP 10.254.254.1.

Execute uma captura de pacotes a partir da WebUI e identifique quaisquer possíveis problemas na LAN.

Resolvendo Problemas Descobertos

Resolvendo Problemas de Roteamento

Se a rota para o recurso interno não for encontrada na tabela de roteamento, verifique e resolva o seguinte:

  • Se o BGP estiver configurado para o site, verifique se as rotas estão sendo anunciadas pelo vizinho. Consulte Mostrar Status do BGP. É importante revisar os prefixos BGP que o roteador local anuncia e confirmar que o Cato está os recebendo.
  • Se a sessão BGP estiver inativa, resolva o problema de desconexão. Consulte Sessão BGP Desconectada
  • Certifique-se de que o site que hospeda o intervalo esteja disponível. Consulte Solução de Problemas de Conectividade do Site

Se o valor da métrica de rota visto na tabela de roteamento estiver causando decisões de roteamento incorretas, verifique e resolva o seguinte:

  • Os valores de métrica de túnel geralmente são definidos pelo Cato. Rotas redundantes devem ter a mesma métrica de túnel, desde que se originem do mesmo tipo de site, por exemplo, IPSec ou Site do Socket.
  • O valor de peso pode ser configurado no CMA, Network > Site > Configurações do Site > BGP. O valor da métrica configurado nesta página será visto como peso na tabela de roteamento. Alterar a métrica para o site corrigirá decisões de roteamento incorretas para rotas redundantes.
  • Os valores métricos de Comprimento AS e Métrica Discriminatória são recebidos do roteador externo. Eles devem ser modificados neste dispositivo, se necessário.

Resolvendo Falsos Positivos de Bloqueios de IPS/Anti-Malware

Se o tráfego interessante for bloqueado pelo IPS/AM, você pode adicionar Lista de Permissão com escopo WAN para as configurações de IPS e Anti-Malware.

 

Resolvendo Aplicativos Personalizados Sobrepostos

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

Ordenação de Regras de Firewall

Lembre-se de que as Regras de Firewall são avaliadas de acordo com sua ordem, por isso é importante definir regras mais específicas acima de regras mais gerais. Por exemplo, Regras de Firewall que definem um Aplicativo Personalizado, Aplicação Incorporada, Domínio, Nome de domínio totalmente qualificado (FQDN) ou Serviço Personalizado devem ser colocadas acima de Regras de Firewall que contenham 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 é colocada acima da Regra #2 que contém Categorias de Aplicações. A Regra #1 é mais específica que a Regra #2 e será uma melhor correspondência para o tráfego destinado a twitter.com. Isso também desativará a aceleração TCP e resolverá quaisquer problemas de roteamento Fora da Nuvem ou Alt-WAN, sendo que a Regra #1 é uma regra simples.

Resolvendo Problemas de Incompatibilidade de Nome de Domínio

Problemas de correspondência de Regra de Firewall baseadas em Domínio/Nome de domínio totalmente qualificado (FQDN) podem ser resolvidos da seguinte forma:

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

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

    • Campo SNI durante o handshake TLS

    • Resolução 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 Firewall seja consistente em todas essas fontes. Nota que apenas o nome de domínio melhor correspondido (avaliado de cima para baixo) é exibido como Nome do Domínio nos eventos de Firewall. 

  • Para outros protocolos, como SSH ou SMB, que não enviam um domínio em texto puro, a Cato depende exclusivamente da interceptação DNS para associar o tráfego a um domínio ou FQDN. Isso é particularmente crítico ao usar um DNS privado, pois precisamos garantir que as consultas/respostas DNS passem pelo Cato. Consulte Melhores Práticas para DNS e Sua Conta Cato
  • DoH (DNS sobre HTTPS) e DNS sobre TLS não são suportados para correspondência de Nome de Domínio/Aplicativo, portanto, eles devem ser bloqueados nas regras de Firewall para forçar a movimentação das consultas DNS para UDP/53.

Resolvendo Problemas de Encaminhamento DNS

Você só pode usar o encaminhamento DNS quando as consultas DNS são destinadas aos seguintes servidores DNS:

  • Servidor DNS padrão do Cato 10.254.254.1
  • Servidores DNS a nível de conta, configurados em Rede > Configurações de DNS
  • Servidores DNS conhecidos, como 8.8.8.8, 1.1.1.1 e 9.9.9.9. A lista de Servidores DNS conhecidos pode variar entre PoPs. Por exemplo, China e Sydney.

DoH (DNS sobre HTTPS) e DNS sobre TLS não são suportados para Encaminhamento DNS, portanto, devem ser bloqueados nas Regras de Firewall para forçar o movimento das consultas DNS para UDP/53. Esta solução aplica-se especialmente aos Clientes SDP de macOS, iOS e Android.

 

Abordando Casos ao Suporte Cato

Envie 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 enfrentado e impacto geral nos usuários.
  • Eventos de Firewall relacionados e Configuração de Regras de Firewall.
  • Reproduza o problema e execute o Suporte Autoatendimento. Inclua o número do ticket gerado pela ferramenta.
  • Se o usuário afetado conectar-se à Cato usando o Cliente SDP, por favor Registre o Problema Usando o Cliente SDP
  •  

Esse artigo foi útil?

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

0 comentário