Comment fonctionne un VPN, du datagramme au serveur

La plupart des pages consacrées aux VPN s'arrêtent aux principes : « le VPN chiffre votre connexion », « il masque votre adresse IP ». C'est exact, mais insuffisant pour comprendre ce qui distingue un service d'un autre, où se situent les limites, et pourquoi certains arguments commerciaux — « chiffrement de grade militaire », « anonymat total » — ne veulent pas dire grand-chose. Pour une entrée en matière plus accessible, un guide comme celui de l'expert en VPN couvre d'abord les cas d'usage courants ; la présente page, elle, décrit le fonctionnement réel d'un VPN, du paquet IP jusqu'au serveur, et renvoie vers six analyses techniques qui approfondissent chaque couche.

Le niveau est délibérément technique : réseau, cryptographie, comportement des clients, infrastructure serveur. Un lecteur qui aborde le sujet depuis un contexte régional précis — par exemple depuis le Brésil, où la latence transcontinentale et le choix des points de sortie dominent les autres critères —, gagnera à croiser ces mécanismes avec un guide local comme le VPN Brasil, puis à revenir ici pour le détail des couches sous-jacentes.

Un VPN est une interface réseau virtuelle

Quand un client VPN démarre, il crée sur le système une interface réseau virtuelle — tun0 sous Linux, un adaptateur WinTUN ou TAP sous Windows, utun sous macOS. Le système d'exploitation la traite comme n'importe quelle carte réseau : il lui attribue une adresse, et il peut y router tout ou partie du trafic. Chaque paquet IP émis par une application et destiné à Internet est alors capté par cette interface plutôt que par la carte physique.

Le client prend ce paquet IP entier, le chiffre, et le place comme charge utile dans un nouveau datagramme — le plus souvent en UDP — adressé au serveur VPN sur sa carte physique. Le serveur reçoit ce datagramme, l'authentifie, le déchiffre, en extrait le paquet IP d'origine et le réémet vers sa destination sous sa propre adresse IP publique. La réponse revient au serveur, qui la chiffre et la renvoie au client, où elle ressort de l'interface virtuelle comme si elle était arrivée directement. C'est ce double emballage — un paquet dans un paquet — qu'on appelle un tunnel.

L'établissement du tunnel, étape par étape

Avant le premier paquet chiffré, plusieurs choses se produisent. Le client résout le nom du serveur en adresse IP — une opération qui doit se faire hors du tunnel, puisque le tunnel n'existe pas encore, ce qui est déjà un point d'exposition. Il ouvre ensuite un échange avec le serveur pour prouver mutuellement son identité et dériver un secret partagé : par clés publiques avec WireGuard, par certificats avec OpenVPN ou IKEv2. De ce secret sont dérivées les clés de session qui chiffreront le trafic.

Le client installe alors les routes : il ajoute une route précise vers l'adresse du serveur via la passerelle physique — pour que les paquets du tunnel eux-mêmes ne bouclent pas dans le tunnel — puis redirige le reste du trafic vers l'interface virtuelle. Il ajuste la MTU, force éventuellement le DNS vers un résolveur du fournisseur, et arme l'interrupteur d'arrêt. Ce n'est qu'ensuite que les applications commencent à émettre à travers le tunnel. Chacune de ces étapes est un endroit où une configuration défaillante crée une fuite, ce qu'examine la page fuites et interrupteur d'arrêt.

La couche où le VPN agit

Un VPN complet opère à la couche réseau, celle du protocole IP. Il transporte donc l'ensemble du trafic de la machine : navigateur, client de messagerie, mises à jour du système, applications en arrière-plan. C'est la différence de fond avec un proxy, qui agit à la couche applicative et ne relaie que le trafic des logiciels explicitement configurés pour l'utiliser.

Ce que le tunnel protège : le contenu et la destination de vos connexions vis-à-vis du réseau local et du fournisseur d'accès, et votre adresse IP publique vis-à-vis des sites visités. Ce qu'il ne protège pas : les métadonnées vis-à-vis du fournisseur du VPN lui-même, qui voit désormais tout ce que voyait votre fournisseur d'accès ; l'empreinte du navigateur et la connexion à des comptes nominatifs, qui vous identifient indépendamment de l'adresse IP ; et les requêtes de résolution de noms si le client les laisse sortir hors du tunnel, un problème détaillé sur la page fuites DNS, IPv6 et WebRTC.

L'encapsulation a un coût : la MTU

Emballer un paquet dans un autre ajoute des octets d'en-tête : en-tête IP et UDP externes, en-tête du protocole VPN, étiquette d'authentification du chiffrement. Selon le protocole, cette surcharge va d'une soixantaine d'octets à un peu plus de quatre-vingts. Or la taille maximale d'un paquet sur un lien Ethernet est de 1500 octets. Si le paquet d'origine fait déjà 1500 octets, le paquet encapsulé dépasse cette limite et doit être fragmenté, ce qui dégrade les performances et provoque des blocages difficiles à diagnostiquer.

Les clients VPN traitent ce problème en abaissant la MTU de l'interface virtuelle et en pratiquant le « MSS clamping » : ils réécrivent la taille de segment annoncée lors de l'établissement des connexions pour que les paquets restent en dessous du seuil, tunnel compris. Un client mal réglé sur ce point donne des symptômes typiques : les petites pages se chargent, les gros transferts et certains sites en HTTPS se bloquent. Le détail par protocole figure sur la page WireGuard, OpenVPN, IKEv2.

