Unité 3.6 : Connectivité hybride : VPN, NAT et interconnexion privée

Introduction

Trois des exigences réseau les plus complexes de FinCorp concernent le franchissement d'une frontière : un lien chiffré entre sites reliant le centre de données d'entreprise au cloud pendant la migration, un moyen pour les serveurs cloud privés de récupérer des correctifs et d'accéder aux points de terminaison SaaS sans jamais posséder d'IP publique, et un chemin privé à faible latence entre deux VDC appartenant à FinCorp. La plateforme répond à chacune de ces exigences avec un produit distinct, et ces produits ne se chevauchent pas : un VPN Gateway chiffre le trafic sur Internet public, un NAT Gateway offre aux serveurs privés une sortie uniquement sortante, et un Private Cross-Connect relie les VDC sur un LAN privé. Cette unité établit quand chaque produit s'applique ainsi que ses contraintes non négociables, puis construit les deux éléments qui portent la migration : un tunnel VPN et un NAT Gateway pour la sortie privée.

1. Les trois primitives hybrides et comment les choisir

La sélection se résume à une question par exigence : traversez-vous Internet de manière chiffrée, sortez-vous d'un réseau privé vers l'extérieur, ou reliez-vous deux réseaux privés de façon privée ?

VPN Gateway établit une connexion site à site sécurisée et chiffrée entre un réseau sur site et vos LAN privés VDC via Internet, en utilisant soit des tunnels IPSec, soit des pairs WireGuard. C'est le cheval de trait de la migration : il connecte un centre de données d'entreprise ou un bureau de succursale aux ressources cloud pendant la durée d'une bascule et au-delà. Ses contraintes déterminantes sont fermes. L'implémentation IPSec est limitée à IKEv2 ; IKEv1 n'est pas pris en charge, de sorte que tout pair legacy configuré pour IKEv1 doit être reconfiguré. L'authentification pour IPSec s'effectue par clé partagée (une PSK de 32 caractères est recommandée). La haute disponibilité est une option actif-passif que vous associez à la tier : son activation fait fonctionner la passerelle en mode actif-passif, de sorte qu'un tunnel redondant prend automatiquement le relais en cas de défaillance, et cette paire HA présente une seule adresse IP publique, si bien que le pair sur site cible toujours une seule adresse. Les adresses IP des tunnels et de la passerelle sont uniquement IPv4, bien que la charge utile transportée à travers le tunnel puisse être bicolore IPv4 et IPv6. BGP n'est pas proposé ; le routage est statique, défini par les CIDR de réseau que vous indiquez de chaque côté du tunnel. Le débit par tunnel est de 1 Gbps maximum, et la tier fixe les plafonds pour les LAN et les tunnels.

NAT Gateway est le chemin de sortie pour les charges de travail privées. Il permet aux VM à l'intérieur d'un VDC d'atteindre Internet sans aucune interface réseau publique : la passerelle effectue une Source NAT, de sorte que les VM privées peuvent initier des connexions sortantes et recevoir les réponses, tandis que les connexions entrantes initiées depuis Internet sont refusées. C'est la forme honnête du produit et le point de confusion le plus courant : NAT Gateway est limité à la SNAT, sans DNAT et donc sans transfert de port entrant. Si vous avez besoin d'accès entrant, c'est le rôle d'un équilibreur de charge, et non de NAT Gateway. Il nécessite une adresse IPv4 publique réservée (il peut en porter plusieurs), prend en charge jusqu'à six réseaux privés par passerelle, et est hautement disponible, déployé sur plusieurs zones de disponibilité dans une région. Ses usages documentés correspondent précisément aux cas de sortie des serveurs privés : récupération des mises à jour du système d'exploitation et des logiciels, accès à NTP, permettant à Backup Service d'atteindre les VM privées, et restriction de l'accès sortant à des points de terminaison spécifiques et de confiance.

