Foxency
Sécurité Informatique et Réseaux

VPN : fonctionnement et choix d'une solution

Un VPN crée un tunnel chiffré entre deux sites ou entre un utilisateur et le réseau de l'entreprise. IPsec, WireGuard, OpenVPN, VPN SSL : comment ils fonctionnent et comment choisir.

Par Rédaction Foxency Publié le 6 min de lecture

Tunnel VPN chiffré reliant deux sites d'entreprise à travers Internet

Un VPN (Virtual Private Network) établit un tunnel chiffré au travers d'un réseau non maîtrisé, généralement Internet. Il garantit la confidentialité et l'intégrité des échanges, et authentifie les extrémités. Deux usages dominent : relier des sites entre eux, et permettre l'accès distant des utilisateurs nomades.

Objectif : comprendre le fonctionnement des principales technologies VPN, leurs différences et les critères de choix, ainsi que les bonnes pratiques de sécurité.

Deux grands cas d'usage

VPN site à site

Deux passerelles (pare-feu ou routeurs) établissent un tunnel permanent. Les postes des deux sites communiquent comme sur un réseau privé, sans logiciel particulier.

Tunnel VPN site à site entre deux réseaux
Tunnel VPN site à site entre deux réseaux

VPN d'accès distant

Un client logiciel sur le poste de l'utilisateur établit un tunnel vers une passerelle de l'entreprise. L'utilisateur s'authentifie, idéalement avec un second facteur.

Deux modes de routage :

  • Tunnel complet (full tunnel) : tout le trafic du poste passe par l'entreprise, ce qui permet d'appliquer les mêmes filtres qu'au bureau.
  • Tunnel partagé (split tunnel) : seul le trafic destiné aux réseaux internes passe par le tunnel ; le reste sort directement. Moins de charge, mais moins de contrôle.

IPsec et IKEv2

IPsec est une suite de protocoles normalisés par l'IETF qui sécurise IP au niveau de la couche réseau.

  • IKE (Internet Key Exchange, version 2 décrite par la RFC 7296) négocie les algorithmes, authentifie les pairs et établit les clés. Il utilise UDP 500, et UDP 4500 lorsqu'un NAT est détecté (NAT-T).
  • ESP (Encapsulating Security Payload, protocole IP 50, RFC 4303) chiffre et authentifie les paquets.
  • AH (Authentication Header) authentifie sans chiffrer ; il est incompatible avec le NAT et peu utilisé.

Deux modes :

  • mode tunnel : le paquet IP d'origine est entièrement encapsulé dans un nouveau paquet ; c'est le mode des VPN site à site ;
  • mode transport : seule la charge utile est protégée ; utilisé entre deux hôtes.

