NAS Synology à deux ports LAN : pourquoi la poignée de main VPN échoue

L'ordinateur portable signale un échec de poignée de main TLS, ce qui ressemble à un problème de certificat et ne l'est généralement pas. Sur un NAS à deux ports Ethernet, la cause la plus fréquente est une redirection du routeur visant l'adresse sur laquelle le paquet n'écoute pas, et le message du client est identique dans les deux cas. Le paquet ne répond pas sur le second port simplement parce que les deux câbles sont branchés. Avant que quiconque réémette un certificat, prouvez qu'un paquet atteint bel et bien le NAS.

Ce que le client signale et ce qui s'est réellement passé

L'échec de poignée de main d'un client OpenVPN est une appellation générique. Elle couvre une divergence de certificat, une divergence de transport, un écouteur sur un autre port et une redirection qui n'a rien livré. C'est pourquoi le message est inutile comme point de départ et utile uniquement comme confirmation. Traitez-le comme l'affirmation que la session ne s'est pas établie, et rien de plus précis.

Le port et l'adresse liée sont les deux faits qui décident si un paquet arrive un jour.

Notez les deux avant de changer quoi que ce soit, car un correctif plausible appliqué à la mauvaise couche est la façon dont un problème de quinze minutes devient tout un après-midi. Relevez l'interface, l'adresse qui s'y trouve, le port et le transport. Ces quatre valeurs constituent tout le chemin entrant, et la section suivante explique où chacune d'elles réside.

Trouvez l'adresse sur laquelle le paquet écoute

DSM numérote les ports Ethernet et chacun porte sa propre adresse. La page VPN Server nomme l'interface qu'utilise le service OpenVPN, et le panneau réseau affiche l'adresse configurée sur cette interface. Lisez-les dans cet ordre, du service vers l'extérieur, afin de décrire ce qui écoute plutôt que ce que vous supposez qu'il devrait utiliser.

Le service lie une adresse. Le fait que les deux ports soient connectés et actifs n'amène pas le service à répondre sur le second. Une adresse statique sur une interface à côté d'une adresse DHCP sur l'autre vous donne deux valeurs semblables faciles à confondre d'un coup d'œil, surtout lorsqu'elles ne diffèrent que par le dernier octet. Copiez l'adresse depuis le panneau au lieu de la taper de mémoire. Confirmez ensuite sur le NAS ce qui est réellement lié au port.

sudo ss -lunp | grep 1194

Si cette sortie nomme une adresse que vous n'attendiez pas, la redirection vise la mauvaise interface et tout le reste ici n'est que comptabilité. Corrigez la règle avant de lire la suite, sinon vous finirez par déboguer un certificat à cause d'un paquet qui n'a jamais quitté le routeur.

Réparez la redirection, puis surveillez le compteur

Modifiez la règle de redirection existante au lieu d'en ajouter une seconde pour le même port externe. Deux règles peuvent coexister dans la table d'un routeur et une seule gagne toujours, ce qui transforme une séance de débogage en discussion sur celle qui est réelle. Pointez l'adresse interne vers la valeur que vous avez lue sur le NAS, et laissez le port interne correspondre à ce sur quoi le service écoute.

Si DSM obtient cette adresse par DHCP, créez d'abord une réservation. Un changement de bail casse silencieusement une redirection qui fonctionnait hier.

sudo tcpdump -i any -n udp port 1194

Lancez la capture avant que le client n'essaie de se connecter, et lisez l'adresse source dans tout ce qui apparaît. Rien du tout signifie que quelque chose en chemin l'a jeté : la redirection, le pare-feu de DSM ou l'interface visée, et les certificats ne peuvent pas être la cause tant que cela tient. Quelque chose qui arrive de l'adresse publique du client sans réponse signifie que le NAS a reçu la requête et a choisi de ne pas répondre. Ce sont des constats différents, et seul le second vous renvoie dans les réglages du paquet lui-même.

C'est seulement alors que vous regardez les certificats et le transport

Une fois les paquets arrivés, réexportez le profil après tout changement de certificat, car l'ancien fichier porte encore l'autorité avec laquelle il a été créé. Un profil modifié à la main pour un autre transport laisse le client attendre un écouteur qui n'existe pas, et il signale le même échec générique que tout le reste. Comparez le transport dans le profil avec le transport que le paquet est réglé pour servir. Deux profils pour deux transports constituent une conception légitime, et un profil modifié pour les deux ne l'est pas.

Testez depuis l'extérieur de votre propre réseau en dernier, car une connexion depuis le LAN peut réussir par un chemin qui ne touche jamais la redirection.

Conservez le profil exporté, l'adresse de l'interface et la règle de redirection ensemble dans une note. Quand une adresse change, cette note fait la différence entre un correctif et une redite. Rien sur ce chemin n'a exigé de réinstaller un paquet, ce qui mérite d'être retenu avant que le prochain redémarrage ne soit mis en cause.