![OpenVPN 客户端因 --ping-restart 而重新连接,即使流量是双向流动](https://linux22.com/image/714259/OpenVPN%20%E5%AE%A2%E6%88%B7%E7%AB%AF%E5%9B%A0%20--ping-restart%20%E8%80%8C%E9%87%8D%E6%96%B0%E8%BF%9E%E6%8E%A5%EF%BC%8C%E5%8D%B3%E4%BD%BF%E6%B5%81%E9%87%8F%E6%98%AF%E5%8F%8C%E5%90%91%E6%B5%81%E5%8A%A8.png)
情况:
- 在Amazon EC2中运行的具有公共IP的OpenVPN(2.3.12)服务器
1.1.1.1
,使用UDP协议。 - 具有公共 IP 的远程 OpenVPN(2.3.10)客户端
2.2.2.2
,位于 ADSL 连接上的某处以及 wifi 家庭路由器和防火墙后面。
问题是,尽管连接看起来工作正常,但客户端每 40 秒就会重新连接一次。
如下所示,我们已经keepalive 10 40
在服务器上进行了配置,并且已将其推送到客户端。我可以更改该值,但当然我们做如果连接断开,希望客户端重新连接实际上损坏(例如,wifi 路由器重新启动并忘记了所有有状态的 UDP 规则)。所以这不是一个好选择。
即使我ssh
通过 VPN 进入客户端并通过(例如在 中上下滚动)双向产生一些流量,或者我通过 VPNless
连续运行到客户端,也会发生断开连接的情况。ping
我们还遇到了 MTU 大小导致的数据包丢失问题,但这个问题已通过mssfix 1200
在客户端上使用得到解决。记录显示,客户端可以使用以下方式 ping 服务器(VPN 之外)
ping -M do -s 1412 -c 1 1.1.1.1
因此,mssfix
理论上我们的值可以设置为 1372,根据这个答案;1200 只是为了增加一个安全边际(这样我们就可以在其他网络上的其他客户端上重复使用此配置)。
来自客户端日志:
[server] Inactivity timeout (--ping-restart), restarting
TCP/UDP: Closing socket
SIGUSR1[soft,ping-restart] received, process restarting
Restart pause, 2 second(s)
Re-using SSL/TLS context
LZO compression initialized
Control Channel MTU parms [ L:1558 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Socket Buffers: R=[212992->212992] S=[212992->212992]
Data Channel MTU parms [ L:1558 D:1200 EF:58 EB:143 ET:0 EL:3 AF:3/1 ]
Local Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-client'
Expected Remote Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-server'
Local Options hash (VER=V4): '22188c5b'
Expected Remote Options hash (VER=V4): 'a8f55717'
UDPv4 link local: [undef]
UDPv4 link remote: [AF_INET]1.1.1.1:1194
TLS: Initial packet from [AF_INET]1.1.1.1:1194, sid=78ff051d c8d027a7
VERIFY OK: depth=1, CN=REDACTED
Validating certificate key usage
++ Certificate has key usage 00a0, expects 00a0
VERIFY KU OK
Validating certificate extended key usage
++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
VERIFY EKU OK
VERIFY OK: depth=0, CN=server
Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
[server] Peer Connection Initiated with [AF_INET]1.1.1.1:1194
SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.84.0.1,topology subnet,ping 10,ping-restart 40,ifconfig 10.84.0.6 255.255.0.0'
OPTIONS IMPORT: timers and/or timeouts modified
OPTIONS IMPORT: --ifconfig/up options modified
OPTIONS IMPORT: route-related options modified
Preserving previous TUN/TAP instance: tun0
Initialization Sequence Completed
从服务器日志中:
MULTI: multi_create_instance called
93.254.95.157:33098 Re-using SSL/TLS context
93.254.95.157:33098 LZO compression initialized
93.254.95.157:33098 Control Channel MTU parms [ L:1558 D:1212 EF:38 EB:0 ET:0 EL:3 ]
93.254.95.157:33098 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:143 ET:0 EL:3 AF:3/1 ]
93.254.95.157:33098 Local Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-server'
93.254.95.157:33098 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-client'
93.254.95.157:33098 Local Options hash (VER=V4): 'a8f55717'
93.254.95.157:33098 Expected Remote Options hash (VER=V4): '22188c5b'
93.254.95.157:33098 TLS: Initial packet from [AF_INET]93.254.95.157:33098, sid=a3383b01 bc17f487
93.254.95.157:33098 VERIFY OK: depth=1, CN=REDACTED
93.254.95.157:33098 VERIFY OK: depth=0, CN=ClientName
93.254.95.157:33098 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
93.254.95.157:33098 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
93.254.95.157:33098 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
93.254.95.157:33098 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
93.254.95.157:33098 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
93.254.95.157:33098 [ClientName] Peer Connection Initiated with [AF_INET]93.254.95.157:33098
MULTI: new connection by client 'ClientName' will cause previous active sessions by this client to be dropped. Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect.
MULTI_sva: pool returned IPv4=10.84.0.6, IPv6=(Not enabled)
MULTI: Learn: 10.84.0.6 -> ClientName/2.2.2.2:33098
MULTI: primary virtual IP for ClientName/2.2.2.2:33098: 10.84.0.6
ClientName/2.2.2.2:33098 PUSH: Received control message: 'PUSH_REQUEST'
ClientName/2.2.2.2:33098 send_push_reply(): safe_cap=940
ClientName/2.2.2.2:33098 SENT CONTROL [ClientName]: 'PUSH_REPLY,route-gateway 10.84.0.1,topology subnet,ping 10,ping-restart 40,ifconfig 10.84.0.6 255.255.0.0' (status=1)
客户端配置:
client
dev tun
proto udp
remote 1.1.1.1 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
key /etc/openvpn/client.key
remote-cert-tls server
cipher AES-256-CBC
comp-lzo
verb 4
mssfix 1200
服务器配置:
port 1194
proto udp
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh.pem
topology subnet
server 10.84.0.0 255.255.0.0
ifconfig-pool-persist ipp.txt
client-to-client
keepalive 10 40
cipher AES-256-CBC
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 4
我可以通过切换到 TCP 而不是 UDP 来解决这个问题,但我担心开销和风险,并且觉得即使它最终起到了作用,也是一个愚蠢的“解决方案”。
关于去哪里寻找和尝试什么,还有其他想法吗?
答案1
您知道什么有帮助吗?不要openvpn
同时在客户端计算机上运行两个客户端进程。第一个会重新连接,此时服务器会忘记第二个并停止 ping 它,因此第二个最终会重新连接,依此类推...
我现在觉得自己有点傻,但我还是保留这个,以防其他人也犯同样的傻。
答案2
我在不同的机器上运行两个具有相同客户端名称 (CN) 的客户端时遇到了同样的问题。为了解决这个问题,我创建了不同的客户端宠物机器。