Authentification des pairs : par clé pré-partagée (simple, mais à réserver aux petits déploiements avec des clés longues et aléatoires) ou par certificats (recommandé à l'échelle).

Points forts : standard, interopérable entre constructeurs, très présent sur les pare-feu et dans le cloud. Points faibles : configuration complexe, nombreux paramètres à aligner entre les deux extrémités.

WireGuard

WireGuard est un protocole VPN moderne, conçu pour la simplicité. Intégré au noyau Linux depuis la version 5.6, il est disponible sur la plupart des plateformes.

  • Cryptographie fixe et moderne (Curve25519, ChaCha20-Poly1305, BLAKE2s) : pas de négociation d'algorithmes, donc pas de configuration faible possible.
  • Code compact, plus facile à auditer.
  • UDP uniquement, port configurable (51820 par convention).
  • Authentification par paires de clés publiques, à la manière de SSH.
# /etc/wireguard/wg0.conf — passerelle (exemple de laboratoire)
[Interface]
Address = 10.99.0.1/24
ListenPort = 51820
PrivateKey = <cle-privee-passerelle>

[Peer]
# Poste nomade d'un administrateur
PublicKey = <cle-publique-poste>
AllowedIPs = 10.99.0.10/32

wg genkey | tee prive.key | wg pubkey > public.key
sudo wg-quick up wg0
sudo wg show

Le paramètre AllowedIPs joue un double rôle : il définit les adresses autorisées en provenance du pair et les routes vers ce pair (cryptokey routing).

Limites : WireGuard ne gère pas nativement l'authentification des utilisateurs (annuaire, MFA) ni l'attribution dynamique d'adresses ; des solutions construites au-dessus apportent ces fonctions.

OpenVPN

OpenVPN s'appuie sur TLS pour l'établissement des clés et peut fonctionner sur UDP ou TCP, sur n'importe quel port, y compris 443/TCP pour traverser des réseaux restrictifs.

  • Très configurable, mature, multiplateforme.
  • Authentification par certificats, éventuellement combinée à un identifiant et un second facteur.
  • Performances inférieures à WireGuard dans de nombreux scénarios, surtout en TCP où la superposition de deux mécanismes de retransmission (TCP over TCP) dégrade le débit en cas de pertes.

VPN SSL / TLS des pare-feu

Les pare-feu du marché proposent des VPN d'accès distant basés sur TLS, souvent avec un portail web et un client propriétaire. Ils s'intègrent à l'annuaire et aux politiques du pare-feu.

Point de vigilance majeur : les passerelles VPN exposées sur Internet sont des cibles prioritaires. Plusieurs vulnérabilités critiques touchant des produits VPN de grands constructeurs ont été massivement exploitées ces dernières années. Appliquez les correctifs sans délai et suivez les alertes des autorités (CERT-FR en France) et de votre constructeur.

Comparatif

Critère IPsec/IKEv2 WireGuard OpenVPN VPN SSL constructeur
Normalisation IETF Protocole ouvert, non IETF Projet libre Propriétaire
Interopérabilité Excellente Bonne (implémentations multiples) Bonne Limitée au constructeur
Complexité Élevée Faible Moyenne Faible à moyenne
Transport UDP 500/4500, ESP UDP UDP ou TCP TCP 443 (souvent UDP en option)
Authentification utilisateur Via EAP Hors protocole Certificats + identifiants Intégrée (annuaire, MFA)
Usage typique Site à site, cloud Site à site, accès distant, maillage Accès distant Accès distant d'entreprise

Critères de choix

  1. Le cas d'usage : site à site avec du matériel hétérogène → IPsec ; accès distant intégré au pare-feu existant → VPN du constructeur ; infrastructure Linux ou besoins de performance → WireGuard.
  2. L'interopérabilité avec les équipements et le cloud (les passerelles VPN des fournisseurs cloud utilisent IPsec/IKEv2).
  3. L'authentification : intégration à l'annuaire, MFA, certificats machine.
  4. L'exploitation : compétences de l'équipe, supervision, journalisation.
  5. La sécurité du produit : historique de vulnérabilités, réactivité du constructeur.

Bonnes pratiques de sécurité

  • Authentification multifacteur pour tout accès distant utilisateur.
  • Algorithmes robustes : IKEv2 plutôt qu'IKEv1 ; AES-GCM, SHA-2, groupes Diffie-Hellman forts ; aucune suite obsolète (DES, 3DES, MD5, SHA-1, groupes DH 1, 2 ou 5).
  • Correctifs rapides sur les passerelles.
  • Filtrage après le tunnel : un utilisateur VPN n'a pas besoin d'accéder à tout le réseau ; appliquez des règles par profil.
  • Journalisation des connexions et alertes sur les comportements anormaux.
  • Révocation immédiate des accès lors d'un départ ou de la perte d'un appareil.
  • Prise en compte de la MTU : l'encapsulation réduit la taille utile des paquets. Voir MTU, MSS et fragmentation des paquets.

Erreurs courantes

  • Clé pré-partagée courte ou réutilisée entre plusieurs tunnels.
  • Paramètres de phase 1/phase 2 non alignés, cause principale des tunnels IPsec qui ne montent pas.
  • Accès VPN donnant accès à l'ensemble du réseau interne.
  • Passerelle VPN non corrigée.
  • Oublier le MSS clamping et subir des connexions qui se figent.

Conclusion

Le choix d'un VPN dépend du cas d'usage, de l'interopérabilité requise et de la capacité d'exploitation. Quelle que soit la technologie, la sécurité repose sur des algorithmes robustes, une authentification forte, des correctifs appliqués et un filtrage strict après le tunnel. Pour aller au-delà du modèle « VPN = accès au réseau interne », découvrez Zero Trust : principes et mise en œuvre progressive.

Références