WireGuard AllowedIPs : un champ qui fait deux métiers (et pourquoi le vôtre est faux)

Presque tous les problèmes de configuration WireGuard qui survivent à un handshake réussi tiennent à un seul champ, et au fait que presque personne ne le lit correctement. AllowedIPs ressemble à une directive de routage. Il l'est, et il est autre chose en même temps.

Ce que dit réellement le manuel

La page de manuel de wg le définit en une phrase qui mérite une lecture lente :

a comma-separated list of IP (v4 or v6) addresses with CIDR masks from which incoming traffic for this peer is allowed and to which outgoing traffic for this peer is directed

Deux propositions, deux métiers différents. Sortant : les paquets dont la destination tombe dans cette liste sont envoyés à ce pair. C'est la moitié routage, celle que tout le monde connaît. Entrant : les paquets qui arrivent de ce pair ne sont acceptés que si leur adresse source tombe dans cette même liste. C'est une liste de contrôle d'accès, et c'est la moitié qu'on ignore.

C'est ce que WireGuard appelle le cryptokey routing : l'association entre une clé publique et un ensemble d'adresses constitue tout le modèle d'autorisation. Aucune règle de pare-feu séparée ne décide quel pair a le droit de revendiquer quelle adresse.

La conséquence que personne n'anticipe

Mettez AllowedIPs = 0.0.0.0/0 sur un pair et vous n'avez pas seulement routé tout votre trafic vers lui. Vous avez aussi déclaré que ce pair peut vous envoyer un paquet prétendant venir de n'importe quelle adresse source d'internet, et votre interface l'acceptera.

Sur un client dont l'unique pair est votre propre serveur, c'est exactement ce que vous voulez et c'est la configuration normale en tunnel complet. Sur un serveur à plusieurs pairs, ou sur toute machine où un pair n'est pas pleinement de confiance, c'est un trou ouvert sans s'en apercevoir.

Gros plan en noir et blanc de boîtes aux lettres métalliques numérotées, les numéros 31 à 40 écrits à la main sur de petites étiquettes. Chaque boîte porte exactement un numéro et aucun numéro n'apparaît deux fois : c'est la contrainte qu'AllowedIPs impose entre les pairs.

Pourquoi deux pairs ne peuvent jamais partager une plage

Puisque la liste décide vers quel pair une destination est envoyée, une même adresse ne peut pas appartenir à deux pairs à la fois : la correspondance doit être univoque. En pratique, c'est pour cela que du côté serveur chaque client reçoit son propre /32 (ou /128 en IPv6) plutôt que le sous-réseau entier.

L'asymétrie surprend. Sur le client, AllowedIPs décrit ce que vous voulez atteindre par le tunnel, souvent tout. Sur le serveur, il décrit qui ce pair précis a le droit d'être, en général une seule adresse. Le même champ, lu depuis deux bouts, veut dire deux choses différentes.

Le problème de l'exclusion du réseau local, et pourquoi la soustraction n'existe pas

La question réelle la plus fréquente est « comment router tout sauf mon réseau local ». Il n'existe aucune syntaxe de soustraction. 0.0.0.0/0 moins 192.168.1.0/24 ne s'exprime pas, parce que le champ est une liste de plages et rien d'autre.

La réponse consiste à énumérer le complément : au lieu d'un fourre-tout, vous listez l'ensemble des blocs CIDR qui couvrent tout l'espace d'adressage sauf la plage que vous voulez garder locale. C'est ingrat, cela produit une longue ligne, et c'est la seule façon correcte. Les fourre-tout eux-mêmes sont documentés sans ambiguïté : 0.0.0.0/0 correspond à toutes les adresses IPv4, ::/0 à toutes les IPv6.

Le symptôme qui mène ici

Un handshake qui aboutit, puis rien. wg show affiche un handshake récent, les pairs se sont manifestement trouvés, et aucun trafic ne passe. Quand le handshake fonctionne, les clés et le point de terminaison sont corrects par définition : le problème est donc en aval, et AllowedIPs est le premier endroit où regarder. Soit la destination n'est pas dans la liste du côté émetteur, soit la source n'est pas acceptée du côté récepteur.

