Tunnels VPN et cryptage des canaux

Résumé succinct

Un VPN (Virtual Private Network) est un ensemble de technologies qui permettent de créer un canal sécurisé sur un réseau dangereux (généralement Internet). Objectifs clés : confidentialité (cryptage), intégrité (authentification des messages), authenticité (authentification mutuelle des nœuds/utilisateurs) et disponibilité (résistance aux pannes et aux blocages). Dans l'infrastructure d'entreprise, le VPN ferme les scripts site-to-site, l'accès à distance, la connectivité inter-cloud et le service-k-service (machine-to-machine). La pratique moderne consiste à minimiser les réseaux L3 « plats » et à appliquer la segmentation, le principe du moindre privilège et la transition progressive vers Zero Trust.

Notions de base

Tunnel - encapsulation de paquets d'un protocole dans un autre (par exemple, IP à l'intérieur de l'UDP), ce qui permet de « transporter » un plan d'adresse privé et des politiques via un réseau public.
Cryptage - Protection du contenu du trafic (AES-GCM, ChaCha20-Poly1305).
Authentification - Confirmation de l'authenticité des nœuds/utilisateurs (certificats X.509, PSK, clés SSH).
Intégrité - protection contre la substitution (HMAC, AEAD).
PFS (Perfect Forward Secret) : Les clés de session ne sont pas extraites à long terme ; compromettre la clé à long terme ne révèle pas les sessions passées.

Scénarios types

1. Site à site (L3) : Bureau ↔ centre de données/nuage ; généralement un routeur IPsec/IKEv2, statique ou dynamique.
2. Accès à distance (User-to-Site) : employés des ordinateurs portables/mobiles ; OpenVPN/WireGuard/IKEv2, MFA, split/full-tunnel.
3. Hub-and-Spoke : toutes les branches vers le hub central (on-bou ou Cloud Transit).
4. Mesh : Réseau complet de succursales/microdatacents (routage dynamique + IPsec).
5. Cloud-to-Cloud : canaux inter-cloud (tunnels IPsec, Cloud VPN/Transit Gateway, SD-WAN).
6. Service-to-Service : connexions machine entre clusters/neimspays (WireGuard, IPsec dans CNI/SD-WAN, mTLS au niveau du service).

Protocoles VPN et où ils sont forts

IPsec (ESP/IKEv2) - « standard d'or » Site-to-Site

Couches : IKEv2 (échange de clés), ESP (chiffrement/authentification du trafic).
Modes : tunnel (habituellement), transport (rarement, hôte-hôte).
Avantages : Offloades matérielles, maturité, interopérabilité, idéal pour les autoroutes et les passerelles cloud.
Inconvénients : complexité du réglage, sensibilité au NAT (le NAT-T/UDP-4500 est décidé), plus de « rituels » lors de l'harmonisation des politiques.
Utilisation : succursales, centres de données, cloud, hautes exigences de performance.

OpenVPN (TLS 1. 2/1. 3)

Couches : L4/L7, trafic sur UDP/TCP ; souvent un schéma de type DTLS par UDP.
Avantages : Flexible, le NAT et le DPI se déroulent bien tout en savant masquer (tcp/443), un écosystème riche.
Inconvénients : frais généraux plus élevés que ceux d'IPsec/WireGuard ; Il faut une crypto-configuration soignée.
Utilisation : accès à distance, environnements mixtes lorsque la « perforation » du réseau est importante.

WireGuard (NoiseIK)

Couches : L3 sur UDP ; base de code minimaliste, cryptomonnaies modernes (Curve25519, ChaCha20-Poly1305).
Avantages : performances élevées (en particulier sur les mobiles/ARM), simplicité des fligs, itinérance rapide.
Inconvénients : pas de PKI intégré ; la gestion des clés/identités nécessite des processus autour.
Utilisation : accès à distance, connectivité interclaster, S2S dans une pile moderne, DevOps.

tunnels SSH (L7)

Типы: Local/Remote/Dynamic (SOCKS).
Avantages : outil de « poche » pour l'accès ponctuel/l'administration.
Inconvénients : ne pas évoluer comme un VPN corporatif, la gestion des clés et l'audit est plus difficile.
Utilisation : accès ponctuel aux services, « périscope » dans un réseau fermé, jump-host.

GRE/L2TP/… (encapsulation sans chiffrement)

But : Crée un tunnel de L2/L3, mais ne chiffre pas. Généralement combiné avec IPsec (L2TP over IPsec/GRE over IPsec).
Utilisation : rares cas où vous avez besoin de la nature L2 du canal (anciens protocoles/VLAN isolés sur L3).

Cryptographie et paramètres

Codes : AES-GCM-128/256 (accélération matérielle, AES-NI), ChaCha20-Poly1305 (mobile/sans AES-NI).
KEH/groupes : ECDH (Curve25519, secp256r1), groupes DH ≥ 2048 ; Activez PFS.
Signatures/ICP : ECDSA/Ed25519 de préférence ; automatiser la sortie/rotation, utiliser OCSP/CRL.
Durée de vie des clés : IKE SA/Child SA, rekey régulier (par exemple, 8-24 h, trafic/heure).
MFA : pour les VPN personnalisés - TOTP/WebAuthn/Push.

