Réseau privé virtuel (VPN) : architecture, modèle et fonctionnement
Cette page détaille l’architecture réseau et le fonctionnement d’un VPN : overlay, encapsulation IP, positionnement dans le modèle OSI, et différences entre les modèles Remote-Access et Site-to-Site.
Un réseau privé virtuel encapsule du trafic IP au sein d’un tunnel chiffré pour le transporter sur une infrastructure non-fiable, en pratique, Internet public. L’objectif n’est pas l’anonymat, mais la confidentialité du contenu transporté (pas des métadonnées de connexion), la modification du point de sortie réseau, et le déplacement de la surface de confiance : au lieu d’exposer directement vos communications à votre fournisseur d’accès, vous déléguez la visibilité à une passerelle VPN distante.
Il existe deux modèles distincts de réseau privé virtuel :
Remote-Access VPN : un terminal client s’attache à une passerelle distante (modèle grand public),
Site-to-Site VPN : deux réseaux privés interconnectés par un tunnel permanent (LAN ↔ LAN), sans intervention utilisateur.
Ces configurations poursuivent des objectifs différents, avec des intégrations réseau et des postures de sécurité distinctes.
Dans le modèle OSI, un VPN commercial opère généralement en couche 3 (interface TUN, encapsulation IP-dans-UDP), ou plus rarement en couche 2 (interface TAP, pont Ethernet). Le VPN n’agit pas dans la couche applicative, même si l’utilisateur perçoit le changement à ce niveau (services accessibles, géolocalisation).
Les modifications essentielles se situent dans :
- la négociation cryptographique et la génération de clé,
- l’encapsulation des paquets,
- le routage,
- la translation d’adresse côté serveur.
Pour situer le VPN parmi d’autres mécanismes :
→ Différences entre Tor, un proxy et un VPN
I. Définition formelle et positionnement
Définition
Un VPN est un overlay chiffré établi au-dessus d’un réseau IP non fiable, garantissant la confidentialité, l’intégrité et l’authentification du transport via encapsulation cryptographique (AEAD).
L’élément clé : le transport sous-jacent n’est pas fiable (Internet, Wi-Fi, réseau d’entreprise). Le VPN ajoute un réseau logique virtuel sans modifier le réseau physique.
- Endpoint client : terminal créant l’interface virtuelle,
- Passerelle VPN : serveur publiant l’accès au tunnel,
- Tunnel : canal chiffré, transporté via UDP ou TCP,
- Encapsulation : transformation du paquet original,
- Négociation cryptographique : établissement du secret partagé, renouvellement des clés (PFS).
- Tunnel : canal chiffré,
- Interface TUN/TAP : périphérique réseau virtuel,
- Endpoint : extrémité du tunnel,
- Overlay : réseau virtuel sur réseau existant.
Deux modèles distincts
- client ↔ passerelle distante,
- modification de la table de routage locale,
- transport chiffré entre endpoint et serveur,
- l’adresse IP publique vue par les services est celle de la passerelle.
Modèle grand public.
- deux réseaux privés reliés par un tunnel,
- aucun terminal individuel n’établit la connexion,
- l’ensemble d’un LAN accède à l’autre LAN,
- implémenté typiquement via IPsec/IKEv2.
Usages typiques : interconnexion entre sites d’entreprise, extension de LAN, topologies hybrides Cloud ↔ on-premise.
Ces approches ne se substituent pas : elles répondent à des architectures de sécurité différentes.
Interface IP point-à-point logique
→ transporte des paquets IP.
Interface Ethernet virtuelle
→ transporte des trames Ethernet complètes.
TAP est utilisé pour : bridging, broadcast, support de protocoles non-IP.
Les services grand public utilisent quasi-exclusivement TUN (transport IP sécurisé, pas virtualisation LAN).
Diagramme 1 — Topologie du tunnel
[Client device]
|
(Plaintext)
|
[VPN client] ← Handshake (ECDH), encapsulation (AEAD)
|
(Encrypted tunnel - UDP/TCP)
|
[Internet] ← Le FAI voit : flux chiffré (UDP/TCP selon protocole)
|
[VPN server] ← Décryptage, NAT
|
(Plaintext)
|
[Destination website]
Diagramme 2 — Position dans la stack OSI
Application (7) ← HTTP, DNS
Transport (4) ← TCP/UDP (application)
Network (3) ← IP packet ← ENCAPSULÉ ICI (TUN)
|
v
[VPN tunnel]
|
v
Transport (4) ← UDP/TCP (transport du tunnel)
Network (3) ← IP (tunnel externe)
Data Link (2) ← Ethernet
Physical (1)
Diagramme 3 — Encapsulation
Avant VPN :
[Eth | IP | TCP | HTTP payload]
Après VPN (IP-dans-UDP) :
[Eth | IP(tunnel) | UDP | [IP | TCP | HTTP] chiffré + tag AEAD]
↑________________________________↑
payload chiffré + authentification AEAD
→ Protocoles VPN
Architecture réseau
Interface virtuelle
À la connexion, le système crée une interface réseau virtuelle (ex. tun0 sous Linux, utun sous macOS) avec sa propre adresse IP virtuelle.
Effet architectural :
- injection de routes vers l’interface VPN,
- contournement de la passerelle locale par défaut.
Encapsulation et impacts techniques
L’encapsulation place un paquet IP existant à l’intérieur d’un autre paquet, chiffré par AEAD (AES-GCM, ChaCha20-Poly1305).
MTU et fragmentation
- MTU Ethernet standard : 1500 bytes
- Overhead VPN : variable selon protocole (WireGuard ~60-80 bytes, OpenVPN ~40-60 bytes)
- MTU effectif typique : 1420-1440 bytes selon protocole
→ risque de fragmentation, perte de performance.
Latence
Chiffrement/déchiffrement CPU-intensif.
Ajout typique : quelques ms à plusieurs dizaines selon algorithme, support matériel (AES-NI) et chemin réseau.
TCP-over-TCP
VPN en TCP + application en TCP → double retransmission, head-of-line blocking.
→ dégradation critique en environnement lossy (forte latence + perte de paquets).
Privilégier UDP.
Routage
À l’établissement du tunnel :
- Full tunnel : tout le trafic passe par le tunnel,
- Split tunnel : seules certaines routes passent par le tunnel.
Mal configuré, le split tunnel crée des fuites.
→ Fuite DNS sous VPN
Translation d’adresse
Au niveau de la passerelle, le trafic client est masqué derrière l’adresse IP du serveur via translation d’adresse source (SNAT ou masquerading iptables).
IP client → IP passerelle VPN → destination
Les services distants voient l’IP de la passerelle, pas celle du client.
Cette dissociation n’est pas un anonymat complet : elle découple l’adresse IP du terminal, sans supprimer les identités applicatives.
Surface de confiance et limites
Déplacement de la confiance
Un VPN ne supprime pas la confiance : il la déplace.
Sans VPN :
Client → FAI → Internet
Le FAI voit : DNS, endpoints, volumes, métadonnées.
Avec VPN :
Client → Tunnel → Passerelle VPN → Internet
La passerelle voit : connexions sortantes, structure du trafic (hors chiffrement applicatif).
Pourquoi faire confiance à un provider VPN plutôt qu’au FAI ?
- juridiction / obligations légales,
- politique de logs (contrat, audits),
- modèle économique (abonnement vs exploitation de données).
Techniquement, la visibilité est similaire. La différence est juridique et contractuelle, pas technique.
Utiliser un VPN signifie choisir à qui on fait confiance, pas l’éliminer.
Cette décision doit reposer sur des critères vérifiables.
Limites structurelles
Tracking applicatif
Le VPN change l’adresse IP, pas l’identité applicative (cookies, tokens, sessions, comptes loggés).
Browser fingerprinting
Le VPN ne modifie pas les paramètres collectables : User-Agent, canvas, WebGL, fonts, résolution, langue, timezone, plugins, hardware concurrency, battery API, audio context.
Votre empreinte reste unique.
Solution : Tor Browser (résistance intégrée).
Corrélation temporelle et volumétrique
Un adversaire observant client ET serveur peut corréler timing, volume, patterns.
Requiert un accès simultané aux deux extrémités — typiquement un État-nation, ou un FAI combiné à une compromission du provider ou de son infrastructure (notamment si hébergement cloud avec peering direct).
Surveillance étatique ciblée
Un État-nation peut contraindre le provider (juridiction), infiltrer l’infrastructure (hyperviseur), corréler trafic (timing attacks).
Si un service de renseignement vous cible, un VPN commercial ne suffit pas.
Ces limites concernent les couches supérieures : HTTP, identités numériques, sécurité du terminal.
Threat models réalistes
Protections structurelles
- réseaux non fiables (Wi-Fi public, hotspots) : protection contre interception locale,
- confidentialité face au FAI : flux chiffré, pas de visibilité sur les sites,
- contournement de blocages DNS/IP.
Les censures utilisant DPI (Deep Packet Inspection) ou active probing nécessitent des protocoles résistants (obfsproxy, Shadowsocks) ou des transports camouflés.
Non-protections
Le VPN ne fournit pas :
- d’anonymat distribué (Tor),
- de protection contre un adversaire observant les deux extrémités,
- de suppression des identités applicatives,
- de protection contre l’exploitation du terminal.
Le VPN intervient dans la couche transport, pas dans la sécurité globale.
Conclusion
Un VPN est une solution d’ingénierie pour confidentialiser le transport, pas un mécanisme d’anonymisation ou d’effacement des identités numériques. L’outil est utile lorsqu’il répond à un threat model concret (réseau non-fiable, surveillance du FAI, filtrage DNS/IP), et inadapté lorsqu’on lui demande ce qu’il n’a pas été conçu pour fournir (anonymat distribué, résistance au fingerprinting, protection contre un adversaire observant les deux extrémités).
Le VPN déplace la surface de confiance : du FAI vers le provider. Ce choix doit reposer sur des critères vérifiables (PFS, audits, reproductibilité, infrastructure, juridiction).
Pour l’anonymisation et la résistance aux corrélations temporelles, le modèle adapté n’est pas le VPN mais Tor (anonymisation distribuée). Pour la médiation applicative (caching, filtrage, identité protocolaire), le mécanisme pertinent est le proxy.