我有一個在 AWS 中的 Ubuntu 上運行的 OpenVPN 伺服器,並使用 macOS 上的 Tunnelblick 來連接到它。我連接到其他 VPN 伺服器沒有問題,但這個伺服器似乎每 2 分鐘逾時/重置一次。
我的 OVPN 個人資料:
client
dev tun
proto udp
remote ............... 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
remote-cert-tls server
cipher AES-256-CBC
verb 3
cipher AES-128-CBC
auth SHA256
key-direction 1
<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>
<cert>
Certificate:
Data:
Version: 3 (0x2)
...
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
</key>
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
...
-----END OpenVPN Static key V1-----
</tls-auth>
連接時,伺服器推送以下設定:
PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 8.8.8.8,route 172.16.0.0 255.255.240.0,route 172.16.16.0 255.255.240.0,route 172.16.128.0 255.255.240.0,route 172.16.144.0 255.255.240.0,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5,peer-id 1,cipher AES-256-GCM'
(特別注意ping 10,ping-restart 120
)
提高客戶端上的日誌級別,看起來連線確實正在發送資料包:
2021-09-03 11:31:21.848620 UDP WRITE [62] to [AF_INET]...:1194: P_ACK_V1 kid=0 pid=[ #13 ] [ 6 ]
2021-09-03 11:31:21.848768 UDP WRITE [130] to [AF_INET]...:1194: P_DATA_V2 kid=0 DATA len=129
2021-09-03 11:31:21.848856 UDP WRITE [226] to [AF_INET]...:1194: P_DATA_V2 kid=0 DATA len=225
然而,連接總是在大約 2 分鐘後斷開。客戶端日誌狀態:
2021-09-03 11:40:26.121900 [cc-vpn] Inactivity timeout (--ping-restart), restarting
2021-09-03 11:40:26.122379 SIGUSR1[soft,ping-restart] received, process restarting
2021-09-03 11:40:26.122504 MANAGEMENT: >STATE:1630683626,RECONNECTING,ping-restart,,,,,
2021-09-03 11:40:26.448969 MANAGEMENT: CMD 'hold release'
除了連接重新啟動之外,伺服器日誌中實際上沒有任何內容。
考慮到推送給客戶端的設置,2 分鐘超時是有意義的ping-restart 120
,但我不清楚為什麼它認為它處於非活動狀態。我缺什麼?客戶端上是否存在阻止 ping 正確發送到伺服器的設定?
特別將 ping/ping-restart 添加到客戶端配置似乎沒有幫助(我認為無論如何它都會被伺服器 PUSH 覆蓋)。
我如何調試它並找出連接不保持活動的原因?
答案1
這通常表示有多個客戶端正在使用此金鑰/憑證對:
- (1) 認證
- (2) 認證;伺服器看到相同的證書,因此它認為它只是被替換的連接,並且 (1) 將不再接收 keepalive ping
- (1) 錯過了一些 ping,確定連接已斷開並重新連接,現在 (2) 不會收到 ping
- (2) 錯過了一些 ping,確定連接已斷開並重新連接,現在 (1) 不會收到 ping
您可以看到發生了什麼,也很清楚ping-restart
這裡如何涉及不活動超時設定。
為了避免這種情況發生,您必須仔細管理您的 VPN CA。尤其:
- 追蹤您的金鑰的安裝位置以及誰負責安裝每個金鑰的裝置。有辦法聯絡任何擁有有效VPN 金鑰的人(例如記錄他們的電話號碼、電子郵件等,您可以設定OpenSSL,以便它在憑證授權期間要求提供該資料並將該資料直接記錄到憑證和CA 索引中) 。
- 切勿多次使用相同的密鑰/憑證;切勿將金鑰/憑證放入範本;如果您克隆某個系統,請清除那裡的密鑰。每次系統啟動時都必須產生密鑰並重新頒發證書已部署。
- 如果某些使用者在擁有活動金鑰/證書時要求提供(另一個)金鑰/證書,則他們必須解釋原因。他們可能因為重新安裝作業系統而丟失了舊數據,並且忘記保存 VPN 配置;或者他們可能只是需要在其他電腦上安裝 VPN。管他呢。評估他們的解釋,你要嘛先撤銷在頒發另一個金鑰之前使用舊金鑰,或使用另一個 CN 頒發金鑰以避免衝突。
- 教育您的用戶始終通知您他們的密鑰/證書不再使用(丟失或其頒發原因丟失),以便您可以撤銷它。然後你必須撤銷它。
- 非常重要,教育用戶緊急地如果他們懷疑金鑰/憑證被盜,請通知您,在這種情況下,您必須立即撤銷它。
這些是「網路安全」過程的一部分。如果沒有一定的紀律,VPN 就不可能安全,無論其軟體和使用的加密技術多麼完美。
如果有人想知道為什麼 OpenVPN 沒有檢測到這種情況並且沒有將其報告到日誌檔案中,請如下評論:這太不可靠且具有誤導性。日誌應該只包含原始事實,唯一確定的事實是同一個 CN 從不同位置重複連接;它不應該包含任何關於為什麼會發生這種情況的假設。
當您遵循上述安全程序時,問題就不會發生。如果發生這種情況,只能意味著違反了程序。在這種情況下,為了確保 VPN 的安全,最安全的方法是假設金鑰已洩漏並立即撤銷憑證。也許VPN會對某些人(其金鑰)造成破壞,但這將是自然的結果他們的無法遵循既定程序:他們未能通知您他們沒有在某台電腦上使用 VPN 並將其複製到另一台電腦上,或者證書被盜,等等。經過該主題的再教育後,您可以為他們頒發新證書。