Performances et fiabilité

MTU/MSS : réglage correct du PMTU (habituellement 1380-1420 pour les tunnels UDP) ; MSS-clamp sur les nœuds frontaliers.
DPD/MOBIKE/Keepalive : détection rapide des « tombés », itinérance ininterrompue (IKEv2 MOBIKE, WireGuard PersistentKeepalive).
Routage : ECMP/Multipath, BGP au-dessus des tunnels pour la dynamique.
Offload : crypto-accélérateurs matériels, SmartNIC/DPU, noyau Linux (xfrm, WireGuard kernel).
Percée des blocages : changement de ports/transports, obstruction de la poignée de main (où légalement acceptable).
QoS : classification et priorité du trafic, contrôle du jitter pour les flux temps réel.

Topologies et design

Full-tunnel vs Split-tunnel:

Full : tout le trafic via VPN (contrôle/sécurité plus élevé, charge plus importante).
Split : uniquement les sous-réseaux dont vous avez besoin (économies, moins de retards, exigences accrues pour la protection des canaux de contournement).
Segmentation : tunnels individuels/VRF/politiques pour les environnements (Prod/Stage), domaines de données (PII/financial), fournisseurs.
Cloud : Cloud VPN/Transit Gateways (AWS/GCP/Azure), IPsec S2S, routage par transit centralisé.
SD-WAN/SASE : overlays avec sélection automatique du canal, télémétrie intégrée et politiques de sécurité.

Sécurité du canal et de l'environnement

Firewall/ACL : allow-lists explicites par port/sous-réseau, deny par défaut.
Sécurité DNS : forcer le DNS d'entreprise via le tunnel, protection contre les fuites (IPv6, WebRTC).
Stratégies client : kill-switch (bloc de trafic en cas de chute de tunnel), interdiction de split-DNS en cas d'exigence de complement.
Logs et audit : centraliser les journaux des poignées de main, authentification, rekey refusés par SA.
Secrets : KMS HSM/vendeurs, rotation, minimisation PSK (de préférence certificats ou clés WG).
Périphériques : vérification de conformité (OS, patchs, cryptage sur disque, EDR), NAC/MDM.

Observabilité, SLO/SLA et alerting

Mesures clés :

Disponibilité du tunnel (% aptyme).
Latency, jitter, packet loss le long des itinéraires clés.
Bande passante (p95/p99), CPU/IRQ de crypto-nœuds.
Taux d'événements rekey/DPD, échecs d'authentification.
Erreurs de fragmentation/PMTU.

Exemples de SLO :

"Disponibilité du centre VPN ≥ 99. 95 % par mois"
"p95 retards entre DC-A et DC-B ≤ 35 ms'.
«< 0. 1 % d'IKE SA échouant par heure".

Alarma :

Tunnel Down> X secondes ; l'éclatement du DPD ; l'augmentation des erreurs de handshake ; Dégradation p95> seuil ; Erreurs CRL/OCSP.

Opérations et cycle de vie

PKI/certificats : Sortie/mise à jour automatique, TTL courts, révocation immédiate en cas de compromission.
Rotation des clés : régulière, avec une conversion progressive des paires.
Modifications : changements de plans avec retour en arrière (ancien/nouveau SA en parallèle), fenêtres de service.
Break-glass : comptes de rechange/clés documentés par accès manuel via jump-host.
Incidents : en cas de suspicion de compromission - révocation de certificats, rotation PSK, force-rekey, changement de ports/adresses, audit de logs.

Conformité et aspects juridiques

GDPR/PII : cryptage en transit obligatoire, minimisation de l'accès, segmentation.
PCI DSS : chiffrement fort, MFA, journaux d'accès, segmentation de la zone cardholder.
Restrictions locales du trafic/cryptomonnaies : respecter les exigences des juridictions (exportation de crypto, DPI, blocages).
Journaux : stockage conformément à la politique (rétentions, intégrité, accès).

Zero Trust, SDP/ZTNA vs VPN classique

