WireGuard contre IPsec pour les bureaux : ce qui est plus facile à maintenir et pièges courants

Prendre la décision comme un opérateur

WireGuard et IPsec peuvent tous deux assurer la connectivité bureau-à-bureau efficacement. La différence n’est pas la « sécurité » au sens abstrait.
La différence porte sur le temps que vous passerez à prouver qu’un paquet a existé, et la fréquence à laquelle un petit décalage se transforme en trou noir.

Ma recommandation orientée production et biaisée

• Privilégiez WireGuard pour les nouveaux VPN site-à-site lorsque vous contrôlez les deux extrémités (routeurs Linux, firewalls modernes, ou appliances qui l’implémentent proprement).
  C’est plus simple à raisonner, plus léger à déboguer et prévisible en cas de changements fréquents.
• Utilisez IPsec/IKEv2 lorsque l’interopérabilité est indispensable avec du matériel d’entreprise existant, des listes de conformité, ou lorsque « IPsec est la seule chose supportée par le fournisseur sans se renvoyer la balle ».
  Aussi : si vous avez besoin d’un hub-and-spoke mature à grande échelle avec des outils IPsec déjà en place, ne combattez pas votre organisation.
• Ne choisissez pas sur la base de mots-clés cryptographiques. Choisissez en fonction de l’observabilité, des modes de panne et de qui sera d’astreinte à 03:00.

Ce que « plus facile à maintenir » signifie vraiment

La maintenance n’est pas l’installation initiale. C’est le deuxième site que vous ajoutez, le changement d’ISP, la mise à jour du firewall, et la « petite » modification de sous-réseau qui n’a pas été notée.
C’est aussi la rotation des identifiants, la supervision et la récupération d’une panne partielle (le trafic unidirectionnel est le roi du « fonctionne en apparence, mais ne roule pas »).

WireGuard a tendance à l’emporter sur la clarté de configuration et la débogabilité.
IPsec l’emporte souvent sur la compatibilité institutionnelle et la richesse fonctionnelle—au prix de davantage d’éléments mobiles et de surfaces de négociation qui échouent.

Une vérité opérationnelle : si votre VPN nécessite une réunion pour changer un jeu de chiffrements, vous n’avez pas un VPN—vous avez un rituel hebdomadaire.

Citation (idée paraphrasée) de Werner Vogels : Vous le construisez, vous l’exploitez—ce qui signifie que le coût d’exploitabilité fait partie du design, pas un post-scriptum.

Faits intéressants et contexte historique (ce qui explique le bazar actuel)

1. IPsec a commencé dans les années 1990 comme partie de la vision originale d’IPv6, puis a été adapté à la réalité d’IPv4. Résultat : des décennies d’extensions, de profils et d’« interprétations » par les fournisseurs.
2. IKE (Internet Key Exchange) a évolué parce que les clés manuelles faisaient souffrir. IKEv1 était flexible mais compliqué ; IKEv2 a simplifié le protocole et amélioré la fiabilité quand les IP changent.
3. NAT a brisé le modèle IPsec propre. ESP n’apprécie pas d’être traversé par un NAT ; NAT-T (encapsulation UDP) est devenu le ruban adhésif qui a rendu IPsec viable sur l’Internet moderne.
4. WireGuard est volontairement petit. Sa base de code est remarquablement compacte comparée aux piles IPsec typiques. Petit ne veut pas dire parfait, mais réduit la surface des « inconnues inconnues ».
5. WireGuard utilise des primitives modernes (handshake basé sur Noise). Il a fait des choix opinionés pour éviter une matrice de négociation foisonnante d’algorithmes.
6. L’adoption dans le noyau Linux a changé la donne pour WireGuard. Une fois intégré au noyau Linux, les performances et le packaging se sont simplifiés, et il a cessé de ressembler à un projet secondaire.
7. IPsec paraît souvent « état-plein » aux humains parce qu’il l’est. Il maintient des Security Associations (SA) avec des durées de vie, des rekeyings, et potentiellement plusieurs child SA.
8. WireGuard paraît « sans état » jusqu’à ce qu’on apprenne le contraire. Il a des handshakes et un comportement de roaming, mais évite la plupart des longues séquences de négociation et du drame des « propositions non concordantes ».
9. Beaucoup de fournisseurs de firewalls considèrent IPsec comme une fonctionnalité de premier plan. Cela compte pour les bureaux parce que les contrats de support et les opérations guidées par interface utilisateur sont de vraies contraintes.

Réalité de la maintenance : ce que votre futur vous détestera

WireGuard : moins de boutons, moins de façons de se tromper

La configuration WireGuard se résume essentiellement à : clés, endpoint, AllowedIPs, et keepalive si vous êtes derrière un NAT. C’est tout.
L’astuce opérationnelle est que AllowedIPs est à la fois routage et contrôle d’accès. C’est élégant, jusqu’à ce que quelqu’un pense que ce n’est que du routage et accorde par erreur l’accès à une plage RFC1918 entière.

Le travail de maintenance avec WireGuard ressemble principalement à :

• Rotation de clés sans casser les pairs.
• Maintenir AllowedIPs propres, non chevauchants et documentés.
• Éviter le « ça marche depuis l’ordinateur de Bob mais pas depuis le routeur du bureau » en standardisant les règles NAT et firewall.
• Surveiller les handshakes et le débit pour détecter tôt une panne silencieuse.

IPsec : le pays du « ça devrait marcher » et du « ça négocie toujours »

