Remarques relatives à la planification des passerelles VPN

Avant de créer une passerelle VPN, examinez les considérations de planification, les exigences de configuration et les autres directives applicables.

Considérations générales

Avant de créer une passerelle VPN, passez en revue les considérations générales suivantes :

  • Assurez-vous que l'espace sur le sous-réseau est suffisant pour la passerelle. Pour vous assurer que les fonctions de gestion VPN et de reprise en ligne peuvent fonctionner correctement, créez la passerelle VPN dans un sous-réseau sans aucune autre ressource VPC. Ce processus garantit que suffisamment d'adresses IP privées sont disponibles pour la passerelle. Une passerelle VPN a besoin de quatre adresses IP privées pour être en mesure de satisfaire aux exigences de la haute disponibilité et d'accueillir les mises à niveau en continu. Étant donné qu'un maximum de cinq adresses IP privées sont réservées dans un sous-réseau, la taille minimale du sous-réseau pouvant être utilisé pour héberger une passerelle VPN est de /28 (16 adresses IP ou masque de réseau 255.255.255.240).
  • Par défaut, PFS (Perfect Forward Secrecy) est désactivé pour IBM Cloud VPN pour VPC. Certains fournisseurs ont besoin de l'activation PFS pour la phase 2. Vérifiez les instructions de votre fournisseur et utilisez des polices personnalisées si vous avez besoin de PFS.
  • La passerelle IBM VPN utilise son adresse IP publique comme identité locale IKE et désigne l'adresse IP publique de l'homologue comme identité d'homologue IKE par défaut. Vous pouvez spécifier les identités IKE locale et homologue pour remplacer ce comportement par défaut lorsque vous créez une connexion VPN. Lorsque la passerelle VPN homologue est située derrière un pare-feu NAT et que l'adresse IP publique de l'homologue n'est pas associée à l'interface de la passerelle VPN homologue, vous pouvez ajuster la configuration de la passerelle VPN homologue. Cette configuration garantit que l'adresse IP publique de l'homologue est utilisée comme identité IKE. Vous pouvez également spécifier l'identité IKE homologue lorsque vous créez une connexion VPN pour utiliser l'identité IKE réelle de votre passerelle VPN homologue.
  • Si votre passerelle VPN homologue se trouve derrière un périphérique NAT et ne possède pas d'adresse IP publique, vous pouvez associer un nom de domaine complet à l'adresse IP NAT. Vous pouvez ensuite utiliser ce FQDN au lieu d'une adresse IP lorsque vous créez une connexion VPN. De cette manière, l'identité IKE de l'homologue par défaut est le nom de domaine complet. Vous pouvez spécifier l'identité IKE de l'homologue pour remplacer cette valeur par défaut lorsque vous créez la connexion VPN si la valeur par défaut ne correspond pas à l'identité IKE réelle de votre passerelle VPN homologue.
  • Vous pouvez sélectionner un mode d'établissement (bidirectionnel ou pair uniquement) lorsque vous créez une connexion VPN. Gardez à l'esprit que si votre passerelle VPN homologue ne possède pas d'adresse IP publique lors de la création d'une connexion VPN, vous devez définir le mode Peer only pour la passerelle VPN. Dans ce cas, la passerelle VPN homologue est chargée de rétablir la connexion en cas de panne.
  • Une fois que vous avez établi une connexion VPN, vous ne pouvez pas changer le type d'adresse de la passerelle homologue d'une adresse IP à un FQDN, ou d'un FQDN à une adresse IP.
  • IBM Cloud VPC prend en charge la résolution des FQDN par le biais des DNS Services. Si le VPC où réside la passerelle VPN se trouve dans le réseau autorisé d'une instance DNS privée, les enregistrements DNS ajoutés dans ce DNS privé peuvent être résolus dans la passerelle VPN.

Considérations sur les passerelles VPN basées sur des règles

Avant de créer une passerelle VPN basée sur des règles, examinez les points suivants :

  • La passerelle VPN basée sur des règles est créée dans la zone associée au sous-réseau que vous sélectionnez. La passerelle VPN ne peut se connecter qu'aux instances de serveur virtuel de cette zone. Par conséquent, les instances dans d'autres zones ne peuvent pas utiliser cette passerelle VPN pour communiquer avec l'autre réseau. Pour assurer la tolérance aux pannes des zones, vous devez déployer une passerelle VPN par zone.
  • Pour les passerelles VPN basées sur des politiques, les routes ne sont pas automatiquement détectées. La table de routage doit être configurée pour accepter les routes provenant de la passerelle VPN, et les routes propagées sont limitées aux préfixes CIDR définis dans la politique VPN. Voir les itinéraires publicitaires.

Considérations sur les passerelles VPN basées sur les routes

Avant de créer une passerelle VPN basée sur les routes, examinez les points suivants :