VPN classique : distribue un accès réseau (souvent large).
ZTNA/SDP : donne accès à une application/service spécifique après vérification contextuelle (identité, état de l'appareil, risque).
Modèle hybride : laisser un VPN pour les autoroutes/S2S, et pour les utilisateurs - une tuile ZTNA aux applications appropriées ; enlever progressivement les sets « plats ».

Comment choisir un protocole (matrice courte)

Entre branches/nuages : IPsec/IKEv2.
Accès à distance aux utilisateurs : WireGuard (si vous avez besoin d'un client facile et rapide) ou OpenVPN/IKEv2 (si vous avez besoin d'un PKI/politique mature).
Haute « perforation » par proxy/DPI : OpenVPN-TCP/443 (avec conscience des lettres de voiture) ou obfuscation (si autorisé).
Mobile/itinérance : WireGuard ou IKEv2 MOBIKE.
L2 au-dessus de L3 : GRE/L2TP avec IPsec (cryptage obligatoire).

Chèque d'implémentation

1. Définir les domaines d'accès (Prod/Stage/Back-office) et le principe des privilèges minimums.
2. Sélectionner le protocole/topologie (hub-and-spoke vs mesh), planifier l'adressage et le routage.
3. Approuver le cryptophile (AES-GCM/ChaCha20, ECDH, PFS, bref TTL).
4. Configurer l'ICP, l'ACM, la politique de calendrier et de rétroaction.
5. Configurer MTU/MSS, DPD/MOBIKE, keepalive.
6. Inclure le journal, les dashboards, les métriques SLO et les alertes.
7. Effectuer des tests de charge/feilover (chute du hub, rekey-burst, changement de link).
8. Documenter le break-glass et la procédure de rotation.
9. Organiser la formation des utilisateurs (clients, politiques).
10. Examiner régulièrement les accès et les rapports d'audit.

Erreurs fréquentes et comment les éviter

L2TP/GRE sans IPsec : pas de chiffrement → ajoutez toujours IPsec.
MTU incorrect : fragmentation/drop → configurer MSS-clamp, vérifier PMTU.
PSK « pour toujours » : clés obsolètes → rotation, passage aux certificats/ED25519.
Réseaux étendus dans split-tunnel : fuites de trafic → routes/politiques claires, DNS uniquement via VPN.
Un seul « super-hub » sans réservation : SPOF → actif, ECMP, plusieurs régions.
Pas de surveillance des poignées de main : chutes « muettes » → DPD/alarms/pas cher.

Exemples de configurations

WireGuard (Linux) — `wg0. conf`

ini
[Interface]
Address = 10. 20. 0. 1/24
PrivateKey = <server_private_key>
ListenPort = 51820

Client 1
[Peer]
PublicKey = <client1_public_key>
AllowedIPs = 10. 20. 0. 10/32
PersistentKeepalive = 25

Client :

ini
[Interface]
Address = 10. 20. 0. 10/32
PrivateKey = <client_private_key>
DNS = 10. 20. 0. 2

[Peer]
PublicKey = <server_public_key>
Endpoint = vpn. example. com:51820
AllowedIPs = 10. 20. 0. 0/24, 10. 10. 0. 0/16
PersistentKeepalive = 25

strongSwan (IPsec/IKEv2) — `ipsec. conf`

conf config setup uniqueids=never

conn s2s keyexchange=ikev2 ike=aes256gcm16-prfsha384-ecp256!
esp=aes256gcm16-ecp256!
left=%any leftid=@siteA leftsubnet=10. 1. 0. 0/16 right=vpn. remote. example rightsubnet=10. 2. 0. 0/16 dpdaction=restart dpddelay=30s rekey=yes auto=start

`ipsec. secrets`:

conf
: RSA siteA. key

OpenVPN (UDP, TLS 1. 3) — `server. conf`

conf port 1194 proto udp dev tun tls-version-min 1. 3 cipher AES-256-GCM data-ciphers AES-256-GCM:CHACHA20-POLY1305 auth SHA256 user nobody group nogroup topology subnet server 10. 30. 0. 0 255. 255. 255. 0 push "redirect-gateway def1"
push "dhcp-option DNS 10. 30. 0. 2"
keepalive 10 60 persist-key persist-tun verb 3

Pratique pour les plates-formes iGaming/fintech

Segmentation : tunnels distincts pour les intégrations de paiement, back-office, fournisseurs de contenu, antifrood ; isoler les domaines PII/paiement.
Politiques d'accès strictes : machine-to-machine pour des ports/sous-réseaux spécifiques (liste d'accès par PSP, régulateurs).
Observabilité : p95 Time-to-Wallet peut se dégrader en raison d'incidents VPN - surveiller la connectivité aux PSP/banques critiques.
Conformité : stockez les logs d'accès et d'authentification, implémentez les MFA, les pentestes de canal réguliers.

FAQ

Est-il possible de faire du full-mesh entre toutes les branches ?
Seulement s'il y a automatisation et routage dynamique ; sinon, la complexité augmente. Souvent plus rentable que hub-and-spoke + exceptions locales.

Dois-je crypter le trafic « interne » entre les nuages ?
Oui, oui. Les backends publics et les autoroutes interrégionales nécessitent IPsec/WireGuard et des ACL strictes.

Quoi de plus rapide - AES-GCM ou ChaCha20-Poly1305 ?
Sur x86 avec AES-NI - AES-GCM ; sur les ARM/mobiles, les ChaCha20-Poly1305 gagnent souvent.

Quand passer à ZTNA ?
Lorsque l'accès réseau via VPN est devenu « large » et que les applications peuvent être publiées ponctuellement avec l'authentification contextuelle et la vérification des appareils.

Résultat

Une architecture VPN robuste n'est pas seulement un « protocole et un port ». C'est un cryptoprofile avec PFS, une segmentation réfléchie, une observabilité avec SLO rigide, une discipline PKI/rotations et une transition gérée vers ZTNA où l'accès réseau est redondant. En suivant la checklist et la matrice de sélection ci-dessus, vous construirez une connectivité durable et gérable pour les systèmes distribués modernes.