Bị ngắt kết nối khỏi máy chủ OpenVPN mỗi giờ


12

Tôi có một vấn đề khá lạ với OpenVPNcấu hình của tôi . Tôi đang kết nối từ Windows 7với OpenVPNkhách hàng mới nhất chính thức đến OpenVPNmáy chủ của tôi ( OpenVPN 2.1.4 i386-redhat-linux-gnu).

Vấn đề là tôi sẽ bị ngắt kết nối khỏi OpenVPNmáy chủ của mình chính xác sau 1 giờ và tôi không thể hiểu chỉ thị / tùy chọn nào có thể sửa chữa được cho việc này. Có lẽ đó là một vấn đề của khách hàng? Tôi đã thử các Windowshệ thống và Windows VPNkhách hàng khác nhau . Các Linuxkhách hàng đang làm việc như mong đợi mà không có sự ngắt kết nối.

Bạn có thể vui lòng giúp tôi giải quyết vấn đề này? Tôi đã thử đọc sách và googling và một số người khuyên nên chơi cùng keepalivereneg-secchỉ thị. Nhưng điều đó dường như không giúp được gì.

Cấu hình máy chủ OpenVPN

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 192.168.2.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 10.0.0.0 255.0.0.0"
client-config-dir ccd
route 192.168.51.0 255.255.255.0
keepalive 60 600
reneg-sec 5000
hand-window 15
tls-auth ta.key 0
comp-lzo
max-clients 50
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 4
crl-verify crl.pem
management localhost 11111
plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so login
push "dhcp-option DNS 192.168.2.1"
push "dhcp-option DOMAIN example.com"
push "dhcp-option SEARCH example.com"

Nhật ký máy chủ (không phải là sự cố trong reinit_src = 1?)

Oct  9 07:23:38 vpn openvpn[19495]: user/192.168.253.20:54568 TLS Error: TLS handshake failed
Oct  9 07:23:38 vpn openvpn[19495]: user/192.168.253.20:54568 TLS: move_session: dest=TM_LAME_DUCK src=TM_ACTIVE reinit_src=1
Oct  9 07:24:53 vpn openvpn[19495]: user/192.168.253.20:54568 TLS Error: TLS handshake failed
Oct  9 07:26:08 vpn openvpn[19495]: user/192.168.253.20:54568 TLS Error: TLS key negotiation failed to occur within 15 seconds (check your network connectivity)
Oct  9 07:26:08 vpn openvpn[19495]: user/192.168.253.20:54568 TLS Error: TLS handshake failed
Oct  9 07:26:39 vpn openvpn[19495]: user/192.168.253.20:54568 [UNDEF] Inactivity timeout (--ping-restart), restarting
Oct  9 07:26:39 vpn openvpn[19495]: user/192.168.253.20:54568 SIGUSR1[soft,ping-restart] received, client-instance restarting

Nhật ký khách hàng

RwrWRwRwRwRwTue Oct 09 07:26:39 2012 us=796000 TLS: soft reset sec=0 bytes=7405621/0 pkts=9459/0
Tue Oct 09 07:26:39 2012 us=600000 ERROR: could not read Auth username from stdin
Tue Oct 09 07:26:39 2012 us=600000 Exiting
Tue Oct 09 07:26:39 2012 us=600000 C:\WINDOWS\system32\route.exe DELETE 192.168.2.1 MASK 255.255.255.255 192.168.100.150
Tue Oct 09 07:26:39 2012 us=600000 Route deletion via IPAPI succeeded [adaptive]
Tue Oct 09 07:26:39 2012 us=600000 C:\WINDOWS\system32\route.exe DELETE 10.0.0.0 MASK 255.0.0.0 192.168.100.150
Tue Oct 09 07:26:39 2012 us=600000 Route deletion via IPAPI succeeded [adaptive]
Tue Oct 09 07:26:39 2012 us=600000 Closing TUN/TAP interface

Cảm ơn rât nhiều.

Câu trả lời:


11

