Glossaire VPN auto-hébergé : 34 termes expliqués (WireGuard, Headscale, DERP, NAT traversal…)

Quand on se lance dans le VPN auto-hébergé, on tombe rapidement sur des termes que les guides utilisent sans les définir : AllowedIPs, DERP, NAT traversal, MTU, PersistentKeepalive, obfuscation DPI… Ce glossaire rassemble les 34 définitions indispensables, organisées par thème, rédigées pour être comprises en 30 secondes et directement citables.

Il complète les guides techniques du site : pour les configurations concrètes, voir le guide WireGuard vs OpenVPN, le comparatif Tailscale vs Headscale et le guide kill switch Linux.

Table des matières

• Protocoles et core VPN
• Réseau mesh et control plane
• NAT, relais et connectivité
• Chiffrement et cryptographie
• Routage et configuration
• Obfuscation et contournement DPI
• Fuites et sécurité opérationnelle
• Fonctionnalités clés

Protocoles et core VPN

WireGuard

WireGuard est un protocole VPN moderne implémenté dans le noyau Linux (kernel-space). Avec moins de 4 000 lignes de code source (contre 400 000 pour OpenVPN), il minimise la surface d'attaque et offre des performances proches du débit brut du lien. Il utilise ChaCha20-Poly1305 pour le chiffrement, Curve25519 pour l'échange de clés et BLAKE2s pour l'authentification des messages. Standard recommandé pour le self-host en 2026.

OpenVPN

OpenVPN est le protocole VPN open source de référence depuis 2001. Contrairement à WireGuard, il tourne en espace utilisateur (userspace), ce qui le rend plus portable mais plus lent. Il supporte TCP et UDP, configure facilement le port 443 en TCP pour contourner les firewalls DPI, et accepte des suites cryptographiques variées (AES-256-GCM par défaut). Toujours pertinent pour les environnements qui bloquent UDP ou nécessitent une audit trail compliance.

IPsec / IKEv2

IPsec est un ensemble de protocoles réseau de chiffrement opérant au niveau IP (couche 3). IKEv2 est le protocole d'échange de clés utilisé avec IPsec — natif sur iOS et macOS, très stable lors des changements de réseau (Wi-Fi ↔ 4G/5G). Moins performant que WireGuard en débit brut, mais nativement intégré aux OS mobiles Apple sans dépendance applicative. Souvent utilisé dans les setups VPN entreprise sur routeur.

Tunnel VPN (full tunnel vs split tunnel)

Un tunnel VPN est un canal chiffré entre deux points. En mode full tunnel (AllowedIPs 0.0.0.0/0), tout le trafic IP transite par le VPN — y compris le trafic vers Internet. En mode split tunnel (AllowedIPs restreint), seule une partie du trafic passe par le tunnel, le reste sortant directement. Le split tunnel réduit la charge sur le serveur VPN et améliore la latence des connexions locales.

Réseau mesh et control plane

Mesh network (réseau maillé)

Un réseau mesh est une topologie réseau où chaque nœud peut communiquer directement avec tous les autres, sans nœud central obligatoire. Dans le contexte VPN, cela signifie que chaque appareil connecté au mesh peut atteindre directement les autres — contrairement à une topologie hub-and-spoke où tout passe par un serveur central. Tailscale et Headscale créent automatiquement un mesh WireGuard entre tous les appareils enregistrés.

Tailscale

Tailscale est un réseau mesh VPN basé sur WireGuard, géré en SaaS. Il automatise l'échange de clés, le NAT traversal, les ACLs et le DNS via son control plane hébergé aux États-Unis. Gratuit jusqu'à 100 appareils pour usage personnel. Le data plane (trafic entre appareils) est chiffré de bout en bout avec WireGuard — Tailscale Inc. ne voit pas le contenu. Le control plane (qui orchestre les connexions) reste sous leur contrôle.

Headscale

Headscale est une implémentation open source du control plane de Tailscale, auto-hébergeable sur n'importe quel VPS Linux. Il est compatible avec les clients officiels Tailscale sur tous les OS. Il offre la même UX (MagicDNS, ACLs, exit nodes) mais sans dépendance aux serveurs de Tailscale Inc. Le control plane tourne sur ton propre VPS — voir le guide Headscale pour le déploiement complet.