Private Cross-Connect relie plusieurs VDC via un LAN privé sans exposition publique, pour un passage de données sécurisé avec une latence plus faible et de meilleures performances que le routage entre eux via Internet public. Ses contraintes sont catégoriques : les VDC participants doivent se trouver dans la même région et sous le même contrat ; le cross-région et le cross-contrat ne sont pas pris en charge. Toutes les NIC de tous les VDC connectés doivent partager la même plage IP, une adresse ne doit pas être utilisée dans plus d'une instance, et chaque LAN ne peut appartenir qu'à un seul Cross-Connect. La bande passante est comparable à celle d'une NIC privée normale, et la fonction elle-même n'est pas facturée. Un LAN est raccordé à un Cross-Connect en définissant l'identifiant de la connexion sur la ressource LAN, et un Cross-Connect ne peut être supprimé qu'après avoir été déconnecté de tous les LAN et VDC. Lorsque deux sites ont besoin d'une ligne dédiée fournie par un opérateur plutôt que d'un lien VDC à VDC dans la même région, il s'agit d'un service de ligne dédiée Cloud Connect distinct, différent de Private Cross-Connect ; les constructions de cette unité utilisent les primitives VPN et NAT.

Pendant une bascule de migration, ces trois éléments jouent des rôles complémentaires : VPN Gateway porte le pont chiffré entre le sur site et le cloud pendant que les charges de travail se déplacent ; NAT Gateway permet aux serveurs privés migrés mais pas encore publics d'atteindre Internet pour les agents, les correctifs et les sauvegardes ; et un Cross-Connect assemble de manière privée des VDC qui doivent échanger des données au sein de la région. Aucun ne remplace l'autre.

Déroulement de l'implémentation de DCD

Vous allez construire les deux primitives qui soutiennent la bascule de FinCorp : une VPN Gateway IKEv2 IPSec avec un tunnel vers le centre de données d'entreprise, et une NAT Gateway offrant une éjection sortante uniquement pour le LAN applicatif privé. Les deux réutilisent le VDC à trois LAN de l'Unité 3.1.

Objectif de construction : Provisionner un tunnel VPN Gateway ; provisionner une NAT Gateway pour l'éjection privée.

Prérequis : réserver les IP publiques en premier

Les deux passerelles consomment une adresse IPv4 publique réservée, et cette adresse doit être réservée dans le même emplacement que la passerelle avant sa création. À l'aide de la gestion des IP, réservez une adresse IPv4 pour la VPN Gateway et une pour la NAT Gateway, dans la région où se trouve le VDC. Une adresse attribuée par DHCP ne fonctionnera pas ; ces passerelles sélectionnent uniquement parmi les adresses réservées.

Étapes - VPN Gateway et tunnel IPSec (dans Data Center Designer) :

1. Depuis la page VPN Gateways, cliquez sur Create VPN Gateway.
2. Dans Properties, définissez un Nom, l'Location (correspondant à l'IP réservée et au VDC), et sélectionnez l'IP Address publique réservée depuis la liste déroulante. (L'IP et le centre de données doivent se trouver dans le même emplacement.)
3. Dans Tier, choisissez le niveau adapté aux besoins de votre LAN et de vos tunnels (Standard permet jusqu'à 5 LAN et 10 tunnels/peers ; Enhanced jusqu'à 10 LAN et 20 ; Premium jusqu'à 15 LAN et 30). Sélectionnez la variante High Availability du niveau pour un fonctionnement actif-passif : les tunnels redondants prennent automatiquement le relais en cas de défaillance, minimisant les temps d'indisponibilité, derrière l'IP unique de la passerelle.
4. Dans Protocol, choisissez IPSec. La Version IKE est IKEv2 par défaut (il n'y a pas d'option IKEv1 à sélectionner ; c'est la seule version IKE prise en charge).
5. Dans LAN Connections, ajoutez le LAN privé qui utilisera la passerelle. Choisissez une IP privée pour la passerelle à partir du CIDR du LAN ; la plage recommandée est de .2 à .9, et l'adresse ne doit pas déjà être utilisée dans le VDC. (Note : une VPN Gateway ne peut pas se connecter à un LAN géré directement par Managed Kubernetes ; ajoutez un LAN de pool de nœuds supplémentaire si c'est votre cible.)
6. Cliquez sur Save. L'état STATE de la passerelle affiche PROVISIONING, puis AVAILABLE. Vous pouvez commencer à créer le tunnel pendant qu'elle est encore en cours de provisionnement.
7. Sur la page VPN Gateways, cliquez sur Create Tunnels pour cette passerelle. Saisissez un Name de tunnel, le Remote Host (l'IPv4 public ou le FQDN du pair sur site), et le PSK sous Authentication (méthode PSK ; utilisez une clé forte de 32 caractères).
8. Définissez la phase Initial Exchange (IKE_SA_INIT) : choisissez un groupe Diffie-Hellman, un algorithme de chiffrement et un algorithme d'intégrité parmi les listes proposées (par exemple groupe DH 16-MODP4096, AES256, SHA256), avec une durée de vie IKE comprise entre 3600 et 86400 secondes.
9. Définissez la phase Child SA (ESP) : choisissez le groupe Diffie-Hellman, l'algorithme de chiffrement et l'algorithme d'intégrité correspondants, avec une durée de vie ESP comprise entre 600 et 14400 secondes.
10. Définissez les réseaux routés : Cloud Network CIDRs (les sous-réseaux du côté IONOS CLOUD autorisés à travers le tunnel) et Peer Network CIDRs (les sous-réseaux sur site). Ces listes statiques de CIDR constituent le routage ; il n'y a pas de BGP. Enregistrez le tunnel, puis configurez l'appareil sur site avec des paramètres identiques et vérifiez que le tunnel atteint un état actif.

Étapes - NAT Gateway pour l'éjection privée (dans Data Center Designer) :

1. Ouvrez le VDC et vérifiez qu'un LAN privé contenant au moins une VM existe (le LAN applicatif privé de l'Unité 3.1).
2. Ajoutez une NAT Gateway à l'espace de travail et connectez son interface (réseau source) à ce LAN privé.
3. Sélectionnez la NAT Gateway et ouvrez ses Properties dans Inspector > Settings. Définissez un Nom et ajoutez une adresse IP publique à partir des adresses réservées (une suffit ; plusieurs peuvent être ajoutées).
4. Créez une règle NAT. Définissez un nom et un Protocol (TCP, UDP, ICMP ou ANY). Pour Source > Public IP, sélectionnez l'une des adresses IP publiques de la passerelle (cela masque l'adresse source sortante). Pour Source > Subnet, saisissez la VM privée ou le sous-réseau en notation CIDR (par exemple 10.10.10.0/24). Facultativement, restreignez Target > Subnet à des destinations externes spécifiques pour autoriser l'éjection uniquement vers des terminaux de confiance.
5. Définissez la route par défaut du LAN vers la passerelle. Sur les VM privées, la table de routage doit envoyer le trafic destiné à Internet vers la passerelle NAT : pointez la route par défaut (0.0.0.0/0) vers celle-ci, ou ajoutez une route dédiée par cible externe si une route par défaut n'est pas acceptable. Sans cette modification de routage, la passerelle existe mais aucun trafic ne l'utilise.
6. Si ces VM privées ont besoin de la résolution DNS tout en utilisant la route par défaut NAT, assurez-vous qu'une règle SNAT couvre UDP, sinon la résolution DNS par défaut échouera.

Erreurs courantes :

• Réservez l'IP publique statique avant de créer la passerelle ; les deux passerelles sélectionnent parmi les adresses réservées et une adresse DHCP ne peut pas être utilisée.
• Ne cherchez pas une option IKEv1, il n'y en a pas ; le pair doit utiliser IKEv2 (ou utiliser WireGuard). Les paramètres de la phase 1 et de la phase 2 doivent correspondre exactement aux deux extrémités, sinon le tunnel ne s'établira pas.
• La paire VPN HA partage une seule IP publique ; configurez le pair sur site pour cibler cette adresse unique, et non deux.
• La NAT Gateway est SNAT uniquement : il n'y a pas de chemin entrant/DNAT. N'essayez pas de publier un service à travers elle ; utilisez un équilibreur de charge pour le trafic entrant.
• Provisionnez la NAT Gateway et ses règles avant d'attendre l'éjection, puis modifiez la route par défaut du LAN vers la passerelle ; la modification de routage est l'étape que les gens oublient, et le trafic ne sort jamais silencieusement tant que celle-ci n'est pas effectuée.
• L'absence d'une règle SNAT UDP casse le DNS pour les VM dont la route par défaut est la passerelle NAT.

