AllowedIPs est une liste de routage, pas une règle de pare-feu

La plupart des gens lisent AllowedIPs comme une liste d'autorisations, l'ensemble des adresses qui peuvent se connecter à un pair, un peu comme une règle de pare-feu écrite pour un tunnel. Ce n'est pas cela. Le champ est une table de routage qui travaille dans les deux sens : il choisit un pair pour un paquet sortant et il valide la source d'un paquet entrant. Le lire comme une liste d'accès produit des configurations qui routent du trafic que personne n'a demandé.

Un champ, deux lecteurs : choix sortant et contrôle de source

Côté client, les préfixes décident quelles destinations passent par ce pair et lesquelles restent sur le réseau ordinaire. Une entrée pour 0.0.0.0/0 capture donc toutes les destinations IPv4, et c'est pourquoi importer un profil de tunnel complet envoie la navigation ordinaire par la machine distante. Les entrées étroites font l'inverse : elles routent uniquement les réseaux que vous avez listés et laissent tout le reste là où il était. La section sur le routage des clés cryptographiques de la documentation WireGuard énonce les deux tâches au même endroit : la sélection du pair sortant et la validation de la source entrante.

Sur le serveur, le même champ décrit quelles adresses sources chaque pair peut utiliser. C'est un contrôle cryptographique et non un filtre de paquets : un paquet dont la source interne ne correspond pas à la liste du pair est supprimé à l'intérieur de WireGuard, avant qu'un pare-feu de l'hôte ne le voie. Les deux tâches partagent une seule liste, et c'est exactement pourquoi une liste copiée d'ailleurs se comporte mal à un endroit que vous n'aviez pas envisagé.

Le bloc client est là où commence la majeure partie de cette confusion. Un tunnel divisé nomme les réseaux distants, et un tunnel complet est le même champ avec un préfixe par défaut :

[Peer]
# split tunnel: only these networks
AllowedIPs = 10.77.0.0/24, 192.168.30.0/24

[Peer]
# full tunnel: everything, both families
AllowedIPs = 0.0.0.0/0, ::/0

Les deux formes sont complètes en elles-mêmes, et ce sont des alternatives plutôt que des étapes. La première n'envoie que ces deux réseaux par le tunnel ; la seconde envoie chaque destination, l'entrée ::/0 ajoutant IPv6 au défaut IPv4. Quel que soit votre choix, ces préfixes constituent toute la décision de routage pour ce pair dès que wg-quick commence à installer des routes.

Le concentrateur a besoin d'une autre liste

Un concentrateur liste l'adresse de tunnel de chaque client comme préfixe d'hôte, plus tout réseau réellement situé derrière ce client. Copier la liste large d'un client sur chaque pair du concentrateur lui dit que de nombreux pairs peuvent utiliser les mêmes adresses comme source, et ce n'est pas un plan d'adressage. Le champ Endpoint appartient à une tout autre couche : il nomme l'adresse et le port externes du pair, jamais une destination à l'intérieur du tunnel.

[Peer]
# laptop: tunnel address 10.77.0.2, office LAN behind it
AllowedIPs = 10.77.0.2/32, 192.168.30.0/24

Le préfixe d'hôte porte l'adresse du tunnel et le préfixe de réseau porte ce qui se trouve derrière le client, et les deux sont nécessaires. Sans le préfixe d'hôte, le concentrateur ne peut pas renvoyer le trafic propre du client, et sans le préfixe de réseau le LAN situé derrière reste inaccessible ; un pair sans rien derrière lui ne reçoit que le préfixe d'hôte.

Sauter l'installation des routes laisse un vide

wg-quick, l'assistant qui monte une interface depuis un fichier de configuration, installe les adresses d'interface et les routes dans le cadre de ce travail. Régler Table = off demande à l'assistant d'omettre le travail des routes, ce qui n'installe aucun remplacement et ne rend pas le réseau privé accessible. Quand les routes automatiques font déjà le travail, nommer les préfixes dont vous avez besoin est la configuration la plus claire. Désactiver la gestion des routes et laisser le remplacement non écrit n'est pas une conception, c'est un oubli.

L'outil de base wg se comporte différemment : il configure l'interface et ne touche jamais aux routes, donc une installation construite directement dessus a besoin de ses propres commandes de route. Des instructions écrites pour un outil peuvent sembler fausses lorsqu'on les suit avec l'autre. Un ping réussi est aussi une preuve faible, car il exerce un seul chemin plutôt que tous les chemins applicatifs dont vous avez besoin.

DNS et IPv6 se décident séparément

Vérifiez l'adresse du serveur DNS annoncée par le tunnel et confirmez qu'une route vers cette adresse existe via les préfixes choisis. Un réglage de résolveur ne rend pas le résolveur accessible, et rétrécir un tunnel peut retirer silencieusement la route qui y menait. Inspectez aussi IPv6 séparément, car un découpage IPv4 correct ne dit rien d'une route par défaut IPv6 qui pointe encore vers la liaison physique. Trois décisions distinctes peuvent changer en même temps lorsque vous modifiez un seul bloc de pair.

Ouvrez ensuite une ressource privée et un site web ordinaire depuis une configuration de départ connue. Si la ressource répond et que la navigation sort toujours par la connexion locale, le découpage fait ce que vous avez demandé. Si la navigation casse au même moment, le tunnel a pris la route par défaut et la liste de préfixes est l'endroit où regarder.