Relier en toute sécurité des réseaux Cloud VPC : VPN vs Direct Connect/ExpressRoute et bonnes pratiques

Qui doit interconnecter de manière sécurisée des réseaux Cloud-VPC se retrouve rapidement face à un conflit d’objectifs : maximiser la stabilité et les performances tout en restant traçable, segmenté et exploitable. En pratique, il ne s’agit rarement d’« une connexion vers le cloud ». Il s’agit d’un couplage réseau entre domaines de sécurité (p. ex. centre de données On-Premises, Cloud-VPC/VNET, réseaux partenaires) qui doit fonctionner au quotidien : déploiements, sauvegardes, monitoring, Identity/Directory, processus de mise à jour et de patch, flux de données pour les logiciels métier et les solutions logicielles proches des processus.

Ce billet compare Site-to-Site-VPN (IPsec) avec des liaisons dédiées comme AWS Direct Connect et Azure ExpressRoute. L’accent n’est pas mis sur des promesses marketing, mais sur l’exploitation : prérequis, risques, pièges typiques, étapes de vérification, troubleshooting et stratégie de repli. Des termes comme VPC (Virtual Private Cloud, réseau cloud isolé logiquement) et VNET (Azure Virtual Network, équivalent Azure du VPC) sont également replacés dans ce contexte.

Interconnecter de façon sécurisée des réseaux Cloud-VPC en pratique

Avant de comparer VPN et Direct Connect/ExpressRoute, un rapide contrôle de réalité est utile. Beaucoup de mauvaises décisions naissent du fait que les exigences sont formulées seulement comme « nous avons besoin d’accès ». Mieux vaut des critères vérifiables :

• Disponibilité et risque : À quel point la connexion est-elle critique ? Que se passe-t-il en cas d’indisponibilité de 15 minutes ? Et de 2 heures ? Quels objectifs RTO/RPO (relatifs à la reprise / à la perte de données) y sont associés ?
• Profil de trafic : Beaucoup de petits flux (API, Auth, Admin) vs. gros transferts (sauvegarde, réplication, batch). Important, car VPN et liaisons dédiées réagissent différemment en matière de débit, jitter et MTU.
• Sensibilité à la latence : Les flux d’annuaire et d’authentification (p. ex. LDAP/Kerberos), les accès aux bases de données ou les services de terminal sont nettement plus sensibles que des intégrations asynchrones.
• Modèle de sécurité : Confiance basée sur le réseau (classique) vs. Zero-Trust (accès selon identité/policy). Même si le Zero-Trust intervient souvent au niveau applicatif / identity, il influence la segmentation, le logging et le « Blast Radius » au sein du réseau.
• Complexité de routage : Un seul sous-réseau vers le cloud ou de nombreux réseaux, plusieurs sites, partenaires, plusieurs clouds ? C’est ici que se décide si l’on peut encore travailler proprement avec des routes statiques ou si l’on a besoin de BGP.
• Fréquence des changements : À quelle fréquence les réseaux, workloads, régions changent-ils ? Des changements fréquents plaident en faveur de patterns clairement standardisés (p. ex. Hub-and-Spoke, transit central) et d’une automatisation soignée.

Une fois ces points clarifiés, le choix technologique devient nettement plus simple — et vous évitez le classique : une « solution VPN rapide » qui se retrouve ensuite sous pression à cause du routage, de la segmentation et de l’exploitation.

VPN vs Direct Connect/ExpressRoute : principes de base et caractéristiques typiques

Site-to-Site VPN signifie en général IPsec (Internet Protocol Security, chiffrement et authentification au niveau réseau) sur l’Internet public. La connexion est généralement établie en deux phases : IKE (Internet Key Exchange, négociation des Security Associations) puis le canal de données proprement dit ESP (Encapsulating Security Payload). NAT-T (NAT Traversal) est optionnel lorsque du NAT se trouve sur le chemin et que l’IPsec doit être encapsulé dans UDP.

Direct Connect (AWS) et ExpressRoute (Azure) sont des liaisons privées dédiées via des fournisseurs/carriers. Elles utilisent aussi du routage (souvent BGP, Border Gateway Protocol — routage dynamique entre systèmes autonomes), mais n’empruntent pas l’Internet public. Important: « privé » ne signifie pas automatiquement « chiffré ». De nombreux designs prévoient toujours un chiffrement supplémentaire pour les données sensibles (par ex. IPsec sur la liaison privée ou TLS au niveau applicatif).

Qu’est-ce qui plaide au quotidien en faveur d’un Site-to-Site VPN?

