Вход
Авторизация

Долгое переподключение после закрытия по timout

Подробнее
4 года 9 мес. назад #1 от kanoviv
kanoviv создал тему: Долгое переподключение после закрытия по timout
Добрый день!

Каждые 6 часов соединение по OpenVpn сбрасывается по неактивности. Наверно, это нормально, но после этого в течение 4 мин. канал не может подняться.
Конфигурационный файл:

client
remote msk.vpnki.ru 35619
proto udp
cipher AES-128-CBC
remote-cert-tls server
key-direction 1
dev tun
auth-user-pass /etc/openvpn/vpnki_login
explicit-exit-notify 2
reneg-sec 0

Лог на клиенте (linux OpenWrt)

Thu Feb 20 15:45:57 2020 daemon.notice openvpn(vpnki)[1044]: [VPNKI] Inactivity timeout (--ping-restart), restarting
Thu Feb 20 15:45:57 2020 daemon.notice openvpn(vpnki)[1044]: /sbin/ifconfig tun0 0.0.0.0
Thu Feb 20 15:45:57 2020 daemon.notice openvpn(vpnki)[1044]: SIGUSR1[soft,ping-restart] received, process restarting
Thu Feb 20 15:46:02 2020 daemon.notice openvpn(vpnki)[1044]: TCP/UDP: Preserving recently used remote address: [AF_INET]84.201.157.25:35619
Thu Feb 20 15:46:02 2020 daemon.notice openvpn(vpnki)[1044]: UDP link local (bound): [AF_INET][undef]:1194
Thu Feb 20 15:46:02 2020 daemon.notice openvpn(vpnki)[1044]: UDP link remote: [AF_INET]84.201.157.25:35619
Thu Feb 20 15:47:02 2020 daemon.err openvpn(vpnki)[1044]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Feb 20 15:47:02 2020 daemon.err openvpn(vpnki)[1044]: TLS Error: TLS handshake failed
Thu Feb 20 15:47:02 2020 daemon.notice openvpn(vpnki)[1044]: SIGUSR1[soft,tls-error] received, process restarting
Thu Feb 20 15:47:07 2020 daemon.notice openvpn(vpnki)[1044]: TCP/UDP: Preserving recently used remote address: [AF_INET]84.201.157.25:35619
Thu Feb 20 15:47:07 2020 daemon.notice openvpn(vpnki)[1044]: UDP link local (bound): [AF_INET][undef]:1194
Thu Feb 20 15:47:07 2020 daemon.notice openvpn(vpnki)[1044]: UDP link remote: [AF_INET]84.201.157.25:35619
Thu Feb 20 15:48:07 2020 daemon.err openvpn(vpnki)[1044]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Feb 20 15:48:07 2020 daemon.err openvpn(vpnki)[1044]: TLS Error: TLS handshake failed
Thu Feb 20 15:48:07 2020 daemon.notice openvpn(vpnki)[1044]: SIGUSR1[soft,tls-error] received, process restarting
Thu Feb 20 15:48:13 2020 daemon.notice openvpn(vpnki)[1044]: TCP/UDP: Preserving recently used remote address: [AF_INET]84.201.157.25:35619
Thu Feb 20 15:48:13 2020 daemon.notice openvpn(vpnki)[1044]: UDP link local (bound): [AF_INET][undef]:1194
Thu Feb 20 15:48:13 2020 daemon.notice openvpn(vpnki)[1044]: UDP link remote: [AF_INET]84.201.157.25:35619
Thu Feb 20 15:49:13 2020 daemon.err openvpn(vpnki)[1044]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Feb 20 15:49:13 2020 daemon.err openvpn(vpnki)[1044]: TLS Error: TLS handshake failed
Thu Feb 20 15:49:13 2020 daemon.notice openvpn(vpnki)[1044]: SIGUSR1[soft,tls-error] received, process restarting
Thu Feb 20 15:49:18 2020 daemon.notice openvpn(vpnki)[1044]: TCP/UDP: Preserving recently used remote address: [AF_INET]84.201.157.25:35619
Thu Feb 20 15:49:18 2020 daemon.notice openvpn(vpnki)[1044]: UDP link local (bound): [AF_INET][undef]:1194
Thu Feb 20 15:49:18 2020 daemon.notice openvpn(vpnki)[1044]: UDP link remote: [AF_INET]84.201.157.25:35619
Thu Feb 20 15:49:21 2020 daemon.notice openvpn(vpnki)[1044]: [VPNKI] Peer Connection Initiated with [AF_INET]84.201.157.25:35619
Thu Feb 20 15:49:22 2020 daemon.notice openvpn(vpnki)[1044]: TUN/TAP device tun0 opened
Thu Feb 20 15:49:22 2020 daemon.notice openvpn(vpnki)[1044]: /sbin/ifconfig tun0 172.16.33.175 netmask 255.255.0.0 mtu 1500 broadcast 172.16.255.255
Thu Feb 20 15:49:22 2020 daemon.notice openvpn(vpnki)[1044]: Initialization Sequence Completed

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Подробнее
4 года 9 мес. назад - 4 года 9 мес. назад #2 от admin
admin ответил в теме Долгое переподключение после закрытия по timout
Перезапуск по неактивности это может быть и нормально, но это делает ваше оборудование. В конфигурационном файле ничего про неактивность нет. Со стороны сервера такого требования тоже нет.

