|
Em Saturday 25 February 2012, Volker Kuhlmann escreveu: > On Sat 25 Feb 2012 09:15:34 NZDT +1300, Dan Williams wrote: > > Are you using KDE or some other desktop environment? > > Yes. The packages are > > NetworkManager-0.9.1.90-4.8.1.x86_64 > NetworkManager-kde4-libs-0.9.1git20111027-1.3.1.x86_64 > NetworkManager-openvpn-0.9.0-2.1.2.x86_64 > NetworkManager-openvpn-kde4-0.9.1git20111027-1.3.1.x86_64
Which openvpn version do you use?
> The wlan part of NM and the KDE panel applet are very good - my only > gripe is that when I disconnect a wireless connection, the connection is > removed from the list of available configurations for quite some time > before it reappears - very irritating when I want to immediately > reconnect (essential for setting up connection details).
I am not aware of this problem (I am the responsible for Plasma NM, the KDE applet for NetworkManager). I have just check it here and my wifi connection stays in the plasmoid and the kcm (Manage Connections") lists after I disconnect it.
> But the desktop should be irrelevant - any usable technology works with > gnome and kde equally well. > > > > Back to the question: Is there any other way for me to set options with > > > which nm runs openvpn? > > > > Other than the options that are provided in the UI, you can edit the > > configuration file in which the VPN connection settings are stored. > > Otherwise there is no other way; there is intentionally no text entry > > for arbitrary options, because openvpn runs as root, and that's a pretty > > big security risk to allow unprivileged users to enter whatever options > > they want that get read by a root-level daemon. Even if/when we do > > switch to doing something like sandboxing the daemon, having a text edit > > box isn't great UI and isn't very helpful for users. Instead, we take a > > more measured approach; if there's a setting that people need, we figure > > out how to add it to the UI in a logical and usable manner. > > Sure there is a security issue to deal with, but given that NM asks for > a root password each time there's a change to the connection settings I > don't see any security *problem* here.
The problem is implemeting in NM all the checks to make sure the options are safe. NM cannot just pass them to openvpn daemon.
> I have come to the conclusion that NM is not useful for openvpn here. > Certainly not for normal users, and power users don't need NM. Here's why > (enter this in your issue tracker, I meant to post this anyway): > > * It doesn't get the job done, and there is no useful diagnostic output > of any kind. (syslog only has successful dis/connections and nothing > else, /var/log/NetworkManager only deals with itself, not with openvpn.) > > Nothing I've seen yet comes close to the functionality of kinternet for > establishing connections (full diagnostic logs a click away, full > configurability, no need to subscribe to mailing lists to get it to work > - very fast to use). > > * The VPN would obviously need to run over another connection. I didn't > see any hint that suggests NM is taking care of bringing up the > connection that VPN relies on first. Auto-connect would be useful, > failing that a list of connections to activate manually would be > required. I don't see that list being reliable.
auto-connect for VPN is not implemented in NM as far as I know. There are some scripts from users in this mailing list to do just that. I have never tested them though.
> * Routing rules would be not so trivial. For the transport connection > basic requirement is to reach DNS and VPN server. A default route would > be useful. For the VPN connection routes need to change again, default > route is essential and all routes that may go to the transport network > need to be reliably removed to ensure all traffic goes through VPN. It's > not happening.
Not everybody wants to route all traffic through VPN. I use VPN to access specific sites, not the whole Internet. In my case that would disrupt my other connections since the VPN I access are local networks and have no access to the Internet.
> There is also the case where a VPN may deliberately be set up for one > particular networking area only, with all other traffic not going > through the VPN. That's what the tickbox "set default route" is for > which I remember seeing in some network configuration GUI.
That is my case. Well, I must admit that VPN routing in NM is not obvious, sometimes I need to change settings in two or three different dialogs to make it work as I want.
> * NM starts openvpn with an openvpn option that causes the vpn to stop > dead halfway through the startup. Impossible to fix with NM.
Which option is that?
> * I want (so far) one security option in openvpn. Impossible to fix with > NM. > > * The routes set up by NM/openvpn aren't quite right for what I need at > least for one connection. I was thinking of using up/down scripts to fix > that up. Impossible to do with NM. Maybe routes can be added with NM, > but they can't be deleted.
I can delete routes.
> > Running nm-openvpn-service --persist --debug will run openvpn with > > "--verb 10" which will also show the verb3/verb4 output. Is that nto > > working for you? > > Sorry I was wrong twice. Yes it does work, and the debug output is from > openvpn (perhaps I didn't see it first because my openvpn wrapper script > wrote arguments and output to file). It does however not show the > arguments to openvpn, and that's pretty poor. For troubleshooting first > thing I want to know is how external programs are called. > > I don't mind editing /etc/NetworkManager/system-connections/VPN_whatever > (as root!) but doing so serves no useful purpose. It still doesn't pass > options to openvpn, all it does is for nm to barf before even starting > openvpn. > > pfsense (a professional firewall with BUI) has a text box for arbitrary > options too. And I haven't used it yet, there is a useful range of > options in the standard option part that just make it work. > > You say a text box isn't good for users? But a useless piece of software > is more user-friendly? "Useless" being the adjective for a kettle that > doesn't boil water. > > Chasing the options which someone might need is a losing proposition. I > doubt you can know in advance. What happens if openvpn changes? 12 > months of "you're stuffed with NM"? > > Bottom line is NM openvpn can't be made to work. I like it for wifi > though.
-- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br |