Control plane vs data plane

Le control plane est le cerveau du VPN : il orchestre l'enregistrement des appareils, l'échange de clés publiques, les ACLs et la distribution des configurations. Dans Tailscale, c'est le service SaaS de Tailscale Inc. ; dans Headscale, c'est ton propre VPS. Le data plane est le flux réel de données chiffrées entre les appareils — il utilise WireGuard directement, indépendamment du control plane. Même si le control plane est compromis, le trafic data plane reste chiffré.

MagicDNS

MagicDNS est la fonctionnalité DNS automatique de Tailscale et Headscale qui assigne un nom de domaine stable à chaque appareil du mesh (machine.tailnet.ts.net). Sans MagicDNS, il faudrait retenir les adresses IP statiques de chaque appareil (ex. 100.64.0.x). MagicDNS évite de maintenir un fichier /etc/hosts ou un serveur DNS interne et simplifie les scripts d'automatisation.

Exit node

Un exit node est un appareil du mesh Tailscale (ou Headscale) configuré pour router tout le trafic Internet des autres appareils — comme un VPN classique. Quand tu actives l'exit node sur un appareil, tout ton trafic sortant transite par lui avant d'atteindre Internet. Utile pour donner une IP fixe à une machine distante ou chiffrer le trafic depuis un Wi-Fi public, en utilisant un VPS comme exit node. Guide : exit node Tailscale.

NAT, relais et connectivité

NAT (Network Address Translation)

Le NAT est le mécanisme par lequel un routeur traduit les adresses IP privées (192.168.x.x, 10.x.x.x) en une adresse publique pour le trafic sortant, et fait l'inverse pour le trafic entrant. La quasi-totalité des connexions résidentielles et mobiles sont derrière un NAT, ce qui rend les connexions entrantes directes impossibles sans configuration manuelle (port forwarding). C'est le problème central que le NAT traversal cherche à résoudre.

NAT traversal (hole punching)

Le NAT traversal est l'ensemble des techniques permettant à deux machines derrière des NAT séparés de s'atteindre directement en UDP, sans port forwarding. La technique principale (hole punching) consiste à ce que les deux pairs envoient simultanément des paquets UDP l'un vers l'autre — les deux NAT ouvrent alors une entrée dans leur table de connexion, permettant le trafic bidirectionnel. Tailscale utilise STUN/ICE pour orchestrer ce processus.

DERP (Designated Encrypted Relay for Packets)

DERP est le réseau de relais TCP de Tailscale activé quand le NAT traversal direct échoue (NAT symétrique, port UDP bloqué). Le trafic transite alors par un serveur DERP, mais reste chiffré de bout en bout avec WireGuard — le serveur ne voit que des paquets chiffrés. DERP est plus lent qu'une connexion directe mais garantit la connectivité dans tous les contextes réseau. Headscale peut utiliser les serveurs DERP de Tailscale ou déployer les siens.

Port forwarding

Le port forwarding (ou redirection de port) consiste à configurer un routeur ou un pare-feu pour transmettre les connexions entrantes sur un port spécifique vers une machine interne. Pour un VPN WireGuard auto-hébergé sur un VPS, c'est en général inutile (le VPS a une IP publique directe). En revanche, pour un serveur WireGuard chez soi (derrière un NAT FAI), le port forwarding UDP sur le port WireGuard (51820 par défaut) est nécessaire.

Endpoint

Dans WireGuard, un endpoint est l'adresse IP publique et le port UDP d'un pair : 203.0.113.42:51820. WireGuard mémorise le dernier endpoint connu de chaque pair et met à jour automatiquement cette information si l'IP change (réseau mobile, IP dynamique). L'endpoint n'est pas fixe côté client (il peut être 0.0.0.0:0 si le client n'a pas d'IP fixe), mais le serveur doit avoir un endpoint stable ou un nom de domaine.

Handshake

