Relier deux réseaux, ou un poste nomade à un réseau d’entreprise, admet plusieurs réponses selon ce que l’on privilégie : la facilité de déploiement, la performance garantie, ou la confidentialité. Ce sont trois logiques différentes — VPN, MPLS, connectivité cloud privée — qu’il faut savoir distinguer avant de les combiner.
VPN SSL/TLS
Le VPN TLS (OpenVPN et consorts) répond avant tout à un besoin de simplicité : accès nomade ou BYOD, déploiement léger via client lourd ou navigateur. Le client lourd force classiquement tout le trafic dans le tunnel, sauf configuration explicite en split-tunnel.
flowchart LR A[Client nomade] -->|TLS| B[Serveur VPN TLS] B -->|Tunnel sécurisé| C[Intranet / SaaS]
OpenVPN, open-source et très audité, reste néanmoins exigeant à configurer correctement. Le choix du transport n’est pas neutre : UDP privilégie la performance, TCP la fiabilité — mais tunneler du TCP dans du TCP expose au TCP-over-TCP meltdown, où les mécanismes de retransmission des deux couches se contrarient mutuellement.
Limite conceptuelle
Le VPN protège le lien, pas les extrémités. Un poste compromis reste une fuite, quelle que soit la qualité du tunnel.
Les bonnes pratiques à retenir : privilégier le Perfect Forward Secrecy (PFS), des chiffrements AEAD (AES-GCM, ChaCha20), et ajuster la MSS pour éviter la fragmentation induite par l’overhead du tunnel. Pour du télétravail massif, on combine typiquement TLS-VPN et split-tunnel pour le SaaS (M365, CDN), avec inspection déportée côté NG-SWG.
VPN IPSec
IPSec (Internet Protocol Security) opère en couche 3 (réseau) pour assurer confidentialité, intégrité et authentification.
Négocier la connexion
Le protocole IKE négocie la connexion ; une association de sécurité est établie soit manuellement, soit via ISAKMP — sur UDP, port 500. IKEv2 structure cette négociation en deux phases : la phase 1 (IKE_SA) établit identité, algorithmes et clés ; la phase 2 (CHILD_SA) définit les sélecteurs (sous-réseaux concernés) et le SPI ESP.
Transférer les données
IPSec offre deux protocoles de sécurité : ESP (Encapsulating Security Payload), qui chiffre et authentifie, et AH (Authentication Header), plus rare, qui garantit l’intégrité sans chiffrement. AH protège les données par un algorithme d’authentification ; ESP protège par chiffrement, avec authentification optionnelle.
Deux modes
Le mode tunnel chiffre y compris l’en-tête IP d’origine — c’est la référence pour l’interconnexion site à site. Le mode transport ne chiffre que la charge utile.
NOTE
Avec AH, traverser un NAT devient impossible : modifier l’adresse IP invaliderait le hash d’authentification. D’où le mécanisme NAT-T (NAT Traversal), qui encapsule ESP dans de l’UDP (port 4500) pour contourner ce blocage — au prix d’une vigilance accrue sur la MTU, l’overhead ESP réduisant la charge utile disponible.
Cas d’usage
En accès nomade, IPSec reste moins flexible que TLS. En interconnexion site à site, en revanche, il fait référence — IKEv2, AES-GCM, PFS :
flowchart LR subgraph "Site A" A1[LAN A] --> GW1[Passerelle IPSec] end subgraph "Site B" A2[LAN B] --> GW2[Passerelle IPSec] end GW1 <-->|ESP tunnel IKEv2| GW2
Pour deux sites interconnectés avec sous-réseaux privés, on retiendra le mode tunnel avec sélecteurs réseau explicites, un test de rekey IKEv2, et une validation de la découverte de MTU de chemin (PMTUD).
MPLS
Le MPLS (MultiProtocol Label Switching) est un mécanisme de transport fondé sur la commutation de labels (label switching), indépendant des protocoles et données transportés. Il bénéficie d’une QoS avancée, garantie contractuellement par le SLA de l’opérateur, et s’appuie sur des chemins déterministes et des liaisons physiques dédiées.
Il supporte nativement le multicast, opère entre les couches 2 et 3 — donc sur tout réseau IP — et offre des paramètres de routage optimaux, faute de recherche et d’analyse à chaque saut.
flowchart TD A[Site A] -->|Label MPLS| CORE[Réseau MPLS] CORE -->|Label MPLS| B[Site B] A -->|Internet| C[Best effort] C --> B
MPLS contre VPN
| Chiffrement | Coût | Priorisation | |
|---|---|---|---|
| VPN | Oui | Faible | Non natif |
| MPLS | Non natif | Élevé | Possible |
Le MPLS ne chiffre rien nativement — il faut y ajouter IPSec ou MACsec si la confidentialité est requise. La comparaison ne porte donc pas sur les mêmes plans : le VPN répond à un besoin de confidentialité, le MPLS à un besoin de qualité de service garantie.
Connexions privées vers le cloud
AWS DirectConnect, Azure ExpressRoute, GCP Interconnect (ou l’équivalent OVH ConnectDirect) ne sont pas des VPN au sens du chiffrement applicatif : ils isolent le trafic et garantissent débit et latence, sans chiffrer par défaut. Si la confidentialité est requise, on y ajoute IPSec.
Chez AWS, DirectConnect combiné à IPSec via un Transit Gateway réduit les coûts par rapport à une passerelle client par tunnel, et peut être redondé en mode dégradé par IPSec. Chez GCP, MACsec est disponible côté Interconnect ; chez AWS, il reste optionnel et non universellement disponible. Chez Azure, ExpressRoute opère en couche 3 via l’opérateur (MPLS, L2 point-à-point, ou échange Internet), avec BGP, SLA et redondance intégrée.
flowchart LR subgraph OnPrem["Data Center"] VR[Routeur/TGW] end subgraph Cloud["PoP opérateur → Cloud"] EDGE[Peering/Port ER/DC/IC] VNET[VPC/VNET] end VR ==BGP==> EDGE VR -."IPSec (option)".-> VNET
Synthèse comparative
Comparer VPN/IPSec, MPLS et une connexion cloud privée revient à arbitrer entre chiffrement, QoS/SLA, coût et latence : le VPN chiffre nativement mais sans garantie de performance ; le MPLS garantit la performance sans chiffrer ; la connexion cloud privée garantit débit et latence, moyennant l’ajout d’IPSec ou de MACsec si la confidentialité est exigée. Aucune de ces trois briques n’est un substitut universel des deux autres — elles se combinent selon le besoin réel.