Отключение от сервера 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).

Что касается причины, по которой повышение значения reneg-sec в конфигурации вашего сервера не помогает, это связано с тем, что этот параметр необходимо указывать как в конфигурации сервера, так и в конфигурации клиента, чтобы он был эффективно повышен по умолчанию выше 3600 секунд (что случается с Вызовите один час - отключение вы видите).

Таким образом, ваши варианты будут

  • использовать метод аутентификации, который не требует ввода пользователя (на ум приходят сертификаты)
  • выяснить, почему ваш клиент не может запросить комбинацию имени пользователя и пароля после установления соединения
  • увеличьте период повторного ввода или полностью отключите повторное использование (что ослабляет безопасность вашего соединения, так что это, безусловно, лишь неполноценное решение вашей проблемы)

Вы правы, добавив reneg-sec в 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. Сейчас работает отлично.
Созданный

@ingcarlos Рад слышать, что это работает на тебя. С праздником.
капча

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