Re: OpenVPN sous Stretch avec systemd
----- Original Message -----
From: "daniel huhardeaux" <no-spam@tootai.net>
To: debian-user-french@lists.debian.org
Sent: Sunday, September 9, 2018 12:51:25 AM
Subject: Re: OpenVPN sous Stretch avec systemd
Le 08/09/2018 à 21:59, roger.tarani@free.fr a écrit :
> [...]
>
> Roger dit :
> ifconfig n'est plus dans Stretch. Alors j'utilise la commande ip
Ah, chez moi elle existe! Peu importe, c'est le résultat qui compte
> Peux-tu préciser ce que tu entends par "conformes" ?
Que les informations affichées soient celles qui correspondent à
l'environnement. On ne peut en dire plus puisqu'aucune info réseau n'a
été divulguée: combien de cartes réseau, identification des cartes, vpn
en mode tun ou tapo, etc.
Roger dit :
$ ls /sys/class/net/
enp8s0 lo tun0 wlp32s0
Installons net-tools !
$ sudo apt-get install net-tools
Et :
$ sudo ifconfig -a
enp8s0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 00:17:42:7a:c8:74 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 16
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1 (Local Loopback)
RX packets 4811 bytes 384593 (375.5 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4811 bytes 384593 (375.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 192.168.27.68 netmask 255.255.255.255 destination 212.27.38.253
inet6 fe80::fffe:d16a:8dbb:72cd prefixlen 64 scopeid 0x20<link>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 16 bytes 1031 (1.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlp32s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.5 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::8ef3:422:1504:638f prefixlen 64 scopeid 0x20<link>
ether 00:21:6a:35:c6:a4 txqueuelen 1000 (Ethernet)
RX packets 246563 bytes 210114507 (200.3 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 185695 bytes 29883060 (28.4 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
et
$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
Tiens, c'est bizarre puisqu'aucune interface n'est configurée ici (par rapport à mon habitude avec Jessie).
> Voilà ce que j'obtiens :
> $ ip r
> default via 212.27.38.253 dev tun0
> <mon-ip-fixe-masquée> via 192.168.0.1 dev wlp32s0
> 169.254.0.0/16 dev tun0 scope link metric 1000
> 192.168.0.0/24 dev wlp32s0 proto kernel scope link src 192.168.0.102
> 192.168.0.0/24 dev wlp32s0 proto kernel scope link src 192.168.0.102
> metric 600
> 192.168.27.64/27 via 212.27.38.253 dev tun0
> 212.27.38.253 dev tun0 proto kernel scope link src 192.168.27.68
>
> Ça vous parle ?
> Je cherche une solution pour cet autre problème de routage.
Donc le VPN devient la route par défaut: ne me semble pas logique car je
suppose que l'IP 212.27.38.253 est celle de la box du réseau local côté
WAN. Cela dépend également de la configuration de la box, mode routeur
ou bridge. Lorsque le VPN n'est *PAS* monté relance cette commande pour
vérifier les routes affichées et compare.
Roger dit :
Le VPN est en mode routé.
http://monip.fr/212.27.38.253
Adresse IP: 212.27.38.253
PTR enregistrement de ressource: freeplayer.freebox.fr
Organisation: Free SAS
...
[...]
>
> CONSTAT INTERESSANT :
> systemd cherche à utiliser */etc/openvpn/client.conf* (avec le nom
> client.conf) qui n'existe pas puisque j'ai le fichier de configuration
> suivant :
> /etc/openvpn/*client*/config_openvpn_routed_debian.conf
J'ai toujours connu OpenVPN cherchant par défaut les fichiers de config
dans /etc/openvpn pour Debian. Le répertoire de travail est dans le
fichier de conf, /etc/init.d/openvpn: CONFIG_DIR=/etc/openvpn
En lancant manuellement (openvpn <chemin du fichier de conf>) on peut
définir n'importe quel chemin pour le fichier.
Roger dit :
Oui, avec Jessie, je fais comme ça.
Je ne comprends pas l'objectif des répertoires /etc/openvpn/server et /etc/openvpn/client
Je me suis dit bêtement que c'était dans /etc/openvpn/client qu'il fallait lancer le fichier de configuration du client...
> Je peux bricoler en copiant mon fichier de configuration client ici
> avec ce nom client.conf (j'ai fait le test : et la commande $ sudo
> systemctl status openvpn@client.service fonctionne)
> Mais quelles sont les règles à respecter pour utiliser systemd avec
> OpenVPN ?
Celles des développeurs DEBIAN, donc dans /etc/openvpn
Roger dit :
OK !
> $ sudo journalctl -xe
> [...]
> Sep 08 21:06:04 debian ovpn-client[924]: Options error: In
> [CMD-LINE]:1: Error opening configuration file: /etc/openvpn/client.conf
> [...]
Dit la même chose, il cherche dans /etc/openvpn
Roger dit :
OK !
> Pouvez-vous me recommander un document de référence sur systemd que je
> me mette au niveau ?
> Et, s'il existe, un document sur OpenVPN avec systemd ?
Comprendre systemd suffit. Voir dans
/etc/systemd/system/multi-user.target.wants/openvpn.service et on
trouvera /etc/openvpn comme working directory, ce qui rejoint init
Roger dit :
OK !
[...]
> A un moment, il faut rationnaliser et s'en tenir à un mécanisme robuste !
systemd continue a gérer la manière init (combien de temps?) afin de
faciliter la transition.
Roger dit :
Entretemps, en lisant des docs, j'ai configuré ainsi :
renommé mon fichier de conf
$ ll /etc/openvpn:*.conf
monserveur.conf
$ sudo systemctl enable openvpn@monserveur.service
Created symlink /etc/systemd/system/multi-user.target.wants/openvpn@monserveur.service → /lib/systemd/system/openvpn@.service.
Et j'utilise les commandes :
$ sudo systemctl start openvpn@monserveur.service
$ sudo systemctl stop openvpn@monserveur.service
$ sudo systemctl restart openvpn@monserveur.service
(au lieu de
$ sudo systemctl start openvpn )
LE POINT :
X on respecte maintenant le répertoire OpenVPN de Debian, cad /etc/openvpn ;
Merci pour ça
O pour ce qui est des routes et des interfaces : je ne comprends pas vraiment les paramètres sous Stretch ;
Est-ce que les résulats publiés sont suffisants pour savoir quoi corriger ?
O pour ce qui est de la gestion rigoureuse de la connexion VPN par la machine Stretch : j'ai lu plusieurs posts de gens qui ont rencontré le même problème ces dernières années et ont cherché diverses solutions.
Cf. mon observation :
"manuellement, le serveur me dit qu'il voit le client apparaître et disparaître instantanément après chaque commande ($ sudo openvpn /etc/openvpn/monserveur.conf et Ctr-C, respectivement) ;
alors qu'avec systemctl (ou service), il se passe autre chose que je ne sais pas identifier : pour le client, la connexion semble coupée (après un $sudo systemctl stop openvpn@monserveur.service ; c'est confirmé par $sudo systemctl status openvpn@monserveur.service), tandis que pour le serveur OpenVPN la connexion du client n'est pas coupée (immédiatement, comme manuellement) et elle devient "fantôme", créant des problème de connexion lorsque le client cherche à se reconnecter, au lieu de récupérer une connexion. Comment configurer systemd pour qu'il coupe immédiatement une connexion OpenVPN ?
Merci
Roger
--
Daniel
Reply to: