Điểm:1

Kết nối OpenVPN đặt lại cứ sau 2 phút

lá cờ vn

Tôi có một máy chủ OpenVPN chạy trên Ubuntu trong AWS và sử dụng Tunnelblick trên macOS để kết nối với nó. Tôi không gặp vấn đề gì khi kết nối với các máy chủ VPN khác, nhưng máy chủ này dường như hết thời gian/đặt lại sau mỗi 2 phút.

Hồ sơ OVPN của tôi:

khách hàng
nhà phát triển điều chỉnh
proto udp
từ xa ............... 1194
giải quyết-thử lại vô hạn
quý tộc
người dùng không ai
nhóm không có nhóm
phím kiên trì
kiên trì điều chỉnh
máy chủ từ xa-cert-tls
mật mã AES-256-CBC
động từ 3
mật mã AES-128-CBC
xác thực SHA256
hướng chính 1
<ca>
-----BẮT ĐẦU GIẤY CHỨNG NHẬN----
...
-----GIẤY CHỨNG NHẬN KẾT THÚC-----
</ca>
<chứng chỉ>
Giấy chứng nhận:
    Dữ liệu:
        Phiên bản: 3 (0x2)
...
-----BẮT ĐẦU GIẤY CHỨNG NHẬN----
...
-----GIẤY CHỨNG NHẬN KẾT THÚC-----
</chứng chỉ>
<phím>
----- BẮT ĐẦU KHÓA RIÊNG TƯ -----
...
----- KẾT THÚC KHÓA RIÊNG TƯ -----
</key>
<tls-auth>
#
# Khóa tĩnh OpenVPN 2048 bit
#
----- BEGIN OpenVPN Khóa tĩnh V1 -----
...
----- KẾT THÚC Khóa tĩnh OpenVPN V1 -----
</tls-auth>

Khi kết nối, máy chủ sẽ đẩy các cài đặt sau:

PUSH: Đã nhận được thông báo điều khiển: '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.255,route 172.16.144.0 255.255.240.0, tuyến đường 10.8.0.1, mạng cấu trúc liên kết 30, ping 10, ping-khởi động lại 120, ifconfig 10.8.0.6 10.8.0.5, id ngang hàng 1, mật mã AES-256-GCM'

(chú ý cụ thể ping 10, ping-khởi động lại 120)

Tăng mức nhật ký trên máy khách, có vẻ như kết nối đang gửi gói dữ liệu:

2021-09-03 11:31:21.848620 UDP WRITE [62] tới [AF_INET]...:1194: P_ACK_V1 kid=0 pid=[ #13 ] [ 6 ]
2021-09-03 11:31:21.848768 UDP WRITE [130] sang [AF_INET]...:1194: P_DATA_V2 kid=0 DATA len=129
2021-09-03 11:31:21.848856 UDP WRITE [226] sang [AF_INET]...:1194: P_DATA_V2 kid=0 DATA len=225

Tuy nhiên, kết nối luôn chết sau khoảng 2 phút. Nhật ký khách hàng nêu rõ:

2021-09-03 11:40:26.121900 [cc-vpn] Hết thời gian không hoạt động (--ping-restart), khởi động lại
2021-09-03 11:40:26.122379 Đã nhận được SIGUSR1[soft,ping-restart], quá trình khởi động lại
2021-09-03 11:40:26.122504 MANAGEMENT: >STATE:1630683626,RECONNECTING,ping-restart,,,,,
2021-09-03 11:40:26.448969 QUẢN LÝ: CMD 'tạm dừng phát hành'

Không có gì thực sự trong nhật ký máy chủ ngoài việc khởi động lại kết nối.

Thời gian chờ 2 phút có ý nghĩa với ping-khởi động lại 120 cài đặt được đẩy tới ứng dụng khách, nhưng tôi không rõ tại sao nó cho rằng nó không hoạt động. Tôi đang thiếu gì? Có cài đặt nào trên máy khách ngăn ping được gửi đến máy chủ đúng cách không?

Cụ thể việc thêm ping/ping-restart vào cấu hình máy khách dường như không giúp ích gì (tôi cho rằng dù sao thì nó cũng sẽ bị máy chủ PUSH ghi đè).

Làm cách nào tôi có thể gỡ lỗi này và tìm ra lý do tại sao kết nối không được duy trì?

Nikita Kipriyanov avatar
lá cờ za
Có thể nào bạn có hai ứng dụng khách sử dụng cùng một cặp chứng chỉ/khóa và chạy đồng thời không?
DrTeeth avatar
lá cờ vn
Chuẩn rồi. Đó là nó. Tôi đã xem qua một vài câu trả lời khác gợi ý điều đó, nhưng tôi không thể tìm thấy khách hàng khác và tôi biết mình không có khách hàng nào đang chạy. Hóa ra người khác có một vùng chứa cũ đang chạy trong nền và vẫn đang sử dụng vùng chứa đó. Tốt hơn nữa, cả hai khách hàng đều cố gắng kết nối lại mỗi khi họ bị ngắt kết nối, vì vậy họ chỉ đang tranh giành kết nối. Tôi ước gì thông báo lỗi tốt hơn... nó không thực sự là "hết thời gian chờ không hoạt động"... @NikitaKipriyanov Nếu bạn muốn viết câu trả lời này như một câu trả lời, tôi rất sẵn lòng cung cấp cho bạn tín dụng. Nếu không, tôi sẽ chỉ viết lên sự ngu ngốc của riêng mình.
Điểm:1
lá cờ za

Đây thường là dấu hiệu cho thấy có nhiều khách hàng đang sử dụng cặp khóa/chứng chỉ này:

  • (1) xác thực
  • (2) chứng thực; máy chủ nhìn thấy cùng một chứng chỉ, vì vậy nó nghĩ rằng nó vừa được thay thế kết nối và (1) sẽ không nhận được ping cố định nữa
  • (1) bỏ lỡ một số ping, quyết định kết nối đã chết và kết nối lại, bây giờ (2) sẽ không nhận được ping
  • (2) bỏ lỡ một số ping, quyết định kết nối đã chết và kết nối lại, bây giờ (1) sẽ không nhận được ping

Bạn thấy những gì đang diễn ra và cũng rõ ràng thời gian chờ không hoạt động được thiết lập bởi ping-khởi động lại được tham gia ở đây.

Để điều này không xảy ra, bạn phải quản lý cẩn thận VPN CA của mình. Đặc biệt:

  • Theo dõi nơi cài đặt chìa khóa của bạn và ai chịu trách nhiệm về thiết bị nơi mỗi chìa khóa được cài đặt. Có cách liên hệ với bất kỳ ai có khóa VPN đang hoạt động (ví dụ: ghi lại số điện thoại, email, v.v. của họ, bạn có thể thiết lập OpenSSL để nó sẽ yêu cầu dữ liệu đó trong quá trình cấp chứng chỉ và ghi dữ liệu đó trực tiếp vào chứng chỉ và chỉ mục CA) .
  • Không bao giờ sử dụng cùng một khóa/chứng chỉ nhiều lần; không bao giờ đặt khóa/chứng chỉ vào mẫu; nếu bạn sao chép một số hệ thống, hãy xóa các phím ở đó. Các khóa phải luôn được tạo và cấp chứng chỉ mới mỗi khi hệ thống được kích hoạt. triển khai.
  • Nếu một số người dùng yêu cầu khóa/chứng chỉ (khác) trong khi họ có một khóa/chứng chỉ đang hoạt động, họ phải giải thích lý do.Họ có thể đã mất dữ liệu cũ do cài đặt lại hệ điều hành và họ quên lưu cấu hình VPN; hoặc đơn giản là họ có thể cần có VPN trên máy tính bổ sung. Hay bất cứ cái gì. Đánh giá lời giải thích của họ, trước tiên bạn thu hồi khóa cũ trước khi cấp một khóa khác hoặc cấp một khóa với CN khác để tránh xung đột.
  • Hướng dẫn người dùng của bạn luôn thông báo cho bạn khóa/chứng chỉ của họ không được sử dụng nữa (bị mất hoặc lý do phát hành bị mất) để bạn có thể thu hồi. Và sau đó bạn phải thu hồi nó.
  • Rất quan trọng, giáo dục người dùng để khẩn cấp thông báo cho bạn nếu họ nghi ngờ khóa/chứng chỉ đã bị đánh cắp, trong trường hợp đó bạn phải thu hồi ngay lập tức.

Đây là những phần của quy trình được gọi là "an ninh mạng". VPN không thể an toàn nếu không có kỷ luật nhất định, cho dù nó đang sử dụng phần mềm và mã hóa hiện đại hoàn hảo đến đâu.

DrTeeth avatar
lá cờ vn
Tôi thực sự mong muốn máy khách hoặc máy chủ có thông báo lỗi tốt hơn - đó không thực sự là "thời gian chờ không hoạt động", mà là cả hai máy khách đều cố gắng đánh cắp kết nối đang hoạt động của nhau. Điều đó nói rằng, đây là câu trả lời cho tôi - một người khác đang sử dụng hồ sơ trên một máy mà cả hai chúng tôi không thực sự sử dụng nữa và nó vẫn cố gắng kết nối/kết nối lại trong khi tôi đang cố gắng làm điều tương tự.
Nikita Kipriyanov avatar
lá cờ za
Máy chủ không thể làm điều đó. Nó chỉ báo cáo những gì nó nhìn thấy: một khách hàng kết nối lặp đi lặp lại. Nó không thể dễ dàng liên kết các lần thử kết nối tiếp theo và quyết định "đây là hai ứng dụng khách xung đột với cùng một chứng chỉ". Mỗi xác thực mới đến từ cặp (địa chỉ, cổng) mới, vì vậy mặc dù có thể có *thông tin chi tiết* nhưng *có thể* chỉ là hai ứng dụng khách này, nhưng không có cách nào đáng tin cậy để xác định điều đó. Tôi đã chứng kiến ​​những trường hợp mà cái nhìn sâu sắc này là sai. Không ai muốn các thông báo lỗi máy chủ *gây hiểu lầm*, vì vậy tốt hơn là chúng nên giữ nguyên như vậy.
DrTeeth avatar
lá cờ vn
Tôi vẫn không tin rằng máy chủ không thể làm gì đó. Khách hàng A kết nối. Sau đó, Máy khách B sẽ kết nối, làm cho kết nối của Máy khách A không còn hiệu lực vì nó sử dụng cùng một chứng chỉ. Chỉ máy chủ biết rằng nó đã làm mất hiệu lực một kết nối vì một máy khách khác đã kết nối. Tại thời điểm đó, máy chủ có thể a) thả một thông báo vào tệp nhật ký của chính nó (tôi không thấy bất kỳ thông báo nào), b) gửi một thông báo tới một hoặc cả hai máy khách rằng nhiều máy khách đang cố sử dụng cùng một chứng chỉ (tương tự như DNS tĩnh tin nhắn xung đột sử dụng cùng một IP), c) theo dõi các IP và gửi tin nhắn đến máy khách kết nối lại
DrTeeth avatar
lá cờ vn
Nhưng tôi hiểu rằng đây là quyết định thiết kế của phía OpenVPN, vì vậy nằm ngoài phạm vi của vấn đề này. Chỉ là... có lẽ nếu một nhà phát triển OpenVPN cảm thấy buồn chán vào một đêm nào đó khi đọc những bình luận này...?

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.