The recent OpenVPN service abnormal quit many times, because the original in order to troubleshoot problems record a large number of debug log, resulting in problems when you want to locate the problem is very difficult, the instant log was brushed off, the process dropped, instantaneous start, instantaneous and dropped, resulting in a lot of orders lost! Because the day file records too much useless information, dare not to search the log to locate the problem, began to boldly guess:
1. The OpenVPN server (virtual machine) has not enough memory because only 2G memory
2. I/O is too high, because the log turned on the cause of DEBUG, a large number of log operations,
3. Open file descriptor not enough, system default 1024
4. Malicious attack on the OpenVPN service
Based on a guess of 4 points, start coping,
1. The first choice of the OPENPVN server (virtual machine) memory adjusted to 4G, after the restart found that the OpenVPN service after the start of a few minutes or abnormal off,
2. The log adjusted for error, OpenVPN after the start of a few minutes or abnormal exit. View Log found to be
Feb 17:17:42 localhost openvpn[1219]: qn_anqiu/xxx.xxx.xxx.xx:27351 crl:cannot read:/usr/local/cine/etc/keys/ Crl.pem:Too many open files (errno=24)
3. With the above error log prompts, the 3rd of the conjecture is correct. To execute a command:
Shell $> Ulimit-shn 65535
After starting the OpenVPN process, the normal did not exit again.
4. View log found that there is an IP per minute in the abnormal request OpenVPN server, directly in the Iptables filter out this IP
Feb 13:06:16 localhost openvpn[1219]: 58.244.191.51:47374 Warning:bad encapsulated Packet length from peer (18245), WH Ich must to > 0 and < = 1544--Please ensure that--TUN-MTU or--LINK-MTU are equal on both peers--this condition Could also indicate a possible active attack on the TCP link--[attemping restart ...]
Feb 13:07:21 localhost openvpn[1219]: 58.244.191.51:6043 Warning:bad encapsulated Packet length from peer (18245), whi CH must to > 0 and < = 1544--Please ensure that--TUN-MTU or--LINK-MTU are equal on both peers--this condition C Ould also indicate a possible active attack on the TCP link--[attemping restart ...]
After the above modification, after two days OpenVPN or abnormal dropped once, after the log or the old problem:
Feb 17:17:42 localhost openvpn[1219]: qn_anqiu/xxx.xxx.xxx.xx:27351 crl:cannot read:/usr/local/cine/etc/keys/ Crl.pem:Too many open files (errno=24)
Even if you open the file descriptor process should not drop AH, this indicates that the OpenVPN BUG, Crl.pem The file is a log off of the certificate, if the certificate of cancellation is not passed, the OpenVPN service will reject the connection, I currently have more than 800 clients to connect, Does every connection request that the file not be freed? Wouldn't it be enough if you didn't release 65,535 file descriptors?
In order to solve the problem, we have to modify the configuration file to remove the verification of the parameters of the certificate, in the restart OpenVPN process, it is normal that there has never been a problem. The specific how to produce also needs to be further observed and studied.