Khắc phục 'Lỗi TLS: Bắt tay TLS không thành công' trên máy khách OpenVPN


16

Tôi đang định cấu hình OpenVPN 2.3.6-1 trên máy chủ Arch Linux của mình để mã hóa lưu lượng SMB qua Internet công cộng. Khi tôi kiểm tra thiết lập trên một trong các máy khách Linux ảo của mình, tôi gặp lỗi : TLS Error: TLS handshake failed.

Tôi đã nhanh chóng đọc ( OpenVPN trên OpenVZ Lỗi TLS: Bắt tay TLS không thành công (google đề xuất giải pháp không giúp đỡ) ) và cố gắng chuyển từ UDP mặc định sang TCP, nhưng điều đó chỉ khiến khách hàng báo cáo rằng kết nối đã hết thời gian. Tôi cũng đã thử vô hiệu hóa xác thực mật mã và TLS, nhưng điều đó khiến máy chủ bị lỗi Assertion failed at crypto_openssl.c:523. Trong cả hai trường hợp, các thay đổi bắt buộc được thực hiện cho cả cấu hình máy khách và máy chủ.

Tôi đã làm theo các hướng dẫn tại ( https://wiki.archlinux.org/index.php/OpenVPN ) để thiết lập OpenVPN và các hướng dẫn tại ( https://wiki.archlinux.org/index.php/Create_a_Public_Key_Infr kia_Using_the_easy- ) để tạo các khóa và chứng chỉ. Những sai lệch duy nhất tôi đã thực hiện từ các hướng dẫn này là chỉ định tên máy tính của riêng tôi và tên tệp khóa / chứng chỉ tương ứng của chúng.

Xem thêm câu hỏi ban đầu của tôi về việc đảm bảo lưu lượng SMB qua Internet: ( Mã hóa đơn giản cho cổ phiếu Samba )

Bất cứ ai có thể giải thích làm thế nào tôi có thể giải quyết vấn đề này?

Chi tiết:

Máy chủ: Arch Linux (cập nhật) được kết nối trực tiếp với cổng thông qua cáp ethernet. Không có iptables.

Máy khách: Máy ảo Arch Linux (cập nhật) trên máy chủ VirtualBox 4.3.28r100309 Windows 8.1, bộ điều hợp mạng được bắc cầu. Không có iptables. Tường lửa Windows bị vô hiệu hóa.

Cổng: Chuyển tiếp cổng cho cổng 1194 được bật, không giới hạn tường lửa.

Dưới đây là các tập tin cấu hình trên máy chủ và máy khách, tương ứng. Tôi đã tạo chúng theo hướng dẫn trên Arch Wiki.

/etc/openvpn/server.conf (Chỉ dòng không bình luận):

port 1194
proto udp
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server-name.crt
key /etc/openvpn/server-name.key
dh /etc/openvpn/dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
tls-auth /etc/openvpn/ta.key 0
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3

/etc/openvpn/client.conf (Chỉ dòng không bình luận):

client
dev tun
proto udp
remote [my public IP here] 1194
resolv-retry infinite
nobind
user nobody
group nobody
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client-name.crt
key /etc/openvpn/client-name.key
remote-cert-tls server
tls-auth /etc/openvpn/ta.key 1
comp-lzo
verb 3

Dưới đây là kết quả đầu ra của việc chạy openvpn trên các máy có cấu hình trên. Tôi khởi động máy chủ trước, sau đó là máy khách.

Đầu ra của openvpn /etc/openvpn/server.confmáy chủ:

Thu Jul 30 17:02:53 2015 OpenVPN 2.3.6 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Dec  2 2014
Thu Jul 30 17:02:53 2015 library versions: OpenSSL 1.0.2d 9 Jul 2015, LZO 2.09
Thu Jul 30 17:02:53 2015 NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x.  Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
Thu Jul 30 17:02:53 2015 Diffie-Hellman initialized with 2048 bit key
Thu Jul 30 17:02:53 2015 Control Channel Authentication: using '/etc/openvpn/ta.key' as a OpenVPN static key file
Thu Jul 30 17:02:53 2015 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 30 17:02:53 2015 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 30 17:02:53 2015 Socket Buffers: R=[212992->131072] S=[212992->131072]
Thu Jul 30 17:02:53 2015 ROUTE_GATEWAY 192.168.0.1/255.255.255.0 IFACE=enp5s0 HWADDR=##:##:##:##:##:##
Thu Jul 30 17:02:53 2015 TUN/TAP device tun0 opened
Thu Jul 30 17:02:53 2015 TUN/TAP TX queue length set to 100
Thu Jul 30 17:02:53 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Thu Jul 30 17:02:53 2015 /usr/bin/ip link set dev tun0 up mtu 1500
Thu Jul 30 17:02:53 2015 /usr/bin/ip addr add dev tun0 local 10.8.0.1 peer 10.8.0.2
Thu Jul 30 17:02:53 2015 /usr/bin/ip route add 10.8.0.0/24 via 10.8.0.2
Thu Jul 30 17:02:53 2015 GID set to nobody
Thu Jul 30 17:02:53 2015 UID set to nobody
Thu Jul 30 17:02:53 2015 UDPv4 link local (bound): [undef]
Thu Jul 30 17:02:53 2015 UDPv4 link remote: [undef]
Thu Jul 30 17:02:53 2015 MULTI: multi_init called, r=256 v=256
Thu Jul 30 17:02:53 2015 IFCONFIG POOL: base=10.8.0.4 size=62, ipv6=0
Thu Jul 30 17:02:53 2015 IFCONFIG POOL LIST
Thu Jul 30 17:02:53 2015 Initialization Sequence Completed

Đầu ra của openvpn /etc/openvpn/client.confmáy khách:

Thu Jul 30 21:03:02 2015 OpenVPN 2.3.6 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Dec  2 2014
Thu Jul 30 21:03:02 2015 library versions: OpenSSL 1.0.2d 9 Jul 2015, LZO 2.09
Thu Jul 30 21:03:02 2015 WARNING: file '/etc/openvpn/client-name.key' is group or others accessible
Thu Jul 30 21:03:02 2015 WARNING: file '/etc/openvpn/ta.key' is group or others accessible
Thu Jul 30 21:03:02 2015 Control Channel Authentication: using '/etc/openvpn/ta.key' as a OpenVPN static key file
Thu Jul 30 21:03:02 2015 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 30 21:03:02 2015 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 30 21:03:02 2015 Socket Buffers: R=[212992->131072] S=[212992->131072]
Thu Jul 30 21:03:02 2015 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Thu Jul 30 21:03:02 2015 UDPv4 link local: [undef]
Thu Jul 30 21:03:02 2015 UDPv4 link remote: [AF_INET][my public IP here]:1194
Thu Jul 30 21:04:02 2015 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Jul 30 21:04:02 2015 TLS Error: TLS handshake failed
Thu Jul 30 21:04:02 2015 SIGUSR1[soft,tls-error] received, process restarting
Thu Jul 30 21:04:02 2015 Restart pause, 2 second(s)

1
Khách hàng của bạn không bao giờ nhận được phản hồi từ máy chủ. Hoặc bạn có một tường lửa mà bạn quên, hoặc chuyển tiếp cổng của bạn không hoạt động.
Michael Hampton

2
Thực hiện đánh hơi gói tin, như: tcpdump -ni eth0 udp and port 1194 trên máy chủ và đảm bảo nếu gói tin đến. Nếu chúng có thể có vấn đề với tường lửa làm rơi các gói, nếu không thì có lẽ có vấn đề với việc chuyển tiếp cổng trên bộ định tuyến. Bạn có thể làm điều đó trên bộ định tuyến là tốt. Hãy thử và sử dụng một số cổng cao hơn, nó không phổ biến nhưng có lẽ ISP của bạn đã làm hỏng thứ gì đó, như cổng 11194 / UDP hoặc 53 / UDP.
Michal Sokolowski

Đúng, đó là chuyển tiếp. Tôi thường không làm việc với UDP, vì vậy tôi quên thay đổi giao thức khi tạo quy tắc. Tôi sẽ đăng nó như là câu trả lời.
Kyle

3
Nếu các gói hiển thị trong tcpdump trên máy chủ, có cách nào để đảm bảo rằng chúng đến openvpn đúng cách không?
Joost

Câu trả lời:


9

Tôi đã có vấn đề này là tốt.

Đang sử dụng nhà cung cấp Digitalocean cho máy chủ của tôi và vấn đề là do tính năng ip nổi.

Để khắc phục điều đó, bạn phải cập nhật cài đặt cấu hình openvpn:

local <ip anchor>

neo ip nên là một địa chỉ ip được thu thập từ ip addrlệnh, xem ví dụ: nhập mô tả hình ảnh ở đây

Tín dụng cho bài viết này


Tôi đã có vấn đề này với một thiết bị pfsense. Thêm local <ip address of VPN server>mục trong cấu hình máy chủ đã sửa nó. Lưu ý rằng đối với TCP, mục này không cần thiết, chỉ có UDP mới đưa ra lỗi.
Vincenzo Pii

5

Theo đề xuất của Michael Hampton và Michal Sokolowski trong các bình luận về câu hỏi của tôi, đó là một vấn đề với quy tắc chuyển tiếp cổng mà tôi đã tạo trên cổng của mình. OpenVPN được cấu hình để sử dụng UDP và tôi quên chuyển từ TCP sang UDP trên cổng vì tôi thường không sử dụng giao thức đó. Quy tắc chuyển tiếp hiện sử dụng UDP và VPN của tôi hoạt động.


0

Nếu nó xuất hiện sau khi cập nhật lõi hệ điều hành. Hoặc các gói đến hiển thị trong tcpdump trên máy chủ, nhưng vẫn không hoạt động. Hãy thử tắt / bật tường lửa đơn giản. Có lẽ ai đó sẽ giúp.

sudo ufw disable
sudo ufw enable

0

Cấu hình hiện tại của tôi sẽ hoạt động trên một số quốc gia nhưng không phải là các quốc gia khác. Tôi nghi ngờ rằng nhà cung cấp hiện tại của tôi đang chặn gói bắt tay TLS. Giải pháp? Vì tôi là người duy nhất sử dụng VPN đó, tôi đã chuyển sang xác thực khóa tĩnh - trong trường hợp của tôi - đã được chứng minh là siêu nhanh https://openvpn.net/index.php/open-source/documentation/misiverse/78-static -key-mini-howto.html


0

Tôi đã gặp vấn đề này do một cổng mặc định được cấu hình sai ở phía máy chủ. Máy chủ OpenVPN đã nhận được nỗ lực kết nối từ máy khách nhưng phản hồi sau đó đã bị mất vì nó không bao giờ đến đúng bộ định tuyến.


Bạn có nhớ nơi bạn phải thay đổi điều này? Đây có phải trong etc/openvpn/server.conf?
Arthur Attout

Tôi nghĩ có gì đó không ổn với các bảng định tuyến ở phía máy chủ. Kiểm tra với ip route.
lanoxx

0

Tôi chỉ có vấn đề này. Khi kiểm tra tệp .ovpn của tôi, tôi thấy rằng? .Dnsns.net đã được thay đổi thành địa chỉ IP, đó là lý do tại sao nó không kết nối. Tôi đã thay đổi IP trở lại địa chỉ? .Dnsns.net và nó được kết nối.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.