From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.2.5 X-Virus-Scanned: amavisd-new at localhost Message-ID: <1359808630.26381.52.camel@v3405.naf.net.ru> From: "Nikolay A. Fetisov" To: ALT Linux Community general discussions Date: Sat, 02 Feb 2013 16:37:10 +0400 In-Reply-To: <510C9B98.50103@mail.ru> References: <50A3B9B9.8070803@mail.ru> <1352923274.6502.6.camel@v3405.naf.net.ru> <50A3FE60.4040104@mail.ru> <51081951.3070300@mail.ru> <1359560342.32585.46.camel@v3405.naf.net.ru> <51094375.6080002@mail.ru> <1359576242.32585.69.camel@v3405.naf.net.ru> <510C9B98.50103@mail.ru> Content-Type: text/plain; charset="KOI8-R" X-Mailer: Evolution 3.6.3 (3.6.3-alt1) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Re: [Comm] Openvpn X-BeenThere: community@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: naf@naf.net.ru, ALT Linux Community general discussions List-Id: ALT Linux Community general discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 12:37:03 -0000 Archived-At: List-Archive: List-Post: Здравствуйте! В Сб, 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 самоподписанный, и им же подписаны сертификаты клиентов), но выглядит оно как-то странно. -- С уважением, Николай Фетисов