Насчет нескольких циклов установления соединения надо подумать...
Дело в том, что мы используем протокол UDP. Этот протокол не использует понятие "сессия", а просто передает данные из точки А в точку В.
Когда ваш клиент отключается, то сервер не обладает возможностью узнать, что клиент отключился - ведь сессии нет и ничего не обрывалось. Для того, чтобы сервер узнал об отключении мы используем параметр explicit-exit-notify 2 . Этот параметр должен обязать клиента дважды послать на сервер сообщение об отключении. Тогда сервер узнает о том, что клиент отключился и ставит Stop-time в вашем предыдущем соединении.
Если сервер не получил сообщение об отключении, но к нему ничего со стороны вашего клиента не приходит в течение какого-то времени, то сервер думает, что клиент на самом деле отключился и ставит Stop-time в этом соединении.
Мне кажется, что таймаут около 5 минут и есть тот самый таймаут при котором сервер еще думает, что клиент подключен. Следовательно, он не пустит его повторно при подключении.
Поэтому у меня есть два предположения.
Первое - при перезапуске сессии ваш клиент ничего не посылает серверу, а просто перезапускается.
Второе - то, что ваше соединение не принимается в течение 4-х минут может отразиться в попытке неудачной аутентификации в логе "Статистика" - "События авторизации". Посмотрите, пожалуйста, есть ли там в это время неуспешные попытки аутентификации?
если все заработало, то, пожалуйста, donate сюда - yoomoney.ru/to/410014618210530
Последнее редактирование: 4 года 9 мес. назад пользователем admin.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Подробнее
4 года 9 мес. назад #3 от kanoviv
kanoviv ответил в теме Долгое переподключение после закрытия по timout
В событиях авторизации ошибок нет. Скорее всего причина, что сервер не понимает сразу, что клиент отвалился и ждет 4 мин. Можно это победить? Было подобное обращение на форуме.
Советовали поменять explicit-exit-notify на 5. Пробовал, результат тот-же.
Установлены последние версии Openwrt и Openvpn.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Подробнее
4 года 9 мес. назад - 4 года 9 мес. назад #4 от admin
admin ответил в теме Долгое переподключение после закрытия по timout
Если в событиях авторизации нет ошибок, то проблема может быть в чем-то другом.

1. Сначала нужно разобраться откуда вообще этот таймаут неактивности срабатывает. В конфигурации вашего клиента ничего про это нет.
Откуда он берется? Если его не будет, то может быть все и наладится.

2. Скорее всего, когда клиент отключается, то он ничего не сообщает, поэтому что explicit-exit-notify 2, что 5 - без разницы.

3. Посмотрел серверную конфигурацию и понял, что уже подзабыл кое-что.
Там есть директива keepalive 10 120, на самом деле она означает, что нужно посылать пинг каждые 10 секунд и если нет ответа в течение 120 секунд, то тогда счиатать соединение разорванным.
Таким образом, речь идет о 120- 130 секундах, но не о 4 минутах. Хотя и близко.
Мне не сложно поменять это на другие параметры, например на keepalive 5 30, но давайте сначала проведем эксперимент.

