Нужна консультация по настройке openvpn в etcnet [решено]

[rotkart]

Добрый день!
Дублирую сюда свой вопрос из рассылки sysadmins, надеясь сократить время его решения.
Настроил vpn из школы на мой домашний роутер под dd-wrt с внешним ip-адресом, с целью в дальнейшем средствами
рутера "высунуть" в интернет школьный электронный дневник.
Используется простейшая конфигурация с одним статическим ключом, сервер получает адрес привязанный по мак через dhcp рутера, после подключения openvpn.

 

Код: [Выделить]

[root@sterver ~]# cat /etc/openvpn/client.conf
 remote 81.xxx.xxx.60
 dev tap
 lladdr ee:05:99:1b:10:36
 secret /etc/openvpn/keys/static.key
 proto udp
 comp-lzoПосле установки соединения получаю адрес так, чтобы bind не среагировал:

Код: [Выделить]

#dhcpcd -C resolv.conf tap0
После настройки пытаюсь автоматизировать это через etcnet:

Код: [Выделить]

[root@sterver ~]# cat /etc/net/ifaces/tap0/options
 DISABLED=no
 ONBOOT=yes
 TYPE=ovpn
 TUNTAP_USER=openvpn
 BOOTPROTO=dhcp
 DHCP_CLIENT=/sbin/dhcpcd
 DHCP_ARGS="-C resolv.conf"
 REQUIRES="eth1"
 
 [root@sterver ~]# cat /etc/net/ifaces/tap0/ovpnoptions
 remote 81.xxx.xxx.60
 dev tap
 lladdr ee:05:99:1b:10:36
 secret /etc/openvpn/keys/static.key
 proto udp
 comp-lzo
 script-security 2
 Происходит следующее: dhcp-клиент запускается сразу после появления в системе интерфейса tap0, пытается получить адрес, отваливается по тайм-ауту, и только после этого происходит соединение по openvpn и становится можно получить адрес по dhcp.
При использовании ifup-post он, по описанию, тоже запустится при активации интерфейса, то есть до openvpn.
Есть способ как-то указать иной порядок действий при поднятии интерфейса - чтобы сначала openvpn и только потом dhcpcd?

[ksa]

Навскидку вижу два варианта. Первый -- изменить порядок старта демонов (что может быть чревато). Второй вариант -- выставить задержку в старте dhcp (если, конечно, это возможно). О реализации ничего конкретного не подскажу бо не сталкивался.

[rotkart]

Навскидку вижу два варианта. Первый -- изменить порядок старта демонов (что может быть чревато). Второй вариант -- выставить задержку в старте dhcp (если, конечно, это возможно). О реализации ничего конкретного не подскажу бо не сталкивался.

Порядок старта - это сложновато для меня будет, да и не через etcnet тогда надо будет действовать, имхо.
А по поводу задержки я пробовал в client.conf или ovpnoptions писать через параметр up скрипт со sleep - получается так: создаётся tap0, потом идёт эта задержка, потом попытка dhcp, потом только openvpn
Проблема в том, что все эти скрипты реагируют на появление в системе tap0, не ожидая окончания установки openvpn-соединения, наоборот задерживая эту самую установку.
Можно, конечно все это просто самописным скриптом оформить - но хочется по правильному, по системному.

[speccyfan]

А принципиально вообще пускать его через etcnet? Почему просто демоном не получается?
У меня все так работает. Клиент загружается, поднимается локалка и Интернет, затем запускается openvpn и когда канал поднимается, создается tap0, вот и все. Атозапуск включается так: chkconfig openvpn on

[rotkart]

А принципиально вообще пускать его через etcnet? Почему просто демоном не получается?
У меня все так работает. Клиент загружается, поднимается локалка и Интернет, затем запускается openvpn и когда канал поднимается, создается tap0, вот и все. Атозапуск включается так: chkconfig openvpn on

Вопрос к Вам: адрес у tap0 статический используете? Или от dhcp-сервера на дальнем конце получаете?

