Resolução de Problemas de Conectividade de Túnel de Site Socket

Visão Geral

A conectividade do site é fundamental para que os hosts por trás de um socket tenham acesso à WAN via nuvem da Cato. A falta de conectividade de um site pode interromper a função de negócios. Este manual busca fornecer orientações para solucionar este cenário.

Sintomas

Uma falha na conectividade do socket pode se manifestar de várias maneiras. Um administrador pode notar os seguintes sintomas:

• O site está desconectado no CMA 
• Site conectando a PoP inesperado
  
• Análise de Rede mostra que o túnel é instável

Causas Possíveis

As seguintes são causas possíveis que você pode identificar durante a solução de problemas

• Sem Conectividade do Socket
  
• Tráfego DTLS em uma única direção
  
• Desempenho Ruim do Underlay
  
• Restrições de Geolocalização de IP
• Configuração inadequada de seleção de PoP
• Configuração de SLA em linhas de base incorretas
• Dispositivo NAT na frente do socket

Resolução do Problema

Os passos para resolver os sintomas que um Administrador pode encontrar estão listados abaixo. Esses passos têm como objetivo identificar causas possíveis para os problemas enfrentados. Os passos de resolução serão destacados posteriormente no manual.

Resolução de Problemas de Site Desconectado no CMA

Coleta de Informações de Eventos

Usando a página Inicial > Eventos no CMA, um administrador pode rapidamente obter um histórico de eventos de conectividade para sites dentro de uma conta. Os eventos podem ser filtrados para eventos relevantes selecionando o 'Status de conectividade dos sites' predefinido ou filtrando pelo Tipo de Evento 'Conectividade' e Subtipo 'Desconectado' Você pode ainda filtrar pelo nome do site em questão com o campo 'Site de Origem'.

Ver o carimbo de hora do evento de desconexão relevante do site em questão pode ajudar a focar a investigação. Houve eventos mais amplos de rede ou eventos de energia locais conhecidos que ocorreram neste carimbo de tempo? Há alguma mudança na trilha de auditoria anterior a isso que pode estar correlacionada?

Verificando Conectividade do Socket

Por favor, veja as Pré-requisitos de Conexão do Socket Cato para entender os requisitos de conexão de um socket.

O status de conectividade do socket pode ser visto através de sua Interface Web local, veja Login na Interface Web do Socket Localmente.. Para que um socket esteja conectado, a porta WAN que está sendo usada para prover a conexão com a nuvem Cato deve mostrar um ícone de status verde. Um indicador diferente do verde sugere um problema de conectividade. O significado de diferentes cores de ícones de status é descrito em Entendendo os Ícones de Status do Link

Para um ícone vermelho, certifique-se de que há um link físico funcionando entre o socket e o dispositivo ISP. Isso inclui os cabos sendo conectados de forma segura e os LEDs das portas acendendo como esperado.

Um conflito de IP também será detectado pelo status de conectividade do socket. O aviso de conflito de IP continuará a ser exibido por um período de 24 horas, começando desde quando o conflito foi detectado pela primeira vez, conforme explicado neste artigo da base de conhecimento.

Confirme que o status Forçar Recuperação via Ignorar Internet em Ferramentas é Normal. O botão 'Forçar Ignorar' forçará todo o tráfego LAN a ignorar Cato e derrubará o túnel da Cato, mostrando o site como desconectado no CMA. Assim, toda configuração e acesso remoto a este dispositivo falhará. Em uma configuração HA, se o Socket Principal estiver com "Desvio Forçado" habilitado, o Socket Secundário continuará como o Socket de backup, e o tráfego atrás dos Sockets será roteado diretamente para a Internet.

A captura de tela abaixo mostra 'Force Bypass' ativado no Socket Principal, e o Socket Secundário permanece como Backup. 

Se o status de Recuperação Forçada é Ativo, saia deste estado clicando no Botão de Sair do Bypass Forçado.

No caso de um problema de conectividade, podemos usar a aba Ferramentas para testar mais. Para conectar-se ao Cato, o socket requer acesso L3 aos endereços IP públicos da Cato. Use a ferramenta de ping para garantir que este Socket possa alcançar endereços IP ou domínios da Cato, ou endereços IP acessíveis conhecidos como 8.8.8.8, diretamente pela porta WAN. Se nenhum for alcançável, por favor ver a Seção de Resolução de Não Conectividade do Socket.

Executando Captura de Pacotes

Uma captura de pacotes também pode ser realizada para garantir que o pedido do Socket para estabelecer um túnel DTLS para o PoP está sendo respondido. Ao capturar na porta WAN em questão, os pacotes bidirecionais no UDP/443 para o PoP devem ser vistos. A captura de tela a seguir mostra um handshake DTLS bem-sucedido e a troca de pacotes de Dados de Aplicação.

