L'option Virtual Connect permet d'étendre en toute sécurité leur réseau privé sur Internet à l'aide de tunnels VPN IP point à point.
Introduction
Virtual Connect est une option supplémentaire pour la connectivité Cloud à une instance dédiée pour Webex Calling (instance dédiée). Virtual Connect permet aux clients d'étendre en toute sécurité leur réseau privé sur Internet à l'aide de tunnels VPN IP point à point. Cette option de connectivité permet d'établir rapidement une connexion au réseau privé en utilisant l'équipement sur site du client (CPE) existant et la connectivité Internet.
Cisco héberge, gère et garantit la redondance des tunnels IP VPN et l'accès Internet requis dans la ou les régions du centre de données de l'instance dédiée de Cisco où le service est requis. De même, l'administrateur est responsable de son CPE correspondant et des services Internet qui sont requis pour l'établissement de Virtual Connect.
Chaque commande Virtual Connect dans une région d'instance dédiée particulière inclurait deux tunnels d'encapsulation de routage générique (GRE) protégés par le chiffrement IPSec (GRE sur IPSec), un pour chaque centre de données Cisco dans la région sélectionnée.
Virtual Connect a une limite de bande passante de 250 Mbps par tunnel et est recommandé pour les petits déploiements. Étant donné que deux tunnels VPN point à point sont utilisés, tout le trafic vers le cloud doit passer par le CPE de tête de réseau du client, et par conséquent, il peut ne pas convenir là où il y a beaucoup de sites distants. Pour d’autres options d’appairage alternatives, reportez-vous à Connectivité Cloud .
 |
Avant de soumettre la demande de peering pour Virtual Connect, assurez-vous que le service Instance dédiée est activé dans cette région respective. |
Conditions requises
Les conditions préalables à l'établissement de Virtual Connect incluent :
Le client fournit
Connexion Internet avec une bande passante disponible suffisante pour prendre en charge le déploiement
adresse IP publique pour deux tunnels IPSec
Adresses IP de transport GRE côté client pour les deux tunnels GRE
Partenaire et client
Collaborer pour évaluer les besoins en bande passante
Assurez-vous que les périphériques réseau prennent en charge le routage BGP (Border Gateway Protocol) et une conception de tunnel GRE sur IPSec
Le partenaire ou le client fournit
Équipe réseau connaissant les technologies de tunnel VPN de site à site
Équipe réseau connaissant BGP, eBGP et les principes généraux de routage
Cisco
Cisco a attribué des numéros de système autonome privés (ASN) et adressage IP transitoire pour les interfaces de tunnel GRE
Réseau de classe C (/24) public mais non routable sur Internet attribué par Cisco pour l'adressage Cloud d'instance dédiée
|
Si un client ne possède qu'un seul périphérique CPE, les 2 tunnels vers les centres de données Cisco (DC1 et DC2) dans chaque région proviendront de ce périphérique CPE. Le client a également une option pour 2 périphériques CPE, puis chaque périphérique CPE doit se connecter à 1 tunnel uniquement vers les centres de données Cisco (DC1 et DC2) dans chaque région. Une redondance supplémentaire peut être obtenue en mettant fin à chaque tunnel dans un site/emplacement physique distinct au sein de l'infrastructure du Client. |
Détails techniques
Modèle de déploiement
Virtual Connect utilise une architecture de tête de réseau à deux niveaux, dans laquelle le routage et les plans de contrôle GRE sont fournis par un périphérique et le plan de contrôle IPSec est fourni par un autre.
À la fin de la Connexion virtuelle connectivité, deux tunnels GRE sur IPSec seront créés entre le réseau d'entreprise du client et les centres de données de l'instance dédiée de Cisco. Un pour chaque centre de données redondant dans la région respective. Les éléments de mise en réseau supplémentaires requis pour l'appairage sont échangés par le partenaire ou le client à Cisco via le formulaire d'activation de Control Hub Virtual Connect.
La Figure 1 montre un exemple du modèle de déploiement Virtual Connect pour l'option 2 concentrateurs du côté du client.
Virtual Connect - VPN est une conception de hub, où les sites de hub du client sont connectés aux centres de données DC1 et DC2 des instances dédiées dans une région particulière.
Deux sites Hub sont recommandés pour une meilleure redondance, mais un site Hub avec deux tunnels est également un modèle de déploiement pris en charge .
|
La bande passante par tunnel est limitée à 250 Mbps. |
 |
