Quand Debian me gonfle : Stretch et OpenVPN

Comme vous le savez sûrement, la nouvelle version stable de Debian, nom de code Stretch, est sortie. Je vous conseille à tous de faire la mise à jour les yeux fermés, ça va bien se passer, aucun accrochage à déplorer, un simple apt dist-upgrade et c’est une affaire qui roule.

…

Nan j’déconne.

Enfin je vous conseille quand même de faire la mise à jour bien entendu, pour des raisons évidentes de sécurité, prévoyez de le faire au moins à long terme. Parce que bon, la oldstable est toujours supportée à travers des mises à jour de sécurité, mais après y a plus rien, et votre serveur est livré à lui même et aux attaquants qui sauront profiter de failles non corrigées.

Ce que je veux dire, c’est qu’en mettant à jour votre distribution, attendez-vous à des trucs qui vont péter sévère. Faites-ça quand vous n’avez rien d’autre à faire et quand un minimum de choses vitales sont attendues de votre serveur par vos utilisateurs. Va y avoir du vilain.

Donc oui j’aime Debian, mais Debian me gonfle parfois. Notamment ce comportement très fâcheux que je viens de découvrir aujourd’hui même concernant OpenVPN.

OpenVPN, j’en ai déjà parlé et je ne m’étendrai pas plus là dessus, est un outil permettant de construire des réseaux virtuels privés (VPN), utiles pour abstraire des réseaux entre des machines géographiquement distantes et/ou pour déporter son point de sortie pour « sembler » se connecter d’ailleurs. Il y a donc une machine qui crée le VPN, dite serveur ou tête de pont, et des machines qui s’y connectent à distance, dites clients.

J’ai donc une tête de pont que j’ai récemment mis à jour sur Stretch. Tout se passa bien entendu parfaitement en apparence, et tout le monde il était beau. Je me retrouvai avec une jolie Debian Stretch toute mignonne dont le cœur et l’âme n’aurait en aucun cas pu être mis en doute par quiconque. Sauf que sous ses jupons, elle avait dissimulé des trucs moins fun. Et en conséquence, quelques jours après, je me rendis compte que mes clients OpenVPN ne se voyaient plus. Je ne mis pas longtemps à soupçonner la belle Stretch d’avoir des aveux à me faire.

L’élément fautif : le service Systemd a changé bien en profondeur.  Sous Jessie, les fichiers nécessaires pour l’établissement du VPN (configurations, certificats, clefs…) se trouvaient alors modestement dans /etc/openvpn, et ne faisait pas la distinction entre configurations clients et configurations serveurs. Le service utilisé pour démarrer OpenVPN était nommé tout simplement openvpn.service, et son boulot était uniquement de lancer une instance d’OpenVPN par fichier de configuration (dont le nom se terminait par .conf) dans ce dossier. Pour lancer openvpn, il suffisait donc de la commande simple suivante :

systemctl start openvpn

Sous Stretch, tout a été changé. Premièrement, le service a changé de nom très salement. Par salement, je veux dire que l’ancien nom existe toujours, mais a été remplacé par un service qui ne fait absolument rien (il lance le programme /bin/true, programme dont l’utilité crève les yeux), ce qui fait que ce changement de service implique non seulement une rupture de ce service si aucune action n’est prise par la suite, mais également que c’est très difficile de s’en rendre compte, le service ancien openvpn.service étant diagnostiqué par le système comme actif et bien portant. Donc, la nouvelle forme de ce service est en fait un couple de service, openvpn-client@.service et openvpn-server@.service, le premier se chargeant de lancer OpenVPN en temps que client, et le second en temps que serveur. Mais ce n’était pas fini : les configurations VPN devaient être déplacées aux nouveaux endroits adéquats, et la ségrégation entre clients et serveurs a été instaurée : désormais, les configurations clients doivent aller dans /etc/openvpn/client et les configurations serveurs dans /etc/openvpn/server. Mais ce n’est encore pas tout : ces nouveaux services ne s’invoquent plus de la même manière. On doit maintenant spécifier le nom de la configuration dans la commande qui démarre le service. Par exemple, pour une configuration serveur qui s’appelle hashtagueule.conf (dûment placée dans /etc/openvpn/server), la commande pour démarrer le service associé est donc :

systemctl start openvpn-server@hashtagueule

Pour couronner le tout, un bug de configuration, oui un bug, et non une modification de comportement, s’est glissée dans le fichier de service openvpn-serveur@.service. Ce fichier comporte la ligne suivante :

LimitNPROC=10

Cette directive est utile pour contrôler le nombre maximum de processus exécutés par un service, pour éviter dans certain cas l’explosion du load du serveur. Sauf qu’ici, cette valeur est beaucoup trop petite. On se retrouve alors avec l’erreur suivante consignée dans les logs :

openvpn_execve: unable to fork: Resource temporarily unavailable

Ce qui veut dire que le système refuse la création d’un nouveau processus pour ce service. Je me résolus donc à réparer salement et de manière non safisfaisante en changeant la valeur 10 par 100 (aucune idée si c’est carrément trop), et enfin, le service a accepté de fonctionner.

Quelle leçon tirer de cette aventure ? Premièrement, les mises à jour sont rarement simple, surtout dans le cas de Debian. Deuxièmement, même si le nouveau fonctionnement d’OpenVPN est désormais plus propre et correspond à l’usage conventionné sur les systèmes les plus récents, on peut déplorer la manière dont elle a été mise en place. Le bon usage aurait été d’instaurer une période de transition pendant laquelle les deux workflows auraient coexisté, plutôt que de casser brutalement une configuration existante et fonctionnelle. Et je ne parle même pas de la mauvaise limite du nombre de processus…

En espérant que cette histoire aura été utile à des gens, je vous souhaite une bonne mise à jour.