Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
OpenVPN sous Stretch avec systemd
247 views
Skip to first unread message
roger....@free.fr
Sep 8, 2018, 9:00:02 AM9/8/18
to
Salut
Je fais fonctionner sans souci un client OpenVPN sous Jessie.
Manuellement ou automatiquement.
Sous Stretch, qui utilise systemd, j'ai des problèmes (par méconnaissance de systemd).
Je peux lancer le client OpenVPN en CLI
$ sudo openvpn client.conf
Et Ctrl-C pour interrompre.
En cherchant, j'ai réglé le problème de la façon suivante :
$ cat /etc/default/openvpn
...
AUTOSTART="all"
...
Cette ligne est commentée par défaut.
Puis, comme indiqué dans ce même fichier :
$ sudo systemctl daemon-reload
$ sudo systemctl restart openvpn
Et là, ça fonctionne immédiatement (je n'ai pas essayé la sortie de veille et d'hibernation).
Il reste cependant deux problèmes à régler :
1/ je n'ai plus accès à internet via le lien où se trouve le serveur VPN (comme la machine Jessie dont l'IP est la même que toute machine qui s'y trouve).
Je ne sais pas comment faire ? : oú dois-je chercher ?
2/ ça crée un problème causé en fait par le serveur OpenVPN : la tentative de reconnexion "sauvage" du client alors que le serveur voit le client connecté déclenche une trentaine de transactions "Failed" pendant quelques minutes et puis ça finit par aboutir. Pendant ce temps là, pas de réseau du tout.
Comment gérer proprement la connexion et la déconnexion du client OpenVPN avec systemd (si connecté, utiliser la cnx VPN ; sinon, se connecter)
Merci
Je fais fonctionner sans souci un client OpenVPN sous Jessie.
Manuellement ou automatiquement.
Sous Stretch, qui utilise systemd, j'ai des problèmes (par méconnaissance de systemd).
Je peux lancer le client OpenVPN en CLI
$ sudo openvpn client.conf
Et Ctrl-C pour interrompre.
En cherchant, j'ai réglé le problème de la façon suivante :
$ cat /etc/default/openvpn
...
AUTOSTART="all"
...
Cette ligne est commentée par défaut.
Puis, comme indiqué dans ce même fichier :
$ sudo systemctl daemon-reload
$ sudo systemctl restart openvpn
Et là, ça fonctionne immédiatement (je n'ai pas essayé la sortie de veille et d'hibernation).
Il reste cependant deux problèmes à régler :
1/ je n'ai plus accès à internet via le lien où se trouve le serveur VPN (comme la machine Jessie dont l'IP est la même que toute machine qui s'y trouve).
Je ne sais pas comment faire ? : oú dois-je chercher ?
2/ ça crée un problème causé en fait par le serveur OpenVPN : la tentative de reconnexion "sauvage" du client alors que le serveur voit le client connecté déclenche une trentaine de transactions "Failed" pendant quelques minutes et puis ça finit par aboutir. Pendant ce temps là, pas de réseau du tout.
Comment gérer proprement la connexion et la déconnexion du client OpenVPN avec systemd (si connecté, utiliser la cnx VPN ; sinon, se connecter)
Merci
daniel huhardeaux
Sep 8, 2018, 9:30:03 AM9/8/18
to
Le 08/09/2018 à 14:40, roger....@free.fr a écrit :
> Salut
Bonjour
>
> Je fais fonctionner sans souci un client OpenVPN sous Jessie.
> Manuellement ou automatiquement.
>
> Sous Stretch, qui utilise systemd, j'ai des problèmes (par méconnaissance de systemd).
> Je peux lancer le client OpenVPN en CLI
> $ sudo openvpn client.conf
> Et Ctrl-C pour interrompre.
sudo systemctl start openvpn ou openvpn@client pour ne lancer que ce client
>
> En cherchant, j'ai réglé le problème de la façon suivante :
> $ cat /etc/default/openvpn
> ...
> AUTOSTART="all"
> ...
> Cette ligne est commentée par défaut.
>
> Puis, comme indiqué dans ce même fichier :
>
> $ sudo systemctl daemon-reload
> $ sudo systemctl restart openvpn
>
> Et là, ça fonctionne immédiatement (je n'ai pas essayé la sortie de veille et d'hibernation).
>
> Il reste cependant deux problèmes à régler :
> 1/ je n'ai plus accès à internet via le lien où se trouve le serveur VPN (comme la machine Jessie dont l'IP est la même que toute machine qui s'y trouve).
> Je ne sais pas comment faire ? : oú dois-je chercher ?
systemctl ne joue en rien sur le routage, le problème doit venir d'autre
part
sudo ifconfig pour afficher les interfaces et vérifier qu'elles soient
conformes
sudo ip r pour afficher les routes et vérifier qu'elles soient conformes
> 2/ ça crée un problème causé en fait par le serveur OpenVPN : la tentative de reconnexion "sauvage" du client alors que le serveur voit le client connecté déclenche une trentaine de transactions "Failed" pendant quelques minutes et puis ça finit par aboutir. Pendant ce temps là, pas de réseau du tout.
> Comment gérer proprement la connexion et la déconnexion du client OpenVPN avec systemd (si connecté, utiliser la cnx VPN ; sinon, se connecter)
sudo systemctl stop openvpn@client
sudo systemctl start openvpn@client
ou sudo systemctl restart openvpn@client
--
Daniel
> Salut
Bonjour
>
> Je fais fonctionner sans souci un client OpenVPN sous Jessie.
> Manuellement ou automatiquement.
>
> Sous Stretch, qui utilise systemd, j'ai des problèmes (par méconnaissance de systemd).
> Je peux lancer le client OpenVPN en CLI
> $ sudo openvpn client.conf
> Et Ctrl-C pour interrompre.
>
> En cherchant, j'ai réglé le problème de la façon suivante :
> $ cat /etc/default/openvpn
> ...
> AUTOSTART="all"
> ...
> Cette ligne est commentée par défaut.
>
> Puis, comme indiqué dans ce même fichier :
>
> $ sudo systemctl daemon-reload
> $ sudo systemctl restart openvpn
>
> Et là, ça fonctionne immédiatement (je n'ai pas essayé la sortie de veille et d'hibernation).
>
> Il reste cependant deux problèmes à régler :
> 1/ je n'ai plus accès à internet via le lien où se trouve le serveur VPN (comme la machine Jessie dont l'IP est la même que toute machine qui s'y trouve).
> Je ne sais pas comment faire ? : oú dois-je chercher ?
part
sudo ifconfig pour afficher les interfaces et vérifier qu'elles soient
conformes
sudo ip r pour afficher les routes et vérifier qu'elles soient conformes
> 2/ ça crée un problème causé en fait par le serveur OpenVPN : la tentative de reconnexion "sauvage" du client alors que le serveur voit le client connecté déclenche une trentaine de transactions "Failed" pendant quelques minutes et puis ça finit par aboutir. Pendant ce temps là, pas de réseau du tout.
> Comment gérer proprement la connexion et la déconnexion du client OpenVPN avec systemd (si connecté, utiliser la cnx VPN ; sinon, se connecter)
sudo systemctl start openvpn@client
ou sudo systemctl restart openvpn@client
--
Daniel
roger....@free.fr
Sep 8, 2018, 4:20:03 PM9/8/18
to
Merci.
Roger dit :
Roger dit :
Je fais fonctionner sans souci un client OpenVPN sous Jessie.
Manuellement ou automatiquement.
Sous Stretch, qui utilise systemd, j'ai des problèmes (par méconnaissance de systemd).
Je peux lancer le client OpenVPN en CLI
$ sudo openvpn client.conf
Et Ctrl-C pour interrompre.
Daniel dit :
sudo systemctl start openvpn ou openvpn@client pour ne lancer que ce client
Roger dit :
seule la commande suivante fonctionne (voir plus bas):
$ sudo systemctl start openvpn
Roger dit :
seule la commande suivante fonctionne (voir plus bas):
$ sudo systemctl start openvpn
Roger dit :
En cherchant, j'ai réglé le problème de la façon suivante :
$ cat /etc/default/openvpn
...
AUTOSTART="all"
...
Cette ligne est commentée par défaut.
Puis, comme indiqué dans ce même fichier :
$ sudo systemctl daemon-reload
$ sudo systemctl restart openvpn
Et là, ça fonctionne immédiatement (je n'ai pas essayé la sortie de veille et d'hibernation).
Il reste cependant deux problèmes à régler :
1/ je n'ai plus accès à internet via le lien où se trouve le serveur VPN (comme la machine Jessie dont l'IP est la même que toute machine qui s'y trouve).
Je ne sais pas comment faire ? : oú dois-je chercher ?
Daniel dit :
systemctl ne joue en rien sur le routage, le problème doit venir d'autre part
sudo ifconfig pour afficher les interfaces et vérifier qu'elles soient conformes
sudo ip r pour afficher les routes et vérifier qu'elles soient conformes
Roger dit :
ifconfig n'est plus dans Stretch. Alors j'utilise la commande ip
Peux-tu préciser ce que tu entends par "conformes" ?
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.
Roger dit :
ifconfig n'est plus dans Stretch. Alors j'utilise la commande ip
Peux-tu préciser ce que tu entends par "conformes" ?
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.
Roger dit :
2/ ça crée un problème causé en fait par le serveur OpenVPN : la tentative de reconnexion "sauvage" du client alors que le serveur voit le client connecté déclenche une trentaine de transactions "Failed" pendant quelques minutes et puis ça finit par aboutir. Pendant ce temps là, pas de réseau du tout.
Comment gérer proprement la connexion et la déconnexion du client OpenVPN avec systemd (si connecté, utiliser la cnx VPN ; sinon, se connecter)
Daniel dit :
sudo systemctl stop openvpn@client
sudo systemctl start openvpn@client
ou sudo systemctl restart openvpn@client
Roger dit :
$ sudo systemctl start openvpn
fonctionne
mais il y a un problème avec :
$ sudo systemctl start openvpn@client
Job for ope...@client.service failed because the control process exited with error code.
See "systemctl status ope...@client.service" and "journalctl -xe" for details.
$ sudo systemctl status ope...@client.service
● ope...@client.service - OpenVPN connection to client
Loaded: loaded (/lib/systemd/system/openvpn@.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2018-09-08 21:06:04 CEST; 10min ago
Docs: man:openvpn(8)
https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage
https://community.openvpn.net/openvpn/wiki/HOWTO
Process: 924 ExecStart=/usr/sbin/openvpn --daemon ovpn-client --status /run/openvpn/client.status 10 --cd /etc/openvpn --config /etc/openvpn/client.conf --writepid /run/openvpn/client.pid (code=exited, status=1/FAILURE)
Sep 08 21:06:04 debian systemd[1]: Starting OpenVPN connection to client...
Sep 08 21:06:04 debian ovpn-client[924]: Options error: In [CMD-LINE]:1: Error opening configuration file: /etc/openvpn/client.conf
Sep 08 21:06:04 debian ovpn-client[924]: Use --help for more information.
Sep 08 21:06:04 debian systemd[1]: ope...@client.service: Control process exited, code=exited status=1
Sep 08 21:06:04 debian systemd[1]: Failed to start OpenVPN connection to client.
Sep 08 21:06:04 debian systemd[1]: ope...@client.service: Unit entered failed state.
Sep 08 21:06:04 debian systemd[1]: ope...@client.service: Failed with result 'exit-code'.
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
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 ope...@client.service fonctionne)
Mais quelles sont les règles à respecter pour utiliser systemd avec OpenVPN ?
$ sudo journalctl -xe
Sep 08 21:06:04 debian sudo[921]: truc : TTY=pts/6 ; PWD=/etc/openvpn/client ; USER=root ; COMMAND=/bin/systemctl start openvpn@client
Sep 08 21:06:04 debian sudo[921]: pam_unix(sudo:session): session opened for user root by (uid=0)
Sep 08 21:06:04 debian systemd[1]: Starting OpenVPN connection to client...
-- Subject: Unit ope...@client.service has begun start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit ope...@client.service has begun starting up.
Sep 08 21:06:04 debian ovpn-client[924]: Options error: In [CMD-LINE]:1: Error opening configuration file: /etc/openvpn/client.conf
Sep 08 21:06:04 debian ovpn-client[924]: Use --help for more information.
Sep 08 21:06:04 debian systemd[1]: ope...@client.service: Control process exited, code=exited status=1
Sep 08 21:06:04 debian systemd[1]: Failed to start OpenVPN connection to client.
-- Subject: Unit ope...@client.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit ope...@client.service has failed.
--
-- The result is failed.
Sep 08 21:06:04 debian systemd[1]: ope...@client.service: Unit entered failed state.
Sep 08 21:06:04 debian systemd[1]: ope...@client.service: Failed with result 'exit-code'.
Sep 08 21:06:04 debian sudo[921]: pam_unix(sudo:session): session closed for user root
Sep 08 21:06:10 debian sudo[931]: truc : TTY=pts/6 ; PWD=/etc/openvpn/client ; USER=root ; COMMAND=/bin/journalctl -xe
Sep 08 21:06:10 debian sudo[931]: pam_unix(sudo:session): session opened for user root by (uid=0)
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 ?
Enfin, je note que la commande
$ sudo systemctl stop openvpn
"libère" le réseau (je peux accéder à internet) mais ne déconnecte pas "proprement" le client du serveur, car le serveur conserve la connexion du client encore quelques mn. Du coup, un
$ sudo systemctl start openvpn
va créer le problème décrit ci-dessus (plusieurs tentatives de connexion "Failed" pendant quelques mn avant que ça aboutisse : concrètement, on voit sur le serveur la machine authentifiée et la même machine "en attente d'authentification")
Je rappelle qu'avec Jessie le lancement d'OpenVPN client ça marche impeccablement.
Par ailleurs, pour être complet, on peut se demander s'il est normal que le serveur OpenVPN (celui d'une FreeBox Revolution) conserve de la sorte des clients dans l'état connecté alors qu'une commande de déconnexion a été exécutée (le client se croit déconnecté ; le serveur n'a pas le même état).
Je cherche, mais j'aimerais bien avoir votre avis sur ce point.
Cerise sur le gâteau : je viens de me rendre compte que la commande suivante fonctionne aussi (avec le même comportement vis-à-vis du serveur) :
$ sudo service openvpn start
Je me demande quel sens ça a de mettre en place systemd pour OpenVPN et de laisser service (utilisé avec Jessie) pour OpenVPN.
A un moment, il faut rationnaliser et s'en tenir à un mécanisme robuste !
Merci
$ sudo systemctl start openvpn
fonctionne
mais il y a un problème avec :
$ sudo systemctl start openvpn@client
Job for ope...@client.service failed because the control process exited with error code.
See "systemctl status ope...@client.service" and "journalctl -xe" for details.
$ sudo systemctl status ope...@client.service
● ope...@client.service - OpenVPN connection to client
Loaded: loaded (/lib/systemd/system/openvpn@.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2018-09-08 21:06:04 CEST; 10min ago
Docs: man:openvpn(8)
https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage
https://community.openvpn.net/openvpn/wiki/HOWTO
Process: 924 ExecStart=/usr/sbin/openvpn --daemon ovpn-client --status /run/openvpn/client.status 10 --cd /etc/openvpn --config /etc/openvpn/client.conf --writepid /run/openvpn/client.pid (code=exited, status=1/FAILURE)
Sep 08 21:06:04 debian systemd[1]: Starting OpenVPN connection to client...
Sep 08 21:06:04 debian ovpn-client[924]: Options error: In [CMD-LINE]:1: Error opening configuration file: /etc/openvpn/client.conf
Sep 08 21:06:04 debian ovpn-client[924]: Use --help for more information.
Sep 08 21:06:04 debian systemd[1]: ope...@client.service: Control process exited, code=exited status=1
Sep 08 21:06:04 debian systemd[1]: Failed to start OpenVPN connection to client.
Sep 08 21:06:04 debian systemd[1]: ope...@client.service: Unit entered failed state.
Sep 08 21:06:04 debian systemd[1]: ope...@client.service: Failed with result 'exit-code'.
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
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 ope...@client.service fonctionne)
Mais quelles sont les règles à respecter pour utiliser systemd avec OpenVPN ?
$ sudo journalctl -xe
Sep 08 21:06:04 debian sudo[921]: truc : TTY=pts/6 ; PWD=/etc/openvpn/client ; USER=root ; COMMAND=/bin/systemctl start openvpn@client
Sep 08 21:06:04 debian sudo[921]: pam_unix(sudo:session): session opened for user root by (uid=0)
Sep 08 21:06:04 debian systemd[1]: Starting OpenVPN connection to client...
-- Subject: Unit ope...@client.service has begun start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit ope...@client.service has begun starting up.
Sep 08 21:06:04 debian ovpn-client[924]: Options error: In [CMD-LINE]:1: Error opening configuration file: /etc/openvpn/client.conf
Sep 08 21:06:04 debian ovpn-client[924]: Use --help for more information.
Sep 08 21:06:04 debian systemd[1]: ope...@client.service: Control process exited, code=exited status=1
Sep 08 21:06:04 debian systemd[1]: Failed to start OpenVPN connection to client.
-- Subject: Unit ope...@client.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit ope...@client.service has failed.
--
-- The result is failed.
Sep 08 21:06:04 debian systemd[1]: ope...@client.service: Unit entered failed state.
Sep 08 21:06:04 debian systemd[1]: ope...@client.service: Failed with result 'exit-code'.
Sep 08 21:06:04 debian sudo[921]: pam_unix(sudo:session): session closed for user root
Sep 08 21:06:10 debian sudo[931]: truc : TTY=pts/6 ; PWD=/etc/openvpn/client ; USER=root ; COMMAND=/bin/journalctl -xe
Sep 08 21:06:10 debian sudo[931]: pam_unix(sudo:session): session opened for user root by (uid=0)
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 ?
Enfin, je note que la commande
$ sudo systemctl stop openvpn
"libère" le réseau (je peux accéder à internet) mais ne déconnecte pas "proprement" le client du serveur, car le serveur conserve la connexion du client encore quelques mn. Du coup, un
$ sudo systemctl start openvpn
va créer le problème décrit ci-dessus (plusieurs tentatives de connexion "Failed" pendant quelques mn avant que ça aboutisse : concrètement, on voit sur le serveur la machine authentifiée et la même machine "en attente d'authentification")
Je rappelle qu'avec Jessie le lancement d'OpenVPN client ça marche impeccablement.
Par ailleurs, pour être complet, on peut se demander s'il est normal que le serveur OpenVPN (celui d'une FreeBox Revolution) conserve de la sorte des clients dans l'état connecté alors qu'une commande de déconnexion a été exécutée (le client se croit déconnecté ; le serveur n'a pas le même état).
Je cherche, mais j'aimerais bien avoir votre avis sur ce point.
Cerise sur le gâteau : je viens de me rendre compte que la commande suivante fonctionne aussi (avec le même comportement vis-à-vis du serveur) :
$ sudo service openvpn start
Je me demande quel sens ça a de mettre en place systemd pour OpenVPN et de laisser service (utilisé avec Jessie) pour OpenVPN.
A un moment, il faut rationnaliser et s'en tenir à un mécanisme robuste !
Merci
roger....@free.fr
Sep 8, 2018, 4:30:02 PM9/8/18
to
PS :
Quand j'éteins ma machine en Jessie (shutdown), elle disparaît _instantanément_ du serveur OpenVPN.
Sur la machine en Stretch, quand je lance le client OpenVPN manuellement avec la commande
$ sudo openvpn maconfig.conf
le serveur l'enregistre immédiatement, et un Ctrl-C le fait disparaître _instantanément_ de sclients authentifiés par le serveur.
-> J'en conclue que mon serveur OpenVPN a un comportement acceptable.
Avec systemctl ET avec service, sur la machine en Stretch (qui me pose problème), il y a bien une gestion "automatique" mystérieuse du client OpenVPN.
Comment faire pour arriver à reproduire le comportement simple, naturel et reproductible avec ces outils de gestion de service ? (censés nous simplifier la vie)
Quand j'éteins ma machine en Jessie (shutdown), elle disparaît _instantanément_ du serveur OpenVPN.
Sur la machine en Stretch, quand je lance le client OpenVPN manuellement avec la commande
$ sudo openvpn maconfig.conf
le serveur l'enregistre immédiatement, et un Ctrl-C le fait disparaître _instantanément_ de sclients authentifiés par le serveur.
-> J'en conclue que mon serveur OpenVPN a un comportement acceptable.
Avec systemctl ET avec service, sur la machine en Stretch (qui me pose problème), il y a bien une gestion "automatique" mystérieuse du client OpenVPN.
Comment faire pour arriver à reproduire le comportement simple, naturel et reproductible avec ces outils de gestion de service ? (censés nous simplifier la vie)
daniel huhardeaux
Sep 8, 2018, 7:10:02 PM9/8/18
to
Le 08/09/2018 à 21:59, roger....@free.fr a écrit :
> [...]
> 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.
> 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.
[...]
>
> CONSTAT INTERESSANT :
> systemd cherche à utiliser */etc/openvpn/client.conf* (avec le nom
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.
> $ sudo journalctl -xe
> [...]
Dit la même chose, il cherche dans /etc/openvpn
> 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
[...]
faciliter la transition.
--
Daniel
> [...]
>
> 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
> Roger dit :
> ifconfig n'est plus dans Stretch. Alors j'utilise la commande ip
> Peux-tu préciser ce que tu entends par "conformes" ?
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.
> 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.
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.
[...]
>
> 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
> suivant :
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.
>
> 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 ope...@client.service fonctionne)
> Mais quelles sont les règles à respecter pour utiliser systemd avec
> OpenVPN ?
Celles des développeurs DEBIAN, donc dans /etc/openvpn
> 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 ope...@client.service fonctionne)
> Mais quelles sont les règles à respecter pour utiliser systemd avec
> OpenVPN ?
> $ 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
> [...]
> [CMD-LINE]:1: Error opening configuration file: /etc/openvpn/client.conf
Dit la même chose, il cherche dans /etc/openvpn
> 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 ?
/etc/systemd/system/multi-user.target.wants/openvpn.service et on
trouvera /etc/openvpn comme working directory, ce qui rejoint init
[...]
> 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.
--
Daniel
roger....@free.fr
Sep 8, 2018, 8:40:03 PM9/8/18
to
----- Original Message -----
From: "daniel huhardeaux" <no-...@tootai.net>
To: debian-us...@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....@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.
$ 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.
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.
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 ope...@client.service fonctionne)
> Mais quelles sont les règles à respecter pour utiliser systemd avec
> OpenVPN ?
Celles des développeurs DEBIAN, donc dans /etc/openvpn
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
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
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.
Entretemps, en lisant des docs, j'ai configuré ainsi :
renommé mon fichier de conf
$ ll /etc/openvpn:*.conf
monserveur.conf
$ sudo systemctl enable ope...@monserveur.service
Created symlink /etc/systemd/system/multi-user.target.wants/ope...@monserveur.service → /lib/systemd/system/openvpn@.service.
Et j'utilise les commandes :
$ sudo systemctl start ope...@monserveur.service
$ sudo systemctl stop ope...@monserveur.service
$ sudo systemctl restart ope...@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 ope...@monserveur.service ; c'est confirmé par $sudo systemctl status ope...@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
daniel huhardeaux
Sep 9, 2018, 9:30:02 AM9/9/18
to
Le 09/09/2018 à 02:20, roger....@free.fr a écrit :
> [...]
Donc connecté en WIFI, pas de liaison filaire. L'IP destination de tun0
ne correspond pas: elle devrait etre de type 192.168.27.1 en imaginant
que le masque est en /24 et que le serveur VPN est de type server. Je ne
comprends pas l'adresse 212.27.38.253 qui est une IP publique de FREE:
pourquoi via VPN ?
> 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).
Tout dépend si tu utilises network-manager ou non. Si non, les
définitions sont dans interfaces.d
>> Voilà ce que j'obtiens :
>> $ ip r
>> default via 212.27.38.253 dev tun0
??? Incohérent
192.168.0.254. As tu modifié? Si elle est en mode bridge
<mon-ip-fixe-masquée> est attribuée à wlp32s0. Pour moi, tout semble
incohérent.
>> 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
2 fois la même route ...
[...]
On/je ne comprends pas quel est le but de ton VPN même le but tout court
des manipulations. Vérifie que la table de routage et la liste des
interfaces lorsque le VPN n'est pas monté (ifconfig sans option) sont
cohérent et que le réseau local fonctionne.
--
Daniel
> [...]
ne correspond pas: elle devrait etre de type 192.168.27.1 en imaginant
que le masque est en /24 et que le serveur VPN est de type server. Je ne
comprends pas l'adresse 212.27.38.253 qui est une IP publique de FREE:
pourquoi via VPN ?
> 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).
définitions sont dans interfaces.d
>> 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
Si la Freebox est en mode routeur elle prend en général l'IP
192.168.0.254. As tu modifié? Si elle est en mode bridge
<mon-ip-fixe-masquée> est attribuée à wlp32s0. Pour moi, tout semble
incohérent.
>> 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
[...]
On/je ne comprends pas quel est le but de ton VPN même le but tout court
des manipulations. Vérifie que la table de routage et la liste des
interfaces lorsque le VPN n'est pas monté (ifconfig sans option) sont
cohérent et que le réseau local fonctionne.
--
Daniel
roger....@free.fr
Sep 9, 2018, 1:20:02 PM9/9/18
to
Bonjour,
Suite à tes remarques, j'ai ajouté mes observations concernant les deux machines (Jessie qui fonctionne et Stretch qui râle).
Merci
----- Original Message -----
From: "daniel huhardeaux" <no-...@tootai.net>
To: debian-us...@lists.debian.org
Sent: Sunday, September 9, 2018 3:05:48 PM
Subject: Re: OpenVPN sous Stretch avec systemd
Daniel dit :
sur mon autre machine en Jessie, j'ai aussi 212.27.38.253 comme ça ;
inet 192.168.27.67 peer 212.27.38.253/32 scope global tun0
tandis que sur la machine en Stretch, j'ai :
$ sudo ifconfig
eth0 Link encap:Ethernet HWaddr 00:23:26:3b:9f:15
inet addr:192.168.0.152 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::223:26ff:fe3b:9f15/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3954 errors:0 dropped:1 overruns:0 frame:0
TX packets:1586 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2354094 (2.2 MiB) TX bytes:209838 (204.9 KiB)
Interrupt:16
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:221 errors:0 dropped:0 overruns:0 frame:0
TX packets:221 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:23287 (22.7 KiB) TX bytes:23287 (22.7 KiB)
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:192.168.27.67 P-t-P:212.27.38.253 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:1063 errors:0 dropped:0 overruns:0 frame:0
TX packets:716 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1356357 (1.2 MiB) TX bytes:46040 (44.9 KiB)
toujours la machine Jessie :
<mon-ip-fixe-masquée> via 192.168.0.1 dev eth0
169.254.0.0/16 dev eth0 scope link metric 1000
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.152
> 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).
Daniel dit :
Je ne comprends pas encore très bien network-manager et il semble bien me le rendre
J'utilise network-manager car il n'y a rien dans interfaces.d :
$ ls -l /etc/network/interfaces.d/
total 0
$ sudo systemctl status NetworkManager
● NetworkManager.service - Network Manager
Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; vendor p...
Active: active (running) since Wed 2018-08-22 22:27:13 CEST; 2 weeks 3 days a...
...
>> Voilà ce que j'obtiens :
>> $ ip r
>> default via 212.27.38.253 dev tun0
Daniel dit :
Pour configurer le client OpenVPN sur la machine Stretch (serveur Free OpenVPN en mode routé), j'ai suivi la même procédure (simple) que pour la machine Jessie : en plaçant au bon endroit un fichier de conf OpenVPN (sauf que j'avais d'abord mal placé le fichier de conf ; je l'ai remis dans /etc/openvpn suite à tes conseils).
Sur la machine Stretch, le lancement d'OpenVPN s'est fait avec "succès" _manuellement_ (sauf qu'il n'y avait plus d'accès à internet quand la machine Stretch est connectée en VPN).
Automatiquement, avec systemd, comme discuté, ça patauge.
Mais comme tu le cernes, le problème ne vient a priori pas d'OpenVPN ni de systemd, mais de la configuration des réseaux sur cette machine.
J'ai refais un test avec la machien Jessie et je confirme :
Manuellement ($ sudo openvpn mon serveur.conf puis Crtl-C pour interrompre) : OK.
Automatiquement avec service (sudo openvpn start ; sudo openvpn stop ) : OK
Dans les deux cas, je vois le client apparaître et disparaître immédiatement du côté du serveur.
C'est simple et sain. Je comprends ce que je configure et ce qui se passe.
>> 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
Daniel dit :
Oui, mais quels composants réseau produisent donc ça (ce comportement réseau) ? network-manager ?
Je me suis contenté de poser un fichier de configuration OpenVPN fonctionnel dans cette machine Stretch !
[...]
Daniel dit :
Le réseau local fontionne bien sans VPN (ping entre les machines dans les deux sens, accès à internet), en filaire et en WiFi.
- machine Stretch en filaire :
$ sudo ifconfig
enp8s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.101 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::217:42ff:fe7a:c874 prefixlen 64 scopeid 0x20<link>
$ sudo ifconfig
Le but des manipulations sur cette machine Stretch est d'obtenir le même comportement que sur la machine Jessie.
Et franchement, en matière de réseau, autant je me débrouille complètement et sans aucun souci avec Jessie, autant je patauge avec Stretch dont je ne comprends pas (encore) le fonctionnement et pour lequel je n'ai pas (encore) trouvé une doc officielle de référence sur ce point (réseaux, VPN).
Quels sont les composants et fichiers mis en oeuvre et la syntaxe à respecter pour configurer les réseaux avec Stretch ?
Merci pour ta patience.
Suite à tes remarques, j'ai ajouté mes observations concernant les deux machines (Jessie qui fonctionne et Stretch qui râle).
Merci
----- Original Message -----
From: "daniel huhardeaux" <no-...@tootai.net>
To: debian-us...@lists.debian.org
Sent: Sunday, September 9, 2018 3:05:48 PM
Subject: Re: OpenVPN sous Stretch avec systemd
Donc connecté en WIFI, pas de liaison filaire. L'IP destination de tun0
ne correspond pas: elle devrait etre de type 192.168.27.1 en imaginant
que le masque est en /24 et que le serveur VPN est de type server. Je ne
comprends pas l'adresse 212.27.38.253 qui est une IP publique de FREE:
pourquoi via VPN ?
Roger dit :
ne correspond pas: elle devrait etre de type 192.168.27.1 en imaginant
que le masque est en /24 et que le serveur VPN est de type server. Je ne
comprends pas l'adresse 212.27.38.253 qui est une IP publique de FREE:
pourquoi via VPN ?
sur mon autre machine en Jessie, j'ai aussi 212.27.38.253 comme ça ;
inet 192.168.27.67 peer 212.27.38.253/32 scope global tun0
tandis que sur la machine en Stretch, j'ai :
inet 192.168.27.68 netmask 255.255.255.255 destination 212.27.38.253
machine Jessie (réseaux fonctionnels) :
$ sudo ifconfig
eth0 Link encap:Ethernet HWaddr 00:23:26:3b:9f:15
inet addr:192.168.0.152 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::223:26ff:fe3b:9f15/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3954 errors:0 dropped:1 overruns:0 frame:0
TX packets:1586 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2354094 (2.2 MiB) TX bytes:209838 (204.9 KiB)
Interrupt:16
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:221 errors:0 dropped:0 overruns:0 frame:0
TX packets:221 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:23287 (22.7 KiB) TX bytes:23287 (22.7 KiB)
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:192.168.27.67 P-t-P:212.27.38.253 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:1063 errors:0 dropped:0 overruns:0 frame:0
TX packets:716 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1356357 (1.2 MiB) TX bytes:46040 (44.9 KiB)
toujours la machine Jessie :
$ ip r
default via 212.27.38.253 dev tun0
default via 212.27.38.253 dev tun0 proto static metric 1024
default via 212.27.38.253 dev tun0
<mon-ip-fixe-masquée> via 192.168.0.1 dev eth0
169.254.0.0/16 dev eth0 scope link metric 1000
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.152
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.67
> 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).
Tout dépend si tu utilises network-manager ou non.
Si non, les définitions sont dans interfaces.d
Roger dit :
Si non, les définitions sont dans interfaces.d
Je ne comprends pas encore très bien network-manager et il semble bien me le rendre
J'utilise network-manager car il n'y a rien dans interfaces.d :
$ ls -l /etc/network/interfaces.d/
total 0
$ sudo systemctl status NetworkManager
● NetworkManager.service - Network Manager
Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; vendor p...
Active: active (running) since Wed 2018-08-22 22:27:13 CEST; 2 weeks 3 days a...
...
>> Voilà ce que j'obtiens :
>> $ ip r
>> default via 212.27.38.253 dev tun0
??? Incohérent
>> <mon-ip-fixe-masquée> via 192.168.0.1 dev wlp32s0
Si la Freebox est en mode routeur elle prend en général l'IP
192.168.0.254. As tu modifié? Si elle est en mode bridge
<mon-ip-fixe-masquée> est attribuée à wlp32s0. Pour moi, tout semble
incohérent.
Roger dit :
>> <mon-ip-fixe-masquée> via 192.168.0.1 dev wlp32s0
Si la Freebox est en mode routeur elle prend en général l'IP
192.168.0.254. As tu modifié? Si elle est en mode bridge
<mon-ip-fixe-masquée> est attribuée à wlp32s0. Pour moi, tout semble
incohérent.
Pour configurer le client OpenVPN sur la machine Stretch (serveur Free OpenVPN en mode routé), j'ai suivi la même procédure (simple) que pour la machine Jessie : en plaçant au bon endroit un fichier de conf OpenVPN (sauf que j'avais d'abord mal placé le fichier de conf ; je l'ai remis dans /etc/openvpn suite à tes conseils).
Sur la machine Stretch, le lancement d'OpenVPN s'est fait avec "succès" _manuellement_ (sauf qu'il n'y avait plus d'accès à internet quand la machine Stretch est connectée en VPN).
Automatiquement, avec systemd, comme discuté, ça patauge.
Mais comme tu le cernes, le problème ne vient a priori pas d'OpenVPN ni de systemd, mais de la configuration des réseaux sur cette machine.
J'ai refais un test avec la machien Jessie et je confirme :
Manuellement ($ sudo openvpn mon serveur.conf puis Crtl-C pour interrompre) : OK.
Automatiquement avec service (sudo openvpn start ; sudo openvpn stop ) : OK
Dans les deux cas, je vois le client apparaître et disparaître immédiatement du côté du serveur.
C'est simple et sain. Je comprends ce que je configure et ce qui se passe.
>> 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
2 fois la même route ...
Roger dit :
Oui, mais quels composants réseau produisent donc ça (ce comportement réseau) ? network-manager ?
Je me suis contenté de poser un fichier de configuration OpenVPN fonctionnel dans cette machine Stretch !
[...]
Daniel dit :
On/je ne comprends pas quel est le but de ton VPN même le but tout court
des manipulations. Vérifie que la table de routage et la liste des
interfaces lorsque le VPN n'est pas monté (ifconfig sans option) sont
cohérent et que le réseau local fonctionne.
Roger dit :
des manipulations. Vérifie que la table de routage et la liste des
interfaces lorsque le VPN n'est pas monté (ifconfig sans option) sont
cohérent et que le réseau local fonctionne.
Le réseau local fontionne bien sans VPN (ping entre les machines dans les deux sens, accès à internet), en filaire et en WiFi.
- machine Stretch en filaire :
$ sudo ifconfig
enp8s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.101 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::217:42ff:fe7a:c874 prefixlen 64 scopeid 0x20<link>
ether 00:17:42:7a:c8:74 txqueuelen 1000 (Ethernet)
RX packets 16917 bytes 7953917 (7.5 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 15679 bytes 2756980 (2.6 MiB)
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 5251 bytes 417121 (407.3 KiB)
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 errors 0 dropped 0 overruns 0 frame 0
TX packets 5251 bytes 417121 (407.3 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
- machine Stretch en WiFi :
$ sudo ifconfig
enp8s0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 00:17:42:7a:c8:74 txqueuelen 1000 (Ethernet)
RX packets 16979 bytes 7973796 (7.6 MiB)
ether 00:17:42:7a:c8:74 txqueuelen 1000 (Ethernet)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 15730 bytes 2772306 (2.6 MiB)
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 5253 bytes 417199 (407.4 KiB)
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 errors 0 dropped 0 overruns 0 frame 0
TX packets 5253 bytes 417199 (407.4 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlp32s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::728e:fd77:36f1:a585 prefixlen 64 scopeid 0x20<link>
wlp32s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether 00:21:6a:35:c6:a4 txqueuelen 1000 (Ethernet)
RX packets 287447 bytes 231604167 (220.8 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 221935 bytes 36433522 (34.7 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Le but de mon VPN est simple et habituel : il me permet de faire travailler plusieurs machines sur un réseau sécurisé dédié, que les machines soient sur le même LAN ou en des points différents, qu'il y ait une bête borne Orange qui autorise ou pas le NAT (...).
Le but des manipulations sur cette machine Stretch est d'obtenir le même comportement que sur la machine Jessie.
Et franchement, en matière de réseau, autant je me débrouille complètement et sans aucun souci avec Jessie, autant je patauge avec Stretch dont je ne comprends pas (encore) le fonctionnement et pour lequel je n'ai pas (encore) trouvé une doc officielle de référence sur ce point (réseaux, VPN).
Quels sont les composants et fichiers mis en oeuvre et la syntaxe à respecter pour configurer les réseaux avec Stretch ?
Merci pour ta patience.
daniel huhardeaux
Sep 9, 2018, 2:30:02 PM9/9/18
to
Le 09/09/2018 à 19:02, roger....@free.fr a écrit :
> [...]
Y'a un problème, pas d'IP !
--
Daniel
> [...]
> - machine Stretch en WiFi :
> $ sudo ifconfig
> enp8s0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
> ether 00:17:42:7a:c8:74 txqueuelen 1000 (Ethernet)
> RX packets 16979 bytes 7973796 (7.6 MiB)
> RX errors 0 dropped 0 overruns 0 frame 0
> TX packets 15730 bytes 2772306 (2.6 MiB)
> 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 5253 bytes 417199 (407.4 KiB)
> RX errors 0 dropped 0 overruns 0 frame 0
> TX packets 5253 bytes 417199 (407.4 KiB)
> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
>
> wlp32s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
> inet6 fe80::728e:fd77:36f1:a585 prefixlen 64 scopeid 0x20<link>
> ether 00:21:6a:35:c6:a4 txqueuelen 1000 (Ethernet)
> RX packets 287447 bytes 231604167 (220.8 MiB)
> RX errors 0 dropped 0 overruns 0 frame 0
> TX packets 221935 bytes 36433522 (34.7 MiB)
> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
> [...]
> $ sudo ifconfig
> enp8s0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
> ether 00:17:42:7a:c8:74 txqueuelen 1000 (Ethernet)
> RX packets 16979 bytes 7973796 (7.6 MiB)
> RX errors 0 dropped 0 overruns 0 frame 0
> TX packets 15730 bytes 2772306 (2.6 MiB)
> 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 5253 bytes 417199 (407.4 KiB)
> RX errors 0 dropped 0 overruns 0 frame 0
> TX packets 5253 bytes 417199 (407.4 KiB)
> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
>
> wlp32s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
> inet6 fe80::728e:fd77:36f1:a585 prefixlen 64 scopeid 0x20<link>
> ether 00:21:6a:35:c6:a4 txqueuelen 1000 (Ethernet)
> RX packets 287447 bytes 231604167 (220.8 MiB)
> RX errors 0 dropped 0 overruns 0 frame 0
> TX packets 221935 bytes 36433522 (34.7 MiB)
> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Y'a un problème, pas d'IP !
--
Daniel
roger....@free.fr
Sep 9, 2018, 2:50:02 PM9/9/18
to
Waouh !...
1/ Voilà ce que je viens de découvrir en analysant ma configuration OpenVPN de la machine Stretch :
j'utilisais un fichier de configuration OpenVPN un poil trop âgé encore en AES128, alors que j'utilisais le nouveau fichier de conf en AES256 pour la machine Jessie (le serveur a été passé en AES256).
Cela provoquait un Warning ( 'cipher' is used inconsistently, local='cipher AES-128-CBC', remote='cipher AES-256-CBC') et un message d'erreur ("Authenticate/Decrypt packet error: cipher final failed") trop discrets d'OpenVPN : ce qui expliquait le comportement bizarre du client qui cherchait à se reconnecter régulièrement et n'était en fait pas connecté comme l'indiquait faussement le serveur.
1/ Voilà ce que je viens de découvrir en analysant ma configuration OpenVPN de la machine Stretch :
j'utilisais un fichier de configuration OpenVPN un poil trop âgé encore en AES128, alors que j'utilisais le nouveau fichier de conf en AES256 pour la machine Jessie (le serveur a été passé en AES256).
Cela provoquait un Warning ( 'cipher' is used inconsistently, local='cipher AES-128-CBC', remote='cipher AES-256-CBC') et un message d'erreur ("Authenticate/Decrypt packet error: cipher final failed") trop discrets d'OpenVPN : ce qui expliquait le comportement bizarre du client qui cherchait à se reconnecter régulièrement et n'était en fait pas connecté comme l'indiquait faussement le serveur.
Dès que j'ai remis le bon fichier de conf en AES256 (au même bon endroit) le comportement de la machine Stretch est redevenu normal, cad identique à celui de la machine Jessie avec les commandes suivantes :
$ sudo systemctl start ope...@monserveur.service
$ sudo systemctl restart ope...@monserveur.service
$ sudo systemctl stop ope...@monserveur.service
On voit sur le serveur OpenVPN que le client se connecte et se déconnecte _immédiatement_.
Et le ping via VPN entre les deux machines Jessie et Stretch fonctionne à nouveau.
Et le ping via VPN entre les deux machines Jessie et Stretch fonctionne à nouveau.
$ 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 via 212.27.38.253 dev tun0
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
$ sudo ifconfig
$ sudo ifconfig
enp8s0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 00:17:42:7a:c8:74 txqueuelen 1000 (Ethernet)
ether 00:17:42:7a:c8:74 txqueuelen 1000 (Ethernet)
RX...
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...
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::bb3e:ca65:f4bc:9df3 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...
wlp32s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.102 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::728e:fd77:36f1:a585 prefixlen 64 scopeid 0x20<link>
inet6 fe80::728e:fd77:36f1:a585 prefixlen 64 scopeid 0x20<link>
ether 00:21:6a:35:c6:a4 txqueuelen 1000 (Ethernet)
RX...
Il semble que l'absence d'accès au réseau internet était causée par cette "transaction en échec en boucle" qui se prolongeait entre le client et le server OpenVPN.
Daniel, merci beaucoup pour le temps que tu as passé pour m'aider à régler ce problème.
Il semble que l'absence d'accès au réseau internet était causée par cette "transaction en échec en boucle" qui se prolongeait entre le client et le server OpenVPN.
2/ la connaissance du système de configuration des réseaux avec Stretch est encore plus d'actualité.
En effet, quand ça marche c'est bien, mais quand ça foire il est crucial de savoir ce qui se passe.
Et là,rien n'a indiqué ce qui était en train de clocher.
De plus, je comprends que ce serait un système en cours de transition.
Comment faudrait-il procéder pour savoir dans quel état se trouve la configuration de composants logiciels réseaux et la configuration réseau d'une machine Stretch ?
Daniel, merci beaucoup pour le temps que tu as passé pour m'aider à régler ce problème.
daniel huhardeaux
Sep 9, 2018, 5:40:03 PM9/9/18
to
Le 09/09/2018 à 20:28, roger....@free.fr a écrit :
> [...] et un message d'erreur ("Authenticate/Decrypt packet error:
élevé (=5 par ex) lorsque l'on rencontre des soucis et de le passer à un
niveau inférieur lorsque le VPN est validé fonctionnel.
> [...]
fonctionnel (route par défaut vers le VPN)
>
> 2/ la connaissance du système de configuration des réseaux avec
> Stretch est encore plus d'actualité.
> En effet, quand ça marche c'est bien, mais quand ça foire il est
> crucial de savoir ce qui se passe.
> Et là,rien n'a indiqué ce qui était en train de clocher.
> De plus, je comprends que ce serait un système en cours de transition.
>
> Comment faudrait-il procéder pour savoir dans quel état se trouve la
> configuration de composants logiciels réseaux et la configuration
> réseau d'une machine Stretch ?
Il n'y a pas de différences (peu éventuellement) entre la gestion réseau
Jessie et Stretch. Les programmes et configurations ont éventuellement
évoluées, il s'agit surtout de savoir qui fait quoi. Dans ton cas, tu
cherches dans le fichier interfaces alors que c'est network-manager qui
semble gérer le réseau (qui n'utilise pas le fichier interfaces). Il
faudrait pour être cohérent faire gérer le VPN également par
network-manage (ou rien et utiliser interfaces + conf OpenVPN à la mano).
--
Daniel
> [...] et un message d'erreur ("Authenticate/Decrypt packet error:
> cipher final failed") trop discrets d'OpenVPN
Il n'y a rien de discret dans OpenVPN, il suffit de mettre un verbose
élevé (=5 par ex) lorsque l'on rencontre des soucis et de le passer à un
niveau inférieur lorsque le VPN est validé fonctionnel.
> [...]
>
> Il semble que l'absence d'accès au réseau internet était causée par
> cette "transaction en échec en boucle" qui se prolongeait entre le
> client et le server OpenVPN.
Non, elle est dûe au fait que le routage était en place mais le VPN non
> Il semble que l'absence d'accès au réseau internet était causée par
> cette "transaction en échec en boucle" qui se prolongeait entre le
> client et le server OpenVPN.
fonctionnel (route par défaut vers le VPN)
>
> 2/ la connaissance du système de configuration des réseaux avec
> Stretch est encore plus d'actualité.
> En effet, quand ça marche c'est bien, mais quand ça foire il est
> crucial de savoir ce qui se passe.
> Et là,rien n'a indiqué ce qui était en train de clocher.
> De plus, je comprends que ce serait un système en cours de transition.
>
> Comment faudrait-il procéder pour savoir dans quel état se trouve la
> configuration de composants logiciels réseaux et la configuration
> réseau d'une machine Stretch ?
Jessie et Stretch. Les programmes et configurations ont éventuellement
évoluées, il s'agit surtout de savoir qui fait quoi. Dans ton cas, tu
cherches dans le fichier interfaces alors que c'est network-manager qui
semble gérer le réseau (qui n'utilise pas le fichier interfaces). Il
faudrait pour être cohérent faire gérer le VPN également par
network-manage (ou rien et utiliser interfaces + conf OpenVPN à la mano).
--
Daniel
roger....@free.fr
Sep 12, 2018, 5:20:03 AM9/12/18
to
Bonjour
*
En ce qui concerne la mise en veille ou en hibernation durables, cad suffisamment longue pour que le serveur déconnecte le client, lorsque la machine cliente se réveille, elle se reconnecte comme lors du démarrage.
Si c'est plus rapide, je crois que ça marche aussi. Je vais refaire le test.
Quel est le comportement normal que doit avoir un client VPN qui se met en veille/hibernation ?
Ne devrait-il pas au préalable se déconnecter du serveur VPN ?
Je vais examiner les paramètres du serveur pour voir si on peut l'obliger à vérifier plus souvent que le client connecté est présent sur le réseau ou s'il est juste inactif.
* network-manager
Il me semble que l'état des connexions du système est parfois incohérent entre l'état réel, ce qu'affiche le menu graphique et ce qu'affiche le System settings/Network.
Est-ce network-manager qui est responsable de ça ?
Peut-on le configurer (ou d'autres composants) pour que les connexions du système soient gérées par systemd, manuellement ou par network-manager de manière cohérente ?
J'ai entendu quelquefois des informaticiens se plaindre de network-manager apparemment pour les mêmes raisons.
Concrètement, comment dois-je procéder pour faire gérer le client OpenVPN par network-manager ?
Qu'est-ce qui est le plus robuste à l'utilisation ?
Configuration manuelle de /etc/network/interfaces et d'OpenVPN ou bien network-manager ?
Merci
Bonne journée
----- Original Message -----
From: daniel huhardeaux <no-...@tootai.net>
To: debian-us...@lists.debian.org
Sent: Sun, 09 Sep 2018 23:14:24 +0200 (CEST)
Subject: Re: OpenVPN sous Stretch avec systemd
*
En ce qui concerne la mise en veille ou en hibernation durables, cad suffisamment longue pour que le serveur déconnecte le client, lorsque la machine cliente se réveille, elle se reconnecte comme lors du démarrage.
Si c'est plus rapide, je crois que ça marche aussi. Je vais refaire le test.
Quel est le comportement normal que doit avoir un client VPN qui se met en veille/hibernation ?
Ne devrait-il pas au préalable se déconnecter du serveur VPN ?
Je vais examiner les paramètres du serveur pour voir si on peut l'obliger à vérifier plus souvent que le client connecté est présent sur le réseau ou s'il est juste inactif.
* network-manager
Il me semble que l'état des connexions du système est parfois incohérent entre l'état réel, ce qu'affiche le menu graphique et ce qu'affiche le System settings/Network.
Est-ce network-manager qui est responsable de ça ?
Peut-on le configurer (ou d'autres composants) pour que les connexions du système soient gérées par systemd, manuellement ou par network-manager de manière cohérente ?
J'ai entendu quelquefois des informaticiens se plaindre de network-manager apparemment pour les mêmes raisons.
Concrètement, comment dois-je procéder pour faire gérer le client OpenVPN par network-manager ?
Qu'est-ce qui est le plus robuste à l'utilisation ?
Configuration manuelle de /etc/network/interfaces et d'OpenVPN ou bien network-manager ?
Merci
Bonne journée
----- Original Message -----
From: daniel huhardeaux <no-...@tootai.net>
To: debian-us...@lists.debian.org
Sent: Sun, 09 Sep 2018 23:14:24 +0200 (CEST)
Subject: Re: OpenVPN sous Stretch avec systemd
daniel huhardeaux
Sep 12, 2018, 8:30:02 AM9/12/18
to
Le 12/09/2018 à 10:53, roger....@free.fr a écrit :
> Bonjour
Bonjour
> [...]
je trouve qu'il c'est stabilisé. Cela dit je continue à la mano avec le
fichier interfaces et Wicd.
> Bonjour
Bonjour
> [...]
> Quel est le comportement normal que doit avoir un client VPN qui se met en veille/hibernation ?
> Ne devrait-il pas au préalable se déconnecter du serveur VPN ?
Pour quelle-s raison-s ?
> Ne devrait-il pas au préalable se déconnecter du serveur VPN ?
> Je vais examiner les paramètres du serveur pour voir si on peut l'obliger à vérifier plus souvent que le client connecté est présent sur le réseau ou s'il est juste inactif.
Quel est l'intérêt ?
>
> * network-manager
> Il me semble que l'état des connexions du système est parfois incohérent entre l'état réel, ce qu'affiche le menu graphique et ce qu'affiche le System settings/Network.
> Est-ce network-manager qui est responsable de ça ?
> Peut-on le configurer (ou d'autres composants) pour que les connexions du système soient gérées par systemd, manuellement ou par network-manager de manière cohérente ?
> J'ai entendu quelquefois des informaticiens se plaindre de network-manager apparemment pour les mêmes raisons.
Ceci est un autre débat. Il y a quelques temps NM était une catastrophe,
> * network-manager
> Il me semble que l'état des connexions du système est parfois incohérent entre l'état réel, ce qu'affiche le menu graphique et ce qu'affiche le System settings/Network.
> Est-ce network-manager qui est responsable de ça ?
> Peut-on le configurer (ou d'autres composants) pour que les connexions du système soient gérées par systemd, manuellement ou par network-manager de manière cohérente ?
> J'ai entendu quelquefois des informaticiens se plaindre de network-manager apparemment pour les mêmes raisons.
je trouve qu'il c'est stabilisé. Cela dit je continue à la mano avec le
fichier interfaces et Wicd.
>
> Concrètement, comment dois-je procéder pour faire gérer le client OpenVPN par network-manager ?
Option VPN du menu de NM en ayant pris soin d'installer nm-openvpn
> Concrètement, comment dois-je procéder pour faire gérer le client OpenVPN par network-manager ?
>
> Qu'est-ce qui est le plus robuste à l'utilisation ?
> Configuration manuelle de /etc/network/interfaces et d'OpenVPN ou bien network-manager ?
à toi de tester et choisir ce qui te conviens le mieux.
> Qu'est-ce qui est le plus robuste à l'utilisation ?
> Configuration manuelle de /etc/network/interfaces et d'OpenVPN ou bien network-manager ?
Erwan David
Sep 12, 2018, 12:50:02 PM9/12/18
to
On Wed, Sep 12, 2018 at 02:04:14PM CEST, daniel huhardeaux <no-...@tootai.net> said:
> Le 12/09/2018 à 10:53, roger....@free.fr a écrit :
> > Bonjour
> Bonjour
> > [...]
> > Quel est le comportement normal que doit avoir un client VPN qui se met en veille/hibernation ?
> > Ne devrait-il pas au préalable se déconnecter du serveur VPN ?
> Pour quelle-s raison-s ?
Pour ne pas bouffer un slot de connexion et les ressources associées
> Le 12/09/2018 à 10:53, roger....@free.fr a écrit :
> > Bonjour
> Bonjour
> > [...]
> > Quel est le comportement normal que doit avoir un client VPN qui se met en veille/hibernation ?
> > Ne devrait-il pas au préalable se déconnecter du serveur VPN ?
> Pour quelle-s raison-s ?
sur le serveur de VPN pendant qu'il dormira par exemple
--
Erwan
0 new messages