Les paramètres du tunnel soulèvent un point architectural réel : les sous-réseaux routés sont des listes statiques de CIDR de chaque côté, et non un protocole dynamique. Une vue API courte du même tunnel rend la forme immuable explicite (les paramètres de phase et les deux tableaux de CIDR constituent l'ensemble du contrat de routage) :

curl -X POST 'https://vpn.de-fra.ionos.com/ipsecgateways/{gatewayId}/tunnels' \
  -H 'Authorization: Bearer <token>' -H 'Content-Type: application/json' \
  --data '{ "properties": {
    "name": "to-fincorp-dc",
    "remoteHost": "vpn.fincorp.example",
    "auth": { "method": "PSK", "psk": { "key": "<32-char-psk>" } },
    "ike": { "diffieHellmanGroup": "16-MODP4096", "encryptionAlgorithm": "AES256", "integrityAlgorithm": "SHA256", "lifetime": 86400 },
    "esp": { "diffieHellmanGroup": "16-MODP4096", "encryptionAlgorithm": "AES256", "integrityAlgorithm": "SHA256", "lifetime": 3600 },
    "cloudNetworkCIDRs": [ "10.0.0.0/24" ],
    "peerNetworkCIDRs":  [ "198.51.100.0/24" ] } }'

Résumé

La connectivité hybride sur IONOS CLOUD repose sur trois produits distincts et non superposables. Le VPN Gateway achemine le trafic chiffré de site à site via Internet à l'aide d'IKEv2 (ou WireGuard), avec une routage statique basé sur des CIDR et une option de haute disponibilité en mode actif/passif qui présente une seule adresse IP publique. Le NAT Gateway offre aux charges de travail privées un accès sortant uniquement à Internet via SNAT, sans aucun chemin entrant, ce qui nécessite une adresse IP publique réservée et une modification délibérée de la route par défaut du LAN. Private Cross-Connect interconnecte les VDC de manière privée, mais uniquement au sein de la même région et du même contrat. Le choix entre ces options dépend de la frontière que vous traversez, et lors d'une migration, les primitives VPN et NAT, construites ici, assurent le trafic de bascule.

Points clés :

• Le VPN Gateway utilise IKEv2/WireGuard sans IKEv1 ; le routage repose sur des listes CIDR statiques (pas de BGP) ; la haute disponibilité est en mode actif/passif sur une seule adresse IP publique partagée ; débit maximal de 1 Gbps par tunnel.
• Réservez l'adresse IPv4 publique (dans le même emplacement que le VDC) avant de créer l'un des deux passerelles ; les adresses DHCP ne peuvent pas être utilisées.
• Le NAT Gateway est limité au SNAT (pas d'entrant/DNAT), nécessite une adresse IP publique réservée, prend en charge jusqu'à six LAN privés, et n'achemine le trafic que lorsque la route par défaut du LAN pointe vers lui.
• Pour les VM dont la route par défaut est la passerelle NAT, une règle UDP SNAT est requise, sinon la résolution DNS échoue.
• Private Cross-Connect est limité à la même région et au même contrat, nécessite une plage IP partagée, autorise un seul Cross-Connect par LAN, et est gratuit ; il ne s'agit pas d'un lien inter-régions ou inter-contrats.

Terminologie importante :

• SNAT (Source NAT) : Réécriture de l'adresse source des paquets sortants afin que les hôtes privés puissent initier des connexions Internet ; le NAT Gateway effectue cette opération et refuse tout trafic entrant non sollicité (DNAT).
• IKEv2 : Le protocole d'échange de clés utilisé par le VPN Gateway IPSec ; c'est la seule version IKE prise en charge, IKEv1 n'est pas disponible.
• Clé partagée (PSK) : Le secret partagé qui authentifie un tunnel IPSec ; une clé de 32 caractères est recommandée et doit correspondre sur les deux pairs.

Lectures complémentaires

• Unité 3.1, Topologie et segmentation des VDC, pour les fondations relatives aux IP réservées et aux trois LAN réutilisées par cette configuration.
• Unités 3.3 et 3.4 pour l'équilibrage de charge entrant, une fonctionnalité que NAT Gateway ne fournit pas délibérément.
• Unité 6.3, Provisionnement d'un Cluster privé, où NAT Gateway et Cross-Connect deviennent des prérequis stricts pour les pools de nœuds privés.