La maintenance IPsec est généralement dominée par l’interopérabilité et les surfaces de négociation :
propositions IKE/ESP, groupes DH, durées de vie, timers de rekey, identités, PSK vs certificats, tunnels basés sur politique vs basés sur route, DPD/keepalives, NAT-T, fragmentation, et valeurs par défaut spécifiques aux fournisseurs.

Vous pouvez faire fonctionner IPsec sans accroc pendant des années, mais vous y arrivez seulement en étant discipliné :
standardiser des profils, documenter les réglages exacts et surveiller le comportement de rekeying. Si vous « cliquez jusqu’à voir vert », vous paierez plus tard.

Ce qui cause réellement la charge opérationnelle (quel que soit le protocole)

• NAT et routage asymétrique : le VPN est blâmé, la table de routage est coupable.
• Problèmes MTU/PMTUD : les petits pings fonctionnent ; les gros paquets meurent ; le support perd une semaine.
• Attentes DNS : les gens veulent que le « DNS du bureau » fonctionne magiquement à travers les tunnels sans planification split-horizon.
• Dérive d’identité : l’IP ou le nom d’un pair change ; la configuration ne suit pas.
• Cycle de vie des clés : personne ne le planifie, puis c’est une panne quand on tente.

Blague #1 : les VPN sont comme les machines à café de bureau—personne ne sait comment elles marchent, mais tout le monde le remarque dès qu’elles ne fonctionnent plus.

WireGuard dans les bureaux : comportement opérationnel et pièges

Ce en quoi WireGuard excelle

• Routage site-à-site simple lorsque chaque bureau a des sous-réseaux stables et que vous voulez une connectivité prévisible.
• Roaming et liens instables : si l’IP publique d’un endpoint change, WireGuard peut récupérer rapidement tant que le pair est joignable et que les handshakes se produisent.
• Débogage léger : les commandes « montrez-moi l’état » ont tendance à être directes : dernier handshake, compteurs de transfert, endpoint.
• Performance par CPU : souvent excellente sur le matériel moderne, avec moins de surcharge que de nombreuses implémentations IPsec.

Les pièges qui causent de vraies pannes

Piège : chevauchement d’AllowedIPs et détournement de routes

Dans WireGuard, AllowedIPs côté récepteur décide quel trafic est accepté depuis un pair. Côté expéditeur, il décide quel trafic est routé dans le tunnel.
Les chevauchements peuvent créer un cauchemar de routage : le trafic disparaît dans le mauvais pair parce que le noyau choisit la route la plus spécifique, ou pire, votre « temporaire » 0.0.0.0/0 devient permanent.

Règle pratique : traitez AllowedIPs comme des règles de firewall plus des entrées de table de routage. Passez-les en revue comme une politique de sécurité, pas comme « quelques IP à atteindre ».

Piège : NAT et timeouts d’inactivité sans keepalive permanent

Beaucoup de liaisons de bureau sont derrière un NAT—routeurs ISP, secours LTE, « gateways » d’entreprise avec firmware mystère.
Si aucun côté n’envoie de trafic pendant un moment, l’état expire et le paquet suivant ne va nulle part. Cela ressemble à une panne intermittente, le pire type.
Pour des pairs derrière NAT, réglez PersistentKeepalive (souvent 25 secondes) sur le côté NATé.

Piège : inadéquation de MTU et trou noir TCP

WireGuard ajoute une surcharge. Si vous le faites fonctionner au-dessus de PPPoE, de balises VLAN ou d’autres encapsulations, le MTU effectif peut rapidement diminuer.
Le symptôme : SSH fonctionne, les petits HTTP fonctionnent, mais « le CRM expire » ou les transferts de fichiers s’arrêtent.
La correction consiste généralement à définir un MTU inférieur sur l’interface WireGuard et/ou à clamer le MSS sur le firewall.

Piège : oublier que ce n’est pas un pare-feu

WireGuard déplacera volontiers des paquets. Il ne concevra pas votre segmentation.
Vous avez toujours besoin de règles nftables/iptables, et vous devez toujours réfléchir au mouvement latéral entre réseaux de bureau.
Beaucoup d’équipes supposent à tort que « le VPN est la frontière ». Ce n’est pas le cas. C’est un câble.

Piège : gestion des clés dans un tableur

Les clés WireGuard sont statiques. C’est acceptable, mais vous devez les traiter comme des identifiants : propriété, rotation et révocation.
Le mode de panne classique est « qui a la clé privée du ancien routeur d’agence ? » et la réponse est « un ancien prestataire ».
Stockez les clés dans un système de secrets, pas dans le répertoire personnel de quelqu’un.

IPsec/IKEv2 dans les bureaux : comportement opérationnel et pièges

Ce en quoi IPsec excelle

• Interopérabilité fournisseur : tous les firewalls parlent un dialecte d’IPsec, et beaucoup ont des workflows UI matures pour ça.
• Intégration certificats et PKI : gestion d’identité évolutive lorsqu’elle est bien faite.
• Tunnels basés sur route avec VTI (sur plateformes capables) : plus proche du « routage normal », que les opérateurs comprennent.
• Compatibilité cases de conformité : certaines organisations ont une politique nommant explicitement IPsec.

Les pièges qui causent de vraies pannes

Piège : mismatch de propositions et le « trou noir de négociation »

La négociation IPsec dépend de l’accord sur des paramètres : chiffrement, intégrité, PRF, groupes DH, durées de vie, et plus encore.
Un seul décalage peut faire clapoter le tunnel, l’empêcher de monter, ou le faire monter mais refuser le trafic à cause d’un child SA non concordant.
Les logs ressemblent souvent à un désaccord poli. L’impact métier, lui, n’est pas poli.

