Cet article traite de la fonctionnalité de récupération WAN pour les sites Socket qui assure la résilience dans l'éventualité très improbable d'un problème de connectivité avec le Cloud de Cato.
La fonctionnalité de récupération WAN est l'une des multiples options de récupération qui offrent une résilience si vos sites Socket ne peuvent pas communiquer via le Cloud de Cato. La récupération WAN utilise des tunnels VPN entre les sites Socket via Internet pour préserver la connectivité du trafic WAN entre vos sites s'il y a un problème de connectivité avec le Cloud de Cato.
La récupération WAN est basée sur une topologie en maillage complet et est activée par défaut pour tous les sites Socket. Chaque Socket crée un tunnel DTLS direct à chaque autre via Internet public. Ils envoient régulièrement des messages de keep-alive sur le tunnel et maintiennent un tunnel ouvert pour réduire le temps de récupération. Cette topologie offre une résilience maximale pour les sites Socket dans votre compte.
Le schéma suivant montre un exemple où un Socket est déconnecté du Cloud de Cato. La récupération WAN est activée pour ce site afin de fournir une connexion directe entre les deux Sockets :
Pour assurer la transition la plus fluide des sites vers la récupération WAN, vous pouvez utiliser une IP statique pour le site et définir les paramètres de IP publique et port statique pour un site afin d'améliorer l'établissement des tunnels hors cloud entre les sites.
Pour les comptes où il est difficile de configurer les paramètres d'IP statique pour tous les Sockets, nous vous recommandons d'utiliser des paramètres d'IP statique 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 des sites hub est envoyée aux PoP et propagée aux autres Sockets de votre compte configurés 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 Cloud de Cato, le Socket récupère les connexions avec les autres sites et minimise le temps de déconnexion. Ensuite, le Socket commence immédiatement à envoyer le trafic WAN via le lien de récupération WAN.
Vous pouvez utiliser l'Application de Gestion Cato pour désactiver la récupération WAN soit pour un site spécifique ou pour l'ensemble du compte. Pour plus d'informations, consultez Travailler avec la Configuration Avancée pour le Compte.
Une fois la connectivité avec le Cloud de Cato rétablie, la récupération se termine et le trafic est envoyé via le Cloud de Cato.
La page Socket pour un site montre le statut hors cloud pour les liens WAN. Lorsque le statut est activé, les liens sont prêts pour la récupération WAN.
Nous vous 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éfinissez l'IP Publique hors cloud et le Port Statique pour chaque lien WAN dans les sites hub.
Vous pouvez utiliser la page des Bonnes Pratiques pour confirmer que tous les sites sont activés dans les paramètres de Configuration Avancée pour prendre en charge la Récupération du WAN.
Pour configurer un site pour la récupération WAN :
-
Dans le menu de navigation, sélectionnez Network > Sites, et sélectionnez le site.
-
Dans le menu de navigation, sélectionnez Site Configuration > Socket.
-
Configurez le lien WAN pour la récupération WAN :
-
Cliquez sur le lien WAN. Le panneau Editer l'interface Socket s'ouvre.
-
Définissez le Statut du trafic sur Activé.
-
(Optionnel) Définissez l'IP Publique statique et le Port Statique pour le lien. Nous recommandons ce paramètre pour les sites hubs 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.
Les événements de récupération du WAN sont générés lorsqu'un site envoie du trafic à un autre site en utilisant les tunnels DTLS sur Internet au lieu du Cato Cloud. Le CMA montre les événements suivants pour la récupération du 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 de Cato est rétablie et que le Socket arrête d'envoyer du trafic WAN via le transport de récupération WAN.
Aucun événement n'est généré lorsque la récupération du WAN fonctionne pour un site et aucun trafic n'est envoyé en utilisant les tunnels DTLS.
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, alors 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 impactée et continue de fonctionner normalement pendant la récupération du WAN car le Socket applique la politique.
Remarque
Remarque : Pour des raisons réglementaires, la récupération WAN n'est pas supportée en Chine.
Pendant la récupération WAN, assurez-vous de ne PAS réinitialiser le Socket, sinon, il peut y avoir un impact négatif sur le site et il pourrait ne pas être capable 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 de 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 aléatoirement 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 du site car elle n'est pas connectée au PoP et n'est pas informée du statut des sites impactés.
Vous pouvez vous connecter à l'Interface Web du Socket et utiliser l'onglet SD-WAN pour surveiller le trafic et les tunnels hors-cloud. Ceci est un exemple de surveillance du trafic avec l'interface Web du Socket :
Le trafic qui est passé par le transport hors cloud de récupération WAN n'est pas traité par les PoP dans le Cloud de Cato. 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éseautage
-
Politique NAT
-
Règles de réseau complexes
-
Transfert DNS
-
Relais DHCP
-
Traduction de plage statique (SRT)
-
-
Accès
-
Accès Client (c.-à-d. politique de connectivité des clients)
-
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 de la Cato Cloud, le Alt. Le lien WAN 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 Alt. Lien WAN. Si le Alt. Le lien WAN n'est pas disponible, le Socket déplace alors le trafic WAN vers le lien de Récupération WAN. En général, la Récupération WAN a la priorité la plus basse en tant qu'option de transport et est utilisée uniquement 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 à la Cato Cloud, le PoP informe le Socket sur tous les autres points terminaux, et le Socket ouvre un tunnel DTLS vers chacun d'entre eux. Le Socket utilise la technique de NAT punching pour établir une connexion directe avec les autres Sockets.
Remarque: La négociation du NAT punching commence sur la Cato Cloud. Par conséquent, les Sockets doivent être connectés à la 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 de NAT punching fonctionne pour chaque paire de Sockets de la manière suivante :
-
Le PoP sélectionne l'un des Sockets comme initiateur pour établir une connexion directe (Socket 1) basé sur l'ID du site (le site avec la valeur ID la plus élevée est l'initiateur).
-
Le Socket initiateur envoie une demande à la Cato Cloud pour 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 de 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 demande à la Cato Cloud pour les détails suivants : adresse IP et port
-
Le PoP de 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 que le port correct est trouvé, les Sockets ouvrent un tunnel DTLS avec l'adresse IP source et le numéro de port
Lorsque le Socket 2 se connecte avec le Socket 1, le routeur ajoute l'entrée NAT à sa table de routage
-
À partir de ce moment, les Sockets envoient des messages de keep-alive toutes les 15 secondes pour maintenir la connexion ouverte
Après que le NAT punching réussit, le Socket enregistre ces données NAT. Dans le cas d'un redémarrage du Socket, il peut immédiatement se reconnecter aux autres Sockets avec ces données NAT. Enregistrer les données NAT réduit considérablement le temps de reconnexion du Socket. Pour les Sockets qui sont derrière un pare-feu 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.