On Tue, 3 May 2005, Ralf [iso-8859-1] Lübben wrote: > Hello, > > I tried to create a concept for the RADIUS-Plugin. > Maybe someone have some additional ideas or can answer me some questions I > wrote down in the following text. > > ------------------------------------------------------------------------------------------------------------- > Start of the connection: > > The plugin sends a "access-request-radius-ticket" with the username and a > hash(MD5-hash over the password and the shared-secret) to the radius server. > If the server sends a "access-reject-ticket" or "access-challenge-ticket" the > authorization fails. > > If the server sends a "access-accept-ticket" the authorization is ok, in the > ticket can be some attributes: > > - Framed-IP-Address: The IP-address which is pushed to the client. > > - Framed-Route: These routes have to pushed to the servers routing table. > This > attribut can occur several times in the "access-accept-ticket".
You might need a split privilege model here, because adding routes requires root privileges, and for security reasons, we don't want to run the main OpenVPN process as root. The OpenVPN plugin model supports split privileges, i.e. where the plugin process holds onto root while the main OpenVPN process drops privileges (see auth-pam or down-root for examples of this), so you'd probably need to have the plugin fork a process to handle route additions. > - Acct-Interim-Interval: The interval in which the accounting data is sent to > the radius server. > > Maybe these attributes are not important : > - Session-Timeout: The maximum time for a connection. OpenVPN doesn't support this right now. > - Idle-Timeout: The connection is disconnected, if there is no traffic This is tricky, because how do you define traffic? > Maybe it is possible to create a vendor specific attribut for routes which > are > pushed to the client. There is no attribut for that in the radius protocol. Good idea. > After the authorization is done: > The plugin has to start another process/thread for the accounting data with > the parameter value of the attribut "Acct-Interim-Interval". > This process has to sent an "accounting-request-ticket" to the radius server > with the attribut "acct-status-type"=1 (start). (There must be included some > more attributes for the radius server (NAS-IP-address (=openvpn-ip-address) > or NAS-identifier, real ip address of the user as framed-ip-address-attribut, > NAS-Port or NAS-port-type) > The process has to wait for a "accounting-response-ticket" from the server, > if he gets no response he has to send the ticket again (interval=?). > > The plugin must return 0 if everything is ok, otherwise 1. > > Questions: > > Which is the best plugin to use? I need the username and the password before > the ip address and the routes are sent to the client? Use OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY (called first) to authorize username/password and OPENVPN_PLUGIN_CLIENT_CONNECT (called next) to push IP address and routes to client. > Do the openvpn process waits until the plugin is finished? So I can write the > conf-files without getting a IO-error. With 2.0.x, OpenVPN is running in a single thread, so plugin callbacks will stall the whole process. For 2.1, there will be multithread support (two threads actually), so calls to plugins will occur from a different thread than the main packet forwarding thread. There will only be a single thread for calling plugins, so you won't need to make the plugin callbacks themselves reentrant. > ------------------------------------------------------------------------------------------------------------ > During the connection: > > The separate process/thread which is started at the beginning of the > connection sends > with the interval time of the attribut "Acct-Interim-Interval" accounting > data to the radius server. > The process reads the information out of the status file which is generated > by > the openvpn process every second. The status file must be generated every > second because the attribut "Acct-Interim-Interval" is in seconds and so > nobody knows, when ths process reads the status file. This would work, but it might be cleaner for OpenVPN 2.1 to add a new callback for passing accounting data to the plugin. The problem with polling the status file is that there's no guarantee of change atomicity, i.e. an entry could be added and then deleted from the file between pollings. > The attribut "acct-status-type" must be set to 3 (interim-Update). > > The process has to wait for a "accounting-response-ticket" from the server, > if he gets no response he has to send the ticket again (interval=?). > > Attributes in the accounting-request-ticket: > - NAS ip address and NAS identifier > - Framed ip address (=real ip address of the client) > - NAS-port or NAS-port-type > - Acct-Input-Octets > - Acct-Output-Octets > - Acct-Input-Packets > - Acct-Output-Packets > - Acct-Session-Time > > > Questions: > Is it possible to generate the status file every second? Yes, however if the OpenVPN event loop is not actively forwarding packets, the status file update interval could be as long as 10 seconds. > Is the accounting information in the status file separate for every user? Yes. > Which information can I get from the status file? For each client: Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since For each internal routing table entry: Virtual Address,Common Name,Real Address,Last Reference > ------------------------------------------------------------------------------------------------------ > End of the connection: > At the end a "accounting-request-ticket" with the "acct-status-type"=2 (stop) > must be sent to the radius server. > With the following attributes: > - NAS ip address and NAS identifier > - Framed ip address (=real ip address of the client) > - NAS-port or NAS-port-type > - Acct-Input-Octets > - Acct-Output-Octets > - Acct-Input-Packets > - Acct-Output-Packets > - Acct-Session-Time > (- Acct-Terminate-Cause) > > Also the accouting process must be killed. > > I think the "PLUGIN_CLIENT_DISCONNECT"-type will be fit for this. > > Questions: > Is the "PLUGIN_CLIENT_DISCONNECT"-type called at every disconnect? Yes, but sometimes there is a delay on UDP disconnects, since UDP is connectionless, so the call to PLUGIN_CLIENT_DISCONNECT might occur more than 1 minute after the actual disconnection. Also, with UDP, if a client disconnects and immediately reconnects using the same port number (if nobind isn't used on the client), the server will see both the original connection and the reconnect as being part of the same connection, so there won't be a call to PLUGIN_CLIENT_DISCONNECT then PLUGIN_CLIENT_CONNECT. James
