Unité 3.6 : Connectivité hybride : VPN, NAT, et Cross-Connect

Introduction

Trois des exigences réseau les plus difficiles de FinCorp concernent la traversée d'une limite : un lien de site à site chiffré à partir du centre de données d'entreprise vers le cloud pendant la migration, un moyen pour les serveurs Private Cloud de télécharger des correctifs et d'accéder aux points de terminaison SaaS sans jamais posséder une IP publique, et un chemin privé à faible latence entre deux des centres de données virtuels (VDC) de FinCorp. La plateforme répond à chacune de ces exigences avec un produit distinct, et les produits ne se chevauchent pas : un VPN Gateway chiffre le trafic sur l'internet public, un NAT Gateway offre une sortie privée uniquement pour les serveurs, et un Private Cross-Connect relie les VDC sur un LAN privé. Cette unité établit quand chacun s'applique et ses contraintes non négociables, puis construit les deux qui assurent 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 l'internet public chiffré, quittez un réseau privé sortant, ou joignez deux réseaux privés de manière privée ?

Le VPN Gateway établit une connexion de site à site sécurisée et chiffrée entre un réseau local et vos LAN privés VDC sur l'internet, en utilisant soit des tunnels IPSec, soit des pairs WireGuard. Il s'agit de la migration la plus solide : il relie un centre de données d'entreprise ou un bureau à des ressources cloud pour la durée d'une migration et au-delà. Ses contraintes définissantes sont fermes. La mise en œuvre IPSec est IKEv2 uniquement ; IKEv1 n'est pas pris en charge, donc tout peer hérité configuré pour IKEv1 doit être reconfiguré. L'authentification pour IPSec est par clé prépartagée (une clé PSK de 32 caractères est recommandée). La haute disponibilité est une option active-passive que vous couplez avec le niveau : l'activation de celle-ci fait fonctionner la passerelle en mode actif-passif, de sorte qu'un tunnel redondant prend automatiquement le relais en cas de défaillance, et que cette paire HA présente une seule adresse publique IP, de sorte que le peer local cible toujours une adresse. Les adresses de tunnel et de passerelle IP sont IPv4 uniquement, bien que la charge utile transportée via le tunnel puisse être une pile IPv4 et IPv6 à la fois. Le BGP n'est pas proposé ; le routage est statique, défini par les CIDR de réseau que vous répertoriez de chaque côté du tunnel. Le débit par tunnel est de jusqu'à 1 Gbps, et le niveau définit les plafonds pour les LAN et les tunnels.

La passerelle NAT est le chemin de sortie pour les charges de travail privées. Elle permet aux machines virtuelles à l'intérieur d'un VDC d'accéder à l'internet sans aucune interface de réseau public : la passerelle effectue la source NAT, de sorte que les machines virtuelles privées puissent initier des connexions sortantes et recevoir les réponses, tandis que les connexions entrantes initiées à partir de l'internet sont refusées. Il s'agit de la forme honnête du produit et du point de confusion le plus courant : la passerelle NAT est SNAT uniquement, sans DNAT et donc sans transfert de port entrant. Si vous avez besoin d'un accès entrant, c'est le travail d'un Load Balancer, et non celui de la passerelle NAT. Elle nécessite une adresse publique IPv4 réservée (elle peut en transporter plusieurs), prend en charge jusqu'à six réseaux privés par passerelle, et est hautement disponible, exécutée sur plusieurs zones de disponibilité dans une région. Ses utilisations documentées sont précisément les cas de serveurs privés sortants : tirer des mises à jour du système d'exploitation et des logiciels, atteindre NTP, laisser le Backup Service atteindre des machines virtuelles privées, et restreindre l'accès sortant à des points de confiance spécifiques.

Le Private Cross-Connect relie plusieurs VDC sur un réseau privé LAN 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 sur l'internet public. Ses contraintes sont catégoriques : les VDC participants doivent être dans la même région et sous le même contrat ; les régions et les contrats croisés ne sont pas pris en charge. Toutes les cartes réseau sur tous les VDC connectés doivent partager la même plage d'adresses IP, une adresse ne peut pas être utilisée dans plus d'une instance, et chaque LAN ne peut appartenir qu'à un Cross-Connect. La bande passante est comparable à celle d'une carte réseau privée normale, et la fonction elle-même ne comporte pas de frais. Un LAN est connecté à un Cross-Connect en définissant l'identifiant de connexion sur la ressource LAN, et un Cross-Connect ne peut être supprimé qu'une fois qu'il a été déconnecté de tous les LAN et VDC. Lorsque deux sites ont besoin d'une ligne dédiée fournie par un fournisseur de services de télécommunication 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 du Private Cross-Connect ; les constructions de cette unité utilisent les primitives VPN et NAT.

