openvpn - the LCFG OpenVPN component
This is the openvpn lcfg component. It configures and starts the OpenVPN daemon as necessary. NOTE that this component is very much tailored towards the roadwarrior situation, with one fixed endpoint ("server") and several roaming "clients".
OpenVPN doesn't have a nice clean server model. Instead we have to configure a separate instance for each client of the endpoint server. The resources are arranged as a tagged list, and *ALL* machines which want to use OpenVPN have to have the entire list of those resources which both the client end and server end need to know. Any for which type is "server" will configure and start daemons for all the potential peers; any which are of type "client" will attempt to locate resources pertaining only to themselves.
port_... specifies which port the server end should use to speak to the client. address_... is the address which the client end should appear to have. secret_... is the name of a shared-secret file. If hostname_... is set then this is what the client end will match against to find its own resources; otherwise it'll match against the tag name. compLZO_... controls whether LZO compression should be enabled on the link or not. replayPersist_... enables the replay-persist file for both ends -- see the openvpn man-page.
server is the name of the endpoint server which clients should use. float says that it's allowed to change its address if it wants. serverAddr is the address of its end of the tunnel.
firstPort and lastPort aren't used directly by the component. They should be set for the benefit of the perimeter filters. freezeEPRoute says we should attempt to add a host route to the remote endpoint.
If we've to match against the tag names then we have to know which domain we're in by default.
routeTo lists those networks which should be routed over the tunnel. This is a per-client resource, which doesn't have to be known to the server end, so it doesn't have to go into the tagged list. The helper program that expands addresses may also need to be told a default network prefix (defRoutePrefix) and a default netmask (defRouteMask).
If we're a server, do we want to restrict the addresses to which the daemons will bind?
If we're a client, should we bring the link up or down? This might usefully be set in a context-dependent way. Note also that the component's configure method accepts a parameter which can be used to override the value of this resource. This provides a simple way to bring the tunnel up or down by hand.
Contexts which the component will set, after bringing the VPN circuit up and before taking it down respectively.
Log verbosity. See the openvpn man-page for details.
Where does the OpenVPN binary live?
A helpful label which doesn't actually *do* anything, but may get printed out by "OK" messages and the like.
RedHat 7, RedHat 9.