Chaîner deux VPN : ce que cela cache et ce que cela coûte
Les tunnels imbriqués changent qui voit quel point de sortie, pas qui vous voit. Faites passer le point de sortie interne par le tunnel externe, puis vérifiez le DNS, le MTU et le repli.
Deux tunnels imbriqués ne vous rendent pas anonyme. Ils répartissent les observations entre deux fournisseurs, si bien qu'aucun des deux ne voit à la fois votre adresse de domicile et votre destination. C'est un avantage réel mais étroit, et il s'accompagne de problèmes de routage, de DNS et de MTU qui apparaissent la première fois que vous comptez dessus.
1. Décidez à quoi sert le second saut
Écrivez l'objectif en une phrase avant de configurer quoi que ce soit. Si l'objectif est que votre fournisseur d'accès ne puisse pas voir quels sites vous visitez, un seul tunnel y suffit. Si l'objectif est qu'aucun fournisseur unique ne puisse relier votre adresse à votre trafic, deux y suffisent. Si l'objectif est que personne ne puisse vous identifier, aucun nombre de sauts n'y arrive.
La chaîne n'est aussi solide que les journaux du fournisseur le plus faible et les dossiers de compte que tous deux conservent. Les paiements, l'e-mail d'inscription et la télémétrie de l'application restent entièrement hors du tunnel.
2. Rendez le point de sortie interne joignable via le tunnel externe
L'échec habituel est que le tunnel interne ne s'établit jamais. Une connexion externe en tunnel complet possède la route par défaut, donc la tentative du client interne d'atteindre son propre point de sortie est avalée par le tunnel externe et abandonnée ou mise en boucle. Le point de sortie interne a besoin d'une route explicite via l'interface externe, installée avant le démarrage du client interne. Sinon, la poignée de main fait la course avec la route et perd.
WireGuard montre le même conflit dans l'autre sens. Les AllowedIPs de chaque pair décident quelles destinations entrent dans ce tunnel, si bien qu'une interface interne qui revendique toutes les adresses revendique aussi le point de sortie externe, sauf si une route plus spécifique l'emporte. Des AllowedIPs qui se chevauchent sur deux interfaces forment une configuration où un côté perd en silence.
Le chaînage de conteneurs rend la séparation explicite et le piège évident. Un conteneur avec son propre espace de noms, sa propre route par défaut et un client à l'intérieur relaie ce que l'hôte lui envoie ; l'hôte ne se met pas de lui-même à utiliser ce chemin. Activez le relais, ajoutez une route pour le tunnel du conteneur et pointez le service vers l'adresse du conteneur.
3. Gardez le DNS sur le même chemin
Le DNS doit voyager là où voyage le trafic. Si le fournisseur interne impose ses résolveurs et que l'hôte interroge encore les résolveurs locaux, ces requêtes révèlent exactement les sites que le tunnel devait cacher. Vérifiez par une capture sur chaque interface de tunnel au lieu de faire confiance au panneau d'état du client. Une fuite ici est invisible en navigation normale et évidente dans une capture.
Les conceptions de DNS scindé compliquent cela, car une requête pour un nom local peut légitimement relever de l'extérieur du tunnel. Écrivez la liste des exceptions délibérément au lieu de la découvrir selon le résolveur qui a répondu par hasard.
4. Réglez le MTU avant que les utilisateurs ne le découvrent pour vous
Le MTU est l'autre victime prévisible. Deux encapsulations retirent deux en-têtes, et un tunnel externe qui a déjà abaissé le MTU du chemin laisse moins de place à l'intérieur. Les symptômes sont connus : les petites requêtes passent, les gros transferts et les poignées de main TLS calent.
ip link set dev wg1 mtu 1280 est le correctif brutal, et plafonner le MSS sur le relais est le plus propre. Réessayer la connexion n'est pas un correctif du tout.
5. Testez la panne que vous aurez vraiment
Coupez le tunnel externe exprès et regardez ce qui se passe. Une chaîne qui retombe silencieusement sur un chemin direct quand le saut externe meurt est pire que pas de chaîne du tout, car elle fuit précisément au moment où vous croyiez être couvert. Le comportement à viser est un kill switch qui arrête tout le trafic. Notez le résultat, car vous ne voudrez pas le redécouvrir au milieu d'un incident.
La latence et un second point de défaillance sont les coûts permanents. Deux sauts signifient aussi deux files d'assistance quand quelque chose casse à une heure peu pratique.