嘗試訪問 OpenVPN 伺服器時的 P_CONTROL_HARD_RESET_CLIENT_V2

我想從 Ubuntu 主機連接到 OpenVPN 伺服器，該主機也用作其他內部連接的防火牆（兩個 AP 和幾個在該伺服器上執行的虛擬機）。

我的連接掛在

Sat Nov 19 22:09:41 2016 UDPv4 link remote: [AF_INET]185.145.38.234:1194
Sat Nov 19 22:10:41 2016 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sat Nov 19 22:10:41 2016 TLS Error: TLS handshake failed
Sat Nov 19 22:10:41 2016 SIGUSR1[soft,tls-error] received, process restarting
Sat Nov 19 22:10:41 2016 Restart pause, 2 second(s)

Atcpdump的連接表明

root@srv ~# tcpdump -i any host 185.145.38.234
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
22:35:38.933443 IP 192.168.0.10.41552 > 185.145.38.234.openvpn: UDP, length 42
22:35:40.116782 IP 192.168.0.10.41552 > 185.145.38.234.openvpn: UDP, length 42
22:35:44.849548 IP 192.168.0.10.41552 > 185.145.38.234.openvpn: UDP, length 42

我可以從同一提示連接到任何服務，允許所有流量。當嘗試專門連接到該埠時，我得到

root@srv ~# nc -v -u 185.145.38.234 1194
Connection to 185.145.38.234 1194 port [udp/openvpn] succeeded!

我對tcpOpenVPN 連接有相同的行為（包括成功的nc）。

我能想到這種行為的第一個原因（客戶端發送請求但沒有得到任何回复）是錯誤的路由或防火牆。但是來自同一系統的任何其他連接（curl www.google.com例如，相同的提示）都會成功。那個地方沒有防火牆（流量完全開放）。

另一個原因可能是上游（ISP）的一些過濾。情況並非如此，因為 LAN 上的客戶端（通過上面的機器並最終通過同一介面退出）可以成功連接。

此消息和連接失敗的其他原因可能是什麼？

不知何故遲到了，但原因是自適應防火牆在將流量“辨識”為 OpenVPN 後立即阻止流量（可能基於特定數據包）

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