Re: OpenVPN sous Stretch avec systemd

[daniel huhardeaux <no-spam@tootai.net>]

Le 12/09/2018 à 10:53, roger.tarani@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 ?
> 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, 
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
> 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.
> ----- 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