Tunnel complet WireGuard : AllowedIPs 0.0.0.0/0 ne suffit pas

Mettre 0.0.0.0/0, ::/0 dans les AllowedIPs d’un pair est l’étape dont tout le monde se souvient, et elle ne décide que du trafic que le pair est autorisé à transporter. Ces préfixes ne créent aucune route, ne transfèrent rien de l’autre côté et laissent le résolveur de chaque application exactement là où il était. Quatre choses distinctes doivent être vraies en même temps pour qu’un tunnel complet soit complet, et il vaut mieux les vérifier dans l’ordre ci-dessous, car une vérification tardive ne peut pas sauver une vérification antérieure. Chaque vérification ci-dessous est un fait qu’on peut lire sur une machine, pas un réglage dont on espère qu’il a été appliqué.

Ce que le préfixe du pair sélectionne, et ce qu’il ne sélectionne pas

AllowedIPs est à la fois un sélecteur et une autorisation. Il indique au côté local quelles destinations peuvent être envoyées à ce pair, et il indique au côté récepteur quelles adresses sources ce pair est autorisé à présenter. C’est tout le travail. Rien dans cette description ne crée de route sur l’hôte, n’active le transfert du côté distant ni ne touche à la résolution de noms.

C’est pourquoi une configuration peut sembler complète et se comporter comme un tunneling divisé. Le préfixe dit que le pair accepterait tout ; la table de routage de l’hôte décide de ce qui y arrive réellement, et la passerelle décide si quelque chose en sort. Aucune de ces trois décisions ne vit dans la section du pair.

Router le client, pas seulement la liste des pairs

Des gestionnaires comme wg-quick programment la table de routage de l’hôte pour vous, et c’est pourquoi deux fichiers de configuration identiques se comportent différemment selon la façon dont l’interface a été montée. Un profil minimal est assez court pour être lu d’un coup :

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

Deux détails portent le travail. Le champ Address est un préfixe d’hôte unique plutôt qu’un sous-réseau que le client croit posséder, et c’est le gestionnaire qui convertit les AllowedIPs par défaut en une véritable route par défaut. Montez le même fichier avec ip link et wg setconf et aucune route n’apparaîtra, ce qui ressemble à un tunnel cassé et est en réalité un tunnel sain dont l’étape de routage a été sautée. Le manuel de wg-quick documente le routage et le Table comportement que ces gestionnaires ajoutent.

Lisez le résultat plutôt que le fichier : ip route get 1.1.1.1 devrait nommer l’interface du tunnel, et wg show devrait signaler un handshake récent avec un compteur de transfert qui bouge. Un handshake sans route signifie que le gestionnaire n’a jamais tourné, et modifier à nouveau le profil n’y changera rien. Démarrez l’interface comme l’utilisateur la démarrera, sinon le test mesure votre shell au lieu du déploiement.

Garder le point de terminaison hors du tunnel

Un tunnel complet capture chaque destination, y compris celle à laquelle il doit parler pour exister. Les gestionnaires gèrent cela en ajoutant une route d’hôte pour le point de terminaison via la passerelle d’origine, et c’est pourquoi une configuration correcte contient presque toujours une exception délibérée. Appliquer la moitié de la configuration avec un gestionnaire et l’autre moitié à la main est la façon habituelle dont cette exception disparaît.

Si le point de terminaison est un nom d’hôte qui résout vers plusieurs adresses, ou vers une famille que vous ne transportez pas, l’exception vieillit mal et le tunnel peut échouer après une reconnexion qui semblait routinière. Épinglez le point de terminaison sur une adresse que vous contrôlez, ou confirmez que le gestionnaire la réévalue, et relisez la route d’hôte après chaque changement de réseau.

Le même mécanisme explique pourquoi un tunnel complet et un portail captif se disputent. Le portail s’attend à intercepter le trafic que votre tunnel capture désormais, donc sur les réseaux d’hôtel et d’aéroport vous montez le tunnel après la connexion au portail, jamais avant.

Transfert et chemin de retour sur la passerelle

Sur la passerelle, activez le transfert pour la famille que vous transportez, autorisez la chaîne forward dans les deux sens lorsque vous traduisez, et confirmez le chemin de retour par une recherche spécifique à la source. Rien de tout cela ne découle d’un handshake réussi, car un handshake prouve seulement que les deux pairs peuvent échanger de l’UDP. Il ne dit rien de ce qui arrive ensuite au paquet décapsulé.

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

La recherche s’exécute sur la passerelle et non sur le client, sinon vous lisez une autre table de routage. Si elle nomme la mauvaise interface, ou signale qu’il n’y a pas de route, alors aucun changement côté client ne produira de sortie internet. Lorsque la passerelle traduit les adresses des clients à la sortie, la réponse dépend de cet état de traduction, donc la règle doit exister pour les deux sens du flux et pas seulement pour le sens sortant.

DNS et l’état d’échec, testés séparément

Le protocole lui-même ne configure le résolveur d’aucune application. wg-quick applique la ligne DNS via l’intégration du résolveur de la distribution, les conteneurs et les navigateurs dotés de leurs propres piles peuvent l’ignorer, et un nom peut donc échouer alors que le tunnel transporte parfaitement les paquets. Testez avec un nom d’hôte plutôt qu’une adresse, et notez quel serveur a répondu au lieu de supposer que c’est celui du profil.

Les familles d’adresses sont un test distinct avec une réponse distincte. Une route par défaut v4 ne dit rien de ce que fera la connexion v6 d’une application, et un tunnel qui laisse fuir silencieusement la seconde famille est pire qu’un tunnel qui échoue bruyamment. Interrogez un nom sur chaque famille, lisez l’interface utilisée par chaque requête, et vérifiez les compteurs de traduction avant et après, car une règle qui ne correspond à rien ressemble à une règle manquante.

Enfin, testez l’état que vous voulez lorsque le tunnel s’arrête. Un tunnel complet devrait échouer fermé pour le trafic qu’il revendique : si l’interface tombe et que les applications continuent tranquillement par le lien physique, la conception est un tunneling divisé avec des étapes en plus. Écrivez le comportement d’échec prévu, vérifiez-le délibérément, et terminez en consignant les quatre réponses — quel gestionnaire monte l’interface, quelle route porte la route par défaut, qui transfère et traduit sur la passerelle, et quel résolveur répond.