включать/выключать демон опенвпн по крону

Как Ъ решение подсоедини openvpn к radius-серверу. Там это функционал в коробке :)

Задумаюсь, конфиг один и в нем 10 пользователей, и у каждого свои ограничения. Потребуется множить инстанции.

Как Ъ решение подсоедини openvpn к radius-серверу. Там это функционал в коробке :)

Не имею радиуса и опыта работы с ним. И кроме как для этого требования он и не нужен.

не понимаю почему сложно сделать по крону.

Я бы пошел таким путём:
1) Повесить таких клиентов на отдельный внешний порт, в конфиге этого инстанса задать отдельный tunX интерфейс для туннелей с этими клиентами;
2) Закрыть правилами по умолчанию в iptables любой forward трафика через этот интерфейс в сторону твоих внутренних сетей;
3) Заюзать фичу client-connect script и сдеать что-то в духе (далее псевдокод):

if [проверка дня недели/времени]:
    открываем форвард трафика для $ifconfig_pool_remote_ip/$ifconfig_pool_netmask в сторону необходимого ресурса
else:
    echo "kill $common_name" | telnet <openvpn_management_ip> <management_port>

конфиг один и в нем 10 пользователей, и у каждого свои ограничения. Потребуется множить инстанции.

Тогда сделай правила фаервола для каждого пользователя, и по крону блокируй/разрешай доступ пользователям.

Вынести юзеров в ccd, это стандартное такое решение. Ну и по крону переписывать ccd, да командовать перечитать конфиг. Но активные соединения, по-моему не разорвутся. Можно делать рестарт, но это переподключение всех клиентов. Выбирай.

Вынести юзеров в ccd, это стандартное такое решение. Ну и по крону переписывать ccd, да командовать перечитать конфиг. Но активные соединения, по-моему не разорвутся. Можно делать рестарт, но это переподключение всех клиентов. Выбирай.

Я склонялся именно к этому. Все пользователи вынесены в ccd.

client-config-dir ccd

Доступ регулируется наличием/отсутвивем директивы «disabled». Верно, на активных пользователей это не подействует. Но добавив директиву:

management 127.0.0.1 6001

в конфигурацию сервиса и можно пройти по telnet и выполнить команду «kill <username>».

Кроме этого варианта, я ни чего не смог найти. Остается вопрос какими методами и как вычленять и удалять слово «disabled».

Есть еще вариант. Какой-то из модулей для iptables умеет делать проверки на время суток.

Нашел, пример: iptables -A INPUT -p tcp --dport 80 -m time --timestart 12:00:00 --timestop 23:59:59 --weekdays Sat, Sun -j ACCEPT

Тогда сделай правила фаервола для каждого пользователя, и по крону блокируй/разрешай доступ пользователям.

Возможно, да. У каждого пользователя свой IP, его я могу блокировать изолиролванно от openvpn в cron, подклюxение openvpn будет, но трафика не будет.

Принял, ко вниманию.

Клиенты скорее всего получают постоянные адреса. Просто фильтруй их. Сделай одно правило iptables и меняй набор ipset.

Я бы пошел таким путём:

о требуемую задачу решит на 100%

на 90% это не решает проблему уже существующего подключения. Проверка будет только при инициализации туннеля.

Клиенты скорее всего получают постоянные адреса. Просто фильтруй их. Сделай одно правило iptables и меняй набор ipset.

Да. Взвешу это решение с правкой по cron свойства «disabled» в файлах ccd.

Остается вопрос какими методами и как вычленять и удалять слово «disabled».

Современные админы не умеют bash,sed, awk?

Современные админы не умеют bash,sed, awk?

Пока писал..., пришла идея найти и заменить на пустоту. Не подумал.

Вот это

echo "kill $common_name" | telnet <openvpn_management_ip> <management_port>

(sleep 3; "kill $common_name") |telnet <openvpn_management_ip> <management_port>

Вот такая идея без fw:

3) Заюзать фичу client-connect script и сдеать что-то в духе (далее псевдокод):

