继续补充一个在使用OpenV-P-N时遇到的一个问题。

01

—

自从前阵子构建好V-P-N之后，一直运行比较稳定，但最近突然所有的客户端都连不上了。检查了一下虚拟机和V-P-N server都是正常运行状态，端口也是开放状态，尝试了重启服务、重启机器、重启防火墙都不奏效。于是在ChatGPT的帮助下继续尝试其他方式。

排查与解决

虽然V-P-N server连不上了，但是Tinyproxy的代理方式仍然可以正常连接，所以机器本身是没问题的。查看OpenV-P-N的status日志如下：

SIGUSR1[soft,tls-error] received, client-instance restartingTLS key negotiation failed to occur within 60 seconds>TLS handshake failed

应该是TLS握手的问题，ChatGPT给出了一些排查方案，比如证书是否过期、时间是否同步等，检查了一下都没问题，所以大概率是出在了网络方面。用google搜了下，其中有人提到了一个方法是修改为随机端口。于是我尝试修改了配置文件中的端口号，但启动server时失败了，查看SELinux日志（/var/log/audit/audit.log）如下：

type=AVC msg=audit(1703316538.247:13287): avc:  denied  { name_bind } for  pid=47349 comm="openv-p-n" src=12345 scontext=system_u:system_r:openv-p-n_t:s0 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=udp_socket permissive=0

继续问ChatGPT得知，这是错误消息是由于SELinux的安全策略引起的，错误表明 OpenV-P-N 试图绑定到 12345端口，但被 SELinux 阻止了，因为 12345 端口被标记为非保留端口（unreserved_port_t），而 OpenV-P-N 的 SELinux 策略可能只允许它绑定到特定的端口。

解决方式有很多种，其中最简单的方式是设置SELinux为宽容模式，命令为：

sudo setenforce 0

执行之后再重启OpenV-P-N server，果然成功了。之后将新端口添加到防火墙的白名单：

firewall-cmd --permanent --add-port=12345/udpfirewall-cmd --reload

最后将客户端配置文件中的端口号也修改后，重新连接，成功！

分析

虽然通过修改端口号得以解决了，但也只是一个临时之策，因为这可能涉及到与G-F-W的斗智斗勇，是“不能说的秘密”。如果新端口号继续被封，那就只能再想对策了，所谓道高一尺魔高一丈。但至少，通过Tinyproxy的方式一直没出过任何问题，也算是有一个保底的方案。

另外，我发现在Azure即用即付的12个月免费服务的使用明细中，每月的免费网络出站流量（Networking, Data Transfer Out）写的是15G额度，而在主页搜索“免费服务”，里面写的却是100G，所以不知道以哪个为准，只好亲自测试。

所以我在本次的月度计费周期内将流量用超了3G左右，来测试一下是否会额外扣费。目前看来，是没有扣费的，等下个月账单出来，届时就真相大白了。如果每月流量真的有100G，那足以是一波好福利了。

（全文完）