Відключення від сервера OpenVPN щогодини


13

У мене є досить дивна проблема з моєю OpenVPNконфігурацією. Я підключаюся Windows 7з останнім офіційним OpenVPNклієнтом до свого OpenVPNсервера ( OpenVPN 2.1.4 i386-redhat-linux-gnu).

Проблема полягає в тому, що я відключаюсь від свого OpenVPNсервера рівно через 1 годину, і я не можу зрозуміти, яка директива / варіант відповідає за це. Можливо, це питання клієнта? Я пробував різні Windowsсистеми та Windows VPNклієнтів. В Linuxклієнти працюють , як і очікувалося, без відключень.

Не могли б ви допомогти мені вирішити цю проблему? Я намагався читати книги і вдаючись до допомоги і деякі люди радять грати keepaliveі reneg-secдирективи. Але це, здається, не допомагає.

Конфігурація сервера 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"

Журнал сервера (чи не проблема в 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

Журнал клієнта

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

Дуже дякую.

Відповіді:


12

Винуватцем здається ваша конфігурація аутентифікації. Ви використовуєте, plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so loginщо вимагатиме від клієнта надати дійсну комбінацію імені користувача / пароля для підключення. Мабуть, це також потрібно після повторної переробки і ваш клієнт OpenVPN, здається, не в змозі запитати ім'я користувача від stdin( ERROR: could not read Auth username from stdin).

Що ж стосується причини, чому підвищення конфігурації повторів у конфігурації вашого сервера не допомагає, це тому, що параметр повинен бути вказаний в обох - конфігурація сервера та клієнта, щоб бути ефективно піднята вище за замовчуванням 3600 секунд (що трапляється з викликати одну годину - відключіть, яку ви бачите).

Тож ваші варіанти були б

  • використовувати метод аутентифікації, який не потребує введення користувачем (сертифікати ведуться до уваги)
  • усуньте проблеми, чому ваш клієнт не може запропонувати поєднати ім'я користувача / пароль після встановлення з'єднання
  • підвищити період повторної переробки або повністю відключити перемонтажу (що послаблює безпеку вашого з'єднання, тому це, безумовно, лише неповноцінний спосіб вирішення вашої проблеми)

Ви маєте рацію, додавши оновлення до client.ovpn допомогло вирішити цю проблему.
Андрій

8

ви можете спробувати reneg-sec 0у своєму server.conf:

https://duo.com/docs/openvpn

https://tldrify.com/m80

це дуже просто насправді. Оскільки OpenVPN намагається повторно визначити новий сеанс TLS кожні 3600 секунд за замовчуванням, вам доведеться кожен раз повторно аутентифікуватись, використовуючи новий OTP. Щоб уникнути подібної поведінки, варто просто сказати openvpn ніколи не повторювати сеанс TLS і зберегти існуючий живий, якщо ви поєднаєте keepaliveдирективу, і reneg-sec 0ви матимете стабільний зв'язок, без регонсування.


3

Я відчув подібний ефект, коли я додав опцію "auth-nocache" до своєї конфігурації клієнта. Я використовую сертифікати І Ім'я користувача + комбінацію паролів для автентифікації.

Кілька разів я помічав у журналах підключень, що openvpn повідомляв про таке попередження:

УВАГА: ця конфігурація може кешувати паролі в пам'яті - використовуйте параметр auth-nocache, щоб запобігти цьому

Тому я подумав, що я просто додам цю опцію і подивіться, що станеться. Ну, вищезазначене попередження все-таки знімається, але через годину з’явилося діалогове вікно, запитуючи мене про моє ім’я користувача та пароль.

Я помітив, що наведена вище конфігурація Ендрю не містить цієї опції, тому я трохи не здивований, чому вона не кешує пароль. Можливо, це тому, що я використовую більш нову версію openvpn або, можливо, її можна встановити на конфігурації сервера, щоб передати цю опцію клієнту.

Це було помічено на: OpenVPN 2.2.1-8 + deb7u2 з OpenVPN GUI v5 для Windows.


Мені потрібно генерувати файл за допомогою openvpn, а потім додати параметр auth-nocache. Зараз працює чудово. Згенерований файл можна використовувати як
crsuarezf

@ingcarlos Чудово чути, що це працює для вас. Щасливі vpn-ing.
captcha

+1 Абсолютлі справа, я зіткнувся з тією ж проблемою після додавання директиви про кеш.
Мохаммед Нурелдін
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.