Piège : NAT-T et douleur de fragmentation UDP

Dans un monde NATé, IPsec tourne souvent sur UDP/4500. Sur certains chemins, les gros paquets UDP sont abandonnés.
Cela peut casser le rekeying, casser les données, ou créer un schéma « marche un moment puis meurt ».
Vous finirez par régler le MTU, activer la prise en charge de la fragmentation, ou clamer le MSS de toute façon. Bienvenue au club.

Piège : confusion policy-based vs route-based

IPsec basé sur politique (sélecteurs pour sous-réseaux locaux/distants) paraît simple jusqu’à ce que vous ayez des sous-réseaux chevauchants, plusieurs réseaux, ou du routage dynamique.
Le route-based (VTI) tend à être plus maintenable pour les bureaux car il se comporte comme une interface normale et un problème de routage.
Mais toutes les plateformes ne l’implémentent pas de manière cohérente, et certaines UI cachent la complexité jusqu’à ce que ça casse.

Piège : timers de rekey qui ne correspondent pas à la réalité

Le rekeying est normal. Les tempêtes de rekeying ne le sont pas.
Si les durées sont trop courtes, ou si un côté rekeye agressivement et que l’autre ne suit pas, vous obtenez des pertes périodiques de paquets qui ressemblent à du « jitter ISP aléatoire ».
Surveillez la fréquence des rekeys. Rendez les durées de vie ennuyeuses.

Piège : configuration d’identité qui casse après un changement d’ISP

Beaucoup de déploiements IPsec de bureau lient l’identité à des adresses IP, ou supposent des IP publiques statiques pour toujours.
Puis l’ISP change le CPE, ou une agence passe sur LTE, et l’identité IKE ne correspond plus.
Utilisez des identifiants stables : identités FQDN et certificats, ou au minimum documentez la dépendance et planifiez les changements.

Blague #2 : IPsec ressemble beaucoup aux conventions de nommage conçues par comité—techniquement exhaustif, émotionnellement épuisant.

Playbook de diagnostic rapide (trouvez le goulot avant de « toucher à tout »)

Quand un tunnel est « down », c’est généralement l’un des quatre éléments : atteignabilité du transport, négociation/handshake, routage, ou MTU/état.
L’astuce est de vérifier dans le bon ordre pour ne pas perdre une heure à prouver la mauvaise couche.

Première étape : l’infrastructure sous-jacente est-elle joignable ?

• Confirmez l’atteignabilité IP/port public (UDP 51820 pour WireGuard, UDP 500/4500 pour IPsec).
• Vérifiez si des règles NAT ou de firewall ont changé.
• Validez que les deux côtés s’accordent sur l’adresse du pair (ou sont configurés pour des endpoints dynamiques de façon appropriée).

Deuxième étape : le plan de contrôle réussit-il ?

• WireGuard : vérifiez le dernier handshake, l’endpoint et les compteurs de transfert.
• IPsec : vérifiez l’établissement de l’IKE SA, l’installation du child SA, et le churn de rekey.

Troisième étape : le plan de données est-il routé correctement ?

• Vérifiez les routes sur les deux côtés (et que le chemin de retour correspond).
• Cherchez les sous-réseaux qui se chevauchent et les mauvaises « AllowedIPs » ou selecteurs de trafic.
• Confirmez que le forwarding et les politiques de firewall autorisent le trafic.

Quatrième étape : MTU/fragmentation vous tue-t-il en silence ?

• Testez avec des pings DF et des tailles croissantes.
• Clamez le MSS pour TCP si vous voyez des blocages.
• Surveillez les échecs de rekey corrélés avec de gros paquets.

Cinquième étape : est-ce un problème de ressources ?

• Saturation CPU sur le chiffrement.
• Perte de paquets dans les queues sur l’interface WAN.
• Déséquilibre des IRQ sur des routeurs bon marché avec du marketing « accélération VPN ».

Tâches pratiques avec commandes (et quoi faire des sorties)

Ce ne sont pas des commandes de labo. Ce sont celles que vous lancez pendant que quelqu’un des Finances demande si « le VPN est réparé ».
Chaque tâche inclut : commande, sortie d’exemple, ce que cela signifie, et la décision à prendre.

1) WireGuard : vérifier l’état du pair et le dernier handshake

cr0x@server:~$ sudo wg show
interface: wg0
  public key: 9nQ1x7bWJrZxqQYcVw9m0mQ9mJ3ZJ0mJm8yJm3s9YHg=
  listening port: 51820

peer: 7bq1oYVxRjv0y9u8mS5o2k1m8K9p0t7x6w5v4u3y2x1=
  endpoint: 203.0.113.44:53122
  allowed ips: 10.20.0.0/16
  latest handshake: 1 minute, 12 seconds ago
  transfer: 1.21 GiB received, 980.33 MiB sent
  persistent keepalive: 25 seconds

Signification : le « Latest handshake » est récent ; l’endpoint est connu ; les compteurs bougent.
Décision : Si le trafic échoue quand même, arrêtez de blâmer le tunnel et vérifiez le routage/firewall/MTU en interne. Si le handshake est « jamais » ou vieux de plusieurs heures, concentrez-vous sur l’atteignabilité sous-jacente ou les clés.

2) WireGuard : vérifier les routes kernel créées par AllowedIPs

cr0x@server:~$ ip route show table main | grep wg0
10.20.0.0/16 dev wg0 scope link

Signification : Le système route 10.20.0.0/16 vers wg0.
Décision : Si vous attendiez seulement 10.20.30.0/24 et que vous voyez /16, vous avez trouvé pourquoi le trafic disparaît dans le tunnel. Corrigez AllowedIPs et la politique de routage.