Thủ phạm dường như là cấu hình xác thực của bạn. Bạn đang sử dụng plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so loginsẽ yêu cầu khách hàng cung cấp kết hợp tên người dùng / mật khẩu hợp lệ để kết nối. Rõ ràng, điều này cũng được yêu cầu khi gõ lại và ứng dụng khách OpenVPN của bạn dường như không thể yêu cầu tên người dùng từ stdin( ERROR: could not read Auth username from stdin).

Vì lý do tại sao việc tăng reneg-sec trong cấu hình máy chủ của bạn không có vấn đề gì, điều này là do tham số phải được chỉ định trong cả hai - cấu hình của máy chủ và máy khách được nâng lên một cách hiệu quả trên mặc định 3600 giây (xảy ra với gây ra một giờ - ngắt kết nối bạn đang thấy).

Vì vậy, lựa chọn của bạn sẽ là

  • sử dụng một phương thức xác thực không yêu cầu đầu vào của người dùng (chứng chỉ nảy ra trong đầu)
  • khắc phục sự cố tại sao khách hàng của bạn không thể nhắc kết hợp tên người dùng / mật khẩu sau khi thiết lập kết nối
  • tăng thời gian sử dụng lại hoặc vô hiệu hóa hoàn toàn việc tái sử dụng (điều này làm suy yếu bảo mật kết nối của bạn, do đó chắc chắn đây chỉ là một cách giải quyết kém hơn cho vấn đề của bạn)

Bạn đã đúng, đặt reneg-sec cho client.ovpn đã giúp giải quyết vấn đề này.
Andrew

7

bạn có thể thử reneg-sec 0trong server.conf:

https://duo.com/docs/openvpn

https://tldrify.com/m80

nó thực sự khá đơn giản. Vì OpenVPN cố gắng phân chia lại Phiên TLS mới cứ sau 3600 giây theo mặc định, bạn phải xác thực lại mỗi lần, bằng cách sử dụng OTP mới. Để tránh loại hành vi này, chỉ cần nói với openvpn là không bao giờ đàm phán lại một phiên TLS và giữ cho phiên hiện tại tồn tại, nếu bạn kết hợp keepalivechỉ thị và reneg-sec 0, bạn sẽ có một kết nối ổn định, không có bất kỳ sự từ bỏ nào.


3

Tôi đã trải nghiệm một hiệu ứng tương tự khi tôi thêm tùy chọn 'auth-nocache' vào cấu hình máy khách của mình. Tôi sử dụng chứng chỉ VÀ kết hợp tên người dùng + mật khẩu để xác thực.

Một vài lần tôi nhận thấy trong nhật ký kết nối mà openvpn đã báo cáo cảnh báo sau:

CẢNH BÁO: cấu hình này có thể lưu mật khẩu trong bộ nhớ - sử dụng tùy chọn auth-nocache để ngăn chặn điều này

Vì vậy, tôi nghĩ rằng tôi sẽ chỉ thêm tùy chọn này và xem những gì sẽ xảy ra. Chà, cảnh báo ở trên sẽ biến mất, nhưng sau một giờ, một hộp thoại bật lên, hỏi tôi tên người dùng và mật khẩu.

Tôi nhận thấy rằng cấu hình trên của Andrew không chứa tùy chọn này vì vậy tôi hơi bối rối về lý do tại sao nó không lưu mật khẩu. Có thể điều này là do tôi đang sử dụng phiên bản mới hơn của openvpn hoặc có thể nó có thể được đặt trên cấu hình máy chủ để đẩy tùy chọn này cho máy khách.

Điều này đã được nhìn thấy trên: OpenVPN 2.2.1-8 + deb7u2 với OpenVPN GUI v5 cho Windows.


Tôi phải tạo một tệp bằng openvpn và sau đó thêm tùy chọn auth-nocache. Bây giờ đang làm việc hoàn hảo. Tập tin được tạo có thể được sử dụng như
crsuarezf

@ingcarlos Thật tuyệt khi nghe nó hoạt động cho bạn. Chúc mừng vpn-ing.
captcha

+1 Tuyệt đối đúng, tôi đã gặp phải vấn đề tương tự sau khi thêm không có chỉ thị bộ đệm.
Mohammed Noureldin
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.