n2n revisited
R.A. Hettinga
rah at shipwright.com
Wed Sep 2 07:00:46 PDT 2009
<http://www.snell-pym.org.uk/archives/2009/08/22/n2n-revisited/>
Snell-Pym
Sarah and Alaric Snell-Pym living in interesting times
n2n revisited
I have spoken before about n2n, the peer-to-peer VPN tool that makes
it easy to create efficient virtual networks.
Normal VPN products are really more of a "virtual private cable" than
a "virtual private network" - they just establish a point-to-point
link over the Internet, requiring a login to set it up and encrypting
the traffic. This means you can have a virtual connection to a real
private network somewhere; and if a few people connect into that
network via VPN links, then there really is a virtual private network
between you all, but all going through a central point where all your
links meet.
While with n2n, everyone connects to a shared "supernode" that keeps a
list of who is connected to the VPN, and from where; then when you
want to connect to somebody else, you use the list from the supernode
to establish a direct encrypted connection between yourself and them,
rather than going through any central point. So it's an actual virtual
network out of the box. You can even have more than one supernode
running, so that any one can fail; all the supernode does is to
provide the directory service.
Also, you don't need to maintain a database of user logins; a
supernode can carry any number of virtual networks. When you connect
to the supernode, you just tell it the name of the community you want
to join, and it will share your connection details with anybody else
in the same community - you can make communities up on the fly rather
than needing to maintain a central list. Access control is handled by
the simple fact that you need to know the correct encryption key for
the community you want to join, or your messages will be received
garbled by everyone else, and ignored.
Anyway, for a long time, I wanted to get into n2n, but I couldn't as
it didn't compile out of the box on NetBSD; but a desire for a better
VPN solution at work has led to me getting it working. It wasn't that
much work, in the end, as the existing FreeBSD support already had a
BSD approach to things.
n2n is distributed via Subversion, so they don't have version tarballs
- this is a problem for my NetBSD port. So I decided to mirror it into
git with git svn, then forked it as "Kitten n2n", made my NetBSD port,
tagged a release, pushed it to github, uploaded a tarball from that
tag, and then made a NetBSD package of net/kitten-n2n.
I'll tinker with it for a few more days, then I'll submit it to the
NetBSD folks for consideration.
I'll keep pulling in from the official n2n Subversion repo, to pull
down patches, and I'll see if they'd like my patches pushed up - as
well as NetBSD support, there's a few things I'd like to fix as well
(I've spotted passing an integer through a void* by casting, which is
slightly dodgy practice and produces warnings on my 64-bit machine,
but is easily fixed by passing a pointer to a heap-allocated copy of
the integer!)
Crypto / security | alaric | Sat 22nd Aug 2009 12:49 pm
1 Comment
By alaric, Tue 25th Aug 2009 @ 12:26 pm
We've since spotted a few more neat features of our n2n vpn.
Firstly, it's not fragile, because it has good state recovery. The old
PPTP VPN would, if we moved network or suspended and awoke our
laptops, go down and require manual re-connection. However, n2n works
by having the edge nodes send regular keep-alives to the supernodes,
updating the supernodes' directory tables. So if we're offline, the
edge nodes' keep-alives are discarded due to lacking a route out; and
when we come online again, one gets to the supernode, and then we're
back.
This means that we've ended up leaving our n2n connections running, as
once they're running, they stay running. Being connected to the VPN is
something that's just there, rather than being something you manually
initiate when needed.
And this has led to a second dimension: the laptops of anybody who's
online are all joined on a virtual Ethernet LAN. So we can see if
people are online by just pinging them. And we see each other appear
in Bonjour.
We have a Nabaztag in the office; it announces (via text-to-speech)
when people push to 'mainline' git repositories, and we want to make
the continuous-integration system so it can announce when somebody
breaks the build. But that's not so useful for people who are working
from home; so we've been considering running a reliable-multicast
group (using the Spread Toolkit) that team events can be published
into, and things like the Nabaztag listen from - but then we can
extend it over our VPN, so it can drive Growl notifications on my Mac,
and similar mechanisms for the Linux users.
More information about the Testlist
mailing list