• Disponibilité rapide: souvent réalisable en heures à jours, sans provisionnement par le fournisseur.
• Faible barrière d’entrée: adapté pour les premiers scénarios hybrides, pilotes, migrations temporaires.
• Flexible pour plusieurs sites: particulièrement si vous disposez déjà d’uplinks Internet et d’une passerelle Edge.

Limites typiques: latence/jitter variables, dépendance à la qualité de l’Internet, pièges liés à la MTU, ainsi que limites de performance sur les passerelles VPN. De plus, l’exploitation peut devenir confuse si de nombreux réseaux et exceptions de politique s’accumulent.

Qu’est-ce qui plaide au quotidien en faveur de Direct Connect/ExpressRoute?

• Latence plus stable et souvent un débit plus prévisible, parce que le chemin n’est pas en « Internet‑best‑effort ».
• Mise à l’échelle pour de nombreux réseaux/sites, en particulier si vous utilisez correctement BGP.
• Intégration opérationnelle: les fournisseurs fournissent souvent des SLA plus clairs et des états de liaison plus mesurables.

Limites typiques: délais de mise en place (provisionnement, Cross-Connects), coûts et dépendances accrues (fournisseur, Meet‑Me‑Room, capacités de port). De plus, la décision d’architecture est plus critique: un hub mal conçu peut rapidement devenir un Single Point of Failure.

Patterns d’architecture: Hub-and-Spoke, Transit et segmentation

Indépendamment du transport (VPN ou liaison dédiée), c’est l‘architecture réseau qui détermine si vous pouvez travailler de façon sûre et opérationnellement stable à long terme. Trois modèles sont fréquents en environnement entreprise:

1) Point à point (direct) — uniquement pour de petits périmètres

Un site se connecte directement à une VPC/VNET. C’est rapide, mais peu évolutif: chaque nouvelle VPC/VNET et chaque nouveau sous-réseau augmentent le nombre de tunnels, de routes et de règles de pare-feu. Le risque d’asymétrie (aller et retour différents) augmente.

2) Hub-and-Spoke — contrôle centralisé

Vous construisez un Hub (p. ex. une VPC/VNET réseau centrale) et y connectez des Spokes (VPCs/VNETs de charge de travail). Le hub héberge les services centraux: pare-feu, NAT, résolveur DNS, proxys, journalisation, éventuellement Bastion/Jump. Cela favorise la segmentation (séparation des zones) et facilite les audits, car les « points de contrôle » sont plus clairs.

3) Transit/Virtual WAN — le routage comme plateforme

Chez AWS il s’agit souvent d’un Transit Gateway (routeur/transit central pour de nombreuses VPC et des connexions On-Prem). Dans Azure, un pendant fréquent est le Virtual WAN (orchestration WAN, connectivité centrale via des hubs). Avantage : routage dynamique, connectiques standardisées, meilleure scalabilité. Inconvénient : vous devez concevoir les politiques de routage et de sécurité de manière très consciente, pour éviter que « tout parle avec tout ».

Bonne pratique pour les architectures sécurisées : segmentation avant connectivité. Définissez des zones (par ex. Management, Shared Services, Production, Partner, Dev/Test) et décidez quels flux sont autorisés. Ensuite, établissez les liaisons (VPN/Direct Connect/ExpressRoute) de façon à ce que la segmentation soit appliquée techniquement (Security Groups/NSGs, règles de pare‑feu, tables de routage).

Clarifier le routage : BGP, routes statiques et propagation des routes

De nombreuses pannes ressemblent à « VPN en panne », mais sont en réalité des problématiques de routage ou de politiques. Deux notions doivent figurer dans chaque runbook :

• Routes statiques : Next‑hops configurés de façon fixe. Simple, mais sujet aux erreurs lors de changements et en cas de redondance (le basculement doit être planifié activement).
• BGP : routage dynamique où des préfixes (réseaux) sont échangés. BGP permet de gérer bien mieux le basculement et la croissance, mais exige de la discipline (listes de préfixes, filtres, métriques/Local Preference, stratégies de communauté).

Dans les environnements cloud s’ajoute un troisième facteur : propagation des routes (redistribution des routes). Selon la plateforme, les routes peuvent ou non être injectées automatiquement dans les tables de routage. Piège typique : le tunnel est établi, BGP est « up », mais le sous‑réseau n’a pas de route vers la destination parce que la table de routage n’est pas propagée ou pas associée.

Pièges courants de routage (et pourquoi ils surviennent)

