Use case: VPN client

martin f krafft madduck at debian.org
Thu May 10 07:09:53 UTC 2007


also sprach Marcus Better <marcus at better.se> [2007.05.09.2034 +0200]:
> > Fair enough, although I think this might be a job for the VPN
> > client?
> 
> Yes, maybe. OpenSwan 3.x is supposed to get some functionality in
> this direction - dynamically discovering that interfaces go up and
> down etc. But I don't know if it will have the logic to decide if
> a connection should be brought up. That should be checked...

Maybe. I use OpenVPN, and it should be able to do the same.

> > I want to solve this with dependencies. vpn0 pre-depends on
> > a default gateway, so try to configure network interfaces in
> > a defined order until you get a connection.
> 
> An IPsec connection in Linux 2.6 is not a separate network
> interface (like it was in 2.4, or with the KLIPS module). But
> I guess it could be a virtual interface.

It depends. In-kernel IPsec is done with policies, but to be
honest, I hate it because it's obscure. I use OpenVPN myself and it
makes use of tun devices and the standard routing table. That's
obvious to me.

Anyway, we ought to be able to deal with both.

> I'm not sure the dependency approach is optimal here though. For
> this to work, there has to be a decision to start the vpn0
> "interface". In other words there must be an ultimate goal which
> starts a dependency resolution chain. This is not how it works in
> reality. A user should just plug in the network card, or move into
> a WiFi zone, and automatically the interface is brought up,
> wpa_supplicant does its thing, we get an IP address and some
> routes with DHCP, and finally the VPN connection is started.

The way I see it is *not* that the system automatically links up to
the net whenever it can. Rather, netconfd gets notified about new
devices and link changes and then observes policy. It may be that
under certain circumstances (no eth0 link but a new wlan
association), it just establishes the route, but in other cases it
may do nothing until the user instructs it to up the interface.

Wrt VPN, I can see two models, both of which are interesting and
non-exclusive:

1. the user says s/he wants a VPN connection, so netconfd figures
out what to do in the given environment to satisfy the prerequisites
and established the tunnel. If there is already a link, just bring
up the tunnel...

2. the daemon decides that the link to a given network is either
insecure or unroutable, so it brings up the VPN to guard it.

I think both are supportable.

> Note that there is no probing of network interfaces in some order.
> Such an order may be hard to define ahead of time, since the list
> of possible network interfaces is not known. You should be able to
> plug in a completely new network card.

Agreed. But if netconfd needs to establish a link and there's
a carrier to a link-local net on eth0, an encrypted and thus
inaccessible wlan network close by, and ppp0 linked to the GSM
modem, what does it do? What if the wlan network is open but of crap
quality?

> ================
> ~$ cat /etc/network/if-up.d/upstart
> #!/bin/sh
> 
> exec /sbin/initctl emit interface-up $IFACE

This is nice, but is it necessary? Why do you let hooks notify
upstart to run scripts, instead of running the scripts directly from
if-up.d?

> Then I have a script /etc/event.d/check-local-network which gets
> started on the interface-up event. It does some checks to see
> which network I'm connected to, and emits further
> "home-lan-connected", "office-lan-connected" and "inet-connected"
> events. Other scripts can trigger on those events. For instance
> "inet-connected" would start an IPsec tunnel unless we are between
> the "office-lan-connected" and "office-lan-disconnected" events.

While I would argue that all this can be implemented with ifupdown
hooks and no upstart, it's definitely a nice use of the
event-driven nature of upstart and in as such academic and geeky in
the best sense of the words. :)

However, is it that complex? Do we need upstart for this?

I am pasting more and more of my unfinished but already announced
document, but my idea of netconfd is a daemon that monitors the
kernel and a control socket. ifup/ifdown interact with the control
socket, as does a bridging handler to the dbus protocol. netconf
also provides a number of hooks, which can be used to signal such
tools as upstart.

netconfd gets started very early on in the boot sequence, before
udev. The idea then is that it monitors for new interfaces. When
a new interface is found, it checks the configuration/policy on what
to do. If it's to be brought up automatically, it figures out the
configuration method to use and applies it, running hooks at various
stages. If it's not to be configured automatically, it just
publishes information about the interface to let user-space tools
know it's there.

The user might then choose to bring up the interface (through a GUI
like network-manager) and the netconfd does it's thing, again using
firing off hooks.

Whether it's hooks or events is IMHO a question of perspective,
especially with a fixed set of hooks/events. If you want to allow
free-form hooks/events such as in your above example, then it feels
more natural to think of events. For this scenario, netconfd could
come with a very basic event handler (as simple as run-parts,
passing $1=$event_name to each script) and interface directly with
upstart, if it's installed.

> > What exactly does upstart provide that you think would be stupid to
> > reimplement?
> 
> *Event handling: which jobs are triggered by an event.
> *Job state management: keep track of which jobs (services) are running.
> *Specification of complex conditions for a job to be started, such as this 
> [2]: "Or maybe we only want to be run if a network interface comes up before 
> bind9 has been started:
>   on network-interface-up and from startup until started bind9"
> 
> (All of this assumes that we want an event-based mechanism.)

The question to answer are: are any of these so necessary for our
final goal and yet too complex to implement that we should make
netconf depend on upstart? You see, upstart isn't just an event
handler, it's designed to replace /sbin/init, and I believe it does
so in recent versions. Now that's way too heavy a dependency for my
taste.

Thanks for your input, Markus. Keep it coming.

-- 
 .''`.   martin f. krafft <madduck at debian.org>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"the word yellow wandered through his mind in search of something to
 connect with."
                                 -- hitchhiker's guide to the galaxy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature (GPG/PGP)
Url : http://lists.alioth.debian.org/pipermail/netconf-devel/attachments/20070510/b8946628/attachment-0001.pgp


More information about the netconf-devel mailing list