Cet article traite de la fonctionnalité de récupération WAN pour les sites Socket qui assure la résilience dans le cas très improbable d'un problème de connectivité avec le Cato Cloud.
La fonctionnalité de récupération WAN est l'une des options de récupération qui assurent la résilience si vos sites Socket ne peuvent pas communiquer en utilisant le Cato Cloud. La récupération WAN utilise des tunnels VPN entre les sites Socket via Internet pour préserver la connectivité pour le trafic WAN entre vos sites s'il y a un problème de connectivité avec le Cato Cloud.
La récupération WAN est basée sur une topologie full mesh et est activée par défaut pour tous les sites Socket. Chaque Socket crée un tunnel DTLS direct avec toutes les autres via l'Internet public. Ils envoient régulièrement des messages keep-alive sur le tunnel et maintiennent un tunnel actif ouvert pour réduire le temps de récupération. Cette topologie offre une résilience maximale pour les sites Socket de votre compte.
Le schéma suivant montre un exemple où un Socket est déconnecté du Cato Cloud. La récupération WAN est activée pour ce site afin de fournir une connexion directe entre les deux Sockets :
La récupération WAN est un élément critique de la résilience du Cloud Cato et du maintien de la connectivité pour les sites. Pour plus d'informations, voir ces vidéos:
Pour assurer la transition la plus douce pour les sites vers la récupération WAN, vous pouvez utiliser une adresse IP statique pour le site et définir les paramètres IP publique et Port Statique sur l'interface Socket pour améliorer l'établissement des tunnels hors cloud entre les sites.
Pour les comptes où il est difficile de configurer les adresses IP statiques pour tous les Sockets, nous recommandons d'utiliser les paramètres IP statiques pour quelques sites clés, tels que les centres de données, qui agissent comme des hubs pour la récupération WAN. L'adresse IP pour les sites hub est envoyée aux PoPs et propagée aux autres Sockets de votre compte qui sont configurés pour la récupération WAN.
La topologie en maillage complet pour la récupération WAN est principalement appropriée pour les déploiements petits et moyens, cependant, ce comportement génère un trafic inutile et augmente la charge CPU dans des environnements à grande échelle. Pour ces environnements, vous pouvez passer à une topologie Hub & Spoke pour réduire le nombre de tunnels et de sondes, en maintenant une performance et une efficacité optimales. Pour plus d'informations, consultez Topologie Hub & Spoke Hors-Cloud pour la récupération WAN.
Le Socket maintient un tunnel ouvert pour la récupération WAN, donc s'il perd la connectivité avec le Cato Cloud, le Socket récupère les connexions avec les autres sites et minimise le temps de déconnexion. Le Socket commence ensuite immédiatement à envoyer le trafic WAN sur le lien de récupération WAN.
Vous pouvez utiliser l'application de gestion Cato (CMA) pour désactiver la récupération WAN soit pour un site spécifique, soit pour l'ensemble du compte. Pour plus d'informations, consultez Travailler avec la configuration avancée pour le compte.
Une fois la connectivité au Cato Cloud rétablie, la récupération se termine et le trafic est envoyé via le Cato Cloud.
Nous recommandons d'utiliser des adresses IP statiques pour les sites clés, tels que les centres de données, qui agissent comme des hubs pour la récupération WAN. Définir l'IP publique et le Port Statique hors cloud pour chaque lien WAN dans les sites hub.
Vous pouvez utiliser la page des meilleures pratiques pour confirmer que tous les sites sont activés dans les paramètres de configuration avancée pour soutenir la récupération WAN.
Pour configurer un site pour la récupération du WAN :
-
Dans le menu de navigation, sélectionnez Réseau > Sites et sélectionnez le site.
-
Dans le menu de navigation, sélectionnez Configuration du site > Socket.
-
Configurez le lien WAN pour la récupération WAN :
-
Cliquez sur le lien WAN. Le panneau Modifier l'interface Socket s'ouvre.
-
Définissez l'état du trafic sur activé.
-
(Optionnel) Définissez l'IP publique statique et le Port Statique pour le lien.
Meilleure pratique : Nous vous recommandons de configurer ce paramètre pour les sites hub clés.
-
-
Répétez l'étape 3 pour tous les liens WAN Socket.
-
Cliquez sur Appliquer, puis cliquez sur Enregistrer.
Le site est configuré pour la récupération WAN.
Des événements de récupération WAN sont générés lorsqu'un site envoie du trafic à un autre site en utilisant les tunnels DTLS via Internet au lieu du Cato Cloud. Le CMA montre les événements suivants pour la récupération WAN :
-
Récupération hors-cloud activée - cet événement est généré lorsque le Socket commence à envoyer le trafic WAN via le transport de récupération WAN.
-
Récupération hors-cloud arrêtée - cet événement est généré lorsque la connexion au Cloud Cato est restaurée et que le Socket cesse d'envoyer du trafic WAN via le transport de récupération WAN.
Des événements ne sont pas générés lorsque la récupération WAN fonctionne pour un site (état Prêt), mais le site n'envoie pas de trafic via les tunnels DTLS de récupération.
La CMA offre une visibilité sur la préparation de la récupération WAN de vos sites socket. Vous pouvez identifier de manière proactive les sites posant des problèmes empêchant la récupération WAN et prendre des mesures correctives pour maintenir la résilience WAN.
Meilleure pratique : Configurez chaque interface WAN avec une adresse IP statique ou dynamique pour garantir une détection fiable des tunnels et un rapport de statut précis.
Vous pouvez surveiller la récupération WAN dans la colonne Tunnels de récupération WAN sur la page Réseau > Sites. Le statut en temps réel pour chaque site indique l'état de préparation des liens WAN pour la récupération WAN :
-
Prêt (X/X): Ce site est prêt pour la récupération du WAN et connecté à tous les sites Socket
-
Partiel (X/Y): Le site est partiellement prêt pour la récupération WAN (c'est-à-dire, 16/20 signifie que ce site est connecté à 16 sur 20 sites pour la récupération WAN)
-
Non prêt (0/Y): Ce site n'est pas prêt pour la récupération du WAN et n'est pas connecté à des sites Socket. Ce site va perdre la connectivité WAN en cas de panne avec Cato Cloud
Pour examiner le statut de récupération du WAN pour tous les sites :
-
Dans le menu de navigation, sélectionnez Réseau > Sites, et examinez le statut dans la colonne Tunnels de récupération WAN.
Vous pouvez également voir le statut pour un site spécifique sur ces pages :
-
Accueil > Topologie et sélectionner un site
-
Configuration du site > {site name} > Socket
-
Si un site affiche un statut Partiel ou Pas prêt, prenez les mesures suivantes pour rétablir la préparation totale à la récupération :
-
Vérifiez les paramètres de l'interface WAN : Assurez-vous que chaque interface WAN dispose d'une adresse IP statique ou dynamique valide et que les liens WAN sont opérationnels.
-
Vérifiez l'établissement du tunnel : Utilisez le CMA ou le WebUI du Socket pour confirmer que les tunnels hors-cloud sont créés et maintenus avec les sites distants.
-
Dépannez les problèmes de réseau local : Enquêtez sur des causes possibles telles que :
-
Les règles de pare-feu entrant/sortant bloquent le trafic
-
Comportement incorrect du NAT ou restrictions de port
-
Erreurs de configuration de routage
-
-
Appliquer les meilleures pratiques : Lorsque possible, configurez des IP WAN statiques sur des sites critiques (par exemple, les centres de données ou les hubs) pour améliorer la stabilité des tunnels et la précision du statut.
-
Problèmes spécifiques au site : Un statut Non prêt indique généralement un problème local sur le site (tel qu'une panne du lien WAN, des problèmes de configuration ou de l'attribution des IP) plutôt que des problèmes avec les sites distants.
-
Portée de visibilité du maillage : Le statut reflète le maillage global des tunnels entre les sites. Il ne montre pas immédiatement quels tunnels spécifiques sont en panne. Il peut être nécessaire d'examiner par site ou par interface.
-
Conditions du réseau : Des problèmes de réseau temporaires, le comportement du NAT ou les règles de pare-feu peuvent interférer avec l'établissement des tunnels et retarder ou impacter la précision du statut.
La récupération WAN est activée par défaut pour tous les sites Socket pour fournir une résilience en utilisant le trafic hors cloud ; si elle est désactivée pour un ou plusieurs sites, ils ne peuvent pas communiquer avec les autres. Par exemple, si la récupération WAN est activée sur les sites A et B, mais pas pour le site C, pendant la récupération, le site C ne peut pas communiquer avec les autres sites, et les sites A et B ne peuvent pas communiquer avec le site C.
La politique de pare-feu LAN n'est pas affectée et continue de fonctionner normalement pendant la récupération WAN car le socket applique la politique.
Pendant la récupération WAN, assurez-vous de ne PAS redémarrer le socket, sinon il pourrait y avoir un impact négatif sur le site et il pourrait ne pas être en mesure de rétablir la connectivité avec les autres sites.
Pour tous les déploiements, lorsque la récupération WAN est activée, chaque Socket établit des tunnels DTLS sécurisés vers le site Socket distant sur toutes les interfaces WAN qui sont activées pour le trafic hors cloud. Pour la configuration de lien actif/actif, le Socket sélectionne au hasard l'un des liens actifs pour la récupération WAN. Pour actif/passif, le Socket utilise le lien actif.
L'Application de gestion Cato (CMA) ne reçoit pas toutes les données de site car elle n'est pas connectée au PoP et n'est pas au courant de l'état des sites impactés.
Vous pouvez vous connecter au WebUI du socket et utiliser l'onglet SD-WAN pour surveiller le trafic et les tunnels hors cloud. Voici un exemple de surveillance du trafic avec le WebUI du socket :
Pendant la récupération WAN, la table de routage du Socket est figée, ce qui signifie que toutes les plages BGP qui existaient avant le début de la récupération seront acheminables via le trafic hors cloud vers d'autres sites. Les plages BGP qui sont introduites après le début de la récupération WAN sont inaccessibles jusqu'à ce que le Socket sorte de la récupération et se reconnecte au PoP.
Le trafic qui est transmis via le transport hors cloud de récupération WAN n'est pas traité par les PoPs dans le Cato Cloud. Cela signifie que pendant la récupération WAN, les services PoP ne sont pas appliqués au trafic, y compris les éléments suivants :
-
Sécurité
-
Politiques de pare-feu WAN et Internet
-
Services de prévention des menaces (c'est-à-dire IPS, Anti-Malware)
-
Services XDR gérés
-
-
Réseau
-
Politique NAT
-
Règles de réseau complexes
-
Transfert DNS
-
Relais DHCP
-
Traduction de portée statique (SRT)
-
-
Accès
-
Accès client (c'est-à-dire politique de connectivité client)
-
Posture de l'appareil
-
Pour les comptes qui activent la récupération via Alt. WAN (c.-à-d. MPLS), si le Socket se déconnecte du Cato Cloud, le lien WAN Alt. a une priorité plus élevée que la récupération WAN. Par conséquent, le Socket déplace d'abord le trafic vers le lien WAN Alt. . Si le lien WAN Alt. n'est pas disponible, le Socket déplace alors le trafic WAN vers le lien de récupération WAN. Généralement, la récupération WAN a la plus basse priorité en tant qu'option de transport et n'est utilisée que lorsque les autres options de transport ne sont pas disponibles.
La récupération WAN repose sur le NAT punching pour établir la connectivité WAN entre vos sites. Lorsqu'un socket se connecte au Cato Cloud, le PoP informe le socket de tous les autres points de terminaison, et le socket ouvre un tunnel DTLS vers chacun d'eux. Le Socket utilise la technique du NAT punching pour établir une connexion directe avec les autres Sockets.
Remarque : La négociation du NAT punching commence sur le Cato Cloud. Par conséquent, les Sockets doivent être connectés au Cato Cloud pour permettre le NAT punching.
Le schéma suivant montre le flux pour établir une connexion directe entre deux Sockets pour la récupération WAN :
La technique NAT punching fonctionne pour chaque paire de Sockets de la manière suivante :
-
Le PoP sélectionne l'un des Sockets comme l'initiateur pour établir une connexion directe (Socket 1) basée sur l'ID de site (le site avec la valeur ID la plus élevée est l'initiateur).
-
Le Socket initiateur envoie une requête à Cato Cloud pour obtenir les détails suivants : adresse IP et numéro de port, par exemple, adresse IP 82.128.1.1 et numéro de port 4444 (Étape #2)
-
Le PoP Cato envoie l'adresse IP source et le port au Socket 1
-
Le Socket 1 envoie son adresse IP et son port au Socket 2 via le tunnel Cato
-
Le Socket 2 envoie une requête à Cato Cloud pour obtenir les détails suivants : adresse IP et port
-
Le PoP Cato envoie l'adresse IP source et le port au Socket 2
-
Le Socket 2 envoie son adresse IP et son port au Socket 1 via le tunnel Cato
-
Le Socket 1 envoie 32 paquets au Socket 2 dans la plage du port source, chaque paquet avec un numéro de port différent
-
Le Socket 2 envoie 32 paquets au Socket 1 dans la plage du port source, chaque paquet avec un numéro de port différent
-
Une fois le port correct trouvé, les Sockets ouvrent un tunnel DTLS avec l'adresse IP source et le numéro de port
Lorsque Socket 2 se connecte avec Socket 1, le routeur ajoute l'entrée NAT à sa table de routage.
-
À partir de ce moment-là, les Sockets envoient des messages keep-alive toutes les 15 secondes pour maintenir la connexion ouverte
Après le succès du NAT punching, le Socket enregistre ces données NAT. Dans le cas d'un redémarrage de Socket, il peut se reconnecter immédiatement aux autres Sockets avec ces données NAT. L'enregistrement des données NAT réduit considérablement le temps de reconnexion du Socket. Pour les Sockets qui sont derrière un pare-feu réseau ou un routeur, si votre pare-feu ou routeur redémarre, les entrées NAT sont modifiées. Les données NAT ne sont plus pertinentes, et les Sockets doivent effectuer à nouveau le processus de NAT punching.
0 commentaire
Vous devez vous connecter pour laisser un commentaire.