Pendant une migration, ces trois éléments jouent des rôles complémentaires : le VPN Gateway transporte le pont chiffré entre les locaux et le cloud pendant que les charges de travail sont déplacées ; la passerelle NAT Gateway permet aux serveurs privés migrés mais pas encore publics d'accéder à l'internet pour les agents, les correctifs et les sauvegardes ; et un Cross-Connect relie de manière privée les VDC qui doivent échanger des données à l'intérieur de la région. Aucun ne remplace l'autre.

DCD Déploiement étape par étape

Vous allez créer les deux primitives qui assurent la bascule de FinCorp : un tunnel IPSec VPN Gateway avec un tunnel de retour vers le centre de données d'entreprise, et une passerelle NAT qui donne à l'application privée LAN une sortie enregistrement uniquement. Les deux réutilisent le VDC à trois LAN de l'unité 3.1.

Objectif de construction : Mettre en place un tunnel VPN Gateway ; mettre en place une passerelle NAT pour la sortie privée.

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

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

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

1. À partir de la page des passerelles VPN, cliquez sur Créer un tunnel VPN Gateway.
2. Dans Propriétés, définissez un nom, l'emplacement (correspondant à l'adresse IP réservée et au VDC), et sélectionnez l'adresse publique IP réservée dans le menu déroulant. (La passerelle IP et le centre de données doivent se trouver au même emplacement.)
3. Dans Niveau, choisissez le niveau adapté à vos besoins de LAN et de tunnel (le niveau Standard permet jusqu'à 5 LAN et 10 tunnels/peers ; le niveau amélioré jusqu'à 10 LAN et 20 ; le niveau premium jusqu'à 15 LAN et 30). Sélectionnez la variante Haute disponibilité du niveau pour exécuter une configuration active-passive : les tunnels redondants prennent automatiquement le relais en cas de défaillance, minimisant ainsi les temps d'arrêt, derrière la seule passerelle IP.
4. Dans Protocole, choisissez IPSec. La version IKE est IKEv2 par défaut (il n'y a pas d'option IKEv1 à sélectionner ; il s'agit de la seule version IKE prise en charge).
5. Dans Connexions LAN, ajoutez le LAN privé qui utilisera la passerelle. Choisissez une adresse IP privée pour la passerelle à partir du CIDR du LAN ; la plage recommandée est .2 à .9, et l'adresse ne doit pas déjà être utilisée dans le VDC. (Remarque : un tunnel VPN Gateway ne peut pas être attaché directement à un LAN géré par Managed Kubernetes ; attachez un pool de Node supplémentaire LAN si c'est votre objectif.)
6. Cliquez sur Enregistrer. L'état de la passerelle affiche PROVISIONNING, puis DISPONIBLE. Vous pouvez commencer à créer le tunnel pendant qu'il est encore en cours de provisionnement.
7. Sur la page des passerelles VPN, cliquez sur Créer des tunnels pour cette passerelle. Entrez un nom de tunnel, l'hôte distant (l'hôte distant sur site public IPv4 ou FQDN), et le PSK sous Authentification (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 : CIDR des réseaux cloud (les sous-réseaux IONOS autorisés à travers le tunnel) et CIDR des réseaux pairs (les sous-réseaux sur site). Ces listes de CIDR statiques constituent la totalité du contrat de routage ; il n'y a pas de protocole 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 - passerelle NAT pour la sortie privée (dans le Data Center Designer) :

1. Ouvrez le VDC et confirmez qu'un LAN privé contenant au moins un VM existe (le LAN d'application privée de l'unité 3.1).
2. Ajoutez une passerelle NAT à l'espace de travail et connectez son interface (réseau source) à ce LAN privé.
3. Sélectionnez la passerelle NAT et ouvrez ses Propriétés dans l'Inspecteur > Paramètres. Définissez un nom et ajoutez une adresse IP publique IP à partir des adresses réservées (une seule suffit ; plusieurs peuvent être ajoutées).
4. Créez une règle NAT. Définissez un nom et un Protocole (TCP, UDP, ICMP ou TOUT). Pour Source > Adresse IP publique IP, sélectionnez l'une des adresses IP publiques de la passerelle (cette adresse masque l'adresse source sortante). Pour Source > Sous-réseau, entrez le VM privé ou le sous-réseau en notation CIDR (par exemple 10.10.10.0/24). Vous pouvez également restreindre Cible > Sous-réseau à des destinations externes spécifiques pour autoriser la sortie uniquement vers des points de terminaison de confiance.
5. Définissez la route par défaut du LAN sur la passerelle. Sur les machines virtuelles privées, la table de routage doit envoyer le trafic internet à 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 ce changement de routage, la passerelle existe mais aucun trafic ne l'utilise.
6. Si ces machines virtuelles privées ont besoin d'une résolution DNS lors de l'utilisation de 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'adresse IP publique IPv4 statique avant de créer la passerelle ; les deux passerelles sélectionnent les adresses réservées et une adresse DHCP ne peut pas être utilisée.
• N'essayez pas de trouver une option IKEv1, il n'y en a pas ; le pair doit parler IKEv2 (ou utiliser WireGuard). Les paramètres de phase 1 et de phase 2 doivent correspondre exactement aux deux extrémités, sinon le tunnel ne se mettra pas en place.
• La paire HA VPN partage une seule adresse IP publique IP ; configurez le pair sur site pour cibler cette seule adresse, et non deux.
• La passerelle NAT est uniquement SNAT : il n'y a pas de chemin entrant/DNAT. N'essayez pas de publier un service à travers celle-ci ; utilisez une passerelle Load Balancer pour les entrées.
• Mettez en place la passerelle NAT et ses règles avant d'attendre la sortie, puis modifiez la route par défaut du LAN pour pointer vers la passerelle ; le changement de routage est l'étape que les gens oublient, et le trafic ne sortira jamais jusqu'à ce que cela soit fait.
• L'absence d'une règle SNAT UDP casse la résolution DNS pour les machines virtuelles dont la route par défaut est la passerelle NAT.

