Re: OpenVPN sous Stretch avec systemd
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-spam@tootai.net>
To: debian-user-french@lists.debian.org
Sent: Sun, 09 Sep 2018 23:14:24 +0200 (CEST)
Subject: Re: OpenVPN sous Stretch avec systemd
Le 09/09/2018 à 20:28, roger.tarani@free.fr a écrit :
> [...] 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
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
Reply to: