Fonctions VPN for VPC

Le service IBM Cloud VPN for VPC comprend les fonctions suivantes :

MD-5 et SHA-1, les groupes DH 2 et 5 et l'algorithme de cryptage 3-DES ont été supprimés le 20 septembre 2022 et ne sont plus pris en charge dans la console.

• 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 et SHA-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 stratégies fonctionne en mode actif-de secours avec une adresse IP de passerelle VPN unique partagée entre les membres, tandis qu'un VPN basé sur des routes fournit une redondance active-active avec deux adresses IP de passerelle VPN.

  Un VPN statique basé sur des routes est déployé en mode de redondance Actif-Actif. Deux tunnels VPN sont connectés à la passerelle VPN homologue ; cependant, la passerelle IBM utilise toujours le tunnel avec la petite adresse IP publique comme chemin de sortie principal. Le tunnel avec la grande adresse IP publique est le chemin de sortie secondaire. Le trafic d'IBM VPC vers le réseau sur site passe par le chemin de sortie principal si les deux tunnels sont actifs. Le trafic passe par le chemin de sortie secondaire si le chemin de sortie principal est désactivé. La passerelle VPN sur site doit utiliser la priorité de routage pour choisir le même chemin préféré. En savoir plus

• Dead Peer Detection (DPD) - Mécanisme configurable pour détecter la disponibilité d'un homologue 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 for VPC prend en charge les groupes DH 14-24 et 31.

• Encryption- IBM Cloud VPN for VPC supporte AES-128, AES-192, et AES-256 pour l'encryptage des données durant les phases IKE 1 et 2.

• 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 VPC utilise l'encapsulation UDP des paquets IPsec Encapsulating Security Protocol (ESP) en mode tunnel, qui offre une authentification et un cryptage complet des paquets.

• Modes - IBM Cloud VPN for VPC offre les modes VPN statique basé sur des routes et VPN basé sur des stratégies. Avec un VPN basé sur des règles, le trafic qui correspond aux plages CIDR négociées passe par le VPN. Pour un VPN basé sur des routes statiques, des interfaces de tunnel virtuelles sont créées et tout le trafic qui est acheminé vers ces interfaces logiques avec des routes personnalisées passe par le VPN. Les deux options de VPN offrent les mêmes fonctions.

• 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 non obligatoire, il est recommandé de dédier 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 :

1. Assurez-vous que les listes de contrôle d'accès au réseau sont en place pour permettre au trafic VPN de circuler.

2. 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 Limitations de la passerelle VPN.

3. Passez en revue les remarques relatives à la planification et créez votre passerelle VPN.

4. Créez des connexions VPN.

   IBM Cloud VPN for VPC ne prend en charge qu'un seul VPN basé sur des routes par zone et par VPC.

5. Pour les VPN statiques basés sur des routes, sélectionnez ou créez une table de routage pour le routage statique, puis créez des routes à l'aide du type de connexion VPN.

6. Connectez-vous à un réseau sur site via un tunnel VPN.

7. Vérifiez que votre connexion VPN est disponible en envoyant une commande ping ou un trafic de données aux unités du réseau homologue via le tunnel.

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 stratégies 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.

Cas d'utilisation VPN for VPC

Cas d'utilisation 1 : Connexion VPN à une unité homologue distante unique du même type associée à 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 stratégies et un VPN basé sur des routes. Pour plus d'informations, voir Limitations connues.

Cas d'utilisation 2 : Connexions VPN à plusieurs unités homologues distantes

Les VPN basés sur des stratégies et les VPN basés sur des routes permettent aux utilisateurs de se connecter à plusieurs unités homologues distantes associés à différents VPC/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 site se trouve derrière un périphérique NAT et ne possède pas d'adresse IP publique. 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 a deux tunnels actifs dans le backend. Lorsque les deux tunnels VPN sont activés, un seul tunnel est utilisé pour acheminer le trafic VPN sur le tunnel.

Le VPN utilise le tunnel avec la petite IP publique 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. Le diagramme suivant illustre la configuration par défaut. Lorsque vous créez une route avec la destination 10.1.0.0/24 et le saut suivant est la connexion VPN, si tunnel 1 et tunnel 2 sont tous deux en service, l'IP privée 10.254.0.2 de l'appareil VPN est renvoyée pour la création de la route.

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.

Lors de la création de connexions pour un VPN basé sur des routes, vous pouvez désormais activer la distribution du trafic entre les Up tunnels de la connexion de la passerelle VPN 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 fonction "distribuer le trafic" lors de la création ou de l 'ajout de connexions à une passerelle VPN.

Comme le montre le diagramme suivant, le trafic sortant est acheminé vers les deux tunnels de manière dynamique. Lorsque les tunnels sont Up, 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 est acheminé vers tunnel 1 et tunnel 2 de manière dynamique.

Pour utiliser cette fonction, l'appareil sur site doit prendre en charge le routage asymétrique afin d'améliorer les performances du réseau. 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-feux.

Liens connexes

Ces liens fournissent des informations supplémentaires sur IBM Cloud VPN for VPC :

• Référence d'interface de ligne de commande VPN
• Référence d'API VPN
• Référence Terraform VPN
• Gestion de l'accès IAM pour les services d'infrastructure VPC
• Événements Activity Tracker
• Questions fréquentes sur les passerelles VPN
• Traitement des incidents liés aux passerelles VPN
• Quotas de passerelle VPN