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----- _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