Se apenas pacotes DTLS de saída forem detectados ou o handshake DTLS estiver incompleto, por favor veja Resolução de Handshake DTLS Incompleto. 

Incapaz de Estabelecer Túnel Devido a Dispositivo NAT na Frente do Socket

Para Sockets que usam múltiplos links WAN, se houver um dispositivo NAT entre o Socket e o PoP, então é possível que um ou mais dos links WAN não consigam se conectar ao PoP. Isso pode criar problemas de conectividade, como o Status de HA do Site estar Não Pronto.

O PoP usa a porta de origem de cada conexão DTLS de entrada para conectar cada link WAN ao mesmo túnel lógico. O dispositivo NAT pode alterar a porta de origem e impedir que um link WAN se conecte ao mesmo túnel lógico que os outros links WAN.

Conexões DTLS Falhando com Provedores LTE/5G

Conforme mencionado neste estudo de caso, se provedores LTE/5G estiverem sendo usados para conectar-se à Cato, o ISP pode interferir com o handshake DTLS na porta UDP/443, o que pode ser visto como dados específicos do provedor (por exemplo, APN) durante o handshake.

Embora haja comunicação DTLS bidirecional, o handshake não é concluído; portanto, o túnel Cato não será estabelecido. 

Para resolver este problema, altere a porta DTLS para UDP/1337, por favor veja Resolução de Handshake DTLS Incompleto. 

Solucionar Seleção Inesperada de PoP

Verificar Endereço IP do ISP e o PoP Atualmente Selecionado

Sob Monitoramento, selecione um Site e abra o painel de Visão Geral do Site. Na seção Sockets do Site, clique em 'Ver Log' para ver todas as Conexões Recentes. Procure o IP Público do ISP (IP Remoto) que se conecta à Cato, juntamente com o Nome e a localização do ISP. A coluna 'PoP' mostrará o PoP atual ao qual o Site está conectado.

É importante verificar se o 'IP Remoto' e a localização do ISP estão como esperado e se o ISP não está encaminhando a conexão por uma localização inesperada. A localização do ISP (cidade) deve corresponder ou estar próxima do País/Cidade especificado nas Configurações Gerais do Site dentro do CMA.

Verificar Configuração de Seleção do PoP no CMA

Uma localização preferida de PoP obsoleta ou mal configurada em um site pode forçar conexões a PoPs subótimos. A configuração de seleção de PoP pode ser vista por site através da página Rede > Site > Configurações do Site > Geral.

Se uma localização for configurada aqui que não pareça ser adequada para uma conexão ideal, ou se for preferível permitir que o mecanismo de seleção de PoP da Cato determine o PoP ideal, por favor veja a seção Resolução de Configuração de Seleção de PoP Inadequada.

Verificar Configuração de Seleção de PoP no Socket 

Configuração de seleção de PoP obsoleta ou inadequada também pode existir na configuração do socket. Para ver se este é o caso, navegue até as Configurações de Conexão em Nuvem na Interface Web do Socket, veja Usando a Interface Web do Socket.

Se a configuração existir aqui e for preferido permitir que o mecanismo de seleção de PoP da Cato determine o PoP ideal, por favor veja a seção Resolução de Configuração de Seleção de PoP Inadequada.

Verificar Status do PoP

Sockets podem se conectar a um PoP inesperado devido ao PoP geográfico mais próximo estar afetado por manutenção ou por outro problema similar. Por favor veja a página de Status do PoP para verificar se este é o caso. 

Verificar Restrições de Localização para Geolocalização

Conforme o MSA da Cato, locais de soquete em algumas geolocalizações são restritos de conectar-se a PoPs em outras localizações. O MSA está descrito quando da compra dos serviços da Cato.

Locais de soquete em algumas geolocalizações serão limitados a um grupo de PoPs disponíveis, por exemplo, locais de soquete na China se conectarão a PoPs dentro da China, e locais de soquete vietnamitas se conectarão a um grupo de PoPs dentro da Ásia.

Para mais informações sobre isso, por favor consulte o MSA.

Verificar Sinais do Socket Movendo-se Entre PoPs

A página de Eventos pode ser usada para determinar se um socket provavelmente não está no PoP ideal originalmente determinado devido a problemas de conectividade. Usando uma seleção de Campos, uma Linha do Tempo da conectividade do socket para diferentes PoPs.

