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". - 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. - Idle-Timeout: The connection is disconnected, if there is no 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. 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? Do the openvpn process waits until the plugin is finished? So I can write the conf-files without getting a IO-error. ------------------------------------------------------------------------------------------------------------ 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. 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? Is the accounting information in the status file separate for every user? Which information can I get from the status file? ------------------------------------------------------------------------------------------------------ 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? Greetings Ralf