Le handshake WireGuard est l'échange cryptographique initial qui établit une session chiffrée entre deux pairs. Il utilise Curve25519 (échange de clés Diffie-Hellman) et dure moins d'une milliseconde. WireGuard renouvelle automatiquement le handshake toutes les 3 minutes pour assurer la perfect forward secrecy — chaque session a sa propre clé éphémère. Si aucun trafic n'est échangé pendant 3 minutes, un nouveau handshake est déclenché avant le prochain paquet.

PersistentKeepalive

PersistentKeepalive est un paramètre WireGuard qui envoie un paquet UDP vide à intervalle régulier (en secondes) pour maintenir ouverte l'entrée NAT entre le client et le serveur. Valeur recommandée : 25 secondes (inférieure aux timeouts NAT standard de 30 secondes). Sans keepalive, un client derrière un NAT perd sa session après quelques minutes d'inactivité et doit relancer un handshake. Essentiel pour les clients mobiles.

Chiffrement et cryptographie

Curve25519

Curve25519 est la courbe elliptique utilisée par WireGuard pour l'échange de clés Diffie-Hellman (ECDH). Elle offre un niveau de sécurité équivalent à RSA-3072 avec des clés de seulement 32 octets, ce qui accélère le handshake et réduit la consommation mémoire. Conçue pour résister aux timing attacks. Chaque pair WireGuard génère une paire de clés Curve25519 : clé privée (32 octets, secrète) et clé publique (32 octets, échangée avec les pairs).

ChaCha20-Poly1305

ChaCha20-Poly1305 est la suite AEAD (Authenticated Encryption with Associated Data) utilisée par WireGuard pour chiffrer et authentifier les paquets. ChaCha20 est le chiffrement par flux ; Poly1305 est le MAC qui garantit l'intégrité. Cette suite est particulièrement rapide sur les processeurs sans accélération AES-NI (ARM des Raspberry Pi, MIPS des routeurs) et résiste aux timing attacks structurellement.

BLAKE2s

BLAKE2s est la fonction de hachage cryptographique utilisée par WireGuard pour l'authentification des messages et la dérivation de clés de session. Variante de BLAKE2 optimisée pour les processeurs 32 bits et embarqués. Plus rapide que SHA-256 sur ces architectures tout en maintenant des propriétés de sécurité équivalentes. Utilisé dans le protocole de handshake WireGuard pour mixer les clés éphémères et les données de session.

Perfect forward secrecy (PFS)

La confidentialité persistante garantit que la compromission d'une clé de session ne permet pas de déchiffrer les sessions passées ou futures. WireGuard l'implémente nativement : à chaque handshake (toutes les 3 minutes), de nouvelles clés éphémères Curve25519 sont générées et détruites après usage. Même si un attaquant enregistre du trafic chiffré et compromise ensuite la clé privée statique d'un pair, il ne peut pas retrouver les sessions antérieures.

Clé publique / clé privée WireGuard

WireGuard utilise une cryptographie asymétrique pour l'authentification. La clé privée (32 octets, format base64) ne quitte jamais l'appareil et signe les handshakes. La clé publique est dérivée de la clé privée et partagée avec les pairs — c'est l'identifiant d'un pair dans WireGuard. Chaque pair dans une config WireGuard est identifié par sa clé publique dans la section [Peer]. La commande wg genkey | tee private.key | wg pubkey > public.key génère une paire.

Routage et configuration

AllowedIPs

AllowedIPs est le paramètre de configuration le plus important de WireGuard côté pair. Il définit simultanément les routes envoyées dans le tunnel (tout paquet destiné à ces plages passe par ce pair) et la liste blanche des IPs sources acceptées depuis ce pair. 0.0.0.0/0, ::/0 = full tunnel (tout le trafic). 10.0.0.0/24 = seul ce sous-réseau. Les AllowedIPs d'un pair côté serveur définissent quelle IP interne est allouée à ce client.

MTU (Maximum Transmission Unit)

Le MTU est la taille maximale d'un paquet réseau en octets. Pour WireGuard sur Ethernet (MTU 1500), le MTU du tunnel doit être réduit de 60 octets pour l'overhead WireGuard/UDP/IP : recommandation standard de 1420 octets. Un MTU mal configuré provoque de la fragmentation silencieuse ou des connections qui "accrochent" sur certains sites (notamment TLS). À ajuster dans la section [Interface] de la config WireGuard. Tester avec ping -M do -s 1400 8.8.8.8.

