OpenVPN & reneg-sec & 一小时断线一次 & Solution

--reneg-sec n
Renegotiate data channel key after n seconds (default=3600).
When using dual-factor authentication, note that this default value may cause the end user to be challenged to reauthorize once per hour.

Also, keep in mind that this option can be used on both the client and server, and whichever uses the lower value will be the one to trigger the renegotiation. A common mistake is to set --reneg-sec to a higher value on either the client or server, while the other side of the connection is still using the default value of 3600 seconds, meaning that the renegotiation will still occur once per 3600 seconds. The solution is to increase --reneg-sec on both the client and server, or set it to 0 on one side of the connection (to disable), and to your chosen value on the other side.

http://openvpn.net/index.php/open-source/documentation/manuals/69-openvpn-21.html

OpenVPN 有一个参数 reneg-sec 定义了一段时间之后需要重新验证key ,
如果你注意观察输出信息 你会看到这个

Tue May 24 12:00:49 2011 TLS: soft reset sec=0 bytes=65661711/0 pkts=118605/0
Tue May 24 12:00:49 2011 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Tue May 24 12:00:50 2011 VERIFY OK: depth=1, /C=CN/ST=JiangSu/L=ChangZhou/O=CCZU/OU=QS/CN=ihipop.info/[email protected]/[email protected]
Tue May 24 12:00:50 2011 VERIFY OK: nsCertType=SERVER
Tue May 24 12:00:50 2011 VERIFY OK: depth=0, /C=US/ST=CA/L=SanFrancisco/O=Fort-Funston/CN=server/[email protected]
Tue May 24 12:00:51 2011 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue May 24 12:00:51 2011 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue May 24 12:00:51 2011 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue May 24 12:00:51 2011 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue May 24 12:00:51 2011 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA

这里实际上发生了一次重新连接 如果你用freeradius 认证并且限制了最大同时用户登录数目为1，即Simultaneous-Use := 1，的时候，原来那个session没有结束掉，radius会认为你已经在线，并拒绝你登录，收到radius，这样就会导致用户断线。 默认值3600， 也就是一个小时进行一次TSL重新协商。
这个参数在服务端和客户端设置都有效 如果两边都设置了，那马就按照时间短的设定优先。当两边同时设置成0，表示禁用TSL重协商。

终于知道了学校荣瑞OpenVPN一小时断线一次的秘密 哈哈哈哈哈

当然 你也可以选择在服务端和客户端同时设定reneg-sec为0 这样禁用了TSL 重协商后，就不会有上面所说的问题。但是坏处也显而易见。如果如果流量超了，或者密码改了，禁止TSL重协商后，客户都不会掉线。

所以这是下策。

请教了下@yegle 也翻阅了radiuspiugin邮件列表，看到的解决方案也是我早就测试过的，但是没有效果。

不过我反复测试了3天后，觉得邮件列表里面的解决方案的思路应该是对的，但是为什么不行呢？我当时也发了一封邮件咨询，没有人回答，只有一个人说"I can confirm this behavior with Radiusplugin 2.1 and freeradius 1.1.3" 我想来想去，忽然想起来了radwho这个东西，当时就有一种预感是不是freeradius在文件session里面查到了用户，就拒绝我登录了？

于是我先，修改freeradius的simul_count_query

[sql]simul_count_query = "SELECT COUNT(*) \
FROM ${acct_table1} \
WHERE username = '%{SQL-User-Name}' \
AND acctstoptime IS NULL "[/sql]

修改为

[sql]simul_count_query = "SELECT COUNT(*) \
FROM ${acct_table1} \
WHERE username = '%{SQL-User-Name}' \
AND acctstoptime IS NULL AND acctsessionid != '%{Acct-Session-Id}'"[/sql]

同时，禁用掉freeradius的文件session验证。
freeradius的文件session验证使用的模块是radutmp，如果你不能确定是在哪个节里面删除，就把freeradius的sites-enabled里面的配置文件里面的radutmp前面都加上#号注释掉，而不仅仅是session节。 我是把“files”和“radutmp”全部注释了，也懒的看了。

后来测试通过了，就是这个原因，也就算是大功告成啦。哈哈。

相应的解决方法我也反馈到了radiusplugin的邮件列表

Author Info :

From:OpenVPN & reneg-sec & 一小时断线一次 & Solution

URL:https://blog.ihipop.com/2011/05/2393.html

Please Reserve This Link,Thanks!

本作品采用知识共享署名-非商业性使用 3.0 Unported许可协议进行许可。