On Saturday 03 July 2004 15:13, Brandon Knitter wrote: > Hey there. James and I had a prior discussion about the systray app > offline, but I thought I'd just poke my head in here. I'm not a strong > Windows application programmer, but I've been doing a lot of C# these days. > > With that in mind, I was gonna whip together a quickie little systray app > in C# which could control the openvpn server. I know that C# adds the > rather large .NET framework runtime installation, so my app could be > considered a prototype if you would like! > > Where do I start? Are the namedpipe hooks into the OpenVPN service built? > I'm not too familiar with named pipes on Windows (done a bit on *nix), but > I'm sure it can't be too hard. I guess what I'd need to know are the > command to send to the named pipe, and also what I can get from the named > pipe in regards to status and such.
There are no hooks as of yet to control a running OpenVPN instance (other than sending signals). While I initially thought that named pipes might be the appropriate channel for this, I'm wondering if if might make more sense (for portability) to use a local TCP/IP socket as the control channel, such as 127.0.0.0:[some port]. Then for testing purposes, you could just telnet to the socket. I am thinking the interface should consist of a standard ascii command response loop, such as is used by SMTP. Possible client -> server commands: (1) send auth credentials (2) get status (as in SIGUSR2) (3) send signal (SIGHUP, SIGUSR1, or SIGUSR2, SIGTERM) And server -> client commands: (1) need auth credentials -- GUI should query the user then return them to the daemon via a "send auth credentials" command The basic mechanism of operation to enable the management interface would be to pass an option like this in the config file: management 127.0.0.1 20001 This will cause OpenVPN to listen on 127.0.0.1:20001 as its management interface port. It's important, of course, that the management port always be local, since we are using it to potentially pass passwords and other sensitive data that should never actually touch a real network interface. Thinking ahead, the challenge/response sequence for passing authentication info should be open-ended to provide for future implementation of alternative authentication methods such as Radius, LDAP, NT Auth, etc. This is all just a proposal, no code has been written yet, comments are welcome. James