DNS leak (fuite DNS)

Une fuite DNS survient quand les requêtes DNS (résolution de noms de domaine) sortent hors du tunnel VPN et passent par le résolveur du FAI ou de l'OS. Résultat : le FAI voit quels domaines tu visites malgré le VPN actif. Dans WireGuard, configurer DNS = 1.1.1.1 dans la section [Interface] force toutes les requêtes DNS dans le tunnel. Guide complet de prévention : DNS leak WireGuard.

PostUp / PostDown

PostUp et PostDown sont des hooks de configuration WireGuard qui exécutent des commandes shell au démarrage et à l'arrêt de l'interface. Utilisés pour configurer des règles iptables (NAT masquerade, kill switch), activer le forwarding IP (sysctl net.ipv4.ip_forward=1), ou lancer des scripts de monitoring. La commande PostUp s'exécute après wg-quick up ; PostDown après wg-quick down. Indispensable pour le masquerading et le kill switch systemd.

wg-quick

wg-quick est l'outil de configuration haut niveau livré avec WireGuard qui simplifie la gestion des interfaces. Il lit les fichiers .conf de /etc/wireguard/, crée l'interface réseau, configure les routes, le DNS et exécute les hooks PostUp/PostDown. Commandes principales : wg-quick up wg0, wg-quick down wg0. Il crée automatiquement les routes pour les AllowedIPs et gère le routage par défaut en full tunnel. Différent de wg (la commande bas niveau).

Obfuscation et contournement DPI

DPI (Deep Packet Inspection)

Le DPI est une technique d'analyse réseau qui examine le contenu des paquets (pas seulement les en-têtes) pour identifier les protocoles, filtrer du trafic ou détecter des VPN. Les firewalls d'entreprise, les gouvernements (Great Firewall chinois) et certains FAI utilisent le DPI pour bloquer WireGuard ou OpenVPN. WireGuard est détectable par DPI car il a une signature UDP distinctive. L'obfuscation vise à déguiser ce trafic en HTTPS normal.

Obfuscation

L'obfuscation VPN déguise le trafic chiffré pour qu'il ressemble à du trafic HTTPS ordinaire, rendant sa détection difficile par DPI. Techniques courantes : wstunnel (tunnel WireGuard dans WebSocket sur port 443), Cloak (plugin obfsproxy for OpenVPN), Shadowsocks (proxy SOCKS5 chiffré), V2Ray VMess/VLESS. L'obfuscation est nécessaire dans les réseaux avec DPI agressif (Chine, Iran, réseaux corporate). Guide : anti-DPI bypass 2026.

wstunnel

wstunnel est un outil qui encapsule du trafic UDP (notamment WireGuard) dans une connexion WebSocket sur port 443 (HTTPS). Côté client, wstunnel écoute sur un port UDP local et transmet vers le serveur wstunnel distant via WebSocket. Côté serveur, wstunnel décapsule et transmet au port WireGuard local. Résultat : tout ressemble à du trafic HTTPS depuis l'extérieur. Guide détaillé : wstunnel TCP over WebSocket.

Shadowsocks

Shadowsocks est un protocole proxy SOCKS5 chiffré conçu initialement pour contourner le Great Firewall chinois. Il chiffre le trafic avec AES-256-GCM ou ChaCha20-Poly1305 et le déguise en trafic HTTPS. Différent d'un VPN : Shadowsocks est un proxy applicatif, pas un tunnel réseau complet. Peut être combiné avec WireGuard (Shadowsocks comme transport) pour un double niveau d'obfuscation. Voir Shadowsocks vs VPN.

V2Ray / VMess / VLESS

V2Ray est un framework multi-protocole de proxy et de tunneling. VMess est son protocole propriétaire (authentification, chiffrement, camouflage HTTPS) ; VLESS est sa version allégée sans chiffrement embarqué (délègue au TLS). Tous deux supportent des transports multiples (WebSocket, gRPC, HTTP/2) pour contourner le DPI. V2Ray est plus complexe à configurer que WireGuard ou Shadowsocks mais offre les meilleures capacités de camouflage dans des environnements avec DPI avancé.

Fuites et sécurité opérationnelle

WebRTC leak (fuite WebRTC)

WebRTC est une API navigateur pour la communication peer-to-peer. Pour fonctionner, elle interroge toutes les interfaces réseau de la machine — y compris l'IP réelle avant masquage VPN. Un site peut ainsi récupérer l'IP réelle via JavaScript malgré le tunnel actif. Solution pour un self-host : configurer le client WireGuard au niveau OS (pas juste navigateur) et activer la protection WebRTC dans le navigateur (Firefox : media.peerconnection.enabled = false).

IPv6 leak (fuite IPv6)

Si ton VPS ou ton réseau supporte IPv6 et que ton config WireGuard ne tunnelise que l'IPv4, les connexions IPv6 sortent en clair et exposent ton identité réelle. Solution : ajouter ::/0 dans les AllowedIPs (full tunnel IPv6), ou désactiver IPv6 au niveau de l'interface OS si ton setup ne le gère pas. WireGuard supporte nativement IPv6 — il suffit de l'inclure dans la config [Interface] (Address) et [Peer] (AllowedIPs).

Fonctionnalités clés

Kill switch

Le kill switch coupe toute connexion réseau si le tunnel VPN tombe, empêchant l'exposition de l'IP réelle. Sur Linux avec WireGuard, il s'implémente via des règles iptables/nftables dans le hook PostUp : on bloque tout trafic hors de l'interface wg0 sauf le trafic vers l'endpoint WireGuard. Guide complet avec systemd et iptables : kill switch VPN Linux.

Split tunneling

Le split tunneling consiste à router uniquement une partie du trafic dans le VPN, le reste sortant directement. Dans WireGuard, il se configure via AllowedIPs : en listant seulement les sous-réseaux cibles (ex. 10.8.0.0/24), le reste du trafic sort par l'interface normale. Utile pour accéder aux ressources du réseau VPN (NAS, services internes) tout en conservant la latence optimale pour le trafic Internet. Voir split tunnel et tables de routage.

ACLs (Access Control Lists)

Les ACLs dans Tailscale et Headscale définissent quelles machines peuvent communiquer entre elles dans le mesh. Configurées en JSON (format HuJSON dans Tailscale), elles permettent de segmenter l'accès : par exemple, autoriser les serveurs de prod à parler entre eux mais interdire aux machines personnelles d'y accéder directement. Sans ACLs, tous les appareils du mesh se voient et peuvent communiquer — ce qui est pratique mais pas adapté à un usage professionnel multi-équipes.

Subnet router

Un subnet router est un appareil Tailscale/Headscale configuré pour annoncer un sous-réseau privé au reste du mesh. Exemple : un NAS sur 192.168.1.0/24 peut être rendu accessible depuis Internet si une machine de ce réseau agit comme subnet router et annonce cette plage. Ainsi, les autres appareils du mesh peuvent atteindre toutes les machines du LAN sans que chacune soit inscrite individuellement dans Tailscale.

Peer-to-peer (P2P direct)

Dans le contexte Tailscale/Headscale, P2P désigne les connexions directes entre deux appareils sans passer par un serveur intermédiaire. Tailscale tente toujours d'établir une connexion P2P directe via NAT traversal avant de basculer sur DERP. Une connexion P2P offre la latence minimale (direct UDP entre les deux endpoints). L'interface tailscale status indique si une connexion est directe (Direct) ou relayée (Relay).

Ce que ce glossaire ne remplace pas

Ces définitions donnent le vocabulaire de base, mais la compréhension réelle vient de la pratique. Pour aller plus loin : le comparatif WireGuard vs OpenVPN détaille les choix concrets par cas d'usage, le guide Tailscale vs Headscale compare les deux approches de control plane, et le guide anti-DPI couvre l'obfuscation de A à Z.

Publié le 12 juin 2026. Définitions établies à partir des spécifications officielles WireGuard (Jason A. Donenfeld, whitepapers.wireguard.com), de la documentation Tailscale (tailscale.com/kb), du code source Headscale (github.com/juanfont/headscale), et des RFC IETF concernés. Mis à jour en continu.