3) WireGuard : vérifier le MTU de l’interface et ajuster si nécessaire

cr0x@server:~$ ip link show dev wg0
7: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none

Signification : MTU 1420 est courant pour WireGuard sur Ethernet typique. Au-dessus de PPPoE ou d’autres encapsulations, ça peut encore être trop élevé.
Décision : Si vous voyez un trou noir TCP, baissez le MTU (ex. 1380) et/ou clamez le MSS sur le bord.

4) Test de Path MTU avec ping DF (trouver les trous noirs)

cr0x@server:~$ ping -M do -s 1372 -c 3 10.20.30.10
PING 10.20.30.10 (10.20.30.10) 1372(1400) bytes of data.
1372 bytes from 10.20.30.10: icmp_seq=1 ttl=63 time=18.7 ms
1372 bytes from 10.20.30.10: icmp_seq=2 ttl=63 time=18.5 ms
1372 bytes from 10.20.30.10: icmp_seq=3 ttl=63 time=18.6 ms

--- 10.20.30.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Signification : Payload 1372 avec DF réussit, donc au moins des paquets d’environ 1400 octets passent sur ce chemin.
Décision : Si cela échoue avec « Frag needed », ajustez MTU/MSS. Si ça time-out, suspectez un filtrage ICMP ou un vrai trou noir—clamez le MSS et réduisez le MTU de façon proactive.

5) WireGuard : confirmer que le processus écoute sur le port attendu

cr0x@server:~$ sudo ss -lunp | grep 51820
UNCONN 0      0          0.0.0.0:51820      0.0.0.0:*    users:(("wg-quick",pid=1324,fd=6))

Signification : UDP/51820 est ouvert localement.
Décision : S’il n’écoute pas, votre service n’a pas démarré ou s’est lié incorrectement. Réparez systemd/wg-quick puis vérifiez firewall/NAT.

6) WireGuard : capturer les tentatives de handshake (prouver que les paquets existent)

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 51820 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:10:01.123456 IP 198.51.100.22.51820 > 203.0.113.44.53122: UDP, length 148
12:10:01.223901 IP 203.0.113.44.53122 > 198.51.100.22.51820: UDP, length 92

Signification : UDP bidirectionnel circule ; l’infrastructure sous-jacente et le firewall sont probablement OK.
Décision : Si vous voyez seulement de l’outbound et aucune réponse, c’est firewall/NAT/ISP. Si vous voyez du bidirectionnel mais aucun handshake dans wg show, suspectez un mauvais appariement de clés ou une configuration de pair incorrecte.

7) IPsec (strongSwan) : afficher l’état IKE et des child SA

cr0x@server:~$ sudo swanctl --list-sas
vpn-office: #12, ESTABLISHED, IKEv2, 3c2f2e8d1d0a9c1f_i* 9a8b7c6d5e4f3210_r
  local  'office-a' @ 198.51.100.10[4500]
  remote 'office-b' @ 203.0.113.44[4500]
  AES_GCM_16-256/PRF_HMAC_SHA2_256/ECP_256
  established 42 minutes ago, rekeying in 2 hours
  office-a-office-b: #14, INSTALLED, TUNNEL, reqid 1
    local  10.10.0.0/16
    remote 10.20.0.0/16
    AES_GCM_16-256, 51023 bytes_i, 48890 bytes_o, rekeying in 46 minutes

Signification : IKE SA établie, child SA installée, les sélecteurs correspondent aux sous-réseaux des bureaux.
Décision : Si IKE est up mais child SA manquant, vous avez un mismatch de sélecteur/proposition. Si les deux sont up mais le trafic échoue, vérifiez routage, firewall et MTU/fragmentation.

8) IPsec : vérifier les logs de charon pour les erreurs de négociation

cr0x@server:~$ sudo journalctl -u strongswan --since "10 min ago" | tail -n 12
Dec 28 12:02:11 gw-a charon-systemd[998]: 14[IKE] received NO_PROPOSAL_CHOSEN notify error
Dec 28 12:02:11 gw-a charon-systemd[998]: 14[IKE] failed to establish CHILD_SA, keeping IKE_SA
Dec 28 12:02:11 gw-a charon-systemd[998]: 14[IKE] peer supports MOBIKE

Signification : Le pair a rejeté la proposition pour le child SA (transforms ESP, groupe DH, etc.).
Décision : Alignez les jeux de chiffrements/propositions sur les deux côtés. N’« ouvrez » pas tout. Standardisez un profil connu bon et appliquez-le partout.

9) IPsec : vérifier les écouteurs UDP 500/4500

cr0x@server:~$ sudo ss -lunp | egrep ':500|:4500'
UNCONN 0      0          0.0.0.0:500        0.0.0.0:*    users:(("charon",pid=998,fd=12))
UNCONN 0      0          0.0.0.0:4500       0.0.0.0:*    users:(("charon",pid=998,fd=13))

Signification : Le démon écoute sur les ports IKE/NAT-T requis.
Décision : Si absent, votre service est down ou lié incorrectement. Réparez cela d’abord ; ne touchez pas encore aux propositions.

10) IPsec : confirmer que NAT-T est en jeu (ou pas)

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 4500 -c 3
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:06:44.001122 IP 198.51.100.10.4500 > 203.0.113.44.4500: UDP, length 244
12:06:44.101455 IP 203.0.113.44.4500 > 198.51.100.10.4500: UDP, length 276

