La plupart des problèmes de VPN se ramènent à une poignée de causes, et les vérifier dans le bon ordre vous fait gagner une soirée. Lancez les commandes sur le serveur, sauf indication contraire. Les exemples utilisent WireGuard sur son port par défaut 51820/udp ; pour OpenVPN ou Xray, remplacez par le nom de votre service et votre port.
Dernière vérification le 2026-11-13.
1. Le serveur est-il sur une offre avec IPv4 dédiée ?
Un client VPN se connecte vers votre serveur. Une offre NAT ne laisse entrer de l'extérieur qu'un seul port, votre port SSH personnel, donc aucun VPN ne peut y fonctionner. Si le tableau de bord affiche une adresse avec un port du type 20xxx, vous êtes en NAT. Passer à une IPv4 dédiée conserve vos données et ne nécessite pas de réinstallation ; voir Changer d'adresse IP.
2. Le service tourne-t-il ?
systemctl status wg-quick@wg0
journalctl -u wg-quick@wg0 -n 30 --no-pager
Pour OpenVPN, l'unité s'appelle généralement openvpn-server@server ; pour Xray, xray. Un service qui n'a pas démarré donne presque toujours la raison dans les dernières lignes de son journal : une faute de frappe dans la configuration, un fichier de clé manquant, un port déjà utilisé.
3. Écoute-t-il sur le port attendu ?
ss -ulpn | grep 51820 # UDP : WireGuard, OpenVPN en UDP
ss -tlpn | grep 443 # TCP : Xray / VLESS, OpenVPN en TCP
Aucune sortie signifie que le service n'écoute pas sur ce port, quoi qu'en dise la configuration. Comparez le port avec celui de votre client.
4. Le pare-feu le laisse-t-il passer ?
ufw status verbose
Si le pare-feu est actif et que votre port n'apparaît pas, ouvrez-le :
ufw allow 51820/udp
Attention au protocole : WireGuard a besoin de UDP, et une règle 51820/tcp ne lui sert à rien. Laissez votre règle SSH en place avant d'activer ou de recharger le pare-feu, sinon vous vous enfermerez dehors. Si cela arrive malgré tout, la console dans le navigateur du tableau de bord vous permet de revenir.
5. Le client atteint-il vraiment le serveur ?
Pour WireGuard, c'est le handshake qui vous le dit :
wg show
latest handshake: N seconds ago sur un peer signifie que le client a atteint le serveur et que les clés correspondent. Aucune ligne de handshake signifie qu'il n'y est jamais arrivé. Vérifiez alors, dans cet ordre : l'IP et le port de l'endpoint dans la configuration du client, le pare-feu de l'étape 4, et la présence de la clé publique du client dans le bloc [Peer] du serveur (et inversement).
6. Connecté, mais rien ne s'ouvre ?
Le tunnel fonctionne, mais le serveur ne fait pas sortir le trafic vers internet. Vérifiez le transfert :
sysctl net.ipv4.ip_forward
La sortie doit être 1. Sinon, activez-le de façon permanente :
echo 'net.ipv4.ip_forward=1' > /etc/sysctl.d/99-vpn.conf
sysctl --system
Vérifiez ensuite la règle NAT. Dans une configuration WireGuard, c'est la ligne PostUp avec MASQUERADE, et le nom d'interface qu'elle contient doit être le vrai nom de celle de votre serveur :
ip -br addr
Si la ligne indique -o eth0 mais que votre interface porte un autre nom, corrigez la configuration et redémarrez le service.
7. Testez depuis un autre réseau
Connectez-vous via les données mobiles plutôt que le Wi-Fi de la maison, ou demandez à quelqu'un dans un autre pays d'essayer. Si le VPN fonctionne là-bas mais pas depuis votre réseau habituel, le serveur va bien et quelque chose entre les deux bloque la connexion.
- Pour savoir si votre serveur est joignable depuis un pays donné : Comment vérifier si l'IP de votre VPS est joignable depuis la Russie et l'Iran.
- Là où WireGuard et OpenVPN sont reconnus et bloqués, VLESS + Reality ressemble à du HTTPS ordinaire et est bien plus difficile à bloquer.
8. Toujours bloqué ?
Ouvrez un ticket en indiquant ce que vous avez vérifié : la sortie des étapes 2 à 5 et le nom de votre client VPN. Avec cela, nous pouvons généralement vous dire où ça coince dès la première réponse.
Commentaires
Pas encore de commentaires. Soyez le premier.