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.
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.
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:
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.
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.
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, veja Trabalhando com Configuração Avançada para a Conta.
Uma vez que a conectividade com a Cato Cloud é restabelecida, a recuperação termina, e o tráfego é enviado pela Cato Cloud.
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 Melhores Práticas 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, selecione Rede > Sites, e selecione o site.
-
No menu de navegação, selecione Configuração do Site > Socket.
-
Configure o link WAN para Recuperação de WAN:
-
Clique no link WAN. O painel Editar Interface do Socket é aberto.
-
Defina o Status do Tráfego para Habilitado.
-
(Opcional) Defina o IP Público e Porta Estática estática para o link.
Melhor Prática: Recomendamos que você configure esta configuração para sites principais.
-
-
Repita o passo 3 para todos os links WAN do Socket.
-
Clique em Aplicar, e então clique em Salvar.
O site está configurado para Recuperação 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. A CMA mostra os seguintes eventos para recuperação 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.
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
-
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.
-
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.
A Recuperação WAN está ativada por padrão para todos os sites de Socket para fornecer resiliência usando tráfego fora da nuvem, se estiver desabilitada para um ou mais sites, eles não conseguirão se comunicar com os outros. Por exemplo, se a recuperação WAN estiver ativada nos sites A e B, mas não para o site C, durante a recuperação, o site C não conseguirá se comunicar com os outros sites, e os sites A e B não poderão se comunicar com o site C.
A política de Firewall do LAN não é impactada e continua a funcionar normalmente durante a Recuperação de WAN porque o Socket aplica a política.
Durante a Recuperação de WAN, certifique-se de NÃO reiniciar o Socket, caso contrário, pode haver um impacto negativo no site, e ele pode não conseguir restabelecer a conectividade com os outros sites.
Para todas as implantações, quando a Recuperação WAN está ativada, cada Socket estabelece túneis DTLS seguros para o site de Socket remoto em todas as interfaces WAN que estão ativadas para tráfego fora da nuvem. Para configuração de link ativo/ativo, o Socket seleciona aleatoriamente um dos links ativos para recuperação WAN. Para ativo/passivo, o Socket utiliza o link ativo.
O Aplicativo de Gerenciamento Cato (CMA) não recebe todos os dados do site porque não está conectado ao PoP e não tem conhecimento do status dos sites impactados.
Você pode fazer login na WebUI do Socket e usar a aba SD-WAN para monitorar o tráfego e túneis fora da nuvem. Este é um exemplo de monitoramento de tráfego com o WebUI do Socket:
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 WAN não é processado pelos PoPs na Nuvem Cato. Isso significa que durante a Recuperação WAN, os serviços 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
-
Acesso do Cliente (ou seja, política de Conectividade do Cliente)
-
Postura do Dispositivo
-
Para contas que habilitam 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.
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 NAT punching 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 NAT punching 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 da Cato envia o endereço IP de origem e a 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 que a porta correta é encontrada, os Sockets abrem um túnel DTLS com o endereço IP de origem e o número da porta
Quando o Socket 2 se conecta com o 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
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.
0 comentário
Por favor, entre para comentar.