А так конечно не принципиально.
Через etcnet я стал действовать тогда, когда сам openvpn не справился: тут та же ситуация.

Если с таким client.conf

Код: [Выделить]

[root@sterver ~]# cat /etc/openvpn/client.conf
 remote 81.xxx.xxx.60
 dev tap
 lladdr ee:05:99:1b:10:36
 secret /etc/openvpn/keys/static.key
 proto udp
 comp-lzo
 стартовать service openvpn start, то канал поднимается, а потом _руками_ надо получать dhcp-адрес,
что, согласитесь, неудобно жутко и обязывает быть во внутренней сети школы для этого.

Если же в этот конфиг добавить вызов скрипта, получающего адрес:

Код: [Выделить]

[root@sterver ~]# cat /etc/openvpn/client.conf.bak
remote 81.ххх.ххх.60
dev tap
lladdr ee:05:99:1b:10:36
secret /etc/openvpn/keys/static.key
proto udp
comp-lzo
script-security 2
up /etc/openvpn/dhcp_tun0.sh

[root@sterver ~]# cat /etc/openvpn/dhcp_tun0.sh
#!/bin/bash
#sleep 30
/sbin/dhcpcd -C resolv.conf tap0
То этот скрипт тоже начинает выполняться _ДО_ установления самого openvpn-соединения и сервис openvpn банально не стартует . Логи есть.

Через etcnet оно хотя бы после таймаута соединение поднимает, остаётся адрес получить как-то.

[speccyfan]

Вопрос к Вам: адрес у tap0 статический используете? Или от dhcp-сервера на дальнем конце получаете?

Я просмотрел, что вы используете tap, я же использую tun интерфейс, адрес мне выдает сервер. А вам обязательно второй уровень по туннелю гонять? Может как раз с этим что-то связано?

я настраиваю так - https://sites.google.com/site/speccyfan/openvpn

[rotkart]

Я просмотрел, что вы используете tap, я же использую tun интерфейс, адрес мне выдает сервер. А вам обязательно второй уровень по туннелю гонять? Может как раз с этим что-то связано?

я настраиваю так - https://sites.google.com/site/speccyfan/openvpn

У меня на принимающей стороне в качестве сервера - DD-WRT на linsys e4200 - там все не так просто с openvpn, как в Альте.
Простая и задокументированная на wiki dd-wrt конфигурация поднялась руками минут за 10-15, без особой возни с сертификатами и подписями, вот и решил зафиксировать именно так.
Оказалось - шиш, причем с неожиданной стороны!
Главное кого винить: openvpn в Школьном сервере или etcnet там же? Баг это или нет?
Или вообще руки (хотя делал все по документации из пакетов дистрибутива)?
Видимо, на каникулах, буду пробовать другие варианты.
Скачал прошивку для рутера поновее, правда preSP2, прошьюсь, буду разбираться.
Спасибо!

[rotkart]

Мне кажется, я нашёл решение проблемы:

Код: [Выделить]

[root@sterver ~]# cat /etc/net/ifaces/tap0/options
DISABLED=no
ONBOOT=yes
TYPE=ovpn
TUNTAP_USER=openvpn
BOOTPROTO=dhcp
DHCP_CLIENT=/sbin/dhcpcd
DHCP_ARGS="--background --timeout 60 -C resolv.conf"
REQUIRES="eth1"

[root@sterver ~]# cat /etc/net/ifaces/tap0/ovpnoptions
remote 81.ххх.ххх.60
dev tap
lladdr ee:05:99:1b:10:36
secret /etc/openvpn/keys/static.key
proto udp
comp-lzo
script-security 2

То есть надо указать dhcpcd просить аренду в фоновом режиме - и пока там идёт тайм-аут, успевает устанавиться openvpn-соединение!!! Ух!!!
Завтра перезапущу машину, чтобы посмотреть так это или нет, но service network reload отрабатывает уже сейчас.