Multi-hop WireGuard quand les deux serveurs sont à vous : ce que ça apporte vraiment

Le multi-hop est l'une des fonctionnalités les mieux marketées des VPN commerciaux : deux serveurs au lieu d'un, de sorte qu'aucune extrémité ne détienne le tableau complet. Le raisonnement est solide, et il mérite d'être bien compris avant de reproduire ce montage sur une infrastructure qui vous appartient, car ce qui fait sa valeur ne survit pas à l'auto-hébergement.

Ce que fait la technique

Votre client se connecte au serveur A. Le serveur A n'atteint pas internet pour votre compte ; il transmet votre trafic, toujours chiffré, au serveur B. C'est le serveur B qui dialogue avec la destination.

Le bénéfice annoncé découle de qui sait quoi. Le serveur A voit votre adresse réelle mais sait seulement que vous parlez à B. Le serveur B voit la destination mais reçoit du trafic venant de A, pas de vous. Aucun ne détient les deux moitiés.

C'est réellement ainsi que cela fonctionne, et c'est la raison d'être de la fonctionnalité.

Pourquoi l'auto-hébergement casse l'argument

Voici la partie que l'enthousiasme saute généralement.

La séparation décrite ci-dessus n'a de sens que si A et B sont exploités indépendamment. Les fournisseurs commerciaux s'appuient dessus : des serveurs différents, parfois des sociétés différentes, des juridictions différentes, aucun opérateur unique détenant les deux journaux.

Si vous louez vous-même les deux instances VPS, sur votre propre compte, payées avec votre propre carte, c'est vous le point commun. Quiconque est en mesure de contraindre ou de compromettre votre hébergeur peut voir les deux bouts de la chaîne, car les deux bouts sont les vôtres et ils sont reliés par la même identité de facturation. La propriété qui rend le multi-hop digne d'être payé dans un contexte commercial est précisément celle que vous ne pouvez pas reproduire seul.

Être clair là-dessus compte davantage que la configuration, car c'est ce qui décide si la configuration vaut la peine d'être faite.

Ce que cela vous apporte malgré tout

Deux bénéfices survivent à l'auto-hébergement, et tous deux relèvent de l'exploitation plutôt que de promesses d'anonymat.

L'étalement juridictionnel. Si le saut A se trouve dans un pays et le saut B dans un autre, une demande légale signifiée à un hébergeur ne produit qu'une moitié de la route. C'est une propriété réelle, et c'est l'argument le plus fort en faveur du chaînage de vos propres serveurs. Ce n'est pas de l'anonymat, c'est de la friction.

La résilience. Si un hébergeur bloque une plage de ports, vous bride ou subit une panne, une chaîne vous laisse un endroit où rerouter. Les montages à saut unique tombent entièrement quand leur unique hébergeur tombe.

Si aucun de ces deux points ne vous concerne, un simple saut bien configuré est la meilleure décision d'ingénierie, et c'est la recommandation honnête pour la plupart des gens qui lisent ces lignes.

Comment le routage fonctionne réellement

WireGuard n'a aucune notion de saut. Le chaînage est entièrement un exercice de routage, et le manuel de wg-quick en décrit les pièces.

wg-quick déduit toutes les routes depuis la liste des allowed IPs des peers et les ajoute automatiquement à la table de routage du système. Lorsque l'une de ces routes est une route par défaut, 0.0.0.0/0 ou ::/0, il utilise ip-rule pour gérer le remplacement de la passerelle par défaut.

Ce comportement est commode pour un tunnel, et c'est exactement ce que vous devez maîtriser pour deux. Trois points en découlent.

La machine intermédiaire doit relayer, pas terminer. Le saut A a besoin du transfert IP activé et d'une route vers le saut B. C'est un relais, pas une destination.

Le second endpoint doit rester joignable en dehors du premier tunnel. Si le tunnel du saut A capture 0.0.0.0/0, les paquets censés atteindre l'endpoint du saut B peuvent finir à l'intérieur du tunnel qui est justement supposé les transporter. C'est la boucle de routage classique, et c'est pourquoi le manuel documente l'option Table : off désactive complètement la création de routes, et auto, la valeur par défaut, ajoute les routes et active le traitement spécial des routes par défaut. Reprendre la main manuellement signifie généralement Table = off plus des routes explicites.

Les hooks font le reste. PostUp et PreDown sont des fragments de script exécutés par bash avant et après la mise en place ou la suppression de l'interface, couramment utilisés pour les règles de pare-feu, et %i est remplacé par le nom de l'interface. C'est là que doivent se trouver les règles de transfert et tout routage par politique.

Le coût, dit clairement

Chaque paquet traverse désormais deux machines et se retrouve chiffré puis déchiffré deux fois. La latence augmente, et sur une chaîne à cheval sur deux continents elle augmente sensiblement.

Vous avez aussi doublé votre surface d'exploitation. Deux serveurs à corriger, deux jeux de clés à faire tourner, deux endroits où une erreur de configuration peut faire disparaître silencieusement votre trafic ou, pire, le laisser fuir hors du tunnel. Notre guide sur la prévention des fuites DNS avec WireGuard s'applique ici en double.

Le résumé honnête

Le multi-hop fonctionne, et la version commerciale de l'argument est cohérente : deux serveurs exploités indépendamment, dont aucun ne détient les deux moitiés.

Auto-hébergez les deux et vous devenez le lien entre eux, ce qui supprime la propriété d'anonymat tout en laissant deux bénéfices réels : l'étalement juridictionnel et la résilience. Ils valent la latence pour certains et pas pour d'autres.

Si vous le construisez, le travail est dans le routage plutôt que dans WireGuard lui-même : le transfert sur le saut intermédiaire, le maintien du second endpoint en dehors du premier tunnel, et la reprise en main manuelle de la table de routage plutôt que de laisser deux tunnels revendiquer tous les deux la route par défaut.

Le comportement de wg-quick décrit ici, y compris la déduction des routes depuis les allowed IPs des peers, l'usage de ip-rule en présence d'une route par défaut, l'option Table avec ses valeurs off et auto, ainsi que les hooks PostUp et PreDown, est tiré de la page de manuel wg-quick(8), vérifiée au moment de la rédaction. Le raisonnement sur ce que change l'auto-hébergement relève de l'analyse et non de la documentation, et il vous appartient de le confronter à votre propre modèle de menace. Les liens commerciaux portent l'attribut rel="sponsored nofollow" ; une commission d'affiliation peut s'appliquer, sans coût supplémentaire pour vous.