Les paramètres du tunnel portent un point architectural réel : les sous-réseaux routés sont des listes de CIDR statiques des deux côtés, et non un protocole dynamique. Une brève vue API du même tunnel rend la forme immuable explicite (les paramètres de phase et les deux tableaux 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 est constituée de trois produits non chevauchants. Le VPN Gateway transporte le trafic chiffré de site à site sur Internet avec IKEv2 (ou WireGuard), une routage basé sur des listes CIDR statiques, et une option HA active-passive qui présente une seule adresse IP publique. La passerelle NAT donne aux charges de travail privées un accès Internet sortant uniquement via SNAT, sans chemin d'entrée, nécessitant une adresse IP publique réservée et un changement délibéré de la route par défaut LAN. Le Private Cross-Connect relie les VDCs de manière privée, mais uniquement dans la même région et le même contrat. Le choix entre eux dépend de la limite que vous traversez, et pendant une migration, les primitives VPN et NAT construites ici transportent le trafic de basculement.

Points clés :

• Le VPN Gateway est IKEv2/WireGuard sans IKEv1 ; la routage est basée sur des listes CIDR statiques (pas de BGP) ; l'HA est active-passive sur une adresse IP publique partagée ; jusqu'à 1 Gbps par tunnel.
• Réservez l'adresse IPv4 publique (même emplacement que le VDC) avant de créer la passerelle ; les adresses DHCP ne peuvent pas être utilisées.
• La passerelle NAT est SNAT uniquement (pas d'entrée/DNAT), nécessite une adresse IP publique réservée, prend en charge jusqu'à six réseaux LAN privés, et ne transmet le trafic qu'une fois que la route par défaut LAN pointe vers elle.
• Pour les VM dont la route par défaut est la passerelle NAT, une règle SNAT UDP est requise ou la résolution DNS est rompue.
• Le Private Cross-Connect est limité à la même région et au même contrat, nécessite une plage d'adresses IP partagée, autorise un Cross-Connect par LAN, et est gratuit ; il ne s'agit pas d'un lien inter-région ou inter-contrat.

Terminologie importante :

• SNAT (Source NAT) : Réécriture de l'adresse source des paquets sortants pour que les hôtes privés puissent initier des connexions Internet ; la passerelle NAT fait cela et refuse les trafics entrants non sollicités (DNAT).
• IKEv2 : Le protocole d'échange de clés que la passerelle IPSec VPN Gateway utilise ; la seule version IKE prise en charge, IKEv1 n'est pas disponible.
• Clé pré-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.

Lecture supplémentaire

• Unité 3.1, Topologie et segmentation du centre de données virtuel, pour les fondations IP réservées et les trois LAN que cette construction réutilise.
• Unités 3.3 et 3.4 pour l'équilibrage de charge entrant, la fonctionnalité que la passerelle NAT ne fournit pas intentionnellement.
• Unité 6.3, Provisionnement d'un Cluster privé, où la passerelle NAT et Cross-Connect deviennent des prérequis obligatoires pour un Node Pools privé.