A propos des passerelles VPN site à site
Vous pouvez utiliser le service IBM Cloud VPN for VPC pour connecter en toute sécurité votre VPC (Virtual Private Cloud) à un autre réseau privé. Utilisez un VPN basé sur les routes ou un VPN basé sur des règles pour configurer un tunnel IPsec de site à site entre votre VPC et votre réseau privé sur site ou un autre VPC.
Fonctions VPN for VPC
Le service d' VPN for VPC de site à site d' IBM Cloud, comprend les fonctionnalités suivantes :
-
Authentification - IBM Cloud VPN for VPC prend en charge une clé pré-partagée pour l'authentification d'homologue de phase 1. Les algorithmes d'authentification pris en charge pour les deux phases sont
SHA-256,SHA-384, etSHA-512. -
Haute disponibilité - IBM Cloud VPN for VPC est construit sur deux périphériques VPN pour fournir une redondance à l'échelle du dispositif. Un VPN basé sur des règles fonctionne en mode actif-veille avec une seule adresse IP de passerelle VPN partagée entre les membres, tandis qu'un VPN basé sur les routes propose à la fois les modes de redondance actif-secours et actif-actif avec deux adresses IP de passerelle VPN.
En mode Active-Backup pour un VPN basé sur les routes, deux tunnels sont établis entre la passerelle IBM et la passerelle VPN homologue. Cependant, la passerelle IBM utilise toujours le tunnel avec l'IP publique la plus petite comme chemin de sortie principal. L'autre tunnel, avec l'IP la plus élevée, sert de chemin de sortie secondaire. Tant que les deux tunnels sont actifs, le trafic entre le VPC IBM et le réseau sur site passe par le chemin de sortie principal. En cas de défaillance du chemin de sortie primaire, le trafic bascule automatiquement sur le chemin de sortie secondaire. Cette configuration est utilisée lorsque la fonction "Distribuer le trafic" n'est pas activée. La passerelle VPN sur site doit également utiliser la même configuration pour choisir le même chemin préféré. En savoir plus
-
Détection de pair inactif- Mécanisme configurable permettant de détecter la disponibilité d'un pair IPsec.
-
Diffie-Hellman (DH) - Protocole d'échange de clé utilisé dans la phase 1 pour générer une clé secrète partagée entre les homologues VPN. Le cas échéant, les utilisateurs peuvent activer PFS (Perfect Forward Secrecy) et un groupe DH pour la négociation IPsec de phase 2. IBM Cloud VPN pour VPC prend en charge les groupes DH
14-24et31. -
Chiffrement- Le protocole IBM Cloud VPN pour VPC prend en charge
AES-128,AES-192, et pourAES-256le chiffrement des données pendant les phases 1 et 2 du protocole IKE. -
Internet Key Exchange (IKE) - IKE fait partie du protocole IPsec utilisé pour établir des connexions VPN. Dans la phase 1 d'IKE, les homologues VPN utilisent un échange de clé DH (Diffie-Hellman) pour créer un canal de communication authentifié sécurisé. Dans la phase 2 d'IKE, les homologues utilisent le canal sécurisé de la phase 1 pour négocier les paramètres des tunnels IPsec. IBM Cloud VPN for VPC prend en charge IKEv1 (mode principal) et IKEv2. Pour connaître les combinaisons prises en charge, voir A propos de la négociation de stratégie.
-
IPsec - Ensemble de protocoles qui fournit une communication sécurisée entre des unités. IBM Cloud VPN Pour les utilisations VPC, le protocole ESP ( UDP ) encapsule les paquets IPsec en mode tunnel, ce qui assure l'authentification et le chiffrement complet des paquets.
-
Modes de passerelle VPN- IBM Cloud VPN for VPC offre des modes de passerelle VPN basés sur des règles et des routes.
- VPN basé sur une politique - Avec un VPN basé sur une politique, le trafic qui correspond aux plages CIDR négociées en fonction des politiques de sécurité définies passe par le VPN.
- VPN basé sur les routes- Dans le cas d'un VPN basé sur les routes, des interfaces de tunnel virtuelles sont créées à partir des entrées de la table de routage, et tout trafic acheminé vers ces interfaces logiques via des
routes personnalisées transite par le VPN. Les deux options de VPN offrent les mêmes fonctions. Les VPN basés sur les routes prennent également en charge les connexions VPN statiques et dynamiques.
- Connexion VPN statique- Dans le cas d'une connexion basée sur une route statique, les utilisateurs doivent définir et configurer manuellement les routes dans la table de routage. Pour commencer, sélectionnez le mode Statique lors de la création d'une passerelle VPN, puis créez des routes à l'aide du type de connexion VPN.
- Connexion VPN dynamique- Dans la connexion dynamique basée sur les routes, les routes sont automatiquement découvertes et gérées entre les réseaux à l'aide de BGP, contrairement au routage statique qui nécessite une configuration manuelle. La configuration dynamique permet d'améliorer l'évolutivité, la gestion du réseau et la haute disponibilité. Pour commencer, sélectionnez dynamique comme type de connexion lorsque vous créez une passerelle VPN. N'oubliez pas que vous devez utiliser cette connexion avec une passerelle de transit. Voir les considérations de planification pour le VPN dynamique basé sur les routes.
-
Perfect Forward Secrecy (PFS) - PFS garantit que les clés générées par DH ne sont pas réutilisées durant la renégociation IPsec. Si une clé est compromise, seules seront accessibles les données en transit pendant la durée de vie de l'association de sécurité protégée.
Initiation aux passerelles VPN
Avant de créer un VPN, vous devez d'abord créer un VPC et un ou plusieurs sous-réseaux pour votre VPN et d'autres ressources.
Bien que cela ne soit pas obligatoire, il est recommandé de réserver un sous-réseau d’au moins 16 adresses IP (préfixe /28 ou inférieur) pour votre passerelle VPN. Si vous décidez de mettre à disposition des ressources supplémentaires
dans le sous-réseau VPN, assurez-vous qu'il existe toujours au moins 4 IP disponibles pour les tâches de reprise et de maintenance à utiliser par la passerelle VPN. En plus des 4 adresses IP requises par la passerelle VPN, jusqu'à 5 adresses
IP d'un sous-réseau sont réservées à l'usage interne du réseau, par conséquent, veillez à ce que la taille du sous-réseau soit suffisamment grande.
Pour créer une passerelle VPN, procédez comme suit :
-
Assurez-vous que les listes de contrôle d'accès au réseau sont configurées pour permettre au trafic VPN de circuler entre votre réseau sur site et la passerelle IBM Cloud VPN.
-
Assurez-vous que votre unité homologue prend en charge la conversion NAT-Traversal et que cette fonction est activée sur l'unité homologue. Pour plus d'informations, voir Problèmes connus pour les passerelles VPN.
-
Passez en revue les considérations de planification et créez votre passerelle VPN.
-
Créez des connexions VPN pour établir une connexion entre votre passerelle VPN et votre réseau sur site.
IBM Cloud VPN for VPC ne prend en charge qu'un seul VPN basé sur des routes par zone et par VPC.
-
Pour une connexion VPN basée sur des routes statiques, sélectionnez ou créez une table de routage pour le routage statique, puis créez des routes en utilisant le type de connexion VPN.
-
Pour établir une connexion VPN dynamique basée sur des routes, créez une passerelle de transit et associez-la à la passerelle VPN. Si vous disposez d'une passerelle de transit existante, vous pouvez également l'attacher à la passerelle VPN. Voir la section « Ajouter une connexion ». Pour plus d'informations sur la création d'une connexion dynamique basée sur des routes avec une passerelle de transit, consultez les cas d'utilisation suivants :
- Connexion VPN dynamique à zone unique basée sur un itinéraire, avec Transit Gateway.
- Connexion VPN inter-zones dynamique basée sur des routes, avec Transit Gateway
- Connexion VPN servant de solution de secours à la connexion directe.
- VPN dynamique à haute disponibilité basé sur des routes, avec affinité par zone.
-
Vérifiez que votre connexion VPN est opérationnelle en envoyant une commande ping ou un trafic de données via le tunnel vers des appareils situés sur le réseau homologue.
Architecture
Ce diagramme illustre un exemple de configuration VPN avec plusieurs réseaux sur site. Le VPN est configuré sur un sous-réseau dans le VPC d'un utilisateur, mais peut être partagé par des instances sur tous les sous-réseaux de la zone. Les politiques IKE et IPsec peuvent également être utilisées par une ou plusieurs connexions VPN.
A propos de la négociation de stratégie
Pour les deux phases de négociation IKE, les homologues IPsec doivent échanger des propositions relatives aux paramètres de sécurité dont la prise en charge est configurée sur chacun d'eux, et parvenir à un accord sur un ensemble de configurations. Les stratégies IKE et IPsec personnalisées permettent aux utilisateurs d'IBM Cloud VPN for VPC de configurer ces paramètres de sécurité utilisés lors de cette négociation.
L'utilisation des stratégies IKE et IPsec pour configurer une connexion VPN est facultative. Lorsque aucune politique n'est pas sélectionnée, les propositions par défaut sont sélectionnées automatiquement via un processus appelé Négociation automatique.
Les principaux paramètres de sécurité impliqués dans ce processus de négociation sont les suivants :
- Phase IKE
- Algorithme de chiffrement
- Algorithme d'authentification
- Groupe Diffie-Hellman (protocole d'échange de clé de chiffrement)
Puisque que la négociation automatique IBM Cloud utilise IKEv2, l'unité sur site doit également utiliser IKEv2. Utilisez une stratégie IKE personnalisée si votre unité sur site ne prend pas en charge IKEv2.
Négociation automatique IKE (Phase 1)
Vous pouvez combiner comme vous le souhaitez les options de chiffrement, d'authentification et de groupe Diffie-Hellman suivantes :
| Chiffrement | Authentification | Groupe DH | |
|---|---|---|---|
| 1 | aes128 | sha256 | 14-24, 31 |
| 2 | aes192 | sha384 | 14-24, 31 |
| 3 | aes256 | sha512 | 14-24, 31 |
Négociation automatique IPsec (Phase 2)
Vous pouvez utiliser les options de chiffrement et d'authentification suivantes dans n'importe quelle combinaison, ou utiliser les options de chiffrement en mode combiné suivantes qui requièrent la désactivation de l'authentification.
Par défaut, PFS est désactivé pour IBM Cloud VPN for VPC. Certains fournisseurs ont besoin de l'activation PFS pour la phase 2. Vérifiez les instructions de votre fournisseur et utilisez des règles personnalisées si PFS est requis.
| Chiffrement | Authentification | Groupe DH | |
|---|---|---|---|
| 1 | aes128 | sha256 | Désactivé |
| 2 | aes192 | sha384 | Désactivé |
| 3 | aes256 | sha512 | Désactivé |
| Chiffrement | Authentification | Groupe DH | |
|---|---|---|---|
| 1 | aes128gcm16 | Désactivé | Désactivé |
| 2 | aes192gcm16 | Désactivé | Désactivé |
| 3 | aes256gcm16 | Désactivé | Désactivé |
Cas d'utilisation VPN for VPC
Cas d'utilisation n° 1 : connexion VPN à un seul périphérique distant de même type, associé à un ou plusieurs réseaux homologues
Les VPN basés sur des routes et basés sur des stratégies permettent aux utilisateurs de se connecter à une unité homologue distante unique associée à un ou plusieurs réseaux homologues.
Ce cas d'utilisation ne s'applique pas aux connexions entre un VPN basé sur des règles et un VPN basé sur des routes. Pour plus d'informations, voir Problèmes connus pour les passerelles VPN.
Cas d'utilisation 2 : Connexions VPN à plusieurs unités homologues distantes
Les VPN basés sur des politiques et ceux basés sur des routes permettent aux utilisateurs de se connecter à plusieurs périphériques distants associés à différents VPC ou environnements à l'aide de plusieurs connexions VPN.
Cas d'utilisation 3 : configuration avancée du VPN à l'aide d'un nom de domaine complet
Le cas d'utilisation suivant illustre un client qui possède un VPC dans IBM Cloud et qui souhaite connecter son site sur site avec une passerelle VPN unique. La passerelle VPN du site sur place se trouve derrière un dispositif NAT et n'a pas d'adresse IP publique. Dans ce cas, vous pouvez associer un FQDN (fully qualified domain name) à l'adresse IP NATée. Vous pouvez ensuite utiliser ce FQDN au lieu d'une adresse IP lorsque vous créez une connexion VPN. L'identité IKE locale de la passerelle VPN sur site est l'adresse IP privée qu'elle possède. Un nom de domaine complet est associé à l'adresse IP publique du périphérique NAT.
Cas d'utilisation 4 : distribution du trafic pour un VPN basé sur les routes
Un VPN basé sur les routes est fourni avec deux adresses IP publiques. Vous pouvez choisir de vous connecter à une ou aux deux IP pour la redondance. Si vous souhaitez vous connecter à une IP publique, vous pouvez choisir l'une ou l'autre. Cependant, si vous souhaitez vous connecter aux deux IP publiques, vous avez les options suivantes :
Mode de sauvegarde active pour une connexion VPN basée sur les routes
Dans ce mode, un seul tunnel est utilisé à tout moment pour acheminer le trafic VPN sur le tunnel.
Le VPN utilise toujours le tunnel avec l'IP publique la plus petite comme chemin de sortie primaire. Lorsque le chemin de sortie primaire est désactivé, le trafic passe par le chemin secondaire. L'utilisation d'un seul tunnel pour acheminer le trafic permet d'éviter le problème du routage asymétrique.
Par exemple, lorsque tunnel 1 et tunnel 2 sont en place dans une connexion VPN basée sur une route statique, et que vous créez une route avec la destination 10.1.0.0/24 et la connexion VPN comme prochain
saut, l'IP privée 10.254.0.2 de l'appareil VPN est renvoyée pour la création de la route. Dans ce mode, la distribution du trafic n'est pas activée. Le diagramme suivant illustre la configuration par défaut
d'une connexion basée sur une route statique.
Le filtrage de l'état du protocole sur une interface réseau virtuelle offre des options pour résoudre le problème du routage asymétrique. Pour plus d'informations, voir Mode de filtrage de l'état du protocole.
Le comportement du mode de sauvegarde active pour une connexion VPN dynamique basée sur les routes est similaire à celui d'une connexion statique. Cependant, il n'est pas nécessaire de créer des itinéraires car ils sont automatiquement découverts
par la passerelle de transit. Dans ce cas, un seul tunnel est utilisé pour acheminer le trafic VPN sur le tunnel à tout moment. Le VPN utilise toujours le tunnel avec l'IP publique la plus petite comme chemin de sortie primaire. Lorsque
le chemin de sortie primaire est désactivé, le trafic passe par le chemin secondaire. Le sous-réseau dans lequel l'instance de serveur virtuel est placée 10.255.0.0/24 doit être différent du sous-réseau de la passerelle VPN
10.254.0.0/24 pour que la passerelle de transit puisse acheminer le trafic entre les deux. Le diagramme suivant illustre la configuration par défaut d'une connexion dynamique basée sur les routes.
Mode actif pour les connexions VPN basées sur les routes
Dans ce mode, le trafic sortant est acheminé vers les deux tunnels de manière dynamique.
Par exemple, lorsque tunnel 1 et tunnel 2 sont tous deux en service et que vous créez une route avec la destination 10.1.0.0/24 et la connexion VPN comme prochain saut, les adresses IP privées 10.254.0.2 et 10.254.0.3 sont renvoyées et le service de réseau VPC crée 2 routes. Comme ces routes ont la même priorité, le trafic se dirige vers tunnel 1 et tunnel 2 de manière dynamique lorsque le prochain
saut d'une route VPC est la connexion VPN. Pour réaliser ce mode de redondance actif-actif, vous devez activer la case Distribuer le trafic lors de la création ou de l'ajout de connexions à une passerelle VPN. Le diagramme suivant illustre cette configuration pour une connexion basée sur une route statique.
Pour utiliser cette fonctionnalité et améliorer les performances du réseau, l'appareil sur site doit prendre en charge le routage asymétrique. N'oubliez pas non plus que toutes les passerelles VPN sur site ne prennent pas en charge ce cas d'utilisation. Par exemple, si les sorties et les entrées du trafic VPN proviennent de tunnels différents, le trafic peut être bloqué par des dispositifs VPN sur site ou des pare-feu.
Le comportement du mode actif-actif pour une connexion VPN basée sur des routes dynamiques est similaire à celui d'une connexion basée sur des routes statiques. Lorsque vous activez la case à cocher Distribuer le trafic lors de l'ajout de connexions à une passerelle VPN, le trafic circule simultanément dans les deux tunnels. La passerelle de transit se charge de la découverte, de l'apprentissage et de la gestion des itinéraires. Le diagramme suivant illustre la configuration par défaut d'une connexion dynamique basée sur les routes.
Cas d'utilisation 5 : connexion VPN dynamique basée sur des routes à zone unique avec Transit Gateway
Avec le VPN basé sur les routes dynamiques, vous pouvez établir une connexion VPN à zone unique entre votre VPC et votre réseau privé sur site en utilisant Transit Gateway. Cette configuration permet la découverte automatique de routes, le flux de trafic bidirectionnel et l'échange dynamique de routes entre les appareils, ce qui simplifie la gestion du réseau et réduit la configuration manuelle.
Cas d'utilisation 6 : Connexion VPN dynamique basée sur les itinéraires entre zones avec Transit Gateway
Pour obtenir une haute disponibilité régionale complète pour la connectivité VPN, vous pouvez provisionner une passerelle VPN dans chaque zone de disponibilité et établir des connexions VPN séparées de la passerelle de transit à chaque passerelle VPN. Cette configuration permet d'assurer la redondance entre les zones, ce qui permet un flux continu de paquets et un échange dynamique d'itinéraires même si une zone subit une défaillance.
Cas d'utilisation 7 : Connexion VPN en remplacement d'une liaison directe
Vous pouvez attacher des connexions directes et des connexions VPN à une passerelle de transit pour permettre une haute disponibilité et un routage flexible. Lorsque vous ajoutez des routes à la passerelle VPN, le trafic préfère le chemin direct au chemin VPN dans des conditions normales. En cas de défaillance de la connexion directe, le trafic bascule automatiquement sur la connexion VPN, ce qui permet de maintenir une connectivité ininterrompue entre les réseaux. Vous devez configurer les préférences de routage BGP de votre côté afin que le lien direct soit prioritaire par rapport au VPN. Vous pouvez configurer cette préférence de routage en définissant un chemin AS plus court pour la liaison directe et un chemin AS plus long pour le VPN, de sorte que la liaison directe soit privilégiée.
Cas d'utilisation 8 : VPN dynamique à haute disponibilité basé sur les routes avec affinité zonale
Vous pouvez obtenir une haute disponibilité pour une configuration VPN dynamique basée sur les routes en déployant des passerelles IBM Cloud VPN dans plusieurs zones. Cette configuration introduit une affinité zonale, ce qui signifie que lorsqu'un site Power Virtual Server, un site Transit Gateway et une connexion VPN sont tous situés dans la même zone, le trafic est acheminé de manière préférentielle via cette zone. Le trafic est transféré vers une autre zone uniquement si la passerelle VPN de la zone actuelle devient indisponible.
Le trafic VPN est sécurisé par l'utilisation d'IPsec, et la découverte automatique des routes est activée avec BGP. Votre réseau sur site peut se connecter à Power Virtual Servers via la passerelle de transit. Comme illustré dans le diagramme, deux tunnels VPN sont établis lorsque vous créez une connexion VPN dynamique basée sur les routes. Si vous activez l'option Distribuer le trafic, le trafic circule dynamiquement dans les deux tunnels, ce qui permet d'augmenter le débit.
Pour mettre en place cette configuration, procédez comme suit :
- Fournir une passerelle VPN dans la zone 1 et la zone 3. Voir Création d'une passerelle VPN.
- Ajoutez une connexion VPN à la passerelle provisionnée pour vous connecter à votre réseau sur site. Voir Ajout de connexions à une passerelle VPN.
- Établir une connexion entre IBM Cloud VPN et Transit Gateway. Voir Création d'une passerelle de transit.