19. Démarrer un daemon OpenVPN en utilisant inetd ou xinetd

Le service xinetd peut être utilisé pour instancier automatiquement un daemon OpenVPN, et cela dès qu'il reçoit un premier datagram depuis un pair distant.

La configuration de xinetd l'entraînera à ecouter, sur le port 5000 UDP, le premier datagramme en provenance d'une session de OpenVPN (en utilisant une clef statique pré-partagée), à ce moment là, xinetd démarrera automatiquement un daemon OpenVPN pour gérer la session. Notez que l'utilisation de l'option --inactive entraînera l'arrêt du deamon OpenVPN après 10 minutes d'inactivité. Après l'arrêt du daemon OpenVPN pour n'importe quelle raison que ce soit, le service xinetd reprendra son écoute sur le port 5000, et sera prêt à instancier de nouveaux daemon OpenVPN à l'arrivée de nouvelles connexions. Il faut aussi noter que xinetd instancie dans un premier temps le daemon OpenVPN avec les privilèges root, puis dans un second temps (après lecture du fichier protégé contenant la clef) OpenVPN descend ses privileges vers l'utilisateur nobody.

La clef peut être générée avec la commande suivante :

openvpn --genkey --secret key

Notez que chaque tunnel OpenVPN demande à fonctionner sur un port séparé, et nécessite son propre fichier de configuration xinetd. Cela vient du fait que OpenVPN attend des informations spécifiques à chaque potentielle connexion entrante comprenant la clef de chiffrement, le périphérique TUN/TAP, l'extrémité du tunnel, et les informations de routage. À ce point du développement de OpenVPN, il n'est pas capable de gérer n'importe quelle sorte de connexion entrante qui se contenterait d'un seul fichier de configuration pour décrire un large ensemble de potentielles connexions clientes. Depuis que OpenVPN est implémenté comme un serveur UDP, il ne bénéficie pas de l'avantage de l'infrastructure de TCP qui permet de dupliquer (fork) des serveurs TCP qui écouteront sur un port bien précis, et qui dupliquent (fork off) dynamiquement une nouvelle manipulation du daemon pour chaque session cliente. Néanmoins, le modèle des connexions entrantes est dans la liste des souhaits, et pourra être implémenté s'il y a suffisamment d'intérêt et de support de la part des développeurs et des utilisateurs de la communauté.

sample-config-files/xinetd-server-config


# An xinetd configuration file for OpenVPN.
#
# This file should be renamed to openvpn or something suitably
# descriptive and copied to the /etc/xinetd.d directory.
# xinetd can then be made aware of this file by restarting
# it or sending it a SIGHUP signal.
#
# For each potential incoming client, create a separate version
# of this configuration file on a unique port number.  Also note
# that the key file and ifconfig endpoints should be unique for
# each client.  This configuration assumes that the OpenVPN
# executable and key live in /root/openvpn.  Change this to fit
# your environment.

service openvpn_1
{
        type            = UNLISTED
        port            = 5000
        socket_type     = dgram
        protocol        = udp
        wait            = yes
        user            = root
        server          = /root/openvpn/openvpn
        server_args     = --inetd --dev tun --ifconfig 10.4.0.2 10.4.0.1 --secret /root/openvpn/key --inactive 600 --user nobody
}


sample-config-files/xinetd-client-config


# This OpenVPN config file
# is the client side counterpart
# of xinetd-server-config

dev tun
ifconfig 10.4.0.1 10.4.0.2
remote my-server
port 5000
user nobody
secret /root/openvpn/key
inactive 600