On Wed, May 25, 2011 at 09:46:12AM +1000, Andrew Cowie wrote: > tinc has been really useful for us, and so the other day I blogged about > tinc as a way of saying thank-you, > http://blogs.operationaldynamics.com/andrew/software/research/using-tinc-vpn.html
Thank you, that is indeed a very nice post :) > Somewhat innocuously, I closed with reference to NetworkManager; having > used it with openvpn and been very impressed with the experience (not > the openvpn part, but the fact that GNOME's networking UI made > configuring and managing a connection *really* smooth). Tuns out the > lead developer of NetworkManager saw my post, and replied with one of > his own, > http://blogs.gnome.org/dcbw/2011/05/24/networkmanager-0-9-pidgin-and-tinc/ > > Dan made some fascinating observations about what sort of things he > would need in order to be able to drive a tinc daemon from > NetworkManager. So I thought I should mention his post here in hopes it > might be useful input as you consider architecture and design for tinc > 2.0. That is indeed very helpful. It seems Dan has looked at tinc very closely. I do have some comments on his post though, and since I could not reply on his Gnome blog, I'm answering here, and Cc-ing him. 1. Tinc does supports multiple setups using the -n or -c options. 2. Tinc does not configure any "related connection information" like interface configuration, firewall rules, et cetera. It merely calls the tinc-up and tinc-down scripts which you can fill in to do that. However, this is not a requirement, you can omit the tinc-up script, and have NetworkManager configure the VPN interface and related things for you. Personally I have also set up tinc to integrate with Debian's "ifupdown" way of managing networks. 3 & 4. There is indeed no way currently to have tinc read its public and private keys from anything else but its own configuration files. Other people have already discovered the -o option in tinc 1.0.14 and want to use it to pass the private key to tinc, but this is not (yet) possible. Indeed, it would be even better to accept everything on stdin, although a transient, private configuration directory would work fine with current versions of tinc. I will try adding input from stdin in the next version. * "Configuration appears to require an explicit device name (like “tun0″)" This is not true, it is perfectly OK to omit the Interface variable, in that case tinc will use the netname from the -n option as the interface name, or if none is specified, it will use the first available tunX name. * "Like OpenVPN, it appears that many attributes of the VPN connection cannot be auto-detected" This is also not true. Although not explicitly mentioned in the documentation, each node can have their own Cipher/Digest/Compression settings, and these settings are communicated to the other nodes, so there is no need to manually ensure everyone has exactly the same settings. * "It appears that one can send signals to tincd, but they dump information to syslog." That is true for the 1.0.x versions. In tinc 1.1 (which interested people can already get from the git repository and try out), there is a management interface, allowing you to retrieve status information, and perhaps change run-time settings, add/remove connections, and so on. I will see what information NetworkManager requires, and try to add that to tinc 1.1's management interface. From Dan's blog: > If anyone wants to write a NetworkManager VPN plugin for tinc, definitely let > me know or jump onto the mailing list and we’d be glad to help out with > suggestions and advice." I fully agree with this! -- Met vriendelijke groet / with kind regards, Guus Sliepen <[email protected]>
signature.asc
Description: Digital signature
_______________________________________________ tinc mailing list [email protected] http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
