> 2. Accounting > Here I'm not sure, want is the best way to do it, maybe somebody have > some ideas. > One idea is to create for every openvpn-client who > connects to the openvpn-server a own process with fork(). > So every process gets his own Acct-Interim-Interval and can send > the accounting data to the radius server. The data is read from > the status file. This file must be accessible by the user (nobody) > of the openvpn process. > If there are a lot of users, there are a lot of processes and every > process reads the status file. > > The other idea is to create only one process which handles all > accounting, this process will work like the auth-pam-plugin (split privilege > execution model). This process must schedule the differnt > Acct-Interim-Intervals of the clients. The data is read from > the status file. > > Accounting Attributes: > Acct-Status-Type: > start - at the beginning of the connection > update - during the connection > stop - at the end > NAS-Session-ID: unique for a connection > NAS-Identidier: user-defined value > Acct-Input-Octets: read from the status file > Acct-Output-Octets: read from the status file > Acct-Session-Time: intenal counter or read from the status file > > The accounting stop ticket can only be send by the disconnect plugin. > Can I share informations between plugins? So the disconnect plugin can > send a disconnect signal to the accounting process, maybe over a socket? > So the accounting for this users stopps and the ticket is generated.
Regarding accounting, I am planning to add another plugin call type to pass accounting data to the plugin so that it doesn't have to read the status file to get the same info. While the OPENVPN_PLUGIN_CLIENT_CONNECT and OPENVPN_PLUGIN_CLIENT_DISCONNECT plugin call types can be used to bracket a connection, and the latter passes final accounting data for the connection, I would add a new call type such as OPENVPN_PLUGIN_STATS which would be called once per second for any client with send/receive activity. The environmental variables common_name, bytes_sent (cumulative), and bytes_received (cumulative) would be passed to it. James > > > support > James Yonan wrote: > > > 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 > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: NEC IT Guy Games. > > Get your fingers limbered up and give it your best shot. 4 great events, 4 > > opportunities to win big! Highest score wins.NEC IT Guy Games. Play to > > win an NEC 61 plasma display. Visit http://www.necitguy.com/?r > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click > _______________________________________________ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel >
