Pourquoi un serveur VPN derrière CGNAT n’accepte jamais de connexions
Une adresse 100.64, un nom DNS dynamique qui se résout ailleurs et aucune poignée de main entrante sont un seul problème : le NAT de l’opérateur. Confirmez-le, puis relayez le trafic sortant.
Le routeur annonce une adresse WAN commençant par 100.72, le nom DNS dynamique se résout vers une autre adresse publique, et le serveur VPN de ce routeur n’achève jamais de poignée de main depuis l’extérieur. La redirection de ports est configurée, le service tourne, et un test depuis le LAN fonctionne toujours. Rien dans le journal du routeur ne ressemble à une erreur. Cette combinaison est du NAT de niveau opérateur, et aucune règle de pare-feu ne peut ouvrir un port sur une adresse détenue par le FAI.
Confirmer l’adresse partagée prend deux minutes et évite une semaine de changements de configuration.
Les signes qui désignent le NAT de l’opérateur
Comparez l’adresse WAN de la page d’état du routeur à l’adresse qu’indique une requête externe. Une adresse WAN dans 100.64.0.0/10 est le signe habituel, et les plages privées 10/8, 172.16/12 et 192.168/16 signifient la même chose. Si traceroute montre le même saut public répété, ou qu’un saut précoce répond avec une adresse privée, un autre traducteur se trouve entre le routeur et Internet. Certains FAI ne listent l’adresse attribuée que dans le portail client, alors exportez cette valeur avec le traceroute.
Changer de protocole ou de port n’aide pas, car le problème est l’accessibilité entrante et non un port fermé.
Pourquoi la redirection et le DNS dynamique ne peuvent pas y remédier
Une règle de redirection de port mappe un port sur l’interface WAN du routeur, mais le trafic entrant n’atteint jamais cette interface : le FAI le traduit d’abord et ne transmet que ce que sa propre table autorise. Publier l’adresse partagée dans le DNS dynamique dirige les clients vers une passerelle du FAI utilisée par de nombreux abonnés, ce qui explique que le nom se résolve et que la poignée de main échoue toujours. Les tests en hairpin réussissent parce que le routeur répond à sa propre règle depuis l’intérieur, et UPnP a exactement le même angle mort.
Reconfigurer le client n’aidera pas non plus, car la défaillance survient avant la lecture du moindre réglage client.
Relayer via un VPS avec des routes explicites
Placez une adresse publique devant en louant le plus petit VPS capable de porter le trafic, puis faites composer le routeur domestique vers lui. L’UDP sortant du réseau domestique traverse le NAT de l’opérateur, donc le tunnel s’établit de l’intérieur et le VPS devient le point de terminaison joignable. Le côté domestique devient un client avec une adresse de tunnel fixe, pas un serveur.
Sur le VPS, ajoutez une entrée d’annuaire propre au client pour que le serveur sache quel pair possède le sous-réseau domestique, et ajoutez une route de noyau correspondante.
# /etc/openvpn/server/ccd/home-site.conf ifconfig-push 10.8.0.10 255.255.255.0 iroute 192.168.50.0 255.255.255.0 # server.conf client-config-dir /etc/openvpn/server/ccd route 192.168.50.0 255.255.255.0 push "route 10.8.0.0 255.255.255.0"
La ligne iroute indique à OpenVPN quel client reçoit le trafic du sous-réseau domestique ; la ligne route place ce sous-réseau dans la table du noyau du VPS pour que les paquets entrent dans le tunnel. Pour un service publié, ajoutez une règle NAT de destination qui redirige le port public vers 10.8.0.10 et activez net.ipv4.ip_forward.
Testez le chemin depuis l’extérieur
Vérifiez chaque saut côté public, car un tunnel réussi ne prouve pas que le service est joignable. L’état d’écoute et la capture de paquets sur le VPS distinguent « rien n’est arrivé » de « arrivé puis rejeté ».
ss -lunp | grep 1194 tcpdump -ni any udp port 1194 nft list ruleset | grep -A4 dnat # from a phone on mobile data, not the home Wi-Fi nc -vz -u 203.0.113.10 1194
Si la capture montre des paquets venant du téléphone mais aucune réponse, la configuration du serveur ou le pare-feu sont l’étape suivante. Si la capture ne montre rien, le client résout encore ou envoie à la mauvaise adresse.
Des alternatives à chiffrer en premier
Une adresse IPv4 dédiée fournie par le FAI est la solution la plus courte et coûte généralement un petit abonnement mensuel. L’IPv6 natif supprime la traduction aux deux extrémités lorsque le VPN, le réseau client et les enregistrements DNS le prennent tous en charge. Un maillage superposé avec un routeur de sous-réseau dans le réseau domestique réalise le même relais sans VPS, au prix d’une dépendance à un service de coordination.
Choisissez le relais lorsque l’exigence est un accès entrant stable et que chaque règle doit rester sous votre contrôle. Choisissez l’adresse du FAI lorsque le budget le permet et que le but est simplement de ne plus y penser.