Le handshake OpenVPN échoue sur le Synology ? Vérifiez la redirection LAN

Votre ordinateur portable signale que le handshake TLS a échoué, alors la tentation est de reconstruire les certificats. Avant cela, posez une question plus ennuyeuse : sur quel port Ethernet le Synology écoute-t-il réellement ? Un NAS à deux ports LAN possède deux adresses, et le paquet VPN Server de DSM lie son écouteur OpenVPN à l’une d’elles. Quand le routeur redirige 1194 vers l’autre adresse, aucun paquet n’atteint jamais le service, et le client n’a rien avec quoi négocier.

Le texte de l’erreur trompe parce qu’il décrit la dernière chose que le client a tentée, non la première qui a mal tourné. Deux minutes à comparer la page du paquet avec la règle du routeur règlent la question.

Trouvez l’adresse à laquelle l’écouteur est lié

DSM nomme ses ports LAN 1 et LAN 2, et chacun porte une adresse et un sous-réseau distincts. Ouvrez VPN Server, lisez l’interface nommée dans l’onglet OpenVPN, puis ouvrez le Panneau de configuration et notez l’adresse IPv4 que DSM possède sur cette même interface. Ce sont ces deux valeurs, et non le nom d’hôte du NAS, que la redirection doit nommer.

Un second câble branché ne crée pas un second écouteur. Les deux liens peuvent apparaître connectés alors qu’une seule adresse accepte le trafic, et quand les deux interfaces se trouvent sur le même sous-réseau, les deux adresses diffèrent d’un chiffre que personne ne relit avant d’enregistrer une règle.

Regardez la socket elle-même via SSH, car c’est le seul endroit qui montre ce à quoi le démon s’est réellement lié, plutôt que ce que la page de réglages prévoit.

sudo netstat -anp | grep 1194

Modifiez la redirection existante plutôt que d’en ajouter une autre

Deux règles pour un seul port externe laissent le routeur libre de choisir, et celle qu’il choisit peut changer après une mise à jour du firmware ou un redémarrage. Ouvrez la règle qui existe déjà, changez son adresse interne, enregistrez, puis rouvrez-la et relisez la valeur. Nommer la règle d’après le service aide, car une liste de cinq redirections identiques est la façon dont la mauvaise survit.

external 1194/udp  ->  192.0.2.20:1194/udp

Gardez le port interne égal au port d’écoute, et gardez le protocole cohérent. UDP 1194 est l’écouteur par défaut, tandis qu’un profil TCP a besoin de son propre écouteur côté paquet et d’une redirection correspondante sur le routeur. Rediriger TCP vers un service qui n’écoute qu’en UDP produit du silence, pas une erreur.

Si l’adresse du NAS vient du DHCP, réservez-la avant que la règle soit enregistrée. L’expiration du bail réattribue l’adresse, la redirection continue de pointer vers l’ancienne valeur, et le handshake se met à échouer un jour où personne n’a touché au NAS. Une configuration statique côté NAS résout le même problème, à condition que l’adresse se trouve hors de la plage DHCP du routeur.

Prouvez si les paquets arrivent

Lancez d’abord une capture sur le NAS, puis connectez-vous depuis le client, et lisez l’adresse source dans la sortie. Une capture lancée après l’échec ne montre rien et ne prouve rien.

sudo tcpdump -i any -n udp port 1194

Le silence signifie que le trafic est mort avant le service : une adresse interne erronée, un port fermé sur le pare-feu de DSM, ou une interface administrativement arrêtée. Des paquets dans la sortie signifient que la redirection fonctionne, et la panne restante vit au-dessus de la couche réseau, ce qui est une zone de recherche bien plus petite.

La capture nomme aussi l’interface par laquelle le paquet est arrivé, et ce seul détail sépare une règle visant le mauvais port d’une règle visant un port qui n’est pas actif. Surveillez le compteur propre du routeur pendant la même tentative s’il en expose un. Un compteur qui ne bouge pas pendant que la capture reste vide désigne le routeur, tandis qu’un compteur qui bouge avec une capture vide désigne le chemin entre les deux appareils.

Quand les paquets arrivent, cessez d’accuser la redirection

Le profil est le suspect suivant, et la raison habituelle est l’âge. Un fichier .ovpn exporté contient l’autorité et le matériel du moment de l’export, donc un paquet dont le certificat a été remplacé plus tard rejettera un client qui porte encore l’ancienne copie.

Le transport est l’autre décalage qu’il vaut la peine de vérifier explicitement, parce que le profil et le paquet se modifient à des endroits différents. Passer un profil d’UDP à TCP sans basculer le paquet laisse le client attendre un écouteur qui n’existe pas, et le client signale le même texte générique de handshake qu’il signale pour tout le reste. Lisez la ligne proto du fichier, regardez ensuite le protocole sélectionné sur la page du serveur, et seulement alors concluez qu’ils concordent. Lire les règles du pare-feu de DSM est la troisième vérification : une règle qui autorise le port depuis le sous-réseau local mais pas depuis internet reste facilement en place après les tests, et elle produit une connexion qui fonctionne depuis la cuisine et échoue partout ailleurs.

Testez le chemin qu’un utilisateur distant emprunte vraiment

Un client à l’intérieur du même LAN peut atteindre le NAS sans jamais toucher la redirection, donc cela ne prouve rien sur l’accès distant. Utilisez un téléphone avec le Wi-Fi désactivé, ou demandez à quelqu’un hors du réseau, et surveillez le compteur du routeur pendant cette tentative. Si la tentative distante échoue alors que la locale réussit, la redirection ou le pare-feu sont encore en cause.

Notez l’état qui fonctionne pendant qu’il fonctionne : port externe, adresse interne, protocole, interface du paquet, ainsi que le nom du profil et la date d’export. Quand le handshake échouera de nouveau, la différence entre cette note et la configuration actuelle est la panne, et personne n’a à redécouvrir lequel des deux ports le service utilise.