Signification : IPsec est encapsulé dans UDP/4500. C’est typique quand le NAT est détecté ou forcé.
Décision : Si UDP/4500 est bloqué quelque part, vous aurez des pannes intermittentes ou totales. Ouvrez-le, et surveillez les problèmes de fragmentation UDP.

11) Sanity routage : vérifier le chemin de retour (l’asymétrie tue les VPN)

cr0x@server:~$ ip route get 10.20.30.10
10.20.30.10 dev wg0 src 10.10.0.1 uid 0
    cache

Signification : Le noyau croit que 10.20.30.10 est joignable via wg0.
Décision : Exécutez la même vérification sur le côté distant pour votre sous-réseau source. Si un côté route correctement et l’autre pas, vous avez un routage asymétrique ou des routes manquantes.

12) Sanity firewall : confirmer que la politique de forwarding ne droppe pas silencieusement

cr0x@server:~$ sudo nft list ruleset | sed -n '1,80p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    iifname "wg0" oifname "lan0" accept
    iifname "lan0" oifname "wg0" accept
    ct state established,related accept
  }
}

Signification : La politique forward est drop par défaut ; des accept explicites existent entre wg0 et lan0.
Décision : Si ces règles manquent, le tunnel peut être up mais le trafic ne passera pas. Ajoutez des règles de forwarding minimales et explicites et loggez les drops pendant le déploiement.

13) Voir les drops et erreurs en direct sur les interfaces (détecter congestion/MTU)

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
    9876543210  8123456      0    1203       0  12345
    TX:  bytes packets errors dropped carrier collsns
    8765432109  7345678      0     987       0       0

Signification : Les drops sont non nuls. Cela peut être une pression de queue, du policing, ou un problème de pilote.
Décision : Si les drops augmentent pendant l’utilisation du VPN, enquêtez sur le shaping/QoS WAN, le CPU et le MTU. Ne modifiez pas le chiffrement au hasard en premier.

14) Confirmer que l’IP forwarding est activé (le classique « tunnel up, pas de trafic »)

cr0x@server:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Signification : L’hôte routue les paquets.
Décision : Si c’est 0 sur un routeur Linux, vous avez trouvé votre panne. Activez-le de façon persistante et confirmez les règles de forwarding du firewall.

15) Prouver que le DNS est le problème, pas le tunnel

cr0x@server:~$ dig +short app.internal.example @10.20.0.53
10.20.30.45

Signification : La résolution de nom fonctionne sur le tunnel vers le serveur DNS distant.
Décision : Si l’IP se résout mais que l’application échoue toujours, examinez le routage/ACL de l’application. Si elle ne se résout pas, votre rapport « VPN down » concerne en réalité la reachabilité DNS ou la conception split-horizon.

16) Tracer le chemin vers un sous-réseau distant (trouver une route par défaut rogue)

cr0x@server:~$ traceroute -n 10.20.30.10
traceroute to 10.20.30.10 (10.20.30.10), 30 hops max, 60 byte packets
 1  10.10.0.1  0.334 ms  0.291 ms  0.271 ms
 2  10.20.30.10  18.821 ms  18.654 ms  18.590 ms

Signification : Le trafic atteint l’hôte distant en deux sauts—probablement un routage correct via la passerelle du tunnel.
Décision : Si vous voyez des sauts sortant vers l’ISP, vous fuyiez des routes. Corrigez le routage et envisagez du routage basé sur politique ou des préfixes plus spécifiques.

17) Pour IPsec, vérifier xfrm state/policy (vue kernel Linux)

cr0x@server:~$ sudo ip xfrm state | sed -n '1,60p'
src 198.51.100.10 dst 203.0.113.44
  proto esp spi 0xc0ffee12 reqid 1 mode tunnel
  replay-window 32 flag af-unspec
  auth-trunc hmac(sha256) 0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 128
  enc cbc(aes) 0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
  lifetime config: soft 0 hard 0
  lifetime current: soft 0 hard 0

Signification : Le kernel a une SA ESP installée. Si les politiques manquent, le trafic ne correspondra pas et passera en clair (ou sera dropé par le firewall).
Décision : Si le démon dit « up » mais xfrm est vide, le plan de contrôle n’a pas installé l’état—vérifiez les privilèges, le support kernel, ou les erreurs du démon.

18) Mesurer le débit et la perte de paquets à travers le tunnel

cr0x@server:~$ iperf3 -c 10.20.30.10 -t 10
Connecting to host 10.20.30.10, port 5201
[  5] local 10.10.0.50 port 58312 connected to 10.20.30.10 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-10.00  sec   412 MBytes   346 Mbits/sec   92   1.12 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   0.00-10.00  sec   412 MBytes   346 Mbits/sec   92             sender
[  5]   0.00-10.00  sec   409 MBytes   343 Mbits/sec                  receiver

Signification : Il y a des retransmissions mais le débit est correct. Si les retransmissions sont énormes ou le débit s’effondre, suspectez MTU, perte ou saturation CPU.
Décision : Corrénez avec les drops d’interface et le CPU. Si le CPU est élevé, envisagez une montée en gamme matérielle, des options d’offload (avec précaution), ou réduire la charge de chiffrement seulement si la politique le permet.

Erreurs courantes : symptômes → cause racine → correction

1) « Le tunnel est up, mais rien ne communique »

Symptômes : Handshake/SA établi, les pings vers l’endpoint du tunnel fonctionnent, mais le trafic subnet-à-subnet échoue.

Cause racine : IP forwarding manquant, règles de forwarding firewall manquantes, ou pas de route vers les sous-réseaux distants.

