Sự cố OpenVPN - Đàm phán khóa TLS không xảy ra trong vòng 60 giây

Tôi đang định cấu hình máy chủ OpenVPN (phiên bản 2.3.10) trên máy chủ Windows 2012 nhưng tôi không thể làm cho nó hoạt động.

Máy chủ ở phía sau bộ định tuyến và tôi đã mở cổng 1194 và tạo quy tắc để chuyển tiếp lưu lượng trên cổng này đến máy chủ.

Đây là nhật ký tôi thấy trên máy chủ khi tôi cố gắng kết nối từ máy khách:

Mon Mar 21 11:11:47 2016 XX.XX.XX.XX:57804 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:57804, sid=fdf7a7ac 0264c7f3
Mon Mar 21 11:12:38 2016 XX.XX.XX.XX:55938 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:55938, sid=1f242a3f e454a525
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 TLS Error: TLS handshake failed
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 SIGUSR1[soft,tls-error] received, client-instance restarting

Trong đó XX.XX.XX.XX là ip của máy khách. Vì vậy, tôi hiểu rằng khách hàng ít nhất có thể đến máy chủ, do đó không có vấn đề về định tuyến hoặc tường lửa.

Tôi đã làm theo mô tả được cung cấp ở đây Hướng dẫn Windows dễ dàng Bất kỳ ý tưởng nào?

Điều thú vị là cách số cổng thay đổi giữa dòng:

Mon Mar 21 11:11:47 2016 XX.XX.XX.XX: 57804 TLS: Gói ban đầu từ [AF_INET] XX.XX.XX.XX: 57804, sid = fdf7a7ac 0264c7f3

Mon Mar 21 11:12:38 2016 XX.XX.XX.XX: 55938 TLS: Gói ban đầu từ [AF_INET] XX.XX.XX.XX: 55938, sid = 1f242a3f e454a525

Điều này khiến tôi nghĩ rằng, ở đâu đó giữa máy khách và máy chủ, có một thiết bị NAT hoạt động sai, một thiết bị có các mục trong bảng trạng thái rất ngắn, đang thay đổi số cổng nguồn áp dụng cho luồng được thiết lập của máy khách, khiến máy chủ bị nghĩ rằng hai liên lạc ngắn hạn đang được tiến hành, thay vì một liên tục.

Các thiết bị như vậy thường chỉ làm điều này với UDP, vì vậy tôi đã khuyên bạn nên xác nhận rằng bạn đang sử dụng UDP và thay vào đó hãy thử TCP. Điều này bạn đã làm, và thấy rằng nó khắc phục vấn đề. Bước tiếp theo là xác định thiết bị NAT hoạt động sai, đánh nó bằng búa câu lạc bộ và thay thế nó bằng một thiết bị không mắc lỗi chính yếu khi cho rằng tất cả các giao tiếp UDP là phù du; nhưng bạn đã chỉ ra rằng bạn hài lòng với việc thay đổi thành TCP như một cách giải quyết, và vì vậy vấn đề đã được kết luận.

Đây là một trong những lỗi phổ biến nhất khi thiết lập Openvpn và có mục FAQ cho việc này. Tôi sẽ trích dẫn điều này ở đây:

Lỗi TLS: Đàm phán khóa TLS không xảy ra trong vòng 60 giây (kiểm tra kết nối mạng của bạn)

Một trong những vấn đề phổ biến nhất khi thiết lập OpenVPN là hai trình nền OpenVPN ở hai bên của kết nối không thể thiết lập kết nối TCP hoặc UDP với nhau.

Đây gần như là kết quả của:

• Một tường lửa chu vi trên mạng của máy chủ đang lọc các gói OpenVPN đang đến (theo mặc định OpenVPN sử dụng số cổng UDP hoặc TCP 1194).
• Một tường lửa phần mềm chạy trên chính máy chủ OpenVPN đang lọc các kết nối đến trên cổng 1194. Xin lưu ý rằng nhiều hệ điều hành sẽ chặn các kết nối đến theo mặc định, trừ khi được cấu hình khác.
• Cổng NAT trên mạng của máy chủ không có quy tắc chuyển tiếp cổng cho TCP / UDP 1194 đến địa chỉ nội bộ của máy chủ OpenVPN.
• Cấu hình máy khách OpenVPN không có địa chỉ máy chủ chính xác trong tệp cấu hình của nó. Lệnh từ xa trong tệp cấu hình máy khách phải trỏ đến chính máy chủ hoặc địa chỉ IP công cộng của cổng mạng máy chủ.
• Một nguyên nhân khác có thể là tường lửa windows đang chặn truy cập cho tệp nhị phân openvpn.exe. Bạn có thể cần phải đưa danh sách trắng (thêm nó vào danh sách "Ngoại lệ") để OpenVPN hoạt động.

Rất có khả năng rằng bất kỳ điều nào trong số này cũng gây ra vấn đề tương tự trong trường hợp của bạn. Vì vậy, chỉ cần đi qua danh sách từng cái một để giải quyết nó.

Tham chiếu: Lỗi TLS: Đàm phán khóa TLS không xảy ra trong vòng 60 giây (kiểm tra kết nối mạng của bạn)

Tôi đã nhận được thời gian đàm phán quan trọng của TLS như thế này. Nhưng trong trường hợp của tôi, tôi nhận ra rằng liên kết từ xa là một địa chỉ IP cục bộ.

VPN trên tường lửa pfSense của chúng tôi đã bị đặt nhầm vào giao diện LAN thay vì giao diện WAN, và do đó, cấu hình đã xuất được đặt để thử và kết nối với địa chỉ IP LAN của tường lửa - không bao giờ hoạt động với máy khách tự nhiên được bật một mạng LAN khác nhau.