Si c'est le handshake lui-même qui n'aboutit jamais, le diagnostic est tout autre et notre guide de dépannage du handshake le couvre. Et si les paquets circulent mais que les pages se figent à mi-chemin, vous avez probablement affaire à un problème de MTU plutôt qu'à ce champ.

À ne pas confondre avec PersistentKeepalive

On les mélange parce que les deux apparaissent dans la section du pair et que les deux semblent porter sur « maintenir la connexion ». Ils n'ont aucun rapport. Le manuel décrit PersistentKeepalive comme un intervalle, entre 1 et 65535 secondes, réglant la fréquence d'envoi d'un paquet vide authentifié vers le pair, afin de maintenir valide une entrée de pare-feu à états ou de NAT. Il est désactivé par défaut, et le manuel ajoute que la plupart des utilisateurs n'en auront pas besoin.

AllowedIPs décide de ce qui est permis. PersistentKeepalive décide à quelle fréquence vous frappez à la porte pour qu'un boîtier NAT n'oublie pas votre existence.

Le faire juste du premier coup

Réglez les entrées de pair côté serveur sur une adresse par client et rien de plus. Réglez le client sur les plages que vous voulez réellement atteindre : les fourre-tout pour un tunnel complet, les sous-réseaux précis pour un tunnel partagé. Relisez chaque ligne AllowedIPs deux fois : une fois comme une route, une fois comme une liste d'invités. Nos modèles de configuration prêts à l'emploi appliquent cette séparation.

Le champ est petit, il accepte à peu près tout ce que vous tapez, et il échoue en silence quand il est faux. C'est cette combinaison qui lui vaut plus d'attention qu'on ne lui en accorde d'ordinaire.

★ Datacenter Nuremberg GDPR · ✓ IPv4 dédiée incluse · 200+ Mbps garantis

Héberge ton VPN sur ton propre VPS → ContaboAccès root complet · IPv4 publique · choisis ta région→

Questions fréquentes

À quoi sert AllowedIPs dans WireGuard ?

Il fait deux choses à la fois. Le manuel de wg le définit comme la liste des adresses depuis lesquelles le trafic entrant de ce pair est autorisé, et vers lesquelles le trafic sortant destiné à ce pair est dirigé. C'est donc simultanément une règle de routage pour ce que vous envoyez et une liste de contrôle d'accès pour ce que vous acceptez. La plupart des erreurs viennent de ne lire que la première moitié.

Pourquoi mon handshake réussit-il sans qu'aucun trafic ne passe ?

Parce que le handshake prouve seulement que les clés et le point de terminaison sont corrects. Ce qui arrive aux paquets ensuite est décidé par AllowedIPs. Soit la destination que vous cherchez à joindre n'est pas listée du côté émetteur et rien n'entre dans le tunnel, soit l'adresse source n'est pas listée du côté récepteur et le paquet est jeté à l'arrivée.

Deux pairs peuvent-ils avoir le même AllowedIPs ?

Non, et la raison est structurelle et non une règle de propreté. Puisque la liste décide vers quel pair une destination donnée est envoyée, une adresse appartenant à deux pairs rendrait le choix ambigu. C'est pourquoi chaque client reçoit normalement son propre /32 côté serveur plutôt que le sous-réseau entier.

Comment exclure mon réseau local du tunnel ?

En énumérant le complément, car le champ n'a aucune syntaxe de soustraction. Plutôt qu'un fourre-tout, vous listez les blocs CIDR qui couvrent ensemble tout l'espace d'adressage sauf la plage à garder locale. Le résultat est une longue ligne, et c'est la seule façon correcte de l'exprimer.

Quelle différence entre AllowedIPs et PersistentKeepalive ?

Ils résolvent des problèmes sans rapport. AllowedIPs décide quel trafic est permis dans chaque sens. PersistentKeepalive est un intervalle, entre 1 et 65535 secondes, réglant la fréquence d'envoi d'un paquet vide authentifié pour qu'une entrée de pare-feu à états ou de NAT reste valide. Il est désactivé par défaut et le manuel note que la plupart des utilisateurs n'en auront pas besoin.