Попробуйте отключить соединение вручную, а затем включить его допустим через 5 секунд. Установится ли соединеие и что будет в логе?
если все заработало, то, пожалуйста, donate сюда - yoomoney.ru/to/410014618210530
Последнее редактирование: 4 года 9 мес. назад пользователем admin.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Подробнее
4 года 9 мес. назад #5 от kanoviv
kanoviv ответил в теме Долгое переподключение после закрытия по timout
Если, остановить сервис (openvpn stop) и через потом запустить (openvpn start), то подключается сразу.

Вот лог

Sat Feb 22 08:45:03 2020 daemon.err openvpn(vpnki)[1325]: event_wait : Interrupted system call (code=4)
Sat Feb 22 08:45:03 2020 daemon.notice openvpn(vpnki)[1325]: SIGTERM received, sending exit notification to peer
Sat Feb 22 08:45:08 2020 daemon.notice openvpn(vpnki)[1325]: /sbin/ifconfig tun0 0.0.0.0
Sat Feb 22 08:45:08 2020 daemon.notice openvpn(vpnki)[1325]: SIGTERM[soft,exit-with-notification] received, process exiting
Sat Feb 22 08:46:28 2020 daemon.notice openvpn(vpnki)[1431]: OpenVPN 2.4.7 mipsel-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Sat Feb 22 08:46:28 2020 daemon.notice openvpn(vpnki)[1431]: library versions: OpenSSL 1.1.1d 10 Sep 2019, LZO 2.10
Sat Feb 22 08:46:28 2020 daemon.notice openvpn(vpnki)[1431]: TCP/UDP: Preserving recently used remote address: [AF_INET]84.201.157.25:35619
Sat Feb 22 08:46:28 2020 daemon.notice openvpn(vpnki)[1431]: UDP link local (bound): [AF_INET][undef]:1194
Sat Feb 22 08:46:28 2020 daemon.notice openvpn(vpnki)[1431]: UDP link remote: [AF_INET]84.201.157.25:35619
Sat Feb 22 08:46:28 2020 daemon.warn openvpn(vpnki)[1431]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sat Feb 22 08:46:28 2020 daemon.notice openvpn(vpnki)[1431]: [VPNKI] Peer Connection Initiated with [AF_INET]84.201.157.25:35619
Sat Feb 22 08:46:29 2020 daemon.notice openvpn(vpnki)[1431]: TUN/TAP device tun0 opened
Sat Feb 22 08:46:29 2020 daemon.notice openvpn(vpnki)[1431]: /sbin/ifconfig tun0 172.16.33.175 netmask 255.255.0.0 mtu 1500 broadcast 172.16.255.255
Sat Feb 22 08:46:29 2020 daemon.notice openvpn(vpnki)[1431]: Initialization Sequence Completed

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Подробнее
4 года 9 мес. назад #6 от admin
admin ответил в теме Долгое переподключение после закрытия по timout

kanoviv пишет: Sat Feb 22 08:45:03 2020 daemon.notice openvpn(vpnki)[1325]: SIGTERM received, sending exit notification to peer

Здесь есть оповещение об отключении и сервер корректно отключает соединение. В отключении по таймауту неактивности такого сообщения не было.
Смотрите, я считаю, что отключении по неактивности это некорректная работа openwrt и это причина проблемы.

Я могу изменить вам настройки на сервере, они уменьшат интервал со 120 до 30 секунд, но это может иметь обратный эффект, что если keepalive не придет по какой-то причине в течение 30 секунд, то сервер оборвет соединение. На плохих каналах это вполне вероятное событие. Таким образом, соединение может часто обрываться.

Возможно вам стоит поискать как отключить в openwrt этот таймер неактивности. На этот счет много чего в Интернете, но я не нашел рабочего решения (правда не сильно много искал).
Если будете пробовать, то чтобы не ждать 6 часов попробуйте послать команду из терминальной сессии: killall -s SIGUSR1 openvpn
Это проэмулирует то, что делает сам openvpn в случае когда ему кажется что таймер неактивности истекает.

Если не будете этим заниматься, а просто хотите поставить на сервере keepalive 5 30, то сообщите и я это сделаю.
если все заработало, то, пожалуйста, donate сюда - yoomoney.ru/to/410014618210530

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Время создания страницы: 0.192 секунд