[Comm] Openvpn

[Nikolay A. Fetisov]

Здравствуйте!

В Сб, 02/02/2013 в 08:52 +0400, Vladimir Karpinsky пишет:
> 31.01.2013 0:04, Nikolay A. Fetisov пишет:
> 
> > Offtopic: chroot и работу от псевдо-пользователя _действительно_ надо
> > было отключать в /etc/sysconfig/openvpn ?
> 
> А оно отключено? ...

В /etc/sysconfig/openvpn из пакета присутствуют строки
CHROOT=yes
OPENVPNUSER=openvpn
OPENVPNGROUP=openvpn

При их наличии init-скрипт запускает OpenVPN с ключами командной строки
"--user openvpn --group openvpn --persist-tun --persist-key
--chroot /var/lib/openvpn"

У Вас этого не наблюдается - соответственно, в /etc/sysconfig/openvpn
они отключены.
А есть ли соответствующие параметры в файле конфигурации - надо смотреть
отдельно.

...
> > Итого:
> > - есть две конфигурации, в /etc/net и в /etc/openvpn/ ;
> 
> Спасибо за подробный разбор. Теперь ситуация более-менее понятна. 

Было бы.

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

Вообще-то, есть /usr/share/doc/openvpn-*/README* .

> Есть ли преимущества у какого-нибудь способа запуска?

Не скажу - я не пользуюсь ни конфигураций через etcnet, ни альтератором
в целом.

Запуск через init-скрипт - исторически первый появившийся и де-факто
стандартный. Зато конфигурация через etcnet поддерживается альтератором.

Через init-скрипт по-умолчанию OpenVPN запускается в chroot, через
etcnet, _судя по приведённому Вами файлу конфигурации_ - нет.

Как я понимаю, при наличии нескольких каналов OpenVPN в etcnet под
каждый надо создавать отдельный интерфейс - вне зависимости от того,
запускаются они все вместе, или выборочно. Через init-скрипт можно 
иметь конфигурации, не привязанные к именам интерфейсов (т.е. иметь в 
файле конфигурации просто 'dev tun', а не 'dev tunN') - что для
эпизодически используемых вручную запускаемых подключений может
упростить конфигурацию iptables.

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

Так что, выбирать Вам.

Кстати, как минимум для клиентов есть и ещё один способ - Network
Manager. Со своим собственным способом хранения конфигурации и запуска
openvpn.

> ...
> Пытаюсь для начала свести конфигурации к единообразности по сертификатам.
> ...

На самом деле, зависит от того, как (чем) создаются сертификаты.
В целом:
- должен быть центр сертификации (Certification Authority) - его
  сертификат (или цепочка для SubCA) указывается в параметре ca;
- для сервера должен быть ключ и серверный сертификат, подписанный CA - 
  в key и cert в файле конфигурации сервера соответственно;
- для клиента должен быть ключ и клиентский сертификат, подписанный CA -
  в key и cert в файле конфигурации клиента соответственно;
- сертификаты CA, сервера и клиента должны быть действующими.

Т.е., сертификат CA на сервере должен быть тот же, что и на клиентах,
сертификат сервера должен быть подписан этим CA, и сертификаты клиентов
также должны быть подписаны тем же самым CA.

Опционально, на сервере в каталоге, указанном в ccd, _может_ быть файл
с именем, совпадающим с CN сертификата клиента - тогда клиенту будет
дополнительно при подключении передана конфигурация из такого файла.

Опционально, при задании на сервере параметра ccd-exclusive, файл в ccd
_обязан_ быть - иначе соединение с клиентом не будет установлено даже в
том случае, если сертификат у клиента правильный.


Вариант, когда в двух разных конфигурациях key и cert одинаковые, а
ca разный - какой-то очень подозрительный. Т.е., такое может и работать
(например, сертификат CA помещён внутрь cert, и отдельно указанный ca не
используется; или cert самоподписанный, и им же подписаны сертификаты
клиентов), но выглядит оно как-то странно.

-- 
С уважением,
Николай Фетисов