Double NAT et votre VPN : le client fonctionne, le serveur non

Votre routeur se trouve derrière un autre routeur, l'adresse WAN est privée et le client VPN se connecte quand même. Cette combinaison surprend ceux qui attendent du double NAT qu'il casse les tunnels, mais ce sont justement les connexions sortantes que la traduction gère le mieux. Héberger un serveur VPN derrière les deux mêmes couches est le cas qui échoue habituellement. Dessinez le sens de la connexion avant de changer quoi que ce soit.

Dessinez d'abord le sens de la connexion

Ouvrez la page d'état du routeur intérieur, notez son adresse WAN, puis comparez-la à l'adresse qu'un service public vous indique. Si les deux diffèrent, au moins un traducteur se trouve entre votre routeur et internet. Si l'adresse WAN tombe dans 100.64.0.0/10, le traducteur extérieur appartient probablement à votre fournisseur, et vous ne le contrôlez pas. Ces deux faits déterminent laquelle des étapes suivantes peut fonctionner.

curl -s https://ifconfig.me
ip -brief address
traceroute -n 1.1.1.1

Le double NAT n'est pas un double VPN. La traduction réécrit les adresses et les ports ; elle n'ajoute pas un second tunnel chiffré et ne chiffre rien. Garder les deux idées séparées compte, car les solutions sont complètement différentes, et l'une d'elles suppose une conversation avec votre fournisseur plutôt qu'une page de réglages.

Sortant : le client demande, les traducteurs associent

Un tunnel sortant commence par un paquet de votre machine, donc chaque traducteur peut créer une association et laisser entrer la réponse. Le protocole, le port et les temporisateurs d'inactivité décident si cette association survit assez longtemps pour être utile. La plupart des routeurs grand public s'en sortent sans aucune configuration.

Les défaillances qui apparaissent vraiment concernent généralement les délais d'attente et la prise en charge des protocoles, pas le nombre de routeurs. Un tunnel qui tombe après quelques minutes de silence est une association qui expire, et un keepalive est la réponse habituelle. IPsec dispose d'extensions NAT-traversal standard, donc affirmer qu'il ne peut pas traverser une traduction est tout simplement faux. Si le tunnel ne s'établit pas du tout, regardez le point de terminaison et les identifiants avant d'accuser la topologie.

wg show
ping -c3 10.8.0.1

Arrêtez-vous si le tunnel sortant fonctionne depuis un réseau et pas depuis un autre. Cette comparaison porte sur les réseaux, pas sur le nombre de routeurs.

Entrant : le transfert ne couvre que l'équipement que vous possédez

Héberger un serveur, c'est le sens inverse : une nouvelle connexion arrive d'internet et doit atteindre votre machine en traversant chaque couche. Une règle de transfert de port sur le routeur intérieur n'aide que si le traducteur extérieur vous livre aussi ce trafic. Répéter la règle locale ne donne pas le contrôle de l'équipement du fournisseur.

nc -vz 203.0.113.10 51820
ss -lunp 'sport = :51820'

Comparez l'adresse WAN du routeur intérieur à l'adresse publique que vous avez observée, et notez d'où vient chaque valeur. Si l'adresse WAN est privée ou dans la plage partagée, la couche extérieure fait une traduction que vous ne pouvez pas configurer. Demandez au fournisseur quelle accessibilité entrante il prend en charge avant de passer une soirée sur des règles qui ne peuvent pas prendre effet. Retirer un routeur ou désactiver largement un pare-feu n'est pas un diagnostic, et c'est un mauvais échange pour un seul port ouvert.

Arrêtez-vous si la couche extérieure appartient au fournisseur et qu'elle ne transfère pas. Les réponses prises en charge sont alors une autre méthode d'accès ou un relais, pas une règle de plus de votre côté.

Testez une variable à la fois

Changez une chose par test et notez le résultat, car un chemin en double NAT a plus de variables qu'un chemin à un seul routeur. Gardez le profil et l'appareil fixes, puis comparez un autre réseau d'accès. Notez si la négociation échoue, si la session tombe après inactivité ou si seules les destinations privées échouent. Ces trois observations pointent vers trois couches différentes.

journalctl -u wg-quick@wg0 -n 30 --no-pager
ip route get 10.20.30.40

Les sous-réseaux privés qui se chevauchent sont un piège à part qu'aucune quantité de traduction ne corrige. Si votre réseau domestique et le réseau distant utilisent la même plage, un conflit de routes apparaît quel que soit le nombre de traducteurs entre eux. Renuméroter un côté est la seule réponse durable.

La passerelle distante mérite la même attention, car ses règles de transfert et ses routes de retour peuvent être la pièce manquante. Un tunnel qui s'authentifie peut malgré tout n'avoir aucun chemin applicatif utilisable, et cette défaillance est identique vue du client. Le parcours se termine quand vous pouvez dire quel sens échoue et quelle couche en est responsable.