DHCP clients and VPN connections

[David W. Hankins]

On Fri, Apr 04, 2008 at 03:42:19PM +1000, Andrew Pollock wrote:
> Does anyone have any suggestions on how to deal with this scenario?

solving this in dhclient-script is gets messy...something like
writing an /etc/resolv.conf.cache.${interface}, then awking them
all together rather than writing your own out.  but you have to
detect and remove stale caches, and ... just messy.

which is why i like to go on at length about NetworkManager.


our long-term plans are not yet solidified, we still debate about this
internally.  but what i see as plausible boils down essentially to two
scenarios;

in scenario #1, you:

	dhclient --dbus eth0
	dhclient --dbus vpn0

	[killall dhclient]
	[or dhc stop eth0 maybe]

each dhclient process sends its config to any interested parties on
dbus.  this will probably be NetworkManager, but in theory you could
have anything (or everything) listening.  agents on dbus will be
responsible to sort the config from each interface into a single image
of config, according to local preferences (NetworkManager will
probably reflect this config to other applications, and make parts of
this process tunable by nm-applet) and defaults (you should probably
prefer config from a faster/more reliable interface...wired over
wireless, interleave v4 and v6 information, etc).

i'm unclear on whether or not the dhclient will still be in charge
of configuring addresses on the interface or if we leave that to the
external components.  i suspect it will do it internally.


in scenario #2, you;

	dhclient --daemon

	dhc start eth0 inet
	dhc start vpn0 inet

	dhc stop eth0 [release]
	dhc stop vpn0 [release]

in this case, you're starting a single dhclient daemon, and using a
lightweight control tool (not omapi) to add interfaces and start the
state engine for different kinds of config acquisition (dhcpv4,
v6, stateless, ...).  this 'dhc' will probably use dbus anyway if you
have it; that's slimmer and easier than installing /lib/libisc-cnc.so!

dhclient could still use dhclient-script, in which case it would
maintain a database of config in memory, and each state engine (each
source of config) would insert its config into that one image.  on
each reconfiguration event, we'd flush the entire image out every
time.

as an added bonus, 'dhc status' tells you something useful
(hopefully) without having to tail logs.


in theory there is a scenario #3 where you do the same thing as
scenario #2, except you still use dbus to write out all the config
bits and let something external worry about how they combine.  this
is equivalent to scenario #1 (we wouldn't sort the config), just
fewer sockets and processes.


anyway, i'm kind of experimenting with this right now when i can
find time between other work items, so i hope to have some progress
in this direction in the next few feature releases.

icyc, we elected to keep a single dhclient binary for v4 and v6
because we perceived this problem exists even in the single-interface
trivial case...you still have to combine config data from two
different sources.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins