J'ai donc examiné la configuration openvpn sur mon serveur basé sur Debian 9 et j'ai trouvé quelque chose que je ne peux pas expliquer dans les fichiers d'unité systemd pour le démon openvpn. Le démon lui-même démarre et fonctionne sans problème, mais je ne comprends pas pourquoi… Laissez-moi vous expliquer 🙂

J'ai donc installé openvpn et j'ai une configuration appropriée dans le fichier /etc/openvpn/server.conf dossier. Rien de mal jusqu'à présent.

Cependant, apparemment, deux unités systemd fonctionnent pour openvpn, à savoir openvpn.service et [email protected] . Ce dernier semble être celui qui accepte réellement les connexions vpn entrantes et tel, le premier ne semble pas faire grand-chose du tout. Il fonctionne apparemment juste pour démarrer ce dernier, je suppose…

Vérification de /etc/systemd/system/multi-user.target.wants/ Le répertoire des fichiers liés à openvpn affiche uniquement le fichier openvpn.service, dont la source est un lien symbolique vers un fichier nommé similaire dans /lib/systemd/system. Le contenu de ce fichier est :

# This service is actually a systemd target,
# but we are using a service since targets cannot be reloaded.

[Unit]
Description=OpenVPN service
After=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecReload=/bin/true
WorkingDirectory=/etc/openvpn

[Install]
WantedBy=multi-user.target

OK cool. Donc, cela ne fonctionne que /bin/true. Alors qu'est-ce qui commence exactement par [email protected] démon? Je sais que le fichier d'unité pour cela est /lib/systemd/[email protected] mais je ne trouve aucun indice sur mon système pour savoir exactement ce qui exécute ce fichier d'unité. (Je m'attendais à trouver un lien symbolique pour cela sous /etc/systemd/system quelque part, mais il n'y en a pas.) Le contenu de ce fichier est :

[Unit]
Description=OpenVPN connection to %i
PartOf=openvpn.service
ReloadPropagatedFrom=openvpn.service
Before=systemd-user-sessions.service
Documentation=man:openvpn(8)
Documentation=https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage
Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO

[Service]
PrivateTmp=true
KillMode=mixed
Type=forking
ExecStart=/usr/sbin/openvpn --daemon ovpn-%i --status /run/openvpn/%i.status 10 --cd /etc/openvpn --config /etc/openvpn/%i.conf --writepid /run/openvpn/%i.pid
PIDFile=/run/openvpn/%i.pid
ExecReload=/bin/kill -HUP $MAINPID
WorkingDirectory=/etc/openvpn
ProtectSystem=yes
CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_READ_SEARCH CAP_AUDIT_WRITE
LimitNPROC=10
DeviceAllow=/dev/null rw
DeviceAllow=/dev/net/tun rw

[Install]
WantedBy=multi-user.target

Donc, ce fichier d'unité a beaucoup plus de substance que le fichier openvpn.service. Mais qu'est-ce qui le déclenche ? J'ai remarqué le PartOf=openvpn.service partie dans le fichier ci-dessus, mais rechercher la signification de cela dans les pages de manuel ne m'a pas rendu beaucoup plus sage.

Je vais continuer à chercher parce que je veux juste savoir ce qui fait que ça marche !

Si quelqu'un a une idée de la façon dont ce fichier d'unité spécifique est exécuté ou de ce qui le démarre, veuillez me le faire savoir 🙂

Réponse acceptée :

Vous devez savoir deux choses :

• Il y a plusieurs autres sans-papiers répertoires où systemd conserve les fichiers d'unité.
• Debian et Ubuntu fournissent un générateur dans /lib/systemd/system-generators/openvpn-generator qui place des liens symboliques "veut" dans l'un de ces répertoires non documentés, un pour chaque *.conf fichier dans /etc/openvpn .

Les liens symboliques causent openvpn.service se comporter comme une cible et « vouloir » toutes vos différentes instanciations de modèles ; comme l'explique le commentaire au début de l'unité de service.

Notez que Debian et Ubuntu ne sont pas alignés sur ce que les gens d'OpenVPN eux-mêmes supply pour systemd, qui est utilisé sur Arch, CentOS, Fedora, etc. Debian et Ubuntu remplacent entièrement ce qui est fourni dans OpenVPN lui-même pour tout cela, avec leurs propres trucs pour systemd. Donc, à tout le moins, méfiez-vous lors de la lecture de doco du système d'exploitation que doco suppose que vous avez.

Connexe :Linux – Comment basculer entre les sessions tty et xorg ?

Les gens d'OpenVPN avaient l'habitude fournissez un [email protected] unité de modèle mais pas de générateur ni openvpn.service cible en tant que service. Il fallait explicitement activer et désactiver [email protected]name vous-même avec les mécanismes ordinaires de systemd pour le faire, et ils étaient "recherchés" directement par multi-user.target , plutôt que par une cible intermédiaire en tant que service.

Les gens d'OpenVPN de nos jours fournir un [email protected] distinct et [email protected] templates, continuez à ne pas fournir de générateur ou de openvpn.service target-as-a-service, et attendez-vous à ce que vous activiez et désactiviez explicitement [email protected]name et [email protected]name vous-même avec les mécanismes systemd ordinaires pour le faire. Le *.conf les fichiers ont été déplacés de /etc/openvpn et dans /etc/openvpn/client et /etc/openvpn/server , aussi.

Autres lectures

• Jonathan de Boyne Pollard (2016). "Chemins de recherche système manquants dans systemd.unit page de manuel“. Errata pour systemd docteur . Réponses fréquemment données.
• https://unix.stackexchange.com/a/233581/5132
• https://unix.stackexchange.com/a/206490/5132
• "configuration du service systemd". OpenVPN . Arch wiki.
• "configuration du service systemd". OpenVPN . Wiki Parabole.
• Christian Hesse (2016-12-30). La mise à jour OpenVPN 2.4.0 nécessite une interaction administrative . Actualités Arch.
• https://askubuntu.com/a/640026/43344