Ao usar o pré-ajuste de eventos 'Site reconectado', e ao filtrar ainda mais para o site em questão e também definir o valor do campo 'event_message' para 'Problema de desempenho detectado, reconectado a um nó de serviço diferente na Cato Cloud', podemos ver todas as instâncias onde um site socket moveu os PoPs devido a parâmetros de conectividade do túnel ultrapassarem os Limites de SLA configurados. Se um site socket está ultrapassando os Limites de SLA para vários PoPs, continue o fluxo de solução de problemas para verificar as Configurações de Conexão do SLA.

Verificar se o SLA de Conexão não é muito estrito

SLA de Conexão desempenha um papel importante em garantir que um site esteja conectado ao PoP ideal, especialmente em ambientes de rede dinâmicos com infraestrutura pública como através de conexões de Internet do ISP. Um SLA de Conexão muito estrito, no entanto, pode causar reconexões desnecessárias a PoPs que não sejam o local preferido do administrador.

A configuração do SLA de Conexão por site pode ser vista em Rede > Site > Configurações do Site > SLA de Conexão.

Usando Análise de Rede para construir uma linha de base das métricas de desempenho da última milha, considere se as métricas do SLA são adequadas para este site.

Se esses parâmetros não forem adequados, por favor, veja Resolvendo Configuração de SLA em Linha de Base Incorretas

Se os parâmetros forem adequados, mas os eventos de reotimização do PoP ainda estiverem ocorrendo regularmente em vários PoPs, veja a seção Resolvendo Desempenho Ruim do Subjacente.

Se o Socket continuar se conectando a um PoP inadequado após seguir as etapas acima, por favor, abra um ticket com Suporte e destaque o PoP atual e o esperado.

Solucionar Túnel Instável

Verificar a Correlação Entre o Desempenho da Última Milha e a Conexão do Site

Ao notar que um determinado site está experimentando um desempenho ruim em sua conexão a um PoP, é importante isolar se essa perda de pacotes provavelmente é devido ao desempenho na linha ISP subjacente.

Isso pode ser feito correlacionando qualquer questão de desempenho dada ao longo de um período de tempo com o desempenho observado na última milha dentro do mesmo período e procurando padrões.

A Análise de Rede pode ser usada para isso.

O exemplo acima mostra perda de pacotes upstream detectada em um túnel de site para o PoP. Podemos ver vários picos de ~10% e um nível baixo constante de perda ao longo do período de tempo.

Quando comparamos isso com o desempenho para a última milha no mesmo período, podemos ver o seguinte:

Pode-se ver que a última milha também vê alguma variação no desempenho, mas é afetada por um nível constante de perda entre ~10-20%. É claro a partir disso que a perda de pacotes no túnel do socket para o PoP da Cato provavelmente é um sintoma de desempenho ruim no subjacente.

Se este for o caso ao solucionar um problema de desempenho, por favor, veja Resolvendo Desempenho Ruim do Subjacente

Referenciamento Cruzado de Sites Semelhantes

Propriedades compartilhadas entre sites podem ser usadas para tentar inferir fatos sobre o problema em questão. Por exemplo, o site abaixo está tendo problemas de conectividade. Note que o PoP conectado é Londres:

Esta informação pode ser usada para cruzar referências de outros sites que podem estar conectados a Londres para ver se algum problema é compartilhado. Isso pode ser visto na captura de tela abaixo:

Se o referenciamento cruzado sugerir que o problema está em um PoP da Cato, veja a seção Verificar Estado do PoP.

O referenciamento cruzado também é útil para sites com ISPs compartilhados. Isso está sendo feito no exemplo abaixo:

Se este referenciamento cruzado indicar que o ISP está tendo problemas de conectividade, veja a seção Resolvendo Desempenho Ruim do Subjacente.

Verificar se o SLA de Conexão não é muito tolerante

SLA de Conexão desempenha um papel importante em garantir que um site esteja conectado ao PoP ideal, especialmente em ambientes de rede dinâmicos com infraestrutura pública como através de conexões de Internet do ISP. Um SLA de Conexão muito tolerante, no entanto, pode fazer com que os sockets mantenham conexões sub-ótimas com os PoPs por mais tempo do que um administrador gostaria, impactando assim aplicações sensíveis.

A configuração do SLA de Conexão por site pode ser vista em Rede > Site > Configurações do Site > SLA de Conexão.

Usando Análise de Rede para construir uma linha de base das métricas de desempenho da última milha, considere se as métricas do SLA são adequadas para este site.

Se esses parâmetros não forem adequados, por favor, veja Resolvendo Configuração de SLA em Linha de Base Incorretas.

Resolvendo Problemas Descobertos

Resolvendo Conectividade de Socket

É importante isolar se os problemas de conectividade afetam apenas o Socket. Se você conectar um laptop na mesma conexão ISP, encontra os mesmos problemas ao resolver DNS ou pingar endereços? Se sim, entre em contato com seu ISP para avançar.

