Routage par clé WireGuard : AllowedIPs, radix trie et filtrage anti-usurpation

Les tunnels réseau ont historiquement traité le routage des paquets et la protection cryptographique comme deux sous-systèmes distincts. Dans les réseaux privés virtuels classiques, le système d'exploitation achemine d'abord les paquets vers une interface virtuelle, applique des règles de pare-feu complexes, puis transmet les données à des bases de politiques de sécurité séparées. WireGuard transforme ce modèle fragmenté grâce au routage par clé cryptographique (Cryptokey Routing, CKR). En liant directement les clés publiques statiques des pairs à une liste de sous-réseaux IP autorisés (AllowedIPs), WireGuard intègre le routage, la recherche de session et le filtrage anti-usurpation au débit de ligne au sein d'une opération atomique au niveau du noyau.

Le problème du découplage entre routage et cryptographie dans les VPN classiques

Dans les architectures historiques telles qu'IPsec (RFC 4301) et OpenVPN, les décisions de routage et les contextes de chiffrement résident dans des domaines disjoints. Une implémentation IPsec sous Linux repose sur l'infrastructure XFRM : le sous-système de routage oriente le paquet vers une interface, mais celui-ci est intercepté par la base de politiques de sécurité (SPD). Le noyau doit exécuter des recherches multicritères sur les adresses source, destination, protocoles et ports pour trouver l'association de sécurité (SA) correspondante dans la base SAD.

Cette superposition de couches engendre des failles d'intégrité et des pénalités de performance :

1. Désynchronisation d'état : La mise à jour d'une table de routage sans révision rigoureuse des politiques SPD associées provoque des rejets de paquets inattendus ou des fuites de données en clair sur les liaisons physiques.
2. Complexité de configuration : La maintenance conjointe des tables de routage, des filtres de pare-feu (iptables ou nftables) et des règles IPsec exige des milliers de lignes de configuration, augmentant le risque d'erreur humaine.
3. Surcoût de résolution : Le traitement séquentiel de sélecteurs multifactoriels pour chaque paquet consomme des cycles processeur considérables, limitant le débit sur les réseaux très haut débit.

OpenVPN rencontre un écueil similaire dans l'espace utilisateur. Les flux transitent via des périphériques de caractères tun ou tap, multipliant les changements de contexte coûteux entre l'espace noyau et l'espace utilisateur.

Le paradigme fondamental : comment le routage par clé unifie identité et chemins IP

Le routage par clé cryptographique résout cette dichotomie par une liaison mathématique stricte : la clé publique statique Curve25519 d'un pair fait office d'identité cryptographique et de destination réseau autorisée.

Sous WireGuard, une interface réseau (telle que wg0) se comporte comme un commutateur réseau physique. Au lieu de faire correspondre des adresses MAC à des ports matériels, WireGuard associe des clés publiques à des préfixes IP. Chaque pair dispose d'une directive AllowedIPs contenant des blocs CIDR IPv4 et IPv6 :

# Exemple de configuration de pair WireGuard
[Peer]
PublicKey = 2b6w8mQv8J7yV9hZ0k1LmNoPqRsTuVwXyZ123456789=
Endpoint = 198.51.100.10:51820
AllowedIPs = 10.200.0.2/32, 2001:db8:cafe:1::2/128

Cette déclaration régit les flux entrants et sortants avec une rigueur absolue.

Architecture à double table : résolution sortante et vérification entrante

WireGuard sépare le traitement du trafic en deux phases complémentaires :

• Émission sortante (Outbound) : Lorsque le système transmet un paquet IP non chiffré sur l'interface wg0, WireGuard analyse son adresse IP de destination. Il exécute une recherche du préfixe le plus long (LPM) dans sa table AllowedIPs interne pour localiser le pair associé. Il chiffre ensuite le paquet avec la clé de session symétrique ChaCha20-Poly1305 correspondante et transmet le datagramme UDP vers l'adresse de transit du pair.
• Réception entrante (Inbound) : Lorsqu'un datagramme UDP chiffré arrive sur l'interface, le noyau le déchiffre et l'authentifie via les clés issues de la poignée de main Noise IK. Dès le déchiffrement opéré, WireGuard vérifie l'adresse IP source du paquet interne. Celle-ci doit obligatoirement correspondre à un préfixe AllowedIPs attribué à ce pair émetteur.

Filtrage anti-usurpation au débit de ligne : AllowedIPs face aux pare-feux

Ce contrôle entrant procure un filtrage anti-usurpation natif au débit de la ligne. Si un pair compromis injecte un paquet avec une fausse adresse IP source, l'anomalie est immédiatement sanctionnée :

Contrôle du paquet entrant déchiffré :
[Clé publique : Key_A] -> IP source interne : 10.200.0.99
Recherche dans l'arbre AllowedIPs : 10.200.0.99 est assigné à Key_B, PAS à Key_A.
Action : REJET SILENCIEUX DU PAQUET (Incrémentation du compteur rx_dropped)

Ce filtrage s'exécutant au niveau du pilote avant l'entrée dans la pile réseau globale, les paquets illégitimes ne peuvent altérer les caches ARP/NDP ni solliciter inutilement les chaînes de filtrage complexes (rp_filter).

Au cœur du noyau Linux : la structure en radix trie du fichier allowedips.c

Afin de garantir des transferts en quelques microsecondes, WireGuard rejette les listes linéaires chaînées. Le module du noyau Linux (drivers/net/wireguard/allowedips.c) exploite un arbre radix binaire compact optimisé pour le réseau.

Recherche du préfixe le plus long (LPM) sur arbre binaire compact

Le noyau maintient deux racines d'arbres distinctes par interface WireGuard : l'une pour l'espace IPv4 (clés de 32 bits) et l'autre pour l'espace IPv6 (clés de 128 bits). Chaque nœud représente un préfixe binaire et comprend des pointeurs vers la branche gauche (bit 0) et la branche droite (bit 1), ainsi qu'une référence vers la structure struct wg_peer :

/* Schéma simplifié issu de drivers/net/wireguard/allowedips.h */
struct allowedips_node {
    struct allowedips_node __rcu *bit[2];
    struct allowedips_node *parent;
    struct wg_peer *peer;
    u8 cidr;
    u8 bits[];
};

Lors de la résolution, l'algorithme parcourt l'arbre bit par bit en débutant par le bit de poids fort. Il mémorise le nœud le plus profond doté d'une référence de pair valide, garantissant une recherche en temps $O(K)$ ($K \le 32$ pour IPv4, $K \le 128$ pour IPv6). Les lectures s'effectuent sous synchronisation RCU (Read-Copy-Update), permettant des résolutions concurrentes totalement non bloquantes entre cœurs processeurs.

Gestion des sous-réseaux chevauchants et arbitrage entre pairs multiples

Le principe du routage par clé impose une unicité stricte : une adresse IP de destination ne peut pointer que vers un seul pair à la fois. Lors de configurations comportant des sous-réseaux qui se chevauchent, WireGuard applique une règle d'arbitrage sans ambiguïté :

• Si le pair B enregistre un préfixe identique à un préfixe préexistant du pair A, la propriété du préfixe est transférée au pair B.
• Si le pair B enregistre un sous-réseau plus précis (192.168.1.50/32) inclus dans le réseau plus large du pair A (192.168.1.0/24), l'arbre conserve les deux entrées. La règle du préfixe le plus long attribuera 192.168.1.50 au pair B, tandis que le reste du trafic ira vers le pair A.

Ce comportement assure un acheminement déterministe identique aux standards de l'Internet.

Itinérance dynamique des points de terminaison : persistance de l'état cryptographique

Dans les protocoles IPsec classiques, la session est assujettie à l'adresse IP et au port UDP externes. Si un appareil passe du Wi-Fi à la 5G, la modification de l'adresse externe interrompt le flux jusqu'à ce qu'une renégociation complète intervienne.

WireGuard dissocie totalement le point de transit externe de l'identité cryptographique. L'adresse de transit (Endpoint) n'est qu'une cible de cache :

1. Le pair mobile émet un paquet chiffré depuis une nouvelle adresse externe (par exemple 203.0.113.88:41234).
2. Le serveur déchiffre et authentifie le paquet à l'aide de la clé de session.
3. Dès validation, le serveur met à jour dynamiquement l'adresse de transit interne sur 203.0.113.88:41234.
4. Tous les paquets émis en retour sont immédiatement acheminés vers ce nouvel emplacement.

Cette transition s'effectue sans aucune coupure de service ni renégociation cryptographique.

Routage du trafic global : neutralisation des boucles de routage par fwmark et ip rule

Lorsqu'une interface WireGuard est configurée comme passerelle par défaut (AllowedIPs = 0.0.0.0/0, ::/0), un phénomène de récursion apparaît : si tous les paquets sortants doivent emprunter wg0, les propres datagrammes UDP chiffrés émis par WireGuard sont renvoyés dans wg0.

