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

Проблемы с OpenVPN - длительность сессии

Подробнее
6 года 8 мес. назад #13 от admin
admin ответил в теме Новая возможность - Публикация URL / URL publishing
У вас openvpn держится с установленным reneg-sec 0 ?

Посмотрел, сейчас этот маршрут имеется. Адрес 172.16.4.164 и 192.168.1.1 пингуются с сервера
Вы видите маршрут на странице Инструменты и проходят ли пинги?
если все заработало, то, пожалуйста, donate сюда - yoomoney.ru/to/410014618210530

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

Подробнее
6 года 8 мес. назад #14 от SergNF
SergNF ответил в теме Новая возможность - Публикация URL / URL publishing

admin пишет: У вас openvpn держится с установленным reneg-sec 0 ?

Да. У обоих клиентов.

admin пишет: Посмотрел, сейчас этот маршрут имеется. Адрес 172.16.4.164 и 192.168.1.1 пингуются с сервера
Вы видите маршрут на странице Инструменты и проходят ли пинги?

Сейчас (!) - да. Но когда в 2017-08-17 13:33:46 я добавил клиенту user1438 параметр reneg-sec 0 и клиент перезапустился (штатно!!!), то маршрут пропал. И вчера после 2017-08-17 13:33:46 я мог войти (ssh) только на устройство с ip 172.16.4.164 (естественно подняв второй туннель user1473).
- route на 172.16.4.164 (он же 192.168.1.1) и на остальных компьютерах сети были корректные
- tracert c 172.16.4.195 до 192.168.1.1 доходил до 172.16.0.1 и все
Мне ("моему клиенту") для корректного поднятия туннеля необходимо выключить, выдержать паузу (до письма) и снова включить. Только тогда "появляется" эта строка в таблице маршрутизации.
При этом при "реконнекте" (то, что обсуждаете в данной ветке) маршрут, видимо, не удалялся, т.е. не поднимался и, в итоге, "оставался".

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

Подробнее
6 года 8 мес. назад #15 от admin
admin ответил в теме Новая возможность - Публикация URL / URL publishing
Вчера был тяжелый день по загрузке на сервер, может быть это повлияло. Давайте посмотрим сегодня.
Я правильно понимаю, что ваш клиент ждет получения оповещения по почте об отключении/включении туннеля?
Если не секрет - почему вы делает так, в чем причина?
если все заработало, то, пожалуйста, donate сюда - yoomoney.ru/to/410014618210530

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

Подробнее
6 года 8 мес. назад #16 от SergNF
SergNF ответил в теме Новая возможность - Публикация URL / URL publishing

admin пишет: Вчера был тяжелый день по загрузке на сервер, может быть это повлияло. Давайте посмотрим сегодня.

Я не планирую перезапускать клиента, т.к. для меня пусть без маршрутизации, с "ежечасными" реконнектами, с упавшим socks'прокси, "непубликацией" и т.д. (решу) главное, чтобы туннель 1438 был поднят. Т.е. не находясь у компьютеров сети 192.168.1.0, я клиента перезапускать не буду.

admin пишет: Я правильно понимаю, что ваш клиент ждет получения оповещения по почте об отключении/включении туннеля?

Нет. Это "лженаука" статистика. Пока не выдержать "паузу", соизмеримую со времене прихода письма, ничего (с большой долей вероятности) не получится

admin пишет: Если не секрет - почему вы делает так, в чем причина?

До какого-то часа (дня) X что-то (?) падало редко и реконнект не помогал. tun0 "жил", что было с пингами* я узнать (по объективным причинам) не мог. Я искал критерий перезапуска остановки и запуска клиента. Либо Ваше письмо (оно не приходило при "пропадании связи"), либо "лампочки" статуса (они не краснели), либо "письмо с большой земли" (от меня) - пока лень.
* скорее всего пинги до 172.16.0.1 доходили, а дальше, в моей конфигурации (1473 - аварийный вариант) пинговать некого.
X День X в моем понимании это когда Вы отключили регистрацию в Амстердаме. Опять же "после не значит вследствии" (c), но "проблемы" начались примерно тогда.

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

Подробнее
6 года 8 мес. назад #17 от admin
admin ответил в теме Новая возможность - Публикация URL / URL publishing
Понятно. Прекращение регистрации в Амстердаме совпадаем с началом обновления сервера OpenVPN до следующей версии на нашей стороне. Видимо все после этого и началось.
Еще один нюанс. Возможно вам пригодится. Как я уже писал, мы используем UDP и при обрыве соединения со стороны клиента сервер не может никак узнать о том, что клиент отключился. Если бы была сессия TCP то сервер бы узнал, а тут нет. Для извещения сервера мы ввели параметр explicit-exit notify 2 в файлы .ovpn. В соответствии с этим параметром, клиент дважды посылает на сервер данные о своем отключении. До тех пор, пока сервер не узнал, что соединение оборвалось клиент будет числиться "подключенным" и при повторном соединении его не пустят из-за ограничения "один логин - одна сессия". Затем наступит таймаут неактивности соединения, который сейчас составляет 2 минуты и сервер, в итоге, оборвет соединение. И только через 2 минуты он будет готов принимать соединение от этого клиента вновь.
В вашем случае, если случается событие, при котором клиент не успел послать explicit-exit notify, или эти пакеты потерялись по дороге, то 2-3 минуты это время, которое нужно выждать перед установкой нового соединения. Это самый печальный, но редкий случай, так как в нормальных ситуациях соединение должно устанавливаться моментально. Вы можете поставить explicit-exit notify 5 - хуже не будет.
Мы думали о том, чтобы запустить подключение OpenVPN для клиентов по TCP. Это возможно, но нагрузка на сервер существенно увеличится из-за необходимости поддерживать и TCP и UDP инстансы для клиента. Но однозначно, работа по TCP была бы четче и проблем было бы меньше. Если вам кажется, что это было бы верным решением, то можно в качестве теста попробовать сделать сервер на TCP порту.
если все заработало, то, пожалуйста, donate сюда - yoomoney.ru/to/410014618210530

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

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