Tôi nghĩ rằng những điểm chính của việc này là:

• Có được thời gian chờ đàm phán quan trọng không nhất thiết có nghĩa là bạn thậm chí đã quản lý để kết nối với bất cứ điều gì.

  Vì vậy, ở giai đoạn này, vẫn có thể đáng để kiểm tra xem bạn thực sự đang kết nối đến đúng nơi và không có quy tắc tường lửa nào chặn kết nối, v.v. Đặc biệt nếu cấu hình của bạn đã được tạo tự động.

  Lưu ý rằng nhận được lời nhắc đăng nhập không có nghĩa là bạn đã kết nối , vì OpenVPN yêu cầu thông tin đăng nhập của bạn trước khi thử kết nối.

• Đảm bảo rằng máy chủ VPN của bạn đang lắng nghe trên giao diện phù hợp.

  (Tất nhiên, đây là một trong số các cấu hình sai phía máy chủ có thể xảy ra, chẳng hạn như quy tắc tường lửa, đặt sai số cổng, trộn lẫn TCP và UDP, v.v.)

Tôi đã có cùng một lỗi và không có lời khuyên nào giúp được, mọi thứ dường như đều ổn: IP, cổng, tường lửa, mọi thứ. Đã mất trong 2 giờ.

Giải pháp là thay đổi giao thức từ UDP sang TCP trong cấu hình máy khách (rõ ràng tôi đã vô hiệu hóa UDP trên mục đích cách đây rất lâu).

Hy vọng điều này sẽ giúp được ai đó :)

LE: điều này đã giải quyết vấn đề của tôi nhưng nó không phải là cách tiếp cận tốt nhất theo nhận xét dưới đây. Bạn nên sử dụng UDP thay vì TCP. Nó giúp tôi vì tôi có các cài đặt khác nhau giữa cấu hình máy khách và máy chủ.

Không có giải pháp nào được đề cập trước đó hoạt động. Trong trường hợp của tôi, mặc dù nhật ký máy khách có lỗi tương tự TLS Error: TLS key negotiation failed to occur within 60 seconds, nhưng nhật ký máy chủ đã hiển thị VERIFY ERROR: depth=0, error=CRL has expired.

Trên máy chủ, các bước sau đã giải quyết vấn đề kết nối:

# cd <easyrsa folder>
# ./easyrsa gen-crl
above command generates new crl.pem file (in my case in pki folder)
using chown/chmod make sure 'pki/crl.pem' is readable by openvpn server (for example: chmod 640 pki/crl.pem)
# systemctl restart openvpn

Lưu ý rằng bạn có thể gặp lỗi thương lượng khóa TLS, mà không kết nối thành công với máy chủ OpenVPN - hoặc thậm chí kết nối thành công với bất kỳ điều gì cả!

Tôi đã sửa đổi cấu hình VPN để kết nối với localhost, trên một cổng không nghe thấy gì:

OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] được xây dựng vào ngày 26 tháng 4 năm 2018
Phiên bản Windows 6.2 (Windows 8 trở lên) 64 bit
phiên bản thư viện: OpenSSL 1.1.0h ngày 27 tháng 3 năm 2018, LZO 2.10
TCP / UDP: Bảo tồn địa chỉ từ xa được sử dụng gần đây: [AF_INET] 127.0.0.1:12345
Liên kết UDP cục bộ (bị ràng buộc): [AF_INET] [undef]: 0
Từ xa liên kết UDP: [AF_INET] 127.0.0.1:12345 
Lỗi TLS: Đàm phán khóa TLS không xảy ra trong vòng 60 giây (kiểm tra kết nối mạng của bạn)
Lỗi TLS: Bắt tay TLS không thành công
SIGUSR1 [soft, tls-error] đã nhận được, quá trình khởi động lại
...

Lỗi có thể khiến bạn hiểu lầm rằng bạn đang nói chuyện với máy chủ VPN.

Bạn thậm chí có thể được nhắc về thông tin đăng nhập trước, nhưng không có gì bên ngoài máy tính của bạn thực sự yêu cầu chúng.

Tôi đã gặp phải lỗi này trong AWS, trong đó OpenVPN đã được cài đặt trên máy chủ có IP công cộng, nhưng trong một trường hợp ở mạng con riêng, tức là mạng con không có đường truyền đến cổng internet.

Khi tôi đã triển khai OpenVPN trên một máy chủ trong mạng con công cộng, tất cả đều hoạt động tốt :)

Trên các mạng con công cộng / riêng tư trong AWS: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html

Tôi cũng đã gặp TLS key negotiation failed to occur within 60 secondsvấn đề.

Từ đề xuất chính thức, như bài Diamant, phải có một cái gì đó sai trong kết nối mạng. Tuy nhiên, cả tường lửa và NAT đều không gây ra sự cố.

Trong trường hợp của tôi, lần đầu tiên tôi đã kiểm tra kết nối bằng cách nc -uvz xxx.xxx.xxx.xxx 1194. Liên kết là OK.

Ngoài ra, một số khách hàng vpn khác trong cùng mạng LAN hoạt động tốt.

Từ một nơi nào đó tôi nhận thấy rằng kết nối udp có một số vấn đề trong phản ứng hoặc chuyển tiếp cổng.

Vì vậy, tôi dừng các máy khách vpn đang chạy từ ip lớn nhất đến máy khách treo, ví dụ: từ "10.8.0.100" đến "10.8.0.50".

Sau đó bắt đầu các khách hàng vpn dừng lại ở đảo ngược.

Bang! Tất cả các khách hàng vpn làm việc propo cũ.

Tóm lại, có một cơ hội dẫn đến TLS key negotiation failed to occur within 60 secondsvấn đề là nhiều máy khách vpn trong mạng LAN bắt đầu theo một chuỗi sai.