Correction : Activer le forwarding (sysctl net.ipv4.ip_forward=1), ajouter des règles forward explicites, vérifier les routes avec ip route get sur les deux côtés.

2) « Ça marche quelques minutes, puis ça meurt jusqu’à ce qu’on “redémarre le VPN” »

Symptômes : Connectivité intermittente, souvent après des périodes d’inactivité.

Cause racine : Timeout d’inactivité NAT. WireGuard sans keepalive, ou état IPsec NAT-T expiré.

Correction : WireGuard : définir PersistentKeepalive = 25 sur les pairs derrière NAT. IPsec : assurer que DPD/keepalive est configuré correctement ; valider la stabilité de UDP/4500.

3) « Les petits pings fonctionnent, les applis se bloquent, les transferts de fichiers stagnent »

Symptômes : SSH ok, interface web charge partiellement, SMB/HTTPS bloque, gros uploads expirent.

Cause racine : Échec MTU/PMTUD ou perte de fragmentation UDP.

Correction : Baisser le MTU du tunnel, clamer le MSS TCP, et exécuter des pings DF pour trouver des tailles sûres de paquets.

4) « Après avoir ajouté un nouveau bureau, un autre bureau a cassé »

Symptômes : L’ajout du pair C rend le pair B injoignable ; les routes oscillent.

Cause racine : Chevauchement d’AllowedIPs (WireGuard) ou chevauchement de selecteurs (IPsec basé sur politique). Changement de préférence de route.

Correction : Utiliser des préfixes non-chevauchants par site. Préférer IPsec basé sur route (VTI) et un protocole de routage si vous croissez.

5) « IPsec ne monte pas, mais les deux côtés jurent que c’est bien configuré »

Symptômes : Tentatives de négociation répétées, NO_PROPOSAL_CHOSEN, AUTH failed, ou pas de CHILD_SA apparié.

Cause racine : Mismatch de propositions, mismatch d’identité (IDs/certs), PSK incorrect, ou dérive d’horloge affectant la validation des certificats.

Correction : Standardiser les propositions ; vérifier les identités ; confirmer la synchronisation horaire ; inspecter les logs des deux côtés et aligner exactement les transforms et les sélecteurs.

6) « Les handshakes WireGuard ont lieu, mais les compteurs de trafic ne bougent pas »

Symptômes : wg show affiche un handshake récent mais transfer reste à 0 ; ou seul un sens s’incrémente.

Cause racine : AllowedIPs mal configurés sur un côté, firewall bloquant le forwarding, ou routage asymétrique sur le LAN.

Correction : Valider AllowedIPs sur les deux pairs ; vérifier les tables de routage ; confirmer les règles de forwarding ; exécuter tcpdump sur wg0 et l’interface LAN.

7) « Tout a cassé après que l’ISP a changé l’IP publique de la branche »

Symptômes : Le tunnel ne revient jamais ; les logs montrent mismatch d’identité ou pair injoignable.

Cause racine : Endpoint/identité codé en dur lié à l’ancienne IP ; NAT upstream changé ; pinholes firewall manquants.

Correction : Utiliser des identifiants stables (certs/FQDN pour IPsec), DNS dynamique avec contrôles de sécurité prudents, ou un modèle hub où les branches initient vers l’extérieur.

8) « Les performances VPN sont médiocres pendant les heures ouvrées »

Symptômes : Haute latence, débit faible, pics de perte de paquets, problèmes de voix.

Cause racine : Saturation CPU sur le chiffrement, congestion WAN, bufferbloat, ou QoS mal configuré.

Correction : Mesurer avec iperf3, vérifier les drops d’interface et le CPU ; appliquer un shaping/QoS approprié ; mettre à niveau le matériel si nécessaire.

Trois mini-récits d’entreprise (anonymisés, plausibles et douloureusement familiers)

Incident causé par une mauvaise hypothèse : « Le VPN est le réseau »

Une entreprise de taille moyenne a ouvert un nouveau bureau. Ils avaient déjà utilisé WireGuard pour des utilisateurs distants, donc ils ont réutilisé la même procédure pour site-à-site.
Le déploiement a été rapide : tunnel up, routes ajoutées, pings basiques réussis. Tout le monde s’est tapé dans la main et est retourné à son travail.

Deux semaines plus tard, quelqu’un a remarqué que le nouveau bureau pouvait atteindre un sous-réseau legacy qui devait rester isolé. Pas « oups, un serveur ». Tout le sous-réseau.
L’hypothèse était : « Si c’est dans le tunnel, c’est de confiance comme le LAN interne. » Cette hypothèse n’avait jamais été vraie—mais elle était maintenant encodée dans AllowedIPs et des règles de forwarding permissives.

La cause racine était subtile : AllowedIPs incluait un large 10.0.0.0/8 parce que « on pourrait ajouter d’autres sous-réseaux plus tard ».
Sur le firewall, le forwarding entre wg0 et lan0 était autorisé par un accept global.
Personne n’a documenté les exigences de segmentation parce que « c’est juste un tunnel de bureau ».

La correction n’a pas été héroïque. Ils ont restreint AllowedIPs aux préfixes exacts des sites, implémenté des ACL explicites entre réseaux de bureau, et ajouté de la journalisation pour les flux inter-sites.
La vraie correction a été culturelle : ils ont cessé de traiter le VPN comme une frontière magique et ont commencé à le traiter comme un transport.

La leçon : la façon la plus rapide de créer des accès surprises est de « prévoir la croissance » en routant l’univers entier dès le jour un.

Optimisation qui s’est retournée contre eux : tuning crypto au lieu de planification de capacité

