hi, > Hi Sampo, > > > I have been busy writing a forking server > > addon to openvpn. > > Cool... Does each potential connecting client need a separate config file, > or does the server use a common client template and then keep track of > things like dynamic ports, dynamic endpoint addresses, etc?
No they don't. I just use normal config files/command line and use --remote as server addres in the client. I just got it running. Still with out dynamic ip address assigment and proper signal handling in parent process. And there ain't anykind of DoS protection yet. Lack of dynamic addresses still limits it to a single connection but a pool of addresses should not be too hard to implement. There are also need for a few new options like the range of ports/addresses used. Ofcourse there should also be an ability to define addresses to each client. I haven't decided how to do that yet. > > In openvpn.c I have separated the processing of > > parameters from main() to a new function and > > moved main to another file to allow me to > > link against different main() functions. > > > > One that implements normal peer2peer vpn > > and two others that produces forkin' server > > and client. > > > > These use a simple UDP protocol to agree a > > port to use, after which server forks do > > some handshaking with client and then > > calls openvpn() funcition from openvpn.c > > Are you sure there needs to be a new protocol to do this? No, I am not. But found it easy to implement in this manner. > Suppose the master server listens on a particular port, reads the initial > datagram from a connecting client, verifies the integrity of the datagram > using a --tls-auth variant, allocates a dynamic port, forks a new server > process, and continues in its event loop. It really sounds reasonable. I also though of some kind of message authentication before fork. --tls-auth sounds good since it is quite light-weight. > When the forked process finishes up the TLS authentication, it can take the > Common Name from the client certificate and use it to determine the > appropriate config profile to use (containing ifconfig addresses, route > statements, etc.) > > Or the handshaking could be done by passing a configuration string in the > TLS payload, similar to the string now built by options_string(). At the moment I do some handshaking in dynamically allocated port before calling openvpn(). Mayby I could add the exchange of address info here, since I don't think it needs to be transferred over a secure channel. > > This way I have been able to keep > > those well tested procedures and protocol > > of openvpn untouched. > > > > I still have some questions unsolved like > > DoS protection, dropping root priviledges > > and how to handel SIGUSR1 and SIGHUP. > > Maybe keep track of all children, so when the master process gets a signal, > it dispatches it to each child process, then to itself. Sounds good to me. I am going to keep track of childs anyway to maintain address/port pool. Trying to explain things to someone, amazingly helps to figure out those things for one self! I got a bunch of new ideas while writing this. Got to go home now or I will sit coding here until midnight :-) Sampo
