即使流量雙向流動，OpenVPN 客戶端也會因 –ping-restart 重新連接

情況：

• 1.1.1.1使用 UDP 協議在 Amazon EC2 中執行的具有公共 IP 的 OpenVPN (2.3.12) 伺服器。
• 具有公共 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 來解決這個問題，但我對成本和風險保持警惕，並且覺得即使它最終可以工作，它也是一個愚蠢的“解決方案”。

關於在哪裡尋找和嘗試什麼的任何其他想法？

你知道什麼有幫助嗎？不在openvpn客戶端機器上同時執行兩個客戶端程序。第一個將重新連接，此時伺服器忘記了第二個並停止 ping 它，因此第二個最終重新連接，依此類推……

我現在覺得有點傻，但我會留下這個，以防其他人也同樣愚蠢。

通過在不同的機器上執行具有相同客戶端名稱 (CN) 的兩個客戶端，我遇到了同樣的問題。為了解決這個問題，我創建了不同的客戶端寵物機。

引用自：https://serverfault.com/questions/886168