infra / reseaux-tcp-ip
VPN (concepts, IPsec/WireGuard)
Explication
Ce que vous allez apprendre
- Comprendre ce qu'un VPN garantit réellement (confidentialité et authentification) à travers un réseau non fiable
- Distinguer un VPN site-à-site d'un VPN client-à-site (road warrior)
- Comparer IPsec, OpenVPN et WireGuard selon leur complexité et leurs performances
- Générer une paire de clés WireGuard et configurer un tunnel serveur/client fonctionnel
- Comprendre le double rôle de
AllowedIPsdans WireGuard : routage ET filtrage
Dans quel contexte ?
Une équipe entièrement en télétravail doit accéder à une base de données interne 10.0.5.20 normalement injoignable depuis Internet. Plutôt que d'exposer la base directement (dangereux) ou d'utiliser un VPN historique lourd à configurer (IPsec), l'administrateur déploie WireGuard : chaque développeur reçoit une paire de clés, et une fois le tunnel monté, sa machine accède au réseau interne comme si elle y était physiquement branchée.
Créer un réseau privé à travers un réseau public
Internet n'est pas un réseau de confiance : n'importe quel intermédiaire pourrait techniquement observer ou modifier le trafic qui y transite. Un VPN (réseau privé virtuel) crée un tunnel chiffré à travers ce réseau non fiable, comme si les deux extrémités étaient directement reliées par un câble privé, même si le trafic réel passe par de multiples réseaux intermédiaires.
| Protocole | Complexité | Performance | Cas d'usage typique |
|---|---|---|---|
| IPsec | Élevée | Bonne | Standard historique, interopérabilité entre équipementiers |
| OpenVPN | Moyenne | Correcte | Portable, basé sur TLS |
| WireGuard | Faible | Excellente | Déploiements modernes, configuration minimale |
Piège fréquent
Dans WireGuard, AllowedIPs définit à la fois quel trafic emprunte le tunnel ET quel trafic est accepté depuis ce pair. Mettre 0.0.0.0/0 par erreur peut router tout le trafic Internet du client à travers le tunnel, ou au contraire accepter du trafic depuis des réseaux qu'on ne voulait pas exposer.
Deux usages différents, deux architectures
Un VPN "site-à-site" relie deux réseaux entiers en permanence (deux bureaux d'une même entreprise, par exemple), sans intervention humaine à chaque connexion. Un VPN "client-à-site" (parfois appelé "road warrior") relie un poste individuel, ponctuellement, au réseau de l'entreprise — le cas typique du télétravail. Comprendre cette distinction aide à choisir la bonne architecture selon le besoin réel.
Pourquoi WireGuard change la donne
Les protocoles VPN historiques comme IPsec sont robustes mais complexes à configurer, avec de nombreux paramètres à accorder entre les deux parties. WireGuard adopte une philosophie radicalement plus simple : une paire de clés cryptographiques par participant, une configuration minimale, et un code source volontairement réduit (donc plus facile à auditer pour la sécurité). C'est ce compromis simplicité/performance qui explique son adoption rapide.
AllowedIPs : plus qu'un simple réglage
Dans WireGuard, ce paramètre définit à la fois quel trafic emprunte le tunnel ET quel trafic est accepté depuis chaque pair — une double fonction (routage et filtrage) qu'il est important de bien comprendre pour éviter d'exposer accidentellement plus de réseau que prévu.
Commandes & code
VPN : concepts et mise en oeuvre
# Un VPN crée un tunnel chiffré entre deux points à travers un réseau non fiable (Internet)
# Deux grandes familles :
# - VPN site-à-site : relie deux réseaux entiers (ex: deux datacenters)
# - VPN client-à-site (road warrior) : un poste distant rejoint un réseau d'entreprise
# Protocoles courants
# IPsec -> standard historique, très supporté, configuration plus complexe (IKE, ESP, AH)
# OpenVPN -> populaire, basé sur TLS, portable, plus lourd en performance
# WireGuard -> moderne, code minimal, très performant, configuration nettement plus simple# --- WireGuard : génération des clés (chaque pair a une paire clé privée/publique) ---
wg genkey | tee privatekey | wg pubkey > publickey
cat privatekey # à garder secrète, jamais partagée
cat publickey # à partager avec le pair distant
# Configuration serveur : /etc/wireguard/wg0.conf
sudo tee /etc/wireguard/wg0.conf <<'EOF'
[Interface]
PrivateKey = <clé_privée_serveur>
Address = 10.8.0.1/24
ListenPort = 51820
[Peer]
# Client "ned-laptop"
PublicKey = <clé_publique_client>
AllowedIPs = 10.8.0.2/32
EOF
sudo wg-quick up wg0 # démarre le tunnel
sudo wg-quick down wg0 # arrête le tunnel
sudo systemctl enable --now wg-quick@wg0 # démarrage automatique au boot
sudo wg show # état des pairs, dernier handshake, trafic transféré
# Configuration client
sudo tee /etc/wireguard/wg0.conf <<'EOF'
[Interface]
PrivateKey = <clé_privée_client>
Address = 10.8.0.2/24
[Peer]
PublicKey = <clé_publique_serveur>
Endpoint = vpn.exemple.com:51820
AllowedIPs = 10.0.0.0/8, 10.8.0.0/24 # réseaux accessibles à travers le tunnel
PersistentKeepalive = 25 # ping périodique, utile derrière un NAT
EOF
# --- IPsec (notions) avec strongSwan, VPN site-à-site ---
# /etc/ipsec.conf (extrait)
# conn site-a-to-site-b
# left=203.0.113.1
# leftsubnet=192.168.1.0/24
# right=198.51.100.1
# rightsubnet=192.168.2.0/24
# ike=aes256-sha256-modp2048
# esp=aes256-sha256
# auto=start
sudo ipsec restart
sudo ipsec status # état des tunnels IPsec actifsRésumé
- WireGuard privilégie simplicité et performance (paires de clés, config minimale), IPsec reste le standard interopérable.
AllowedIPscôté WireGuard définit à la fois le routage ET le filtrage des IP autorisées pour chaque pair.- Un VPN chiffre et authentifie le trafic entre deux points ; le choix site-à-site vs client-à-site dépend du besoin.
Exercices pratiques
Mission : corriger une AllowedIPs mal configurée
Objectif : Diagnostiquer les conséquences d'une AllowedIPs trop permissive côté client WireGuard, et comprendre son double rôle.
Contexte
Un employé configure son client WireGuard avec AllowedIPs = 0.0.0.0/0 au lieu de 10.0.0.0/8, 10.8.0.0/24 comme prévu par la politique de l'entreprise. Côté serveur, le pair de cet employé a AllowedIPs = 10.8.0.2/32.