Une autre organisation utilisait IPsec entre le siège et plusieurs agences, principalement sur des appliances firewall milieu de gamme.
Le business se plaignait de synchronisations lentes de fichiers et d’appels hachés. L’équipe réseau a fait ce que font les équipes sous pression : elle a cherché un réglage.

Ils ont changé les propositions IPsec pour des réglages « plus légers » et raccourci les durées de vie, espérant améliorer les performances et la stabilité.
Le changement a légèrement réduit la charge CPU—mais a aussi augmenté la fréquence des rekeys et rendu visibles des rafales de perte de paquets chaque fois que les tunnels renégociaient les clés.
L’expérience utilisateur s’est détériorée, et de manière périodique, difficile à expliquer.

Le débogage a pris du temps parce que chaque branche se comportait différemment. Certaines étaient derrière des NAT agressifs ; d’autres avaient du PPPoE ; d’autres encore avaient du matériel ISP qui détestait l’UDP fragmenté.
Des durées de vie plus courtes signifiaient plus d’échanges de plan de contrôle importants. Ce sont exactement les paquets que le chemin n’aimait pas.

La correction finale fut ennuyeuse : revenir à des durées de vie sensées, clamer le MSS, et appliquer un shaping adéquat sur le bord WAN.
Puis ils ont mis à niveau deux appliances surchargées qui n’avaient tout simplement pas la marge CPU pour les heures de pointe.
L’« optimisation » n’était pas fausse en théorie ; elle l’était dans le contexte.

La leçon : si votre WAN est saturé ou votre routeur sous-dimensionné, bricoler les jeux de chiffrements revient à déplacer des chaises pendant un incendie.

Pratique ennuyeuse mais correcte qui a sauvé la mise : profils standard + validation pré-changement

Une entreprise avec 15 bureaux utilisait un mélange de WireGuard et IPsec suite à des acquisitions. Leur équipe SRE détestait les pannes plus que les papiers, donc ils ont construit une habitude :
chaque changement avait une checklist pré-vol, et chaque tunnel avait un profil « connu bon ».

Un vendredi après-midi (toujours un vendredi), l’ISP d’une branche a eu une fenêtre de maintenance non annoncée et a changé l’IP publique.
Le tunnel est tombé. Mais au lieu de deviner, l’astreinte a exécuté les trois mêmes commandes qu’elle exécute toujours : vérifier l’atteignabilité sous-jacente, vérifier l’état du plan de contrôle, vérifier les routes.
La supervision avait déjà des alertes sur « handshake plus vieux que N minutes » et « SA qui clapote ».

Ils avaient déjà un modèle hub où les branches initient vers l’extérieur, plus une procédure documentée pour mettre à jour les endpoints de branche.
Ils ont mis à jour l’endpoint, vu les handshakes reprendre, et vérifié les applications clés avec une petite suite de pings et de tests TCP.
Impact total : notable, mais contenu.

Ce qui les a sauvés n’était pas un protocole sophistiqué. C’était la cohérence :
configurations standard, bonne observabilité, et une culture du « valider avant et après ».

Listes de contrôle / plan étape par étape (livrez sans vous détester)

Choisir le modèle d’abord : maillage vs hub-and-spoke

• Maillage (chaque bureau vers chaque bureau) : concept simple, opérationnellement chaotique à mesure de la croissance. Les clés/profils se multiplient ; le dépannage devient combinatoire.
• Hub-and-spoke (bureaux vers hub HQ/cloud) : généralement meilleur pour les bureaux. Supervision centralisée, moins de tunnels, contrôle des politiques plus simple.

Règle de décision : si vous avez plus que quelques sites et pas d’équipe réseau dédiée, construisez un hub.
Si vous avez besoin d’un full-mesh pour des raisons de latence, faites-le avec de l’automatisation et des conventions fortes ou n’en faites pas.

Plan de déploiement WireGuard (bureau-à-bureau)

1. Définir l’adressage : allouez des préfixes non-chevauchants par site ; documentez-les.
2. Choisir un port d’écoute et le standardiser (ne devenez pas « créatif » par site).
3. Générer des clés par routeur de site ; stocker les clés privées dans votre système de secrets.
4. Écrire AllowedIPs étroitement : seulement les préfixes du site distant ; éviter les plages « catch-all ».
5. Définir PersistentKeepalive pour les sites derrière NAT.
6. Implémenter la politique firewall : allowlists explicites entre sous-réseaux ; deny par défaut pour le mouvement latéral inter-sites.
7. Définir le MTU et/ou clamer le MSS selon votre réalité WAN (PPPoE/LTE nécessite presque toujours une attention).
8. Supervision : alertes sur l’âge du handshake, blocage des compteurs de transfert, et perte de paquets/latence vers services clés.
9. Faire un test post-changement : ping, connexion TCP sur ports clés, requête DNS, et un petit test de débit.

Plan de déploiement IPsec (IKEv2, bureau-à-bureau)

1. Choisir route-based si possible (VTI). Si vous êtes coincé avec policy-based, gardez les sélecteurs simples et explicites.
2. Standardiser un seul jeu de propositions au sein de l’organisation. Un seul. Pas cinq. Évitez les modes « auto » du fournisseur sauf si vous aimez l’archéologie.
3. Décider PSK vs certificats : PSK est rapide mais ne scale pas ; certificats nécessitent une hygiène PKI mais rapportent à long terme.
4. Définir des durées de vie sensées et les garder cohérentes pour éviter le churn.
5. Activer NAT-T (si nécessaire) et valider l’atteignabilité UDP/4500.
6. Planifier le MTU : clamez le MSS tôt ; confirmez que PMTUD fonctionne ou supposez que non.
7. Logging et supervision : suivre les événements SA up/down, la fréquence de rekey, et les notifications d’erreur comme NO_PROPOSAL_CHOSEN.
8. Documenter les identités : quelle ID chaque côté utilise ; ce qui change quand l’IP ISP change ; où résident les certificats.
9. Validation post-changement : idem WireGuard, plus s’assurer que les sélecteurs child SA correspondent aux réseaux voulus.

