Odłączanie się od serwera OpenVPN co godzinę

Mam dość dziwny problem z moją OpenVPNkonfiguracją. Łączę się Windows 7z oficjalnym najnowszym OpenVPNklientem do mojego OpenVPNserwera ( OpenVPN 2.1.4 i386-redhat-linux-gnu).

Problem polega na tym, że odłączam się od OpenVPNserwera dokładnie po 1 godzinie i nie rozumiem, która dyrektywa / opcja jest za to odpowiedzialna. Może to problem klienta? Próbowałem różnych Windowssystemów i Windows VPNklientów. Że Linuxklienci pracują zgodnie z oczekiwaniami bez rozłączenia.

Czy możesz mi pomóc rozwiązać ten problem? Próbowałem czytać książki i googlować, a niektórzy ludzie radzą się bawić keepalivei stosować reneg-secwytyczne. Ale to nie pomaga.

Konfiguracja serwera 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"

Dziennik serwera (czy problem nie występuje w 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

Dziennik klienta

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

Dziękuję Ci bardzo.

Sprawcą wydaje się Twoja konfiguracja uwierzytelniania. Używasz, plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so loginco wymagałoby od klienta podania poprawnej kombinacji nazwy użytkownika i hasła do połączenia. Najwyraźniej jest to również wymagane po ponownym uruchomieniu, a Twój klient OpenVPN wydaje się nie być w stanie zażądać nazwy użytkownika od stdin( ERROR: could not read Auth username from stdin).

Jeśli chodzi o powód, dla którego podniesienie renegacji w konfiguracji serwera nie ma znaczenia, to dlatego, że parametr musi zostać określony zarówno w konfiguracji serwera, jak i klienta, aby skutecznie przekroczyć domyślną wartość 3600 sekund (co zdarza się ponieważ jedna godzina - rozłącz widzisz).

Twoje opcje byłyby takie

• użyj metody uwierzytelniania, która nie wymaga danych wprowadzanych przez użytkownika (certyfikaty przypominają sobie)
• rozwiąż problemy, dlaczego klient nie może monitować o kombinację nazwy użytkownika i hasła po ustanowieniu połączenia
• wydłużyć okres ponownego generowania klucza lub całkowicie wyłączyć ponowne generowanie klucza (co osłabia bezpieczeństwo połączenia, więc z pewnością jest to tylko gorsze obejście problemu)

możesz spróbować reneg-sec 0w server.conf:

https://duo.com/docs/openvpn

https://tldrify.com/m80

to naprawdę bardzo proste. Ponieważ OpenVPN próbuje renegocjować nową sesję TLS domyślnie co 3600 sekund, musisz za każdym razem ponownie uwierzytelniać, używając nowego OTP. Aby uniknąć tego rodzaju zachowania, wystarczy, że powiesz openvpn, aby nigdy nie renegocjowało sesji TLS i utrzymywała istniejącą, jeśli połączysz keepalivedyrektywę i reneg-sec 0będziesz mieć stabilne połączenie, bez jakiejkolwiek renegocjacji.

Podobny efekt odczułem, gdy dodałem opcję „auth-nocache” do konfiguracji mojego klienta. Do uwierzytelnienia używam certyfikatów ORAZ kombinacji nazwy użytkownika i hasła.

Kilka razy zauważyłem w dziennikach połączeń, że openvpn zgłosił następujące ostrzeżenie:

OSTRZEŻENIE: ta konfiguracja może buforować hasła w pamięci - użyj opcji auth-nocache, aby temu zapobiec

Pomyślałem więc, że dodam tę opcję i zobaczę, co się stanie. Cóż, powyższe ostrzeżenie zniknęło, ale po godzinie pojawiło się okno dialogowe z prośbą o moją nazwę użytkownika i hasło.

Zauważyłem, że powyższa konfiguracja Andrew nie zawiera tej opcji, więc zastanawiam się, dlaczego nie buforuje hasła. Może to dlatego, że korzystam z nowszej wersji openvpn, a może można to ustawić w konfiguracji serwera, aby przekazać tę opcję klientowi.

Widać to na: OpenVPN 2.2.1-8 + deb7u2 z OpenVPN GUI v5 dla Windows.