Hi, On Sat, Apr 12, 2014 at 07:55:01PM +0200, Christoph Biedl wrote: > The essentials for my setup: > > * For each client, the tunnel interface must have a fixed name > > This is required for accounting and/or client-specific packet filter > rules. > > Status: "dev tun123" or similar is not allowed in a CCD file. > > There's not even a trace whether tun device creation is controlable. > Well, for the they don't get created at all, see below.
This can not be done, period. A single instance of OpenVPN will have a
single device.
> * For each client, I need an individual startup file
>
> Status: "up" and friends are not allowed in a CCD file.
>
> There might be a workaround using a global setting and using a
> switch driven by environment variables, I haven't checked yet since
> I failed to get *any* CCD setup running, see below.
This could be done with "--client-connect" - which is called on the
connect of an individual client, and has all the relevant information
to decide on per-client actions. It will be one global script, though,
but as it knows the client ("$common_name" in environment) it can run
per-user scripts to your liking.
> * For some clients, I need individual settings for some of the
> gazillion of {link,tun,whatever}-mtu, and preferibly for "comp-lzo",
> too
>
> Status: You guess it
>
> "comp-lzo" does not trigger a "cannot be used in this context" warning,
> whatever that means.
"comp-lzo" can be done with git master (per-client compression settings),
2.3.x can not yet do that (infrastructure missing that came with the
addition of "compress snappy" and "compress lz4").
I'm not sure about the MTU settings, but at least those that affect the
single "tun" interface can definitely not be used in a ccd/ file. mssfix
might be possible.
> * For an unknown client, the server must reject the connection
>
> Status: DEFAULT is tried, and even if missing/unreadable/invalid, some
> bizarre configuration values are used instead.
An unknown client should never reach that state, if you have per-client
certificates - which is really what you want in a point-to-multipoint
setup.
But in any case, if you have this, just put "disabled" into the DEFAULT
file.
> I have little understanding why the CCD files are *that* restricted.
Some of the things just cannot be done, like "single process, single
interface". This is the architecture, and it is what it is.
> I'd prefer a setup where the master process does x509-based
> authentication, then forks a child with a full (modulo TLS
> credentials) configuration, passing the existing connection. That
> would solve all my problems, can this be done in openvpn?
No. It might be possible with some hackery around --inetd (which
indeed forks a single process for each incoming TCP connection) but
the code would need work, as it currently assumes that --inetd will
always be used with bridge-mode tap interfaces.
> So the big question is: I fail to believe I am the first person with
> such requirements. What else?
It's hard to say why you think you need that (single process, but individual
tun interfaces) - but I've never needed it for any of my setups.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de
pgpl51_mpNhfL.pgp
Description: PGP signature
------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