Checklist d’hygiène opérationnelle (s’applique aux deux)

• Chaque site a : propriétaire, usage, sous-réseaux, endpoints des pairs, et un plan de rollback.
• La supervision couvre : la santé du plan de contrôle du tunnel et la reachabilité applicative.
• La stratégie MTU est documentée (y compris les exceptions PPPoE/LTE).
• Les fenêtres de changement incluent des vérifications pré/post avec sorties sauvegardées.
• Les clés/PSK/certs ont des procédures de rotation et révocation.
• Les règles firewall sont revues comme du code, pas éditées par « qui avait l’accès ».

FAQ

1) Est-ce que WireGuard est « plus sûr » qu’IPsec ?

Pas d’une manière qui importe pour la plupart des déploiements de bureau. Les deux peuvent être sécurisés quand ils sont configurés correctement.
WireGuard réduit la complexité de configuration (moins de façons de malconfigurer), tandis qu’IPsec peut être extrêmement robuste mais a une surface de négociation et de politique plus large.

2) Lequel est plus facile à dépanner en astreinte ?

Typiquement WireGuard. wg show vous dit l’âge du handshake, l’endpoint et les compteurs d’octets en une seule commande.
Le dépannage IPsec exige souvent de lire les logs de négociation et de comprendre quelle SA a échoué et pourquoi.

3) Quelle est l’erreur WireGuard la plus courante en bureau ?

AllowedIPs trop larges ou qui se chevauchent. Cela provoque des détournements de routes, des accès non souhaités, ou le trafic qui disparaît dans le mauvais tunnel.
Traitez AllowedIPs comme du routage et de l’autorisation.

4) Quelle est l’erreur IPsec la plus courante en bureau ?

Les réglages « auto » de propositions et les profils non concordants entre fournisseurs. Ça marche jusqu’au moment où ça ne marche plus, et alors personne ne peut expliquer pourquoi.
Standardisez un profil IKEv2/ESP et appliquez-le partout.

5) Ai-je besoin d’un routage dynamique (OSPF/BGP) sur le VPN ?

Si vous avez plus que quelques sites ou prévoyez des changements, le routage dynamique réduit la charge—surtout avec des tunnels basés sur route.
Si vous êtes petit et stable, des routes statiques peuvent suffire, mais documentez-les et testez les chemins de secours.

6) Comment éviter les problèmes MTU sans devenir un as des paquets ?

Soyez conservateur : abaissez le MTU du tunnel et clamez le MSS en bordure.
Validez avec pings DF et un transfert TCP réel. Supposez que PMTUD échouera sur au moins un chemin ISP.

7) Les branches doivent-elles initier le tunnel, ou le siège doit-il initier ?

Préférez que les branches initient vers un hub stable. Ça évite des pinholes firewall entrants aux branches et tolère mieux les IP changeantes des branches.
Ça simplifie aussi la réponse aux incidents : un hub à surveiller.

8) Puis-je mixer WireGuard et IPsec dans une même organisation ?

Oui, beaucoup le font suite à des acquisitions ou contraintes fournisseurs. Le risque est l’incohérence opérationnelle.
Atténuez-le avec des runbooks standard, une supervision qui raisonne en résultats (latence, reachabilité), et un plan de convergence progressive.

9) Ai-je besoin de certificats pour IPsec, ou un PSK suffit-il ?

Un PSK suffit pour un petit nombre de sites et une gestion disciplinée. Les certificats montent mieux à l’échelle, notamment quand le personnel change et qu’il faut révoquer.
Si vous lancez une PKI, faites-le proprement : synchronisation horaire, automatisation des renouvellements, et mapping d’identité clair.

10) Que signifie « le tunnel est up mais trafic unidirectionnel » habituellement ?

Routage asymétrique, état NAT bizarre, ou règles firewall autorisant une direction seulement.
Prouvez-le avec les compteurs (wg show ou octets SA) et des captures sur les deux côtés ; puis réparez la symétrie de routage et la politique de forwarding.

Prochaines étapes que vous pouvez réellement livrer

Si vous partez de zéro et que vous contrôlez les deux côtés, déployez WireGuard en topologie hub-and-spoke.
Gardez AllowedIPs étroits, activez le keepalive pour les sites derrière NAT, et clamez le MSS tôt. Ajoutez une supervision de l’âge du handshake et des vérifications applicatives, pas seulement « tunnel up ».

Si vous êtes déjà en IPsec, ne le remplacez pas parce que c’est agaçant. Rendez-le ennuyeux :
standardisez un profil IKEv2, migrez vers des tunnels basés sur route quand c’est possible, alignez les durées de vie, et instrumentez les rekeys et erreurs.
La plupart des « mystères » IPsec s’évaporent quand vous arrêtez de laisser chacun inventer son propre jeu de propositions.

Enfin : rédigez le runbook que vous auriez voulu avoir. Utilisez l’ordre de diagnostic rapide, gardez les commandes à portée de main, et stockez les sorties pré/post à chaque changement.
Votre futur vous sera encore appelé, mais au moins il aura des justificatifs.