• Plages d’adresses IP qui se chevauchent : si l’On‑Prem et le cloud utilisent les mêmes réseaux RFC1918 (p.ex. 10.0.0.0/8 sans coordination), le routage devient peu fiable. Ce n’est pas un « problème cloud », mais une question de gestion des adresses. Solution : nettoyer le plan d’adressage, ou le cas échéant mettre en place une stratégie NAT avec règles de journalisation claires.
• Routage asymétrique : aller par le VPN, retour par Internet/NAT ou par une autre liaison. Beaucoup de pare‑feux/gateways VPN sont stateful et rejettent les paquets de retour si le flux ne revient pas par le même chemin.
• Route par défaut dans le tunnel sans planification : un « 0.0.0.0/0 vers le VPN » peut modifier complètement les breakouts Internet centraux et l’egress cloud. Cela conduit à des interruptions, pas seulement à « plus de sécurité ».
• Préfixes trop larges ou trop grand nombre de routes : les limites des plateformes (nb max. de routes dans les tables de routage, nb max. de préfixes par session BGP) sont souvent détectées tard. Résultat : routage partiel, « certains réseaux passent, d’autres pas ».

Bonnes pratiques de sécurité : chiffrement, politiques, journalisation et gestion des clés

« Se connecter en toute sécurité » signifie en exploitation : confidentialité, intégrité, traçabilité et propagation contrôlée. Pour les VPN et les liaisons dédiées, les domaines d’action sont similaires :

Chiffrement : qu’est‑ce qui est obligatoire, qu’est‑ce qui est pertinent ?

Avec IPsec VPN, le chiffrement fait partie intégrante. Il est important de choisir des paramètres adaptés à votre environnement (p. ex. IKEv2 plutôt que IKEv1, suites de chiffrement robustes) et d’assurer la compatibilité avec les Cloud-Gateways. Pour Direct Connect/ExpressRoute : le transport est privé, mais pas automatiquement chiffré de bout en bout. Beaucoup d’entreprises ajoutent donc généralement TLS (Transport Layer Security, chiffrement au niveau applicatif) ou même IPsec over private link — notamment pour les protocoles d’administration et les flux de données sensibles.

Politique : appliquer le « Least Privilege » au réseau

Le principe de Least-Privilege réseau signifie : seuls les ports/protocoles réellement nécessaires, uniquement entre les sous-réseaux/workloads requis. Dans le cloud, plusieurs niveaux interviennent : Security Groups/NSGs (proches des workloads), pare-feu centraux (p. ex. dans le hub) et routage (ce qui est effectivement accessible). Une approche éprouvée :

• Définir d’abord les flux sous forme de matrice de communication (source, destination, port, finalité, propriétaire).
• Ensuite, imposer la segmentation via les sous-réseaux et les tables de routage.
• Ce n’est qu’ensuite que l’on implémente les règles dans les Security Groups/NSGs et les pare-feu.

Cela évite le « pare-feu pansement », qui conduit à trop d’exceptions.

Logging et traçabilité : sans données, pas d’exploitation

Planifiez dès le départ où vous visualiserez les états de connexion et les flow-logs : état VPN (IKE/ESP), état BGP, drops sur les pare-feu, flow-logs dans les VPC/VNET ainsi qu’une intégration centrale Syslog/SIEM. Sont typiquement utiles des ID corrélables (Tunnel-ID, Peer-IP, BGP-Neighbor, Subnet/ENI/NIC) et une synchronisation temporelle (NTP), afin que les événements soient cohérents entre les systèmes.

Pratique : mettre en place correctement l’exploitation VPN (liste de contrôle)

Pour la catégorie VPN, l’essentiel est : stabilité en conditions perturbées, séquences de vérification claires et redondance propre. La liste de contrôle suivante est volontairement orientée exploitation.

Préparation

• Valider le plan IP : pas de chevauchements ; si inévitable, concevoir le NAT avec monitoring et documentation.
• Stratégie MTU : IPsec réduit la MTU effective (overhead). Prévoyez du MSS-clamping ou une MTU de tunnel adaptée (selon la plateforme). Sans cela, vous rencontrerez des problèmes « étranges » sur certains protocoles.
• Redondance : au moins deux tunnels (ou deux fournisseurs/edges). Définissez ce que signifient « Active/Active » et « Active/Standby », et comment mesurer le basculement.
• IKEv2 et profils crypto : choisissez des paramètres modernes et compatibles. Vérifiez les durées (rekey) et le DPD (Dead Peer Detection, disponibilité du pair).
• Définir le routage : statique (petit) ou BGP (évolutif). Pour BGP : définir des filtres de préfixes et une protection max-prefix.

Mise en œuvre : contrôles minimaux pour la mise en service

