Re: VPN architecture

[Colin Walters <walters verbum org>]

On Sun, 2004-11-07 at 20:46 -0500, Dan Williams wrote:
> On Sun, 7 Nov 2004, Colin Walters wrote:
> > So to implement this, I'm thinking that we define a new service,
> > org.freedesktop.NetworkManagerVPN.  NetworkManager would then
> > talk to this service (probably implemented as a separate daemon)
> > when networking parameters change.  The VPN daemon would then
> > invoke methods on NetworkManager, like:
> > void org.freedesktop.NetworkManager.VPNActive(in string name)
> > void org.freedesktop.NetworkManager.VPNInactive(in string name)
> > void org.freedesktop.NetworkManager.AddRouteIPv4(in string netmask, 
> >                                                 in string gateway,
> >                                                 in string device)
> > void org.freedesktop.NetworkManager.AddNameserverIPv4(in string quad)
> > void org.freedesktop.NetworkManager.AddNameserverIPv4Routed(in string quad, in string netmask)
> 
> I actually really like this idea, though you could argue in some way that 
> a VPN _is_ a network connection.  

Yes, sometimes you want it to take over the default route, like
"vpnonly" at work.  This seems a bit hard to autodetect.  Possibly we
define some "well-known" servers for a user, and if we can't reach them
through the normal connection, ask the VPN if it can do default routing,
if it can, we have it take over the default route, and try reaching
those servers again.

> However, to keep the logic simpler, it 
> would suffice to have VPN-specific stuff in a separate daemon, and we 
> could refine the interface between the two so they have what they need.

Yeah.

> > To really implement this well though, NetworkManager will have to start
> > driving things at a lower level.  For example, instead of simply exec'ing
> > dhclient, NetworkManager should speak DHCP itself (as a separate process though
> > still), and e.g. gather a list of returned nameservers itself, then
> > add the VPN ones to it and synthesize /etc/resolv.conf.  Also,
> 
> This is something I've thought about for a while, I'm thinking that it 
> might end up being necessary to take over dhclient and Make It Our Bitch.

I'm a big fan of any project that involves Making Other Software Our
Bitch. :)
  
> Its under a 3-clause (non-advertising) BSD-type license, not sure how that 
> works with GPL code, though NetworkManager is doing the calling here.

3-clause is fine for bitchification, but we might actually be able to
write a "library" around dhclient that does a fork/exec, writes to a
temporary file instead of e.g. /etc/resolv.conf, and then reads out of
that.  Ugly though :/

> > to implement AddNamserverIPv4Routed, NM will really have to run its own
> > caching nameserver.
> 
> This was the suggestion of Jason VasDias, instead of restarting nscd all 
> the time.  Using the caching-nameserver package (which integrates with 
> dhclient in some ways) would work better, in his opinion, than nscd does.

Hm, yeah.  

You know...in the larger picture, it seems to me that NM should be
managing a lot of other services too.  Like every time I boot up my
laptop, ntpd fails, because there's no network connection.  Ideally, NM
would automatically invoke ntpd when there was a connection, and stop it
when there wasn't.  Same for portmap, and...well, like half of my
system.