Les sites distants du Client dans la même région devront se reconnecter au(x) site(s) Hub sur le WAN du Client et Cisco n'est pas responsable de cette connectivité. |
Les partenaires doivent travailler en étroite collaboration avec les clients, en veillant à ce que le chemin le plus optimal soit choisi pour la région de service « Virtual Connect ».
La figure 2 montre les régions d'appairage de la connectivité Cloud de l'instance dédiée.
Routage
Le module complémentaire de routage pour Virtual Connect est mis en œuvre à l’aide de BGP externe (eBGP) entre l’instance dédiée et l’équipement sur site du client (CPE). Cisco annoncera leur réseau respectif pour chaque contrôleur de domaine redondant dans une région au CPE du Client et le CPE doit annoncer une route par défaut vers Cisco.
Cisco gère et attribue
Adressage IP de l'interface du tunnel (lien transitoire pour le routage) attribué par Cisco à partir d'un espace d'adressage partagé désigné (non routable publiquement)
Adresse de destination du transport du tunnel (côté Cisco)
Numéros de système autonome privés (ASN) pour la configuration du routage BGP du client
Cisco attribue à partir de la plage d'utilisation privée désignée : 64512 à 65534
eBGP utilisé pour échanger des routes entre l'instance dédiée et le CPE
Cisco divisera le réseau /24 attribué en 2 /25 un pour chaque contrôleur de domaine dans la région respective
Dans Virtual Connect, chaque réseau /25 est renvoyé à CPE par Cisco via les tunnels VPN point à point respectifs (lien transitoire)
Le CPE doit être configuré avec les voisins eBGP appropriés. Si vous utilisez un seul CPE, deux voisins eBGP seront utilisés, un pointant vers chaque tunnel distant. Si vous utilisez deux CPE, alors chaque CPE aura un voisin eBGP qui pointe vers le tunnel distant unique pour le CPE.
Le côté Cisco de chaque tunnel GRE (IP de l'interface de tunnel) est configuré en tant que voisin BGP sur le CPE
Le CPE est requis pour annoncer une route par défaut sur chacun des tunnels
CPE est chargé de redistribuer, si nécessaire, les routes apprises au sein du réseau d'entreprise du client.
Dans des conditions de non-défaillance de la liaison, un seul CPE aura deux tunnels actifs/actifs. Pour deux nœuds CPE, chaque CPE aura un tunnel actif et les deux nœuds CPE doivent être actifs et transmettre le trafic. Dans le scénario de non-échec, le trafic doit être divisé en deux tunnels allant aux bonnes destinations /25, si l'un des tunnels tombe en panne, le tunnel restant peut acheminer le trafic pour les deux. Dans un tel scénario de panne, lorsque le réseau /25 est en panne, le réseau /24 est utilisé comme route de sauvegarde. Cisco enverra le trafic client via son WAN interne vers le DC qui a perdu la connectivité.
Processus de connectivité
| 1 | |
| 2 | |
| 3 | |
| 4 |
Étape 1 : Commande CCW
Virtual Connect est un module complémentaire pour l'instance dédiée dans CCW.
| 1 | Accédez au site de commande CCW, puis cliquez sur Connexion pour vous connecter au site : |
||
| 2 | Créer une estimation. |
||
| 3 | Ajouter le SKU « A-FLEX-3 ». |
||
| 4 | Sélectionnez Modifier les options. |
||
| 5 | Dans l'onglet d'abonnement qui s'affiche, sélectionnez Options et modules complémentaires. |
||
| 6 | Sous Add-ons supplémentaires, cochez la case à côté de « Virtual Connect for Dedicated Instance ». Le nom SKU est « A-FLEX-DI-VC ». |
||
| 7 | Saisissez la quantité et le nombre de régions dans lesquelles Virtual Connect est requis.
|
||
| 8 | Lorsque vous êtes satisfait de vos sélections, cliquez sur Vérifier et enregistrer dans la partie supérieure droite de la page. |
||
| 9 | Cliquez sur Enregistrer et continuer pour finaliser votre commande. Votre commande finalisée apparaît maintenant dans la grille de commande. |
Étape 2 : Activation de Virtual Connect dans Control Hub
| 1 | Se connecter à Control Hubhttps://admin.webex.com/login . |
||||||||
| 2 | Dans le Services section, accédez à Appel > Instance dédiée > Connectivité Cloud . |
||||||||
| 3 | Dans la carte Virtual Connect, la quantité de Virtual Connect achetée est répertoriée. L'administrateur peut maintenant cliquer sur Activer pour lancer l’activation de Virtual Connect. 
|
||||||||
| 4 | En cliquant sur le Activer bouton, Activer la connexion virtuelle Le formulaire s’affiche pour que l’administrateur fournisse les détails techniques de Virtual Connect requis pour les configurations d’appairage du côté de Cisco.
|
||||||||
| 5 | Cliquez sur le Activer une fois tous les champs obligatoires remplis. |
||||||||
| 6 | Une fois le formulaire d'activation Virtual Connect rempli pour une région particulière, le client peut exporter le formulaire d'activation à partir de Control Hub, Appeler > Instance dédiée > onglet Connectivité Cloud et cliquer sur Exporter les paramètres. 
|
Étape 3 : Cisco effectue la configuration du réseau
| 1 | Une fois le formulaire d'activation de Virtual Connect rempli, le statut sera mis à jour pour Activation en cours dans Appel > Instance dédiée > Carte de connectivité virtuelle Cloud Connectivity. |
| 2 | Cisco effectuera les configurations requises sur l'équipement côté Cisco dans les 5 jours ouvrables . En cas de réussite, le statut sera mis à jour sur « Activé » pour cette région particulière dans Control Hub. |
Étape 4 : Le client effectue la configuration du réseau
Le statut est changé en « Activé » pour informer l'administrateur du Client que le côté Cisco des configurations pour la connectivité IP VPN a été terminé sur la base des entrées fournies par le Client. Cependant, l'administrateur du client doit effectuer son côté des configurations sur les CPE et tester les routes de connectivité pour que le tunnel Virtual Connect soit en ligne. En cas de problèmes rencontrés au moment de la configuration ou de la connectivité, le client peut contacter le service d'assistance technique de Cisco TAC pour obtenir de l'aide. |
Dépannage
Dépannage et validation de la première phase IPsec (négociation IKEv2)
La négociation du tunnel IPsec implique deux phases, la phase IKEv2 et la phase IPsec. Si la négociation de la phase IKEv2 ne se termine pas, il n'y a pas de lancement d'une deuxième phase IPsec. Tout d'abord, exécutez la commande « show crypto ikev2 sa » (sur l'équipement Cisco) ou une commande similaire sur l'équipement tiers pour vérifier si la session IKEv2 est active. Si la session IKEv2 n'est pas active, les raisons potentielles peuvent être :
Le trafic intéressant ne déclenche pas le tunnel IPsec.
La liste d'accès au tunnel IPsec est mal configurée.
Il n'y a pas de connectivité entre le client et l'adresse IP du point de terminaison du tunnel IPsec de l'instance dédiée.
Les paramètres de session IKEv2 ne correspondent pas entre le côté instance dédiée et le côté client.
Un pare-feu bloque les paquets UDP IKEv2.
Tout d'abord, vérifiez les journaux IPsec pour tous les messages qui montrent la progression de la négociation du tunnel IKEv2. Les journaux peuvent indiquer où il y a un problème avec la négociation IKEv2. L'absence de messages de journalisation peut également indiquer que la session IKEv2 n'est pas activée.
Les paramètres pour l'IKEv2 du côté CPE ne correspondent pas au côté Cisco, revérifiez les paramètres mentionnés :
Vérifiez que la version IKE est la version 2.
Vérifiez que les paramètres de chiffrement et d'authentification correspondent au chiffrement attendu du côté de l'instance dédiée.
Lorsque le chiffrement « GCM » est utilisé, le protocole GCM gère l'authentification et définit le paramètre d'authentification sur NULL.
Vérifiez le paramètre de durée de vie.
Vérifiez le groupe de modules Diffie Hellman.
Vérifiez les paramètres de la fonction pseudo-aléatoire.
La liste d'accès pour la carte de chiffrement n'est pas définie sur :
Autoriser GRE (local_tunnel_transport_ip ) 255.255.255.255 (remote_tunnel_transport_ip ) 255.255.255.255" (ou commande équivalente)
La liste d'accès doit être spécifiquement pour le protocole « GRE » et le protocole « IP » ne fonctionnera pas.
Si les messages du journal n'affichent aucune activité de négociation pour la phase IKEv2, une capture de paquet peut être nécessaire.
|
Le côté instance dédiée peut ne pas toujours commencer l’échange IKEv2 et peut parfois s’attendre à ce que le côté CPE du client soit l’initiateur. Vérifiez la configuration côté CPE pour les conditions préalables suivantes pour l'ouverture de session IKEv2 :
|
Lorsqu'ils sont correctement configurés, les éléments suivants démarrent le tunnel IPsec et la première phase de négociation IKEv2 :
Keepalives GRE de l'interface du tunnel GRE côté CPE à l'interface du tunnel GRE côté instance dédiée.
Session TCP du voisin BGP du voisin BGP côté CPE au voisin BGP côté instance dédiée.
Envoyez une requête ping de l' adresse IP du tunnel côté instance dédiée.
Le ping ne peut pas être l'IP de transport de tunnel à l'IP de transport de tunnel, il doit être l'IP de tunnel à l'IP de tunnel.
Si un suivi des paquets est nécessaire pour le trafic IKEv2, définissez le filtre pour UDP et soit le port 500 (lorsqu'aucun périphérique NAT ne se trouve au milieu des points de terminaison IPsec) ou le port 4500 (lorsqu'un périphérique NAT est inséré au milieu des points de terminaison IPsec). points de terminaison).
Vérifiez que les paquets UDP IKEv2 avec le port 500 ou 4500 sont envoyés et reçus vers et depuis l' adresse IP IPsec DI.
|
Le centre de données de l'instance dédiée peut ne pas toujours commencer le premier paquet IKEv2. L'exigence est que le périphérique CPE soit capable d'initier le premier paquet IKEv2 vers le côté de l'instance dédiée. Si le pare-feu local le permet, essayez également un ping vers l'adresse IPsec distante. Si le ping échoue de l'adresse IPsec locale vers l'adresse IPsec distante, effectuez une trace de route pour vous aider et déterminer où le paquet est abandonné. Certains pare-feux et équipements Internet peuvent ne pas autoriser la trace. |
Dépannage et validation de la deuxième phase IPsec (négociation IPsec)
Vérifiez que la première phase IPsec (c'est-à-dire l'association de sécurité IKEv2) est active avant de dépanner la deuxième phase IPsec. Exécutez une commande « show crypto ikev2 sa » ou une commande équivalente pour vérifier la session IKEv2. Dans la sortie, vérifiez que la session IKEv2 est active depuis plus de quelques secondes et qu'elle ne rebondit pas. La durée de fonctionnement de la session s'affiche sous la forme « Durée d'activité » de la session ou l'équivalent dans la sortie.
Une fois que la session IKEv2 a été vérifiée comme étant active et active, examinez la session IPsec. Comme pour la session IKEv2, exécutez une commande « show crypto ipsec sa » ou une commande équivalente pour vérifier la session IPsec. La session IKEv2 et la session IPsec doivent être actives avant que le tunnel GRE ne soit établi. Si la session IPsec ne s'affiche pas comme active, vérifiez les journaux IPsec pour les messages d'erreur ou les erreurs de négociation.
Certains des problèmes les plus courants qui peuvent être rencontrés au cours des négociations IPsec sont :
Les paramètres du côté CPE ne correspondent pas au côté de l'instance dédiée, revérifiez les paramètres :
Vérifiez que les paramètres de chiffrement et d'authentification correspondent aux paramètres du côté de l'instance dédiée.
Vérifiez les paramètres Perfect Forward Secrecy et que les paramètres correspondent du côté de l’instance dédiée.
Vérifiez les paramètres de durée de vie.
Vérifiez que IPsec a été configuré en mode tunnel.
Vérifiez les adresses IPsec source et de destination.
Dépannage et validation de l'interface de tunnel
Lorsque les sessions IPsec et IKEv2 sont vérifiées comme étant actives et actives, les paquets keepalive du tunnel GRE peuvent circuler entre l'instance dédiée et les points de terminaison du tunnel CPE. Si l'interface du tunnel n'affiche pas l'état, certains problèmes courants sont :
Le VRF de transport de l'interface de tunnel ne correspond pas au VRF de l'interface de bouclage (si la configuration VRF est utilisée sur l'interface de tunnel).
Si la configuration VRF n'est pas utilisée sur l'interface du tunnel, cette vérification peut être ignorée.
Les keepalives ne sont pas activés sur l'interface du tunnel côté CPE
Si les keepalives ne sont pas pris en charge sur l'équipement CPE, Cisco doit être notifié afin que les keepalives par défaut du côté de l'instance dédiée soient également désactivés.
Si les keepalives sont pris en charge, vérifiez que les keepalives sont activés.
Le masque ou adresse IP de l'interface du tunnel n'est pas correct et ne correspond pas aux valeurs attendues de l'instance dédiée.
L'adresse de transport du tunnel source ou de destination n'est pas correcte et ne correspond pas aux valeurs attendues de l'instance dédiée.
Un pare-feu bloque les paquets GRE envoyés dans le tunnel IPsec ou reçus du tunnel IPsec (le tunnel GRE est transporté sur le tunnel IPsec)
Un test ping doit vérifier que l'interface du tunnel local est active et que la connectivité est bonne avec l'interface du tunnel distant. Effectuez la vérification ping à partir de l'IP du tunnel (pas l'IP de transport) vers l'IP du tunnel distant.
|
La liste d'accès de chiffrement pour le tunnel IPsec qui achemine le trafic du tunnel GRE autorise uniquement le passage des paquets GRE. Par conséquent, les requêtes ping ne fonctionneront pas à partir de l'IP de transport du tunnel vers l'IP de transport du tunnel distant. |
La vérification ping génère un paquet GRE qui est généré à partir de l'IP de transport du tunnel source vers l'IP de transport du tunnel de destination, tandis que la charge utile du paquet GRE (l'IP interne) sera l'IP du tunnel source et de destination.
Si le test ping échoue et que les éléments précédents sont vérifiés, une capture de paquet peut être nécessaire pour s'assurer que le ping icmp génère un paquet GRE qui est ensuite encapsulé dans un paquet IPsec puis envoyé à partir de l'adresse IPsec source vers l'adresse IPsec de destination. Les compteurs sur l'interface du tunnel GRE et les compteurs de session IPsec peuvent également aider à afficher. si les paquets d'envoi et de réception sont incrémentés.
En plus du trafic ping, la capture doit également afficher les paquets GRE persistants, même pendant le trafic inactif. Enfin, si BGP est configuré, les paquets keepalive BGP doivent également être envoyés en tant que paquets GRE encapsulés dans des paquets IPSEC également sur le VPN.
Dépannage et validation BGP
Sessions BGP
BGP est requis comme protocole de routage sur le tunnel VPN IPsec. Le voisin BGP local doit établir une session eBGP avec le voisin BGP de l'instance dédiée. Les adresses IP des voisins eBGP sont les mêmes que les adresses IP des tunnels locaux et distants. Assurez-vous d'abord que la session BGP est active, puis vérifiez que les routes correctes sont reçues de l'instance dédiée et que la route par défaut correcte est envoyée à l'instance dédiée.
Si le tunnel GRE est actif, vérifiez qu'un ping réussit entre l'IP du tunnel GRE local et distant. Si la commande ping réussit mais que la session BGP ne démarre pas, recherchez les erreurs d'établissement BGP dans le journal BGP.
Certains des problèmes de négociation BGP les plus courants sont :
Le numéro de l'AS distant ne correspond pas au numéro de l'AS qui est configuré du côté de l'instance dédiée, vérifiez à nouveau la configuration de l'AS voisin.
Le numéro de l'AS local ne correspond pas à ce que le côté de l'instance dédiée attend, vérifiez que le numéro de l'AS local correspond aux paramètres attendus de l'instance dédiée.
Un pare-feu empêche les paquets TCP BGP encapsulés dans des paquets GRE d'être envoyés dans le tunnel IPsec ou d'être reçus du tunnel IPSEC
L'adresse IP du voisin BGP distant ne correspond pas à l'adresse IP du tunnel GRE distant.
Échange de route BGP
Une fois la session BGP vérifiée pour les deux tunnels, assurez-vous que les routes correctes sont envoyées et reçues du côté de l'instance dédiée.
La solution VPN d'instance dédiée s'attend à ce que deux tunnels soient établis du côté client/partenaire. Le premier tunnel pointe vers le centre de données de l'instance dédiée A et le second tunnel pointe vers le centre de données de l'instance dédiée B. Les deux tunnels doivent être à l'état actif et la solution nécessite un déploiement actif/actif. Chaque centre de données d'instance dédiée annoncera sa route locale /25 ainsi qu'une route de sauvegarde /24. Lors de la vérification des routes BGP entrantes à partir de l'instance dédiée, assurez-vous que la session BGP associée au tunnel pointant vers le centre de données de l'instance dédiée A reçoit la route locale /25 du centre de données de l'instance dédiée A ainsi que la route de sauvegarde /24. En outre, assurez-vous que le tunnel pointant vers le centre de données de l'instance dédiée B reçoit la route locale du centre de données de l'instance dédiée B /25 ainsi que la route de sauvegarde /24. Notez que la route de sauvegarde /24 sera la même route publiée à partir du centre de données de l'instance dédiée A et du centre de données de l'instance dédiée B.
La redondance est fournie à un centre de données d'instance dédiée si l'interface du tunnel vers ce centre de données tombe en panne. Si la connectivité au centre de données de l'instance dédiée A est perdue, le trafic sera transféré du centre de données de l'instance dédiée B au centre de données A. Dans ce scénario, le tunnel vers le centre de données B utilisera la route du centre de données B /25 pour envoyer le trafic vers le centre de données B et le tunnel vers le centre de données B utilisera la route de sauvegarde /24 pour envoyer le trafic vers le centre de données A via le centre de données B.
Il est important que, lorsque les deux tunnels sont actifs, le tunnel du centre de données A ne soit pas utilisé pour envoyer le trafic au centre de données B et vice versa. Dans ce scénario, si le trafic est envoyé au centre de données A avec une destination de centre de données B, le centre de données A transférera le trafic vers le centre de données B, puis le centre de données B tentera de renvoyer le trafic vers la source via le tunnel du centre de données B. Cela entraînera un routage sous-optimal et peut également interrompre le trafic traversant les pare-feu. Par conséquent, il est important que les deux tunnels soient dans une configuration active/active pendant le fonctionnement normal.
La route 0.0.0.0/0 doit être publiée du côté client vers le centre de données de l'instance dédiée. Les routes plus spécifiques ne seront pas acceptées par l'instance dédiée. Assurez-vous que la route 0.0.0.0/0 est publiée à la fois à partir du tunnel du centre de données de l'instance dédiée A et du tunnel du centre de données de l'instance dédiée B.
Configuration MTU
Du côté de l'instance dédiée, deux fonctionnalités sont activées pour ajuster dynamiquement la MTU pour les paquets de grande taille. Le tunnel GRE ajoute plus d'en-têtes aux paquets IP circulant à travers la session VPN. Le tunnel IPsec ajoute les en-têtes supplémentaires au-dessus des en-têtes GRE, ce qui réduira davantage la plus grande MTU autorisée sur le tunnel.
Le tunnel GRE ajuste la fonctionnalité MSS et le chemin du tunnel GRE dans la fonctionnalité de découverte MTU est activé du côté de l'instance dédiée. Configurez « ip tcp Adjust-mss 1350 » ou une commande équivalente ainsi que « tunnel path\u0002mtu-discovery » ou une commande équivalente du côté client pour faciliter l’ajustement dynamique de la MTU du trafic via le tunnel VPN.
