IBM Cloud Docs
A propos des passerelles VPN site à site

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 sur les règles pour établir un tunnel IPsec de site à site entre votre VPC et votre réseau privé sur site ou un autre VPC.

Un VPN basé sur les routes est désormais disponible en plus d'un VPN basé sur les règles. Pour commencer, sélectionnez le mode basé sur les it inéraires lorsque vous créez une passerelle VPN et créez des itinéraires en utilisant le type de connexion VPN. En outre, un VPN basé sur les routes prend désormais en charge les connexions dynamiques, qui permettent au VPN d'apprendre automatiquement les routes. Voir les considérations de planification pour configurer une connexion dynamique basée sur les itinéraires.

Fonctions VPN for VPC

Le service IBM Cloud site à site VPN for VPC comprend les fonctionnalités 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 règles fonctionne en mode actif-standby avec une seule IP de passerelle VPN partagée entre les membres, tandis qu'un VPN basé sur des routes offre les modes de redondance Active-Backup et Active-Active avec deux 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

  • Dead peer detection- Mécanisme configurable permettant de 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 pour 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 UDP Encapsulation des paquets IPsec Encapsulating Security Protocol (ESP) en mode tunnel, qui offre une authentification et un cryptage 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 sur la base des entrées de la table de routage et tout le trafic acheminé vers ces interfaces logiques avec des routes personnalisées passe 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 Statique comme mode lorsque vous créez une passerelle VPN et créez des itinéraires en utilisant le 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 dédier un sous-réseau d'au moins 16 IP (préfixe /28 ou inférieur) à 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 configurées pour permettre au trafic VPN de circuler entre votre réseau sur site et la passerelle IBM Cloud VPN.

  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 Problèmes connus pour les passerelles VPN.

  3. Passez en revue les considérations de planification et créez votre passerelle VPN.

  4. 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.

  5. 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.

  6. Pour une connexion VPN dynamique basée sur les 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 Ajouter une connexion.

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

  8. Vérifiez que votre connexion VPN est disponible en envoyant un ping ou un trafic de données à travers le tunnel vers des appareils qui se trouvent 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.

Exemple de configuration VPN
Exemple de configuration 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 :

Options de chiffrement, d'authentification et de groupe DH pour la phase 1 de l'auto-négociation IPsec
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.

Options de chiffrement et d'authentification pour la phase 2 de l'auto-négociation IPsec
Chiffrement Authentification Groupe DH
1 aes128 sha256 Désactivé
2 aes192 sha384 Désactivé
3 aes256 sha512 Désactivé
Options de cryptage en mode combiné pour la phase 2 de l'auto-négociation IPsec
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 1 : connexion VPN à un seul appareil homologue distant du 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 n'est pas applicable 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 VPN homologue unique
Cas d'utilisation VPN homologue unique

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

Les VPN basés sur des stratégies et sur des routes permettent aux utilisateurs de se connecter à plusieurs appareils homologues distants associés à différents VPC ou environnements en utilisant plusieurs connexions VPN.

Cas d'utilisation VPN homologues multiples
Cas d'utilisation VPN homologues multiples

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.

Configuration avancée VPN avec nom de domaine complet
Configuration avancée VPN avec nom de domaine complet

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.

Trafic distribué désactivé :
La fonction de trafic distribué est désactivée pour les connexions statiques

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.

Trafic distribué désactivé :
La fonction de trafic distribué est désactivée pour les connexions dynamiques

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.

Trafic distribué activé : route VPN active-active
La fonction de trafic distribué est activée pour la connexion 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.

Trafic distribué activé : route VPN active-active
La fonction de trafic distribué est activée pour la connexion dynamique

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.

VPN dynamique à base de routes à zone unique avec passerelle de transit
VPN dynamique à base de routes à zone unique avec passerelle de transit

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.

VPN dynamique basé sur des routes transversales avec passerelle de transit
VPN dynamique basé sur des routes transversales avec passerelle de transit

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.

Connexion VPN comme sauvegarde du lien direct
Connexion VPN comme sauvegarde du lien direct

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.

Connexion VPN avec passerelle de transit et serveurs d'alimentation
Connexion VPN avec passerelle de transit et serveurs d'alimentation

Pour mettre en place cette configuration, suivez les étapes suivantes :

  1. Fournir une passerelle VPN dans la zone 1 et la zone 3. Voir Création d'une passerelle VPN.
  2. Ajoutez une connexion VPN à la passerelle provisionnée pour vous connecter à votre réseau sur site. Voir Ajout de connexions à une passerelle VPN.
  3. Établir une connexion entre IBM Cloud VPN et Transit Gateway. Voir Création d'une passerelle de transit.