Quand le tunnel est « en place », ce n’est que le début. Vérifiez dans cet ordre :

1. IKE/ESP-Status : Y a-t-il une Security Association active ? Y a-t-il des erreurs de rekey ?
2. Routen : Le réseau cible est-il accessible et la route pointe-t-elle réellement vers le tunnel/le transit ?
3. Security/Firewall : Les flux sont-ils autorisés ou rejetés ?
4. Path MTU : Les paquets de plus grande taille fonctionnent-ils ? Sinon, constatez-vous de la fragmentation/des pertes.
5. DNS : Souvent, « le réseau ne fonctionne pas » est en réalité un problème de DNS/Split-DNS.

Quick-Checks vom Linux-Host (Cloud oder On-Prem)

Les commandes suivantes aident à classer les symptômes. Elles ne remplacent pas le débogage de la passerelle, mais sont rapidement disponibles en cas d’incident.

# Routing zum Ziel prüfen
ip route get 10.20.30.40

# Pfad-MTU testen (Don't Fragment). Schrittweise Payload erhöhen.
# Achtung: je nach Umgebung ist ICMP gefiltert; dann ist das Ergebnis begrenzt.
ping -M do -s 1372 -c 3 10.20.30.40
ping -M do -s 1400 -c 3 10.20.30.40

# Traceroute mit TCP (falls ICMP blockiert ist) auf einen Zielport
traceroute -T -p 443 10.20.30.40

# Pakete mitschneiden (Interface anpassen), um SYN/SYN-ACK bzw. ICMP-Frag-needed zu sehen
sudo tcpdump -ni any host 10.20.30.40

Pourquoi cela aide : si ip route get ne pointe pas vers le saut suivant attendu, ne cherchez pas dans le VPN. Si ping -M do échoue au-delà d’une certaine taille, MTU/MSS est un candidat plausible. Et tcpdump montre rapidement si des paquets quittent le système, si des réponses reviennent ou si des messages d’erreur ICMP apparaissent.

Dépannage : modèles d’erreur fréquents et mesures ciblées

En exploitation, reconnaître les scénarios d’erreur a une grande valeur. Voici les modèles typiques pour la connectivité hybride.

Fehlerbild 1: Tunnel ist „UP“, aber kein Traffic geht durch

• Ursachen : association à la table de routage manquante, propagation de routes désactivée, Security Group/NSG bloquant, pare-feu On-Prem bloquant le chemin de retour, selectors/traffic-selectors incorrects (pour VPN basés sur des policies), asymétrie.
• Prüfen : route vers la cible (Cloud et On-Prem), ports autorisés, Flow Logs/Drops, chemin de retour (Reverse Path).
• Fix : corriger les routes, activer la propagation (ou configurer statiquement de manière consciente), restreindre la policy, vérifier les règles du pare-feu stateful.

Fehlerbild 2: „Manche Anwendungen gehen, manche hängen“

• Ursachen : problèmes MTU/MSS, PMTUD (Path MTU Discovery) échoue, la fragmentation est rejetée, les protocoles à base d’UDP sont sensibles au jitter.
• Prüfen : tests PMTU, tcpdump pour ICMP « fragmentation needed », comparaison de petites/grandes charges utiles.
• Fix : MSS-Clamping sur l’edge/pare-feu, ajuster le MTU du tunnel, gérer proprement l’ICMP (ne pas le bloquer aveuglément).

Fehlerbild 3: Verbindungsabbrüche alle X Minuten

Symptôme 4 : BGP est up, mais des routes manquent ou oscillent

• Causes: filtres de préfixes trop stricts/trop permissifs, déclenchement de la limite Max-Prefix, liaison underlay instable, timers incorrects, préférences ambiguës entre plusieurs chemins.
• Vérifier: routes annoncées/reçues, logs liés au Max-Prefix, stabilité de la liaison underlay, cohérence des communities/LocalPref.
• Correction: corriger les filtres, définir consciemment les limites, stabiliser l’underlay, documenter et standardiser la routing-policy.

Utiliser correctement une liaison dédiée: Direct Connect/ExpressRoute en pratique

Les liaisons dédiées résolvent de nombreux problèmes liés à « Internet », mais elles introduisent de nouvelles responsabilités. Trois points sont souvent sous-estimés dans les projets :

1) La redondance n’est pas un « nice to have »

Un port unique ou une seule liaison fournisseur représente un risque opérationnel. Prévoyez au minimum deux chemins indépendants (idéalement des PoPs/Meet-Me-Rooms et des fournisseurs distincts). Définissez des critères de bascule : Link down, BGP down, seuils de perte de paquets/latence. Et testez la bascule non seulement au moment du go-live, mais régulièrement pendant les fenêtres de maintenance.

