Debian部署OpenVPN视频流传输达阈值后速度骤降，重连后故障复现

一、优先解决UDP路径NAT会话老化问题 #

两端都采用UDP协议传输时，这类连接没有TCP的状态保活机制，中间路径上的家宽设备、运营商网关的NAT映射表项有固定超时时间，大流量传输过程中如果映射表项被超时清除，所有回传的UDP包都会被直接丢弃，表现就是速率掉到接近0；重连时NAT重新生成映射表，传输会临时恢复。

• 调整服务端配置的保活参数：将原有keepalive 10 120修改为keepalive 5 60，缩短心跳发送间隔，持续刷新中间设备的NAT会话，避免表项超时删除。
• 客户端配置补充对应保活逻辑：新增ping 5、ping-restart 60参数，和服务端保活逻辑匹配，双向发送保活包，覆盖所有路径上的NAT设备会话超时场景。

二、修复MTU不匹配导致的UDP分片黑洞 #

视频流都是大尺寸连续报文，隧道默认MTU值如果大于实际链路的可传输上限，超过MTU的报文会被分片传输；只要任意一个分片在传输中丢失，整个报文就会被丢弃。大流量传输过程中一旦触发分片丢包，就会形成持续的传输黑洞，表现为速率逐步降到0，重连初期报文小、未触发分片逻辑时传输正常。

• 服务端与客户端配置同步新增mssfix 1400参数，自动钳制所有通过隧道的TCP连接的MSS值，避免触发分片。
• 客户端配置新增tun-mtu 1400参数，统一两端的隧道MTU阈值，扣除UDP隧道头、加密的额外开销后，这个值可以兼容绝大多数家宽、运营商的实际链路MTU，不会出现分片丢包。

三、解决UDP缓冲区不足导致的队列堵死 #

OpenVPN默认的UDP读写缓冲区只有百KB级别，长时间拉取视频流的大流量场景下，缓冲区会快速堆积数据包，内核达到丢包阈值后会直接丢弃后续所有到达的包，最终连接彻底堵死；重连时缓冲区被清空，传输会临时恢复。

• 临时调大服务端系统的UDP缓冲区上限，执行命令：
  sysctl -w net.core.rmem_max=26214400
sysctl -w net.core.wmem_max=26214400
• 服务端OpenVPN配置中新增sndbuf 0、rcvbuf 0参数，让OpenVPN自动使用系统分配的最大缓冲区，不再使用默认的小尺寸缓冲区。
• 上述sysctl参数永久生效需要将两行配置写入/etc/sysctl.conf，执行sysctl -p加载配置即可。

四、排查加密性能瓶颈导致的连接僵死 #

你当前采用AES-256-CBC加密套件，如果服务器CPU不支持AES-NI硬件加速，单进程OpenVPN的加密处理能力会在大流量场景下达到上限，CPU占满后无法及时处理传输队列的包，最终传输速率被拖到接近0。

• 在视频流传输过程中通过top命令监控OpenVPN进程的CPU占用，如果CPU使用率长期接近100%，即可判定为性能瓶颈。
• 将两端的加密配置同步修改为cipher AES-256-GCM，GCM模式可以充分利用CPU的硬件加密指令集，同等CPU负载下加密吞吐量比CBC模式高30%以上，从根源上降低大流量下的CPU占用。

五、排查CRL校验权限问题 #

服务端降权为nobody用户运行时，如果CRL证书吊销列表文件的权限设置不当，运行一段时间后触发CRL定期校验时，进程会因为无法读取文件进入僵死状态，不传输任何数据但不会主动断开连接，表现就是速率掉到0。

• 检查crl.pem文件的权限，确保nobody用户拥有读取权限，配置中的文件路径使用绝对路径，避免降权后无法定位到文件。
• 定期检查CRL文件的有效期，过期的CRL文件会触发校验逻辑异常，导致连接被卡死。

内容的提问来源于stack exchange，提问作者Joe