Le choix du protocole

Trois protocoles se partagent l'essentiel des usages. WireGuard est récent, tient en quelques milliers de lignes de code, utilise un jeu d'algorithmes figé une fois pour toutes et ne fonctionne qu'en UDP ; il gère nativement le changement de réseau. OpenVPN est plus ancien, très configurable, négocie ses algorithmes, et fonctionne en UDP comme en TCP — ce dernier mode étant utile pour traverser un réseau restrictif, au prix de performances moindres. IKEv2/IPsec est intégré à la plupart des systèmes et se comporte bien sur mobile, notamment lors des bascules entre Wi-Fi et données cellulaires.

Le transport compte autant que le protocole : encapsuler du TCP dans du TCP crée un effet d'emballement des retransmissions qui peut effondrer le débit sur une liaison instable. Quand c'est possible, l'UDP est préférable. La comparaison complète — handshake, roaming, empreinte de code, résistance au filtrage, débit mesuré — est développée sur la page protocoles VPN comparés.

Ce que le chiffrement garantit, et ce qu'il ne garantit pas

Un tunnel moderne repose sur un chiffrement authentifié — ChaCha20-Poly1305 ou AES-GCM — qui assure à la fois la confidentialité et l'intégrité : un paquet modifié en transit est rejeté. L'échange de clés initial utilise une courbe elliptique (Curve25519) et procure une confidentialité persistante : les clés de session sont renouvelées régulièrement, de sorte que la compromission d'une clé ne permet pas de déchiffrer le trafic passé.

« Chiffrement AES-256 de grade militaire » est, dans ce contexte, un argument creux : AES-256 est un standard public utilisé partout, et sa robustesse n'est pas le maillon faible d'un VPN. Ce qui fait la différence, c'est la qualité de l'implémentation, la gestion des clés, l'absence de repli silencieux vers un algorithme affaibli, et la vérification de l'identité du serveur. Ces points sont examinés sur la page la cryptographie d'un tunnel VPN.

Les fuites : quand le tunnel laisse passer

Un client peut router correctement le trafic dans le tunnel tout en laissant échapper des informations par trois voies. Les requêtes DNS, si elles partent vers le résolveur du fournisseur d'accès, révèlent les noms de domaine consultés. Le trafic IPv6, si le client ne le prend pas en charge, sort avec l'adresse IPv6 réelle pendant que l'IPv4 est masquée. Et le navigateur, via le mécanisme WebRTC, peut divulguer l'adresse locale et parfois l'adresse publique. L'interrupteur d'arrêt, qui bloque tout le trafic si le tunnel tombe, est la contre-mesure de dernier recours. Tout ceci est traité sur la page fuites et interrupteur d'arrêt.

Routage : tout le trafic, ou une partie

Par défaut, un VPN établit un tunnel complet : toutes les routes de la machine pointent vers l'interface virtuelle. Certaines configurations préfèrent un tunnel divisé, qui n'y envoie que certaines applications ou certaines destinations. Les mécanismes diffèrent selon le protocole — l'astuce des routes 0.0.0.0/1 et 128.0.0.0/1 avec OpenVPN, les règles de politique de routage et le marquage de paquets avec WireGuard, le champ AllowedIPs. La page routage d'un client VPN en fait le tour.

Quand le tunnel lui-même est bloqué

Dans les réseaux qui filtrent activement, l'inspection profonde des paquets identifie un tunnel VPN à la signature de son établissement, à la taille et au rythme de ses paquets, ou par sondage actif du serveur. Les contre-mesures consistent à faire ressembler le trafic VPN à un autre trafic : encapsulation dans une session TLS, dans du HTTPS ou du WebSocket, transports pluggables comme obfs4, protocoles dérivés de Shadowsocks. La page obfuscation et résistance au blocage décrit cette course.

Côté serveur

Le comportement d'un VPN dépend autant de l'infrastructure du fournisseur que du client. Le réseau du fournisseur — ses systèmes autonomes, ses accords de transit et de peering — détermine la latence et le débit réels, souvent davantage que la distance géographique. Les adresses IP partagées entre de nombreux abonnés diluent le trafic et compliquent l'attribution, à l'inverse d'une adresse dédiée. Les serveurs qui démarrent sans disque, en mémoire vive, ne livrent rien lors d'une saisie de matériel. Et un audit indépendant, quand il porte sur l'infrastructure et pas seulement sur une politique affichée, est le seul moyen de sortir du régime de la parole donnée. La page architecture serveur d'un fournisseur détaille ces points.

Ce qu'un VPN ne remplace pas

Un VPN est une brique réseau, pas une suite de sécurité. Il ne protège pas contre un logiciel malveillant déjà présent, contre l'hameçonnage, ni contre l'exploitation d'une faille d'un système non mis à jour. Il déplace la confiance depuis le fournisseur d'accès vers le fournisseur du VPN, ce qui n'a d'intérêt que si ce dernier est plus digne de confiance — question qui se juge sur la juridiction, le modèle économique et l'audit, pas sur le slogan.