Pour remédier à cette impasse, les déploiements modernes recourent au routage par politiques (Policy-Based Routing) associé au marquage de paquets (fwmark) :

# 1. Affectation d'un marqueur persistant à l'interface WireGuard
wg set wg0 fwmark 51820

# 2. Règle de routage orientant les paquets non marqués vers la table 51820
ip -4 rule add not fwmark 51820 table 51820
ip -4 rule add table main suppress_prefixlength 0

# 3. Déclaration de la passerelle par défaut dans la table 51820
ip -4 route add default dev wg0 table 51820

Lorsqu'une application transmet des données, le noyau constate l'absence de marque 51820. La règle not fwmark 51820 active l'usage de la table 51820 et oriente le flux vers wg0.

Une fois le paquet chiffré, le noyau appose automatiquement la marque 51820 sur le datagramme UDP sortant grâce à la configuration de wg0. Lors de la seconde étape de routage, ce paquet marqué ignore la table 51820 et s'échappe via l'interface réseau physique (telle que eth0), neutralisant la boucle.

Routage par clé face aux architectures de politiques IPsec SPD/SAD

La comparaison technique entre le routage par clé de WireGuard et le cadre XFRM d'IPsec souligne les avantages de la simplification architecturale :

Comment RiceGuard accélère la recherche en arbre radix et le multi-acheminement Anycast

Au sein de l'architecture de VPNRice, le moteur d'accélération RiceGuard optimise les mécanismes de routage par clé pour les réseaux Anycast distribués :

• Traitement déporté via eBPF et XDP : RiceGuard intègre les tables AllowedIPs sous forme de structures eBPF de type le plus long préfixe (BPF_MAP_TYPE_LPM_TRIE). Les paquets subissent le contrôle cryptographique au niveau du pilote XDP avant l'allocation mémoire système, permettant d'atteindre plus de 14 millions de paquets par seconde.
• Routage de retour Anycast optimisé : Dans une architecture Anycast où plusieurs passerelles partagent des annonces IP identiques, RiceGuard synchronise l'état des points de transit entre les nœuds régionaux pour maintenir les sessions actives lors d'oscillations de routes BGP.
• Convergence instantanée : Lors des migrations de sous-réseaux, RiceGuard actualise les tables de routage en quelques microsecondes sans renouveler les clés de session, garantissant un temps de latence minimal.

Inspection pratique des tables de routage internes et des transferts de paquets

Les administrateurs système peuvent inspecter le fonctionnement du routage par clé au moyen des utilitaires standards Linux.

Afficher la liste des pairs configurés et leurs sous-réseaux AllowedIPs associés :

# Consultation de l'état de l'interface WireGuard et des AllowedIPs
wg show wg0

Vérifier les règles de routage par politiques régissant la passerelle par défaut :

# Examen des règles de politiques et de la table personnalisée
ip rule show
ip route show table 51820

Identifier les paquets rejetés pour cause de discordance avec les préfixes autorisés :

# Surveillance des compteurs de paquets rejetés sur l'interface
ip -s link show dev wg0
grep -E "AllowedIPs" /var/log/messages 2>/dev/null

Ajouter dynamiquement une plage d'adresses autorisée sans redémarrer le tunnel :

# Mise à jour des sous-réseaux AllowedIPs d'un pair en production
wg set wg0 peer "2b6w8mQv8J7yV9hZ0k1LmNoPqRsTuVwXyZ123456789="   allowed-ips "10.200.0.2/32,192.168.10.0/24"

Perspectives d'avenir : protocoles de routage dynamique BGP et OSPF sur WireGuard

Une interface WireGuard fonctionnant comme une interface réseau classique, elle s'associe aisément avec les suites de routage dynamique telles que FRRouting (FRR) ou BIRD.

En configurant AllowedIPs = 0.0.0.0/0, ::/0 entre routeurs de confiance, WireGuard établit une liaison chiffrée sécurisée au-dessus de laquelle les protocoles BGP et OSPF échangent des métriques et des annonces d'état de liens de manière dynamique.

Le routage par clé constitue une avancée majeure en matière d'ingénierie réseau : il supprime les couches d'abstraction superflues tout en renforçant les garanties de sécurité. En unifiant identité cryptographique et routage des paquets, WireGuard offre une base pérenne pour les communications sécurisées à haute performance.