Hello, I finished a C++class for the radius protocol. So I can send, receive and analyze authentication and accounting radius packets.
Now I will start to create the openvpn-plugin. I have there still some quesitions: When are called the funktions: openvpn-plugin_open_v1 openvpn-plugin_func_v1 openvpn-plugin_close_v1 Is this right? - openvpn-plugin_open_v1: At the start of openvpn. - openvpn-plugin_func_v1: When the event happens. - openvpn-plugin_close_v1: When openvpn is closed. To communicate between the functions I can create a user-defined struct, which can be shared between the functions over the openvpn_plugin_handle_t. Is that also right? I want divide the hole plugin in two parts: 1. Authorisation and Authentification This will work like the auth-pam-plugin (split privilege execution model) only with radius support. The plugin-process holds root rights, so routes from the radius server can be set. I want to send following attribute: Username Password NAS-Port = number of the tun interface NAS-IP-Address = ip address of the openvpn server NAS-Identifier = user defined string I want to analyze following attributes of the radius response: Framed-Route = set to the server routing table and write to the client file in client-config-dir with the iroute directive Framed-IP-Address = write to the client file in the client-config-dir with the (ifconfig Framed-IP IP2) directive, the other point (IP2) must be create maybe by (IP2+1). Acct-Interim-Interval = the accounting interval (Maybe later a vendor specific attributs for routes which can be pushed to the client= The Framed-Route and the Framed-IP-Address will be written to a file with the name of the enviroment variable envp[common-name]. At the end of a connection the routes should be deleted. If a client disconnect, the iroutes in the OpenVpn-process are deleted automatically? 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. Maybe someone has additional ideas. Greetings Ralf 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