Este artigo discute o recurso de Recuperação WAN para sites Socket que proporciona resiliência na circunstância muito improvável de haver um problema de conectividade com a Nuvem Cato.
Visão geral da recuperação WAN
O recurso de Recuperação WAN é uma das múltiplas opções de recuperação que fornecem resiliência caso os sites Socket não consigam se comunicar usando a Nuvem Cato. A Recuperação WAN utiliza túneis VPN entre sites Socket pela Internet para preservar a conectividade do tráfego WAN entre seus sites, caso ocorra um problema de conectividade com a Nuvem Cato.
Como Funciona a Recuperação WAN?
A Recuperação WAN é baseada em uma topologia de malha completa e é ativada por padrão para todos os sites Socket. Cada Socket cria um túnel DTLS direto para cada outro através da Internet pública. Eles enviam regularmente mensagens de keep-alive pelo túnel e mantêm um túnel ativo aberto para reduzir o tempo de recuperação. Esta topologia proporciona máxima resiliência para os sites Socket em sua conta.
O diagrama a seguir mostra um exemplo onde um Socket está desconectado da Nuvem Cato. A Recuperação WAN é ativada para esse site para proporcionar uma conexão direta entre os dois Sockets:
A Recuperação WAN é um componente crítico da resiliência do Cato Cloud e mantém a conectividade para sites. Para mais informações, veja estes vídeos:
Porta Estática do Site e Recuperação WAN
Para garantir a transição mais suave para sites de Recuperação WAN, você pode usar um IP estático para o site e definir a configuração de IP Público e Porta Estática para um site para melhorar o estabelecimento dos túneis fora da nuvem entre os sites.
Para contas onde é difícil configurar as configurações de IP estático para todos os Sockets, recomendamos que você use configurações de IP estático para alguns sites-chave, como centros de dados, que atuam como hubs para Recuperação WAN. O endereço IP para os sites hubs é enviado para os PoPs e propagado para os outros Sockets em sua conta que estão configurados para Recuperação WAN.
Usando Topologia Hub & Spoke
A topologia de malha completa para Recuperação WAN é principalmente adequada para implementações pequenas e médias, no entanto, esse comportamento gera tráfego desnecessário e aumenta a carga da CPU em ambientes de grande escala. Para esses ambientes, você pode transitar para uma topologia hub & spoke para reduzir o número de túneis e sondas, mantendo desempenho e eficiência ótimos. Para mais informações, consulte Topologia Hub & Spoke Fora da Nuvem para Recuperação WAN.
Os sites Socket na China suportam comunicação via túneis diretos fora da nuvem. Isso permite o roteamento de tráfego de alto volume diretamente entre sites dentro da China e casos de uso de continuidade de negócios.
Recuperando Tráfego de WAN
O Socket mantém um túnel aberto para Recuperação WAN, então se perder a conectividade com a Nuvem Cato, o Socket recupera as conexões com os outros sites e minimiza o tempo de desconexão. O Socket então imediatamente começa a enviar o tráfego WAN pelo link de recuperação WAN.
Você pode usar o Aplicativo de Gerenciamento Cato (CMA) para desativar a Recuperação de WAN, seja para um site específico ou para toda a conta. Para mais informações, consulte este artigo.
Uma vez que a conectividade com a Cato Cloud é restabelecida, a recuperação termina, e o tráfego é enviado pela Cato Cloud.
Configurando Sites para Recuperação de WAN
Recomendamos que você use endereços IP estáticos para sites-chave, como centros de dados, que atuam como hubs para Recuperação WAN. Defina o IP Público e Porta Estática fora da nuvem para cada link WAN nos sites hubs.
Você pode usar a página Postura para confirmar que todos os sites estão habilitados nas configurações de Configuração Avançada para suportar a Recuperação de WAN.
Para configurar um site para Recuperação de WAN:
No menu de navegação, clique em Rede > Locais e selecione o local.
No menu de navegação, clique em Configurações do Site > Socket.
Configure o link WAN para Recuperação de WAN:
Clique no link WAN. O painel Editar Interface de Soquete abre.
Defina o Status do Tráfego para Habilitado.
(Opcional) Defina o IP Público e Porta Estática para o link.
Melhor Prática: Recomendamos que você configure esta configuração para sites principais.
Repita a etapa 3 para todos os links WAN do Socket.
Clique em Aplicar e depois clique em Salvar.
O site está configurado para Recuperação de WAN.
Analisando Eventos de Recuperação de WAN
Eventos de Recuperação WAN são gerados quando um site envia tráfego para outro site usando os túneis DTLS pela Internet, em vez da Nuvem Cato. O CMA mostra os seguintes eventos para recuperação de WAN:
Recuperação Fora da Nuvem Ativada - este evento é gerado quando o Socket começa a enviar o tráfego WAN através do transporte de Recuperação de WAN.
Recuperação Fora da Nuvem Parada - este evento é gerado quando a conexão com o Cato Cloud é restaurada, e o Socket para de enviar tráfego WAN através do transporte de Recuperação WAN.
Eventos não são gerados quando a Recuperação de WAN está funcionando para um site (status está Pronto), mas o site não está enviando tráfego pelos túneis de recuperação DTLS.
Monitorando o Status da Recuperação de WAN
O CMA fornece visibilidade para a prontidão de recuperação de WAN dos seus sites Socket. Você pode identificar proativamente sites com problemas que estão impedindo a Recuperação de WAN e tomar ações corretivas para manter a resiliência da WAN.
Melhor Prática: Configure cada interface de WAN com um endereço IP estático ou dinâmico para garantir uma detecção confiável de túneis e um relatório de status preciso.
Você pode monitorar a recuperação de WAN na coluna Túneis de Recuperação de WAN na página Rede > Sites. O status em tempo real de cada site indica o estado de prontidão dos links WAN para recuperação de WAN:
Pronto (X/X): Este site é para Recuperação de WAN e está conectado a todos os sites de Socket
Parcial (X/Y): O site está parcialmente pronto para recuperação WAN (ou seja, 16/20 significa que este site está conectado a 16 de 20 sites para recuperação WAN)
Não Pronto (0/Y): Este site não está pronto para Recuperação de WAN, e não está conectado a nenhum site de Socket. Este site perderá conectividade WAN se houver uma interrupção com a Cato Cloud
Para revisar o status de Recuperação de WAN para todos os sites:
No menu de navegação, selecione Rede > Sites, e reveja o status na coluna Túneis de Recuperação de WAN.
Você também pode ver o status de um site específico nestas páginas:
Início > Topologia e selecione um site
Configuração do Site > {site name} > Socket
Corrigindo Status Parcial ou Não Pronto
Se um site mostrar um status Parcial ou Não Pronto, tome as seguintes medidas para restaurar a prontidão completa de recuperação:
Verifique as Configurações da Interface WAN: Certifique-se de que cada interface WAN tenha um endereço IP estático ou dinâmico válido e que os links WAN estejam operacionais.
Verifique o Estabelecimento do Túnel: Use o CMA ou a WebUI do Socket para confirmar que os túneis fora da nuvem são criados e mantidos com sites remotos.
Solucione Problemas na Rede Local: Investigue possíveis causas como:
Regras de firewall de entrada/saída estão bloqueando o tráfego
Comportamento incorreto do NAT ou restrições de porta
Configurações de roteamento incorretas
Aplique as Melhores Práticas: Onde possível, configure IPs WAN estáticos em sites críticos (por exemplo, data centers ou hubs) para melhorar a estabilidade do túnel e a precisão do status.
Limitações Conhecidas para Monitoramento de Recuperação de WAN
Problemas Específicos do Site: Um status Não Pronto geralmente indica um problema local no site (como falha no link WAN, problemas de configuração ou problemas de atribuição de IP) ao invés de problemas com sites remotos.
Escopo de Visibilidade da Malha: O status reflete a malha geral de túneis entre sites. Ele não mostra imediatamente quais túneis específicos estão em baixo. Você pode precisar investigar por site ou interface.
Condições de Rede: Problemas temporários de rede, comportamento do NAT ou regras de firewall podem interferir no estabelecimento do túnel e atrasar ou impactar a precisão do status.
Impacto na Conta Durante a Recuperação de WAN
A Recuperação WAN é ativada por padrão para todos os sites Socket para fornecer resiliência usando tráfego fora da nuvem. Se estiver desativada para um ou mais sites, esses sites não poderão se comunicar com outros durante a Recuperação de WAN. Por exemplo, se a Recuperação WAN estiver ativada nos Sites A e B, mas não no Site C, então, durante a Recuperação WAN, o Site C não poderá se comunicar com os Sites A e B, e os Sites A e B não poderão se comunicar com o Site C.
A política de Firewall LAN não é impactada e continua a funcionar normalmente durante a Recuperação de WAN, pois o Socket aplica a política localmente.
Não Reinicie o Socket
Durante a Recuperação WAN, não reinicie o Socket. Reiniciar o Socket durante a Recuperação WAN pode impactar negativamente o site e impedir que ele restabeleça a conectividade com outros sites.
Recuperação de WAN em Ativo/Ativo ou Ativo/Passivo
Para todas as implantações, quando a Recuperação WAN está ativada, cada Socket estabelece túneis DTLS seguros com os sites Socket remotos em todas as interfaces WAN que estão ativadas para tráfego fora da nuvem. Em uma implantação ativo/ativo, o Socket seleciona aleatoriamente um dos links WAN ativos para recuperação WAN. Em uma implantação ativa/passiva, o Socket utiliza o link WAN ativo.
Impacto no CMA Durante a Recuperação de WAN
O Aplicativo de Gerenciamento da Cato (CMA) não recebe dados completos dos sites durante a Recuperação WAN porque os sites impactados não estão mais conectados ao PoP.
Você pode fazer login na WebUI do Socket e usar a aba SD-WAN para monitorar o tráfego e os túneis fora da nuvem. O seguinte exemplo mostra o monitoramento de tráfego na WebUI do Socket:
BGP e Recuperação de WAN
Durante a Recuperação WAN, a tabela de roteamento do Socket é congelada, o que significa que todas as faixas de BGP que existiam antes do início da recuperação serão roteáveis via tráfego fora da nuvem para outros sites. Faixas de BGP que são introduzidas após o início da Recuperação WAN são inalcançáveis até que o Socket saia da recuperação e se reconecte ao PoP.
O tráfego que é passado pelo transporte fora da nuvem de Recuperação de WAN não é processado pelos PoPs na Nuvem Cato. Isso significa que durante a Recuperação de WAN, os serviços do PoP não são aplicados ao tráfego, incluindo os seguintes itens:
Segurança
Políticas de firewall WAN e de Internet
Serviços de Prevenção de Ameaças (ou seja, IPS, Anti-Malware)
Serviços XDR Gerenciados
Rede
Política de NAT
Regras de Rede Complexas
Encaminhamento DNS
Relé DHCP
Tradução de Faixa Estática (SRT)
Acesso à Nuvem
Acesso do Cliente (ou seja, política de Conectividade do Cliente)
Postura do Dispositivo
Recuperação de WAN e Alt. Recuperação WAN
Para contas que permitem recuperação via Alt. WAN (ou seja, MPLS), se o Socket desconectar da Nuvem Cato, o link Alt. WAN tem maior prioridade do que a Recuperação WAN. Portanto, o Socket primeiro move o tráfego para o link Alt. WAN. Se o link Alt. WAN não estiver disponível, o Socket então move o tráfego WAN para o link de Recuperação WAN. Geralmente, a Recuperação WAN tem a menor prioridade como opção de transporte, e é usada apenas quando as outras opções de transporte não estão disponíveis.
Compreendendo o NAT Punching para Conectar Sockets
A Recuperação WAN depende do NAT punching para estabelecer a conectividade WAN entre seus sites. Quando um Socket conecta-se à Cato Cloud, o PoP informa o Socket sobre todos os outros endpoints, e o Socket abre um túnel DTLS para cada um deles. O Socket usa a técnica de perfuração NAT para estabelecer uma conexão direta com os outros Sockets.
Nota: A negociação do NAT punching começa pela Nuvem Cato. Portanto, os Sockets devem estar conectados à Nuvem Cato para permitir o NAT punching.
O diagrama a seguir mostra o fluxo para estabelecer uma conexão direta entre dois Sockets para Recuperação WAN:
A técnica de perfuração NAT funciona para cada par de Sockets da seguinte maneira:
O PoP seleciona um dos Sockets como o iniciador para estabelecer uma conexão direta (Socket 1) com base no ID do site (o site com o maior valor de ID é o iniciador).
O Socket iniciador envia uma solicitação para a Cato Cloud para os seguintes detalhes: endereço IP e número da porta, por exemplo, endereço IP 82.128.1.1 e número da porta 4444 (Passo #2)
O PoP da Cato envia o endereço IP de origem e a porta para o Socket 1
O Socket 1 envia seu endereço IP e porta para o Socket 2 através do túnel Cato
O Socket 2 envia uma solicitação para a Cato Cloud para os seguintes detalhes: endereço IP e porta
O PoP Cato envia o endereço IP de origem e porta para o Socket 2
O Socket 2 envia seu endereço IP e porta para o Socket 1 através do túnel Cato
O Socket 1 envia 32 pacotes para o Socket 2 na faixa da porta de origem, cada pacote com um número de porta diferente
O Socket 2 envia 32 pacotes para o Socket 1 na faixa da porta de origem, cada pacote com um número de porta diferente
Uma vez encontrada a porta correta, os Sockets abrem um túnel DTLS com o endereço IP de origem e o número da porta
Quando Socket 2 se conecta com Socket 1, o roteador adiciona a entrada NAT à sua tabela de roteamento
A partir desse ponto, os Sockets enviam mensagens keep-alive a cada 15 segundos para manter a conexão aberta
Minimizando o Tempo de Reconexão com Perfuração NAT
Depois que a perfuração NAT é bem-sucedida, o Socket salva esses dados NAT. No caso de um reinício do Socket, ele pode se reconectar imediatamente com os outros Sockets utilizando esses dados NAT. Salvar os dados NAT reduz significativamente o tempo de reconexão do Socket. Para Sockets que estão atrás de um firewall de rede ou um roteador, se o firewall ou roteador reiniciar, as entradas NAT são alteradas. Os dados NAT não são mais relevantes, e os Sockets devem realizar o processo de perfuração NAT novamente.