Considérations relatives aux connexions VPN basées sur des routes statiques

Avant de créer une connexion VPN basée sur une route statique, examinez les points suivants :

  • Si vous prévoyez de définir une route par défaut (0.0.0.0/0) dans une table de routage VPC pour laisser le trafic sortant de vos ressources VPC passer par une passerelle VPN, créez votre passerelle VPN dans un sous-réseau différent de celui associé à la table de routage. Sinon, cette route par défaut provoque un conflit de routage pour la passerelle VPN et peut interrompre la connexion VPN.
  • IBM Cloud VPN for VPC ne prend en charge qu'un seul VPN basé sur des routes par zone et par VPC.

Considérations sur les connexions VPN dynamiques basées sur les routes

Avant de créer une connexion VPN dynamique basée sur des routes, examinez les points suivants :

  • Pour activer le routage dynamique entre votre passerelle VPN et les appareils sur site, vous devez créer une passerelle de transit et l'attacher à la passerelle VPN. Dans cette configuration, la passerelle de transit gère et distribue automatiquement le trafic entre vos appareils. Voir les considérations relatives à la connexion de la passerelle VPN avec Transit Gateway. Gardez à l'esprit que le routage statique ne prend pas en charge ce type d'attachement.
  • Vous pouvez créer des connexions VPN dynamiques à tout moment, même avant que la passerelle VPN ne soit connectée à la passerelle de transit. Cependant, le trafic ne circule que lorsque la passerelle VPN est connectée à la passerelle de transit.
  • Une valeur ASN locale et homologue est requise pour le VPN dynamique basé sur les routes. L'ASN local identifie votre réseau local pour le peering BGP tandis que l'ASN pair identifie le réseau pair distant avec lequel le VPN échange des routes. Si vous ne spécifiez pas la valeur ASN locale, la passerelle VPN est créée avec l'ASN par défaut de 64520.
  • Certaines valeurs ASN sont limitées lorsque vous créez une passerelle VPN et ne peuvent pas être utilisées comme ASN local ou homologue, notamment 0, 13884, 36351, 64512, 64513, 65100, 65200–‍65234, 65402‍–‍65433, 65500, ou 4201065000‍–‍4201065999. Ces valeurs sont soit réservées, soit font partie de plages ASN privées, et peuvent entraîner des conflits de routage.
  • Lorsque vous connectez une passerelle de transit à un VPN, vous ne pouvez pas modifier la valeur ASN tant que vous n'avez pas supprimé la connexion au service.
  • Plusieurs passerelles VPN peuvent se connecter à la même passerelle de transit, mais chaque passerelle VPN ne peut s'attacher qu'à une seule passerelle de transit.
  • Si vous prévoyez d'utiliser un CIDR non RFC 1918 pour votre connexion de passerelle de transit qui n'est pas dans les plages IP privées standard (10.0.0.0/8, 172.16.0.0/12, ou 192.168.0.0/16), vous devez ajouter une route delegate-VPC dans la table de routage de sortie de votre VPC. Cette route doit pointer vers le CIDR que vous avez choisi et doit être associée au sous-réseau VPN dans la même zone. Voir les considérations relatives à la connexion de la passerelle VPN pour la passerelle de transit.
  • Chaque site IBM VPN supporte un maximum de 120 routes pour chaque pair VPN dans une configuration de routage dynamique. Si cette limite est dépassée, la session BGP pour cet homologue s'arrête automatiquement. Pour rétablir la session, réduisez le nombre d'itinéraires annoncés par votre réseau homologue sur site à 120 ou moins, puis basculez la connexion sur le site IBM Cloud pour rétablir la session BGP. Pour plus d'informations, voir Combien de routes VPN for VPC prend-il en charge par homologue VPN pour une connexion dynamique basée sur les routes?

IBM Power Virtual Servers automatiser le déploiement de l'espace de travail : Automatiser le déploiement de l'espace de travail

Un projet d'automatisation VPN de site à site est disponible et fournit un module Terraform pour créer une passerelle VPN de site à site. Il permet également une connexion sécurisée sur l'internet depuis votre réseau local sur site vers des ressources privées dans un espace de travail Power Virtual Server. Ce module Terraform Infrastructure as Code ( IaC ) crée une passerelle VPN basée sur des politiques et une connexion avec des politiques locales et de pairs. Un espace de travail Transit Gateway et IBM Power Virtual Server est créé par défaut, mais vous pouvez remplacer la valeur par défaut en spécifiant des espaces de travail existants.

Le référentiel GitHub pour ce projet d'automatisation est situé dans le répertoire IBM / référentiel power-vpn-gateway GitHub. Le fichier README du projet crée une passerelle VPN et l'attache à un espace de travail Power Virtual Server nouveau ou existant, fournissant un accès sécurisé à l'infrastructure IBM Cloud Power.