Re: vpnc and determining correct routes

[Dan Williams <dcbw redhat com>]

On Mon, 2006-10-23 at 17:01 +0200, Thomas Liebetraut wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> Dan Williams schrieb:
> > Correct, it doesn't care about the environment variables that vpnc
> > pushes out for split routing yet.
> And this is the problem for me. I don't know how these variables gout be
> obtained by vpnc plugin in an elegant manner. Maybe I missed some

The process flow is this:

1) nm-vpnc-service starts vpnc
2) vpnc calls nm-vpnc-service-helper
3) nm-vpnc-service-helper (which takes the place of vpnc-script) grabs
the configuration and sends it to the nm-vpnc-service via dbus
4) nm-vpnc-service-helper forwards the config to NetworkManager

If you look at nm-vpnc-service-helper.c, around line 254, you'll see
that the config bits are just pulled in from environment variables set
by vpnc.  The interface between nm-vpnc-service-helper and
nm-vpnc-service is private and may be changed without worry.  The
interface between nm-vpnc-service and NM, however, is semi-standard and
needs a bit more care.

I've added a dict-based VPN config interface to 0.7/HEAD, which is what
should be used here.  The vpnc plugin hasn't been converted over yet,
but it will need to be for this to work.  We then simply add a new dict
entry with a standard name, say "vpn_routes", which is a dbus array of
ipv4 addresses formatted as dbus_uint32_t.

We should then standardize on a VPN config key for the two different
types of route lists, "explicitly route these over VPN" and "never route
these over VPN", and then every VPN plugin's user-config would store
those two options (or we consider them blank if they don't exist).

The vpn-manager would fix up the routes based on what the vpn service
plugin said the VPN server/concentrator advertised, and what the user's
preferences were (from the NetworkManagerInfo service which provides
user config storage).

> details in vpnc's code and we already have an interface for those
> variables, but I don't really want to add a dbus interface to vpnc which
> has not seen a new update for more than  12 months.
> 

That's fine, 0.7/HEAD is open for changing.  More than just the VPN DBus
API is going to change in 0.7.

> > Not a ton of work, you just need to know where to put the code.  I'd be
> > happy to point people in the right direction.
> I think I already know (roughly) where to put the code to and I think I
> could work on it. Sorry if this was not clear from my first mail, but my
> intention was to ask for possibility to do it, not to let others do it ;-)
> 
> In case we find a solution for getting the required information by vpnc,
> here are the issues I see:
> - - DNS. Linux's resolver (at least for my Ubuntu distro) only allows 3
> DNS servers. How should split DNS be handled if the VPN's DNS server
> provides domain names for hosts in the VPN but not for hosts in the
> Internet and the ISP's DNS does not provide domain names for hosts in
> the VPN?

You can't use the Linux resolver anymore then.  To get split DNS, you
must use a caching nameserver locally.  NetworkManager has support for a
dbus-enabled bind, which fully supports split DNS, and works perfectly
in a caching-nameserver configuration.  In this configuration _NO_PORTS_
are open on the machine, except port 127.0.0.1/53.  The bits to have
NetworkManager set each forwarding domain aren't implemented.

We talked with the glibc folks a while ago, and they decided not to
include split DNS capability in the libc resolver.  They don't want to
complicate the libc resolver with functionality that not too many people
need.

The other option was lwresd and nss_lwres, which wasn't viable at the
time because it had bitrotted and would have required a few months of
work to get it up to speed, which was unacceptable.

Note that since NM uses dbus to communicate with the local caching
nameserver, it's easy to plug in another nameserver (ie, not bind), that
uses the same DBus interface.  Some people have a kneejerk reaction to
running bind.

> - - How much flexibility should the user be given? Or in other words, how
> far should NM compensate for incompetent netowkr admins? I would say
> that a simple override for *all* of vpnc's routes would be sufficient.

That's the way it already works; if you enter routes, they ones you
entered override anything the VPN server/concentrator reports.  But I
think you're right; if you override the routes with your own, NM should
ignore any routes the VPN returns.

Do we care about the 'never route this' case?  That would be where, for
example, you don't override what the VPN returned, but just say that
192.168.1/24 is never routed over the VPN.  If we could at least plan
for that, it would be great, but we don't need to put it in the UI for
now.

> This would mean that the UI stays as it is and that someone can either
> use the routes the concentrator provides or specify his own routes. For
> users who know what they do, this is as much flexibility as they may
> need, for user who don't know, it won' help one way or the other without
> the admin helping them, and in this case the admin might fix his network
> setup right away.
> 
> If everything is sorted out and I still have the time, I'll try to write
> the required patches. It doesn't seem to be too much code for me, as
> long as I don't have to hack up vpnc itself to provide a new interface.

Sounds good, lets just ignore the 'never route this' case in the GUI for
now, but at least code for it in the dbus dict which the VPN service
plugin returns to NM.

Thanks,
Dan

> Regards,
> Thomas
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFFPNk+xVmZpTAq4IgRAlWsAJ9uokAiBqmoeMs178YdU9QoLDYzFACfTb9K
> HpqVZyZLkHuY1FA/HK84xus=
> =/p0f
> -----END PGP SIGNATURE-----