2) Une liaison privée ne remplace pas les contrôles de sécurité

La connectivité « privée » réduit la surface d’attaque (pas d’Internet public comme transport), mais le risque interne subsiste : erreurs de configuration, mouvements latéraux, exposition accidentelle. La segmentation, la journalisation et le contrôle d’accès restent obligatoires. Pour les accès administratifs, il est souvent préférable de passer par une bastion/jump et une identité forte (MFA, Conditional Access) plutôt que « RDP/SSH partout ».

3) La discipline de routage détermine la stabilité

Avec ExpressRoute/Direct Connect, le nombre de préfixes augmente souvent rapidement. Sans listes de filtres claires et sans ownership (qui est autorisé à annoncer quels réseaux ?), on arrive progressivement à une situation où une modification sur un site a des effets imprévisibles. Bonne pratique : propriété des préfixes documenter, passer les changements via un processus de changement, et configurer les Max-Prefix-Limits de façon à ce que les erreurs de configuration ne perturbent pas l’ensemble du routage.

Stratégie de migration et de repli : planifier pour dormir tranquille la nuit

Une stratégie de repli claire n’est pas un document annexe, mais fait partie du design. Pour la connectivité hybride, les principes suivants se sont avérés efficaces :

Exploitation parallèle plutôt que Big Bang

Dans la mesure du possible, déployez VPN et liaison dédiée en parallèle. Utilisez des priorités de routage (p.ex. BGP-Pref, métriques) pour basculer progressivement. Avantage : vous pouvez mesurer sous charge réelle (latence, drops, taux d’erreur) et revenir rapidement en cas de problème.

Étapes de cutover explicites avec points de mesure

Définissez pour le cutover une checklist : accessibilité des services centraux (DNS, Identity, Monitoring), workflows métier critiques, fenêtres de sauvegarde, accès administratifs. Important : un critère d’arrêt : à partir de quel symptôme interrompez-vous et revenez-vous en arrière ?

Rollback non seulement « possible », mais exercé

Les rollback échouent souvent parce que, sous stress, quelqu’un modifie « vite fait » les routes et policies, et au final personne ne sait quel était le dernier état stable. Pratiquement, ceci aide :

• Versionner les configurations (y compris pour les équipements réseau/objets de routage cloud).
• Effectuer les modifications en petites unités réversibles.
• Consigner des mesures avant/après (latence, perte de paquets, comptage de flux, taux d’erreur).

Runbook: standard opérationnel pour une connectivité hybride sécurisée

Un bon Runbook empêche que chaque incident parte de zéro. Ces contenus se sont révélés utiles aux équipes d’administration :

1) Contrôles de santé standardisés

• État des tunnels (IKE/ESP), événements de rekey, état DPD
• État du voisin BGP (up/down), nombre de routes reçues/annoncées
• CPU/débit de la passerelle, pertes/erreurs
• Logs de flux/paquets rejetés par le pare-feu pour des flux de test définis

2) Flux de test définis (synthétiques)

Choisissez par zone un à deux points de terminaison et ports à tester régulièrement (p. ex. HTTPS vers l’endpoint de monitoring, DNS vers le résolveur, SSH vers la bastion). Ainsi, vous détectez tôt les erreurs de routage/de politique, avant l’arrivée de tickets utilisateurs.

3) Points d’escalade clairs

Qui est responsable de : plan d’adressage IP, Cloud-Routing, pare-feu sur site, liaison opérateur, DNS ? Sans cette attribution, chaque incident devient une question organisationnelle.

Conclusion : quelle option convient quand ?

Le VPN est, au quotidien, le bon choix si vous devez démarrer rapidement, si l’ampleur est maîtrisable et si vous avez bien sous contrôle les pièges typiques (routage, MTU, rekey, redondance). Direct Connect/ExpressRoute est pertinent lorsque la stabilité et l’échelle sont prioritaires, lorsque de nombreux réseaux/sites doivent être interconnectés ou lorsque les charges de travail sont sensibles aux fluctuations de l’Internet. Dans les deux cas, ce n’est pas l’étiquette produit qui décide, mais votre architecture : segmentation, discipline de routage, supervision et un plan de recours éprouvé.

Si vous planifiez votre connexion hybride ou devez stabiliser une configuration existante, l’étape suivante n’est généralement pas « plus de bande passante », mais une matrice de communication propre, une conception claire transit/hub et un Runbook avec des vérifications mesurables.