Certifique-se de que o laptop de teste tenha o IPv6 desativado e, no caso de alocação de Endereço de IP Estático, atribua o mesmo IP do Socket ao testar.

Se os problemas de conectividade estiverem isolados no seu Socket, certifique-se de que a configuração de IP está correta na aba Configurações de Rede do WebUI:

Resolvendo o Handshake DTLS Incompleto

Certifique-se com seu provedor que o tráfego DTLS na porta UDP 443 é permitido para saída em direção à Internet. Se necessário, esta porta pode ser alterada para UDP/1337 conforme descrito em Configurar uma Porta Diferente para Conectar ao Cato PoP.

Resolvendo Desempenho Fraco da Subcamada

O fraco desempenho da subcamada impactará qualquer túnel construído nessa subcamada. Embora a subcamada seja domínio do ISP, existem algumas ferramentas que podem ser usadas para identificar onde os problemas de desempenho estão sendo introduzidos e também para tentar mitigar problemas de desempenho quando possível.

A Interface Web do Socket possui uma ferramenta de rastreamento de rota que permitirá que você pinge hosts acessíveis publicamente pela conexão do ISP. Ao pingar nomes de host acessíveis publicamente, pode-se determinar o salto em que perda ou atraso excessivo é introduzido no caminho l3 entre um socket e o serviço.

No exemplo acima, a perda de pacotes está claramente sendo introduzida diretamente do limite L3 fornecido pelo ISP.

Embora, em última instância, quaisquer problemas de subcamada precisem ser levados ao ISP, garantir que as configurações no CMA estão corretas ajudará a mitigar o impacto dos problemas de desempenho. Certifique-se de que a configuração de largura de banda para uma interface de soquete é precisa para a largura de banda fornecida pela linha. Ferramentas de teste de velocidade da Interface Web do Socket podem ser realizadas para avaliar a Conexão. Além disso, reduzir os parâmetros de explosão de uma conexão pode forçar a Cato a acionar o motor de QoS mais cedo, permitindo que seu tráfego menos prioritário seja descartado em favor de aplicativos mais críticos. 

Resolvendo Configuração de Seleção de PoP Inadequada

Para reverter qualquer configuração manual de seleção de PoP e permitir que Cato selecione o PoP ideal para uma conexão de socket, primeiro certifique-se de que não há configuração manual de localização de PoP no CMA e, em seguida, faça o mesmo para o socket.

No CMA isso pode ser feito em Rede > Site > Geral > Localizações PoP Preferidas.

Certifique-se de que 'Automático' está selecionado.

Na Interface Web do Socket, navegue até Configurações de Conexão com a Nuvem.

Certifique-se de que Destino está definido como 'Steering'.

Resolvendo Configuração de SLA em Limiares Incorretos

O primeiro passo para garantir que a configuração de SLA seja adequada é entender quais são os limites críticos ou requisitos para aplicativos críticos em uso no site.

Para expandir isso, considere dois exemplos.

• A aplicação A é tolerante a baixos níveis de perda de pacotes e tem boas capacidades de reordenação de pacotes; no entanto, a sessão precisa ser mantida para que o serviço funcione; a interrupção e recriação do fluxo causa problemas no aplicativo.
• A aplicação B é muito sensível à perda de pacotes esporádica. Mesmo baixos níveis de perda podem causar interrupções nas transferências de dados e a transferência teria que ser reiniciada do início. Dito isso, o canal de controle é muito resiliente ao término e reconexão de sessões.

Com o perfil da aplicação A, criaríamos uma configuração de SLA que permita baixos níveis de perda, mesmo em janelas temporais longas; é preferível manter a conexão ao PoP para manter a sessão, mesmo que a perda esteja impactando o serviço.

A aplicação B, em contraste, requer uma configuração de SLA mais estrita. É preferível mudar de PoP se mesmo pequenas quantidades de perda de pacotes forem detectadas para proteger a integridade das transferências.

Obviamente, sites usam uma mistura de aplicações com diferentes perfis e requisitos. Um administrador terá que ser estratégico ao equilibrar essas necessidades para uma política de SLA adequada. 

Levantando casos para o Suporte Cato

Se seguir este manual não resolveu o problema, envie um ticket de suporte. Para obter a resposta mais útil a uma solicitação, um administrador deve fornecer resultados das etapas de solução de problemas realizadas durante o uso deste manual. Incluindo, por exemplo:

• Filtros relevantes para chamar a atenção para eventos específicos.
• Resultados dos testes da Interface Web.
• Constatações da Análise de Rede.
• Requisitos de configuração de SLA.