Port VPN muet ? Écouteur, adresse de liaison ou pare-feu de l'hôte

Le VPN ne répond rien sur son port, et les deux causes possibles exigent des réparations opposées : soit aucun processus n'a ouvert la socket, soit la socket existe et quelque chose entre les machines arrête les paquets. Une seule commande tranche la première moitié de cette question, c'est pourquoi elle passe avant toute règle de pare-feu. L'ordre ci-dessous retire une explication par étape au lieu d'ajouter une supposition de plus. C'est deviner entre les deux qui transforme un diagnostic de dix minutes en une soirée entière.

Supposez que vous pouvez vous connecter au serveur et que le client est un vrai profil et non un scanner. Les deux hypothèses comptent, car une sonde générique ne peut pas répondre à une question propre au protocole.

La socket existe-t-elle seulement

Commencez par ce que le service dit de lui-même : s'il a démarré et, plus utile, quelle a été sa première erreur au démarrage. Un échec d'analyse, une clé absente ou une erreur de liaison empêchent l'écouteur d'exister, et le processus peut sortir si discrètement que la ligne d'état se lit de façon ambiguë. Une unité qui se déclare active n'est pas une preuve en soi, car le processus principal peut être vivant alors que le composant censé lier le port a déjà renoncé.

systemctl status openvpn-server@server --no-pager
journalctl -u openvpn-server@server -n 30 --no-pager
ss -lunp

La liste des sockets est le fait sur lequel repose le reste du diagnostic. Lisez la colonne de l'adresse locale plutôt que le seul port, car c'est dans cette colonne qu'apparaissent les liaisons loopback et les liaisons sur la mauvaise interface. Un écouteur qui existe sur 127.0.0.1 fonctionne parfaitement et reste invisible pour votre portable.

Sur quelle adresse et quelle famille la socket répond

Deux erreurs se ressemblent depuis le client et expliquent la plupart des signalements "injoignable". Un serveur lié à l'adresse de loopback n'accepte jamais de trafic venant d'une autre machine, et un serveur lié uniquement à une adresse IPv4 ne répond jamais à un client qui compose l'adresse IPv6 du même hôte. Comparez l'adresse de la table des sockets à celle que le client compose réellement, caractère par caractère, avant de supposer quoi que ce soit sur la politique.

Limiter la liste à un seul port la garde lisible quand l'hôte fait tourner plusieurs services. Le filtre sport prend le port avec le transport que vous testez :

ss -lun 'sport = :51820'
ss -ltnp 'sport = :1194'

La colonne du protocole change toute la réponse

La table des sockets s'indexe sur le protocole autant que sur le port, et ce sont deux entrées indépendantes. Un service qui répond en TCP sur 1194 ne vous dit rien sur ce qui écoute en UDP 1194, et le client n'en utilisera jamais qu'un seul. Confirmez quel transport la configuration du serveur choisit et lequel envoie le profil du client, puis cherchez exactement cette ligne.

UDP a une seconde particularité : une sonde non authentifiée n'est pas une erreur que le service doit traiter. Un scan qui signale le port comme muet a mesuré la discrétion du service, pas sa disponibilité, testez donc avec le vrai client et le vrai profil.

Une tentative, trois endroits où regarder

Depuis un client approuvé, faites exactement une tentative et notez l'heure à la seconde. Lisez ensuite trois sources pour cette fenêtre : la règle réseau ou la console du fournisseur, les compteurs ou le journal du pare-feu de l'hôte, et le journal propre au service. Le faire une fois rend les trois récits comparables, et coûte moins que de répéter une tentative dont personne n'a noté l'horodatage.

Les deux issues pointent en sens opposés. Si aucun paquet n'a atteint l'hôte, le chemin le jette et l'écouteur est sans objet. Si le paquet est arrivé à la socket et que le service l'a rejeté, le chemin est bon et la réponse tient au protocole, à la cryptographie ou aux identifiants. Ouvrir un port pour un service qui a déjà accepté une connexion rend le diagnostic suivant plus difficile, pas plus facile.

Nommez l'étape avant de changer une règle

Une négociation qui démarre et une authentification qui échoue sont une seule panne, et un tunnel qui s'établit pendant que le transfert se bloque en est une tout autre. Nommer l'étape d'abord garde la réparation étroite : un problème d'identifiants ne se règle pas par une règle de pare-feu, et un problème de chemin de données ne se règle pas par un redémarrage.

Utilisez le diagnostic le plus étroit qui réponde à la question. Une observation temporaire de paquets sur un port, sous le contrôle d'un administrateur, est un instrument raisonnable ; désactiver tout le pare-feu ne l'est pas, car le résultat devient impossible à imputer. La documentation de ss couvre les filtres utilisés plus haut, et c'est un premier pas moins coûteux que n'importe quelle capture. Notez laquelle des deux branches vous avez prouvée, et l'occurrence suivante part d'une réponse connue.