if ! [проверка дня недели/времени и common_name ]; then
 заблокировано 
 exit 1
fi

А в крон скрипт который убьет тех кто подключен

(sleep 3; "kill $common_name") |telnet <openvpn_management_ip> <management_port>

Остается вопрос какими методами и как вычленять и удалять слово «disabled».

Не disabled, а disable.

delete
sed -i '/^disable$/d' ccd/username
add
echo 'disable' >> ccd/username

Т.е «client-connect script» сможет прервать соединенение, я правильно понял?

Т.е «client-connect script» сможет прервать соединенение, я правильно понял?

signal The reason for exit or restart. Can be one of sigusr1, sighup, sigterm, sigint, inactive (controlled by --inactive option), ping-exit (controlled by --ping-exit option), ping-restart (controlled by --ping-restart option), connection-reset (triggered on TCP connection reset), error, or unknown (unknown signal). This variable is set just prior to down script execution.

(c) Environmental Variables

Нет, он не даст создать нового подключения.
А разорвет существующее скрипт из крона.
ЗЫ Только вот telnet <openvpn_management_ip> <management_port> выполняйте последовательно, openvpn не дает одновременно соединиться, точнее telnet будет висеть и ждать пока предыдущее соединение не разорвется.

Абсолютно верно. Внутри этого скрипта можно даже сделать что-то в духе:

echo "disable" >> $1

UPD: посыпаю голову пеплом, если речь была про «прервать _уже установленное_ соедиение»

Абсолютно верно. Внутри этого скрипта можно даже сделать что-то в духе:

echo «disable» >> $1 что будет аналогично нахождению этой директивы в ccd-конфиге клиента.

Тогда это прямее, чем править ccd файл.

UPD: посыпаю голову пеплом, если речь была про «прервать _уже установленное_ соедиение»

Нет, как оно прервет установленное соединение. Оно работает на моменте инициализации оного. Пока вариант, прерывать надо чем-то внешним.

что будет аналогично нахождению этой директивы в ccd-конфиге клиента.

аналогично это как я написал exit 1 (ну или любое другой число кроме нуля )

Итог

При использовании Openvpn по календарю контролировать необходимо два состояния:

• Проверять возможность предоставления сервиса на моменте подключения;
• Проверять может ли предоставляемый сервис предоставляться и далее.

Мнения разделились на два основопологающих:

• Контролировать возможность прохождения трафика используя iptables и статические IP клиентов.
• Контролировать процесс инициализации и существования туннеля.

Первый вариант не подразумевает взаимодействия с openvpn, а работает независимо от него.

Второй вариант подразумевает использование openvpn, в части контроля инициализации - нативных методов openvpn, а в части контролля поддержания соединения - cron.

Общее для всех, задача оставленная за кадром, это генерация ответа на вопрос «В этот момент времени можно или нельзя предоставлять сервис?». Если рассуждать об использованием cron, то требуется определять в конфигурации весь период времени, и тот который должен быть запрещен, и тот который должен быть разрешен. К примеру, имея недельный календарь доступа, необходимо последоватьно в cron описать, что в каждый понедельник в 7-00 включаем доступ, а в каждый понедельник в 20-00 отключаем и следить, что бы события включения и отключения были поступательны, что на первый взгляд громоздко. Рисуется возможность интеграции с caldav, но это уже дополнительные сущности и применительность надо взешивать с возможностями Radius в этом плане.

http://www.cyberciti.biz/tips/iptables-for-restricting-access-by-time-of-day....

http://www.cyberciti.biz/tips/iptables-for-restricting-access-by-time-of-day....

Благодарю

Имхо разжевали еще выше. Проверка возможности новых подключений при конекте клиента, если запрещено то не пускаем.
Для нескольких десятков клиентов поднимать caldav или Radius имхо смысла нет, обертки дольше писать будешь чем распарсить текстовый файл какой-нибудь.
А отключение прописываем в крон на то время когда необходимо (создание записей рекомендую автоматизировать беря за основу тот же конфиг), можно даже не заморачиватся с проверкой подключен клиент или нет, посылать kill по списку.