L’écouteur OpenVPN 2.5 sur DD-WRT est mort ? Lisez la configuration générée

Un écouteur mort sur DD-WRT signifie généralement que le démon s’est arrêté pendant l’analyse de sa configuration, pas qu’une règle de pare-feu a bloqué le port. OpenVPN 2.5 a durci plusieurs valeurs par défaut sur lesquelles reposaient les anciennes configurations, et une configuration générée qui fonctionnait sur une version plus ancienne peut être rejetée avant même que le socket ne soit ouvert. La raison se trouve dans le journal du routeur lui-même, et l’entrée dans le fichier généré. Lire les deux dans cet ordre est plus rapide que n’importe quelle capture de paquets.

Le démon n’est pas le pare-feu

La distinction compte parce que les deux pannes se ressemblent de l’extérieur : un client envoie une poignée de main et ne reçoit rien. L’une est un processus qui ne tourne pas, l’autre un processus qui tourne et filtre.

Séparez-les par deux vérifications avant de changer quoi que ce soit, car modifier le pare-feu sur un démon mort n’ajoute qu’une seconde variable.

Lisez la configuration générée par DD-WRT

DD-WRT ne transmet pas à OpenVPN le texte que vous avez saisi dans l’interface web. Il écrit une configuration générée dans /tmp/openvpn/openvpn.conf et démarre le démon avec ce fichier, si bien que les champs de l’interface et tout texte d’Additional Config sont fusionnés avant qu’OpenVPN ne les voie. Si vous déboguez le formulaire au lieu du fichier généré, vous lisez une intention et non l’entrée réelle. Copiez ce fichier dans un emplacement persistant avant qu’un redémarrage /tmp ne le vide.

Comparez le fichier généré à ce que vous vouliez, surtout là où l’interface écrit une directive que vous n’avez jamais choisie. Une liste déroulante qui émet une option obsolète est invisible dans le formulaire et fatale pour le démon.

Si le fichier généré est vide ou absent, le démon n’a même pas atteint le démarrage, et le problème se situe en amont d’OpenVPN.

Ce qu’OpenVPN 2.5 a cessé d’accepter

OpenVPN 2.5 a remplacé ncp-ciphers par data-ciphers, et il a relevé la version minimale de TLS par défaut à 1.2. Il a aussi changé le traitement de la compression, de sorte qu’un pair qui propose la compression est refusé sauf si la configuration l’autorise explicitement, et il a rendu obsolètes des noms d’option plus anciens comme ns-cert-type au profit de remote-cert-tls. Chacun de ces changements transforme une configuration qui fonctionnait en échec d’analyse ou de négociation.

Le mode de panne dépend de la directive. Une option inconnue ou supprimée arrête le démon au démarrage, c’est votre écouteur mort. Un désaccord de négociation laisse le démon tourner et refuse les clients, ce qui, côté client, ressemble à un problème de pare-feu.

Lisez la première erreur du journal, pas la dernière. L’analyse s’arrête à la première directive fautive, et tout ce qui suit n’est que bruit d’arrêt.

Les prérequis propres à Broadcom

Sur les versions Broadcom, le périphérique de tunnel doit exister avant que le démon puisse l’utiliser. Vérifiez que le module tun est chargé et que /dev/net/tun est présent, car un périphérique manquant produit un échec de démarrage qui n’a rien à voir avec les certificats. Il en va de même des scripts auxiliaires que DD-WRT génère pour les routes et le DNS : s’ils manquent ou ne sont pas exécutables, le démon peut démarrer et malgré tout ne pas terminer sa configuration.

Lancez le démon au premier plan avec une verbosité plus élevée sur la configuration générée lorsque vous avez besoin du message réel. Une exécution au premier plan imprime l’erreur d’analyse que le script init a avalée.

Restaurez ensuite le service normal, car un démon au premier plan et le script init vont se disputer le port.

Prouvez que l’écouteur existe avant de déboguer les clients

Confirmez le processus et le socket séparément : une commande pour le démon en cours d’exécution, une autre pour un port UDP lié à l’adresse attendue. Un processus sans socket signifie qu’il est encore en configuration ou lié à la mauvaise interface. Le couple est un test utile précisément parce qu’une moitié ne peut pas être vraie sans l’autre.

Le débogage côté client n’a de sens qu’une fois l’écouteur existant. Vérifiez alors que le chiffrement et les réglages TLS du client correspondent à la liste data-ciphers du serveur et à sa version minimale, et que le port est bien redirigé vers le routeur.

Conservez la configuration générée et la ligne de journal qui a prouvé la correction. La prochaine mise à jour du firmware peut changer à nouveau les valeurs par défaut, et c’est cette trace qui transforme une récidive en vérification de cinq minutes.