На главную

OpenVPN HOWTO

Перевод М. Альхименко при помощи OmegaT и GoldenDict.
Последнее изменение: 19 декабря 2011 года.
Изначально планировалось так же выполнить перевод и man-страниц, но по причине отсутствия времени перевод отложен на 2-3 месяца. Если кто-то соберется сделать это сам, напишите мне на почту чтобы не делать двойную работу.
По вопросам перевода обращайтесь на articles <at> lithium.opennet.ru. По вопросам содержания — к авторам. Оригинал (и самая последняя версия) этого документа находится на http://lithium.opennet.ru.

Введение

OpenVPN -- это полнофункциональный SSL VPN (Virtual Private Network — виртуальная частная сеть), реализующий увеличение безопасности сети на 2-м и 3-м уровне OSI используя являющийся промышленным стандартом протокол SSL/TLS, поддерживает гибкие методы аутентификации клиента на основе сертификатов, смарт-карт и/или имени пользователя/пароля, а также предоставляет политики контроля доступа пользователя или группы, используя правила файрвола, применяемые к виртуальному VPN-интерфейсу. OpenVPN не является прокси-сервером для веб-приложений и не работает через веб-браузер.

OpenVPN 2.0 расширяет возможности OpenVPN 1.x и предлагает масштабируемый клиент-серверный режим, позволяющий нескольким клиентам подключаться к одному процессу OpenVPN-сервера через один TCP- или UDP-порт.

Этот документ содержит пошаговые инструкции по настройке сервера и клиента OpenVPN 2.0, включая:

Самые нетерпеливые, возможно, сразу захотят перейти к примерам конфигурационных файлов:

Целевая аудитория

Этот HOWTO предполагает что читатели обладают предварительным пониманием основных концепций сетей, таких как IP-адреса, имена DNS, маски подсетей, IP-маршрутизация, маршрутизаторы, сетевые интерфейсы, локальные сети, шлюзы и правила файрвола.

Дополнительная документация

Книги по OpenVPN

beginning-openvpn-2-0-9

Beginning OpenVPN 2.0.9
byMarkus Feilner and Norbert Graf
Publisher: Packt Publishing (December 2, 2009)
ISBN: 184719706X
[Другие книги]

OpenVPN 1.x HOWTO

Оригинальный OpenVPN 1.x HOWTO по-прежнему доступен и остается актуальным для конфигураций точка-точка или конфигураций с использованием статических ключей.

Статьи по OpenVPN

Дополнительную документацию смотрите на странице статей на сайте OpenVPN.

Быстрый запуск OpenVPN

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

Вы можете перейти к Static Key Mini-HOWTO, если хотите получить работающий VPN быстро и с минимальной конфигурацией.

Преимущества использования статического ключа

  • Простая настройка
  • Не нужно поддерживать X509 PKI (Public Key Infrastructure, инфраструктуру публичных ключей)

Недостатки использования статического ключа

  • Ограниченная масштабируемость -- один клиент, один сервер
  • Отсутствие идеальной тайны переписки -- компрометация ключа повлечет за собой полное раскрытие предыдущих сессий.
  • Секретный ключ должен присутствовать в виде открытого текста на каждом участнике VPN (VPN peer)
  • Секретный ключ должен быть скопирован (при настройке нового подключения) с использованием уже существующего безопасного канала

Установка OpenVPN

OpenVPN можно скачать здесь.

В целях обеспечения безопасности будет хорошей идеей проверить сигнатуру файла с релизом после загрузки.

Исполняемые файлы OpenVPN должны быть установлены и на сервере, и на клиентских машинах, так как одна и та же программа предоставляет и клиентские и серверные функции.

Замечания для Linux (если вы используете RPM-пакет)

Если вы используете дистрибутив Linux, поддерживающий RPM-пакеты (SuSE, Fedora, Redhat и др.), то будет лучше произвести установку с помощью этого механизма. Самый простой способ -- найти уже существующий бинарный RPM-файл для вашего дистрибутива. Вы также можете создать свой собственный бинарный RPM-файл:

rpmbuild -tb openvpn-[version].tar.gz

Как только у вас будет rpm-файл, вы можете установить его обычным способом

rpm -ivh openvpn-[details].rpm

или при обновлении существующей установки

rpm -Uvh openvpn-[details].rpm

При установке OpenVPN из бинарного RPM-пакета необходимо удовлетворить зависимости:

  • openssl
  • lzo
  • pam

Кроме того, если вы собираете свой собственный бинарный RPM-пакет, существуют несколько дополнительных зависимостей:

  • openssl-devel
  • lzo-devel
  • pam-devel

Файл openvpn.spec содержит дополнительные замечания о сборке RPM-пакета для Red Hat Linux 9 или сборке без удовлетворения всех зависимостей.

Замечания для Linux (дистрибутивы без RPM)

Если у вас Debian, Gentoo или другой не-RPM дистрибутив Linux, используйте механизмы управления пакетами вашего дистрибутива, такие как apt-get в Debian или emerge в Gentoo.

Кроме того, можно установить OpenVPN в Linux с помощью универсального ./configure-метода. Для начала распакуйте tar.gz-файл:

tar xfz openvpn-[version].tar.gz

Затем перейдите в каталог верхнего уровня (распакованного архива) и выполните:

./configure
make
make install

Замечания для Windows

OpenVPN для Windows можно установить из самоустанавливающегося исполняемого файла, который необходимо взять на странице загрузки OpenVPN. Помните, что OpenVPN будет работать только на Windows 2000 и выше. Также следует отметить, что OpenVPN необходимо устанавливать и запускать под пользователем, имеющим права администратора (это ограничение накладывается Windows, а не OpenVPN). Ограничение можно обойти путем запуска OpenVPN в фоновом режиме в качестве службы, в этом случае даже без административных прав пользователи смогут получить доступ к VPN, когда он будет установлен. Более подробное обсуждение вопроса OpenVPN + ограничения в Windows.

OpenVPN также может быть установлен в Windows с графическим интерфейсом с помощью установочного пакета Mathias'а Sundman'а, который устанавливает и OpenVPN и GUI для Windows.

После окончания работы инсталлятора (в Windows) OpenVPN будет готов к использованию, а файлы с расширением . ovpn будут ассоциированы с OpenVPN. Запустить OpenVPN можно несколькими способами:

  • Щелкните правой кнопкой на файле конфигурации OpenVPN (.ovpn) и выберите Start OpenVPN on this configuration file. После запуска вы можете использовать F4 для выхода.
  • Запустить OpenVPN из окна командной строки с помощью команды: 
    openvpn myconfig.ovpn

    После запуска в окне командной строки OpenVPN может быть остановлен с помощью F4.

  • Запустить OpenVPN как службу, разместив один или несколько конфигурационных файлов .ovpn в \Program Files\OpenVPN\Config и запустив cлужбу OpenVPN (OpenVPN Service), которую можно контролировать из Пуск / Панель управления / Администрирование / Службы (Start Menu / Control Panel / Administrative Tools / Services).

Для Windows-версии OpenVPN также доступен графический интерфейс (GUI).

Дополнительные замечания по установке в Windows.

Замечания для Mac OS X

Angelo Laub и Dirk Theisen разработали OpenVPN GUI для OS X.

Другие операционные системы

Некоторые примечания для конкретных операционных систем доступны в файле INSTALL. В общем случае может быть использован метод

./configure
make
make install

или вы можете поискать порт или пакет OpenVPN, специфичный для вашей ОС (операционной системы) или дистрибутива.

Определение в каком режиме использовать VPN: в режиме моста или в режиме маршрутизации

Смотрите в FAQ обзор вопроса "Маршрутизация vs. Ethernet-мост" (Routing vs. Ethernet Bridging). Посмотрите также страницу о Ethernet-мостах в OpenVPN для получения более детальной информации.

В целом, для большинства маршрутизация будет являться наилучшим выбором, так как она является более эффективной и более простой в настройке (в плане конфигурирования OpenVPN), чем мост (bridging). Также, маршрутизация предоставляет более широкие возможности для выборочного контроля прав доступа на основе данных клиентов.

Я бы рекомендовал всегда использовать маршрутизацию, кроме случаев когда вам необходимы специальные функции, требующие моста, такие как:

  • VPN должен быть в состоянии обрабатывать не-IP протоколы, такие как IPX,
  • вы запускаете поверх VPN приложения, которые работают с использованием широковещательных пакетов (например, игры по локальной сети), или
  • вы хотели бы разрешить обзор общих ресурсов Windows в сетевом окружении через VPN без настройки Samba- или WINS- серверов.

Нумерация частных подсетей

Настройка VPN часто влечет за собой объединение частных сетей (private subnets), расположенных в разных местах.

Internet Assigned Numbers Authority (IANA) зарезервировала следующие три блока адресного пространства IP для частных сетей (описанные в RFC 1918):

10.0.0.0 10.255.255.255 (префикс 10/8)
172.16.0.0 172.31.255.255 (префикс 172.16/12)
192.168.0.0 192.168.255.255 (префикс 192.168/16)

Хотя адреса из этих блоков, как правило, могут без проблем использоваться в конфигурациях VPN, важно выбрать адреса, которые минимизируют вероятность конфликтов IP-адресов или подсетей между собой. Виды конфликтов, которые необходимо предотвратить:

  • конфликты разных сайтов, подключенных к VPN, которые используют одинаковую нумерацию своих сетей, или
  • подключения удаленного доступа с сайтов, которые используют частные подсети, конфликтующие с вашими VPN-подсетями.

В качестве примера предположим, что вы используете популярный диапазон 192.168.0.0/24 для нумерации вашей частной локальной сети. Вы пытаетесь подключиться к VPN из Интернет-кафе, которое использует те же адреса в своей Wi-Fi сети. У вас получится конфликт в маршрутизации, потому что ваша машина не будет знать к чему относится 192.168.0.1 -- к локальному Wi-Fi шлюзу или такому же адресу в VPN.

В качестве другого примера предположим, что вы хотите связать воедино множество сайтов с помощью VPN, но каждый сайт использует для адресации диапазон 192.168.0.0/24. Это не будет работать без добавления прослойки трансляции адресов с помощью NAT, потому что VPN не знает как маршрутизировать пакеты между несколькими сайтами, если эти сайты не используют однозначно идентифицирующие их адреса подсетей.

Наилучшим решением будет избегать использования адресов 10.0.0.0/24 и 192.168.0.0/24 для адресов в частных локальных сетях. Вместо этого используйте те адреса, которые имеют меньшую вероятность быть использованными в Wi-Fi кафе, аэропорте или гостинице, откуда можно было бы ожидать подключения в удаленном режиме. Лучшими кандидатами являются подсети в середине огромного сетевого блока 10.0.0.0/8 (например 10.66.77.0/24).

Чтобы избежать межсайтовых конфликтов с IP-нумерацией, всегда используйте уникальные адреса локальных подсетей.

Настройка вашего собственного центра сертификации (Certificate Authority, CA) и генерация сертификатов и ключей для OpenVPN-сервера и нескольких клиентов

Обзор

Первый шаг в построении конфигурации OpenVPN 2.0 заключается в создании инфраструктуры открытых ключей (Public Key Infrastructure, PKI). PKI состоит из:

  • отдельного сертификата (также известного как открытый ключ) и секретного ключа для каждого сервера и клиента, и
  • главного сертификата центра сертификации (Certificate Authority, CA) и ключа, который используется для подписи каждого сертификата для сервера и клиентов.

OpenVPN поддерживает двунаправленную аутентификацию на основе сертификатов, это означает что клиент должен проверять подлинность сертификата сервера, а сервер должен проверять подлинность сертификата клиента до того как они начнут доверять друг другу.

И сервер и клиент будет аутентифицировать друг друга, сначала проверив что представленный сертификат подписан центром сертификации (CA), а затем путем проверки информации в заголовках уже аутентифицированного сертификата, таких как "common name" сертификата (этот термин оставлен в тексте "как есть" по причине отсутствия общеупотрбительного варианта перевода, само же понятие в общем случае обозначает имя объекта, котрому выдается сертификат -- прим. перв.) сертификата и тип сертификата (клиент или сервер).

Эта модель безопасности с точки зрения VPN имеет ряд желательных функций:

  • Серверу необходим только свой сертификат/ключ -- у него нет необходимости знать индивидуальные сертификаты каждого клиента, который может подключиться к нему.
  • Сервер будет принимать только клиентов, чьи сертификаты были подписаны главным CA-сертификатом (который мы будем генерировать ниже). Поскольку сервер может выполнить эту проверку подписи без необходимости доступа непосредственно к закрытому ключу CA, есть возможность для CA-ключа (наиболее чувствительного ключа во всем PKI) находиться на совершенно другой машине, даже без сетевого подключения.
  • Если закрытый ключ скомпрометирован, его можно отключить, добавив его сертификат к CRL (certificate revocation list, список отозванных сертификатов). CRL позволяет выборочно отклонять скомпрометированные сертификаты без необходимости перестройки всего PKI.
  • Сервер может применять клиент-специфичные права доступа на основании встроенных областей сертификата, таких как Common Name.

Создание главного сертификата и ключа в Certificate Authority (CA)

В этом разделе мы будем генерировать главный CA-сертификат/ключ, сертификат/ключ сервера и сертификаты/ключи для 3-х отдельных клиентов.

Для управления PKI мы будем использовать набор скриптов, который идет в комплекте с OpenVPN.

Если вы используете Linux, BSD или UNIX-подобные ОС, откройте консоль и перейдите в подкаталог easy-rsa, который находится в распакованных файлах OpenVPN. Если OpenVPN у вас установлен из RPM-файла, каталог easy-rsa обычно можно найти в /usr/share/doc/packages/openvpn или /usr/share/doc/openvpn-2.0 (чтобы в будущем при обновлении OpenVPN не перезаписать свои изменения, будет лучше скопировать этот каталог в другое место, например, /etc/openvpn, прежде чем делать какие-либо действия в нем). Если вы делали установку из .tar.gz -файла, каталог easy-rsa будет находиться в каталоге верхнего уровня распакованного дерева исходных текстов.

Если вы используете Windows, откройте окно командной строки и перейдите в \Program Files\OpenVPN\easy-rsa. Запустите следующий пакетный (batch) файл для копирования файлов конфигурации на место (это приведет к перезаписи любого существующего vars.bat и openssl.cnf файлов):

init-config

Теперь необходимо отредактировать файл vars (называемый vars.bat в Windows) и установить параметры KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG и KEY_EMAIL. Не оставляйте любой из этих параметров пустым.

Далее инициализируем PKI. На Linux/BSD/Unix:

. ./vars
./clean-all
./build-ca

В Windows:

vars
clean-all
build-ca

Последняя команда (build-ca) создаст сертификат и ключ центра сертификации (CA), вызвав интерактивную команду openssl:

ai:easy-rsa # ./build-ca
Generating a 1024 bit RSA private key
............++++++
...........++++++
writing new private key to 'ca.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [KG]:
State or Province Name (full name) [NA]:
Locality Name (eg, city) [BISHKEK]:
Organization Name (eg, company) [OpenVPN-TEST]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:OpenVPN-CA
Email Address [me@myhost.mydomain]:

Обратите внимание, что в указанной выше последовательности большинство запрошенных параметров установлены в значения по умолчанию, взятые из файлов vars или vars.bat. Common name -- единственный параметр, который должен быть явно указан. В примере выше я использовал "OpenVPN-CA".

Генерация сертификата и ключа для сервера

Далее мы будем генерировать сертификат и закрытый ключ для сервера. На Linux/BSD/Unix:

./build-key-server server

В Windows:

build-key-server server

Как и на предыдущем шаге, большинство параметров могут быть оставлены в значениях по умолчанию. Когда будет запрошен Common name введите "server". Два других запроса требуют положительных ответов, «Sign the certificate? (Подписать сертификат?) [y/n]" и "1 out of 1 certificate requests certified, commit? (заверен 1 из 1 запросов на сертификацию, фиксировать?) [y/n]".

Создание сертификатов и ключей для 3-х клиентов

Процесс создания клиентских сертификатов очень похож на предыдущий шаг. На Linux/BSD/Unix:

./build-key client1
./build-key client2
./build-key client3

В Windows:

build-key client1
build-key client2
build-key client3

Замените использованный выше скрипт на build-key-pass если вы хотите защитить паролем ключи клиента .

Помните, что для каждого клиента необходимо обязательно ввести соответствующий Common name в ответ на запрос, то есть "client1", "client2", или "client3". Всегда используйте уникальные common name для каждого клиента.

Генерация параметров Diffie Hellman'а

Для сервера OpenVPN необходимо создать параметры Diffie Hellman'а. На Linux/BSD/Unix:

./build-dh

В Windows:

build-dh

Вывод:

ai:easy-rsa # ./build-dh
Generating DH parameters, 1024 bit long safe prime, generator 2
This is going to take a long time
.................+...........................................
...................+.............+.................+.........
......................................

Основные файлы

Теперь мы найдем наши вновь созданные ключи и сертификаты в подкаталоге keys. Вот разъяснение соответствующих файлов:

Имя файла Где необходим Назначение Секретный
ca.crt сервер + все клиенты Корневой CA-сертификат НЕТ
ca.key машина для подписи ключей Корневой CA-ключ ДА
dh{n}.pem только сервер Параметры Diffie Hellman'а НЕТ
server.crt только сервер Сертификат сервера НЕТ
server.key только сервер Ключ сервера ДА
client1.crt только клиент1 Сертификат клиента1 НЕТ
client1.key только клиент1 Ключ клиента1 ДА
client2.crt только клиент2 Сертификат клиента2 НЕТ
client2.key только клиент2 Ключ клиента2 ДА
client3.crt только клиент3 Сертификат клиента3 НЕТ
client3.key только клиент3 Ключ клиента3 ДА

Последний шаг в процессе создания ключа -- скопировать на каждую машину необходимые для неё файлы, позаботившись о том, чтобы секретные файлы копировались по защищенному каналу.

У вас может возникнуть один вопрос. Есть ли возможность настроить PKI без заранее созданного безопасного канала?

Ответ явно "да". В приведенном выше примере, мы для краткости сгенерировали все секретные ключи в одном и том же месте. С немного большими усилиями мы могли бы сделать это по-другому. Например, вместо создания клиентских сертификатов и ключей на сервере, клиенты могли бы сгенерировать свой закрытый ключ локально, а затем отправить запрос на подпись сертификата (Certificate Signing Request, CSR) на машину с ключем для подписи (key-signing machine). В свою очередь, машина с ключем для подписи могла бы обработать CSR и вернуть клиенту подписанный сертификат. Это можно было сделать даже не требуя, чтобы секретный .key-файл покидал жесткий диск машины, на которой он был сгенерирован.

Создание конфигурационных файлов для сервера и клиентов

Получение образцов файлов конфигурации

Лучше всего использовать примеры конфигурационных файлов OpenVPN в качестве отправной точки для создания своей собственной конфигурации. Эти файлы могут также быть найдены в

  • каталоге sample-config-files дерева исходных кодов OpenVPN
  • каталоге sample-config-files в /usr/share/doc/packages/openvpn или /usr/share/doc/openvpn-2.0, если вы производили установку из RPM-пакета
  • Пуск -> Программы -> OpenVPN -> OpenVPN Sample Configuration Files в Windows

Следует отметить, что в Linux, BSD, UNIX или подобных операционных системах примеры конфигурационных файлов названы server.conf и client.conf. В Windows они называются server.ovpn и client.ovpn.

Редактирование файла конфигурации сервера

Пример файла конфигурации сервера является идеальной отправной точкой для настройки сервера OpenVPN. Этот файл создает VPN с использованием виртуального TUN-интерфейса (работает в режиме маршрутизации), OpenVPN будет принимать клиентские подключения на 1194 UDP-порту (официальный номер порта для OpenVPN), и выдавать виртуальные адреса для подключаемых клиентов из подсети 10.8.0.0/24.

Прежде чем использовать пример файла конфигурации вы должны сначала изменить параметры ca, cert, key и dh таким образом, чтобы они указывали на файлы, которые вы сгенерировали выше в разделе про PKI.

На данный момент файл конфигурации сервера уже можно использовать, тем не менее, у вас может появиться желание еще больше приспособить его под свои задачи:

  • Если вы хотите использовать Ethernet-мост, вам необходимо заменить server и dev tun на, соответственно, server-bridge и dev tap.
  • Если вы хотите, чтобы ваш OpenVPN-сервер слушал TCP-порт вместо UDP-порта, используйте proto tcp вместо proto udp (если вы хотите чтобы OpenVPN слушал и UDP- и TCP-порт, необходимо запустить два отдельных экземпляра OpenVPN).
  • Если вы хотите использовать диапазон виртуальных IP-адресов, отличных от 10.8.0.0/24, вы должны изменить директиву server. Помните, что этот диапазон виртуальных IP-адресов должен быть частным диапазоном, который в настоящее время не используется в вашей сети.
  • Раскомментируйте директиву client-to-client, если вы хотите, чтобы клиенты могли подключаться друг к другу через VPN. По умолчанию клиенты смогут установить связь только с сервером.
  • Если вы используете Linux, BSD или Unix-подобные ОС, вы можете улучшить безопасность, раскомментировав директивы user nobody и group nobody.

Есть возможность запустить несколько экземпляров OpenVPN на одной машине, каждый из которых использует отдельный файл конфигурации, если вы:

  • Используете различные значения параметра port для каждого экземпляра (протоколы UDP и TCP используют различные пространства портов, поэтому вы можете запустить один демон прослушивающий 1194 порт UDP, а другой -- 1194 порт TCP).
  • Если вы используете Windows, каждая конфигурация OpenVPN должна иметь свой TAP-Win32 адаптер. Вы можете добавить дополнительные адаптеры, перейдя в Пуск / Программы / OpenVPN / Add a new TAP-Win32 virtual ethernet adapter.
  • Если вы запускаете несколько экземпляров OpenVPN из одного каталога, отредактируйте дерективы, которые создают файлы вывода таким образом, чтобы разные экземпляры OpenVPN не перезаписывали файлы друг друга. Это такие директивы как log, log-append, status и ifconfig-pool-persist

Редактирование файлов конфигурации клиента

Пример конфигурационного файла клиента (client.conf на Linux/BSD/Unix или client.ovpn на Windows) содержит те же значения для директив, которые встречаются в примере конфигурационного файла сервера.

  • Как и в случае с файлом конфигурации сервера, в первую следует отредактировать параметры ca, cert и key таким образом, чтобы они указывали на файлы, которые вы сгенерировали выше в разделе про PKI. Обратите внимание на то, что каждый клиент должен иметь свою собственную пару cert/key. Универсальным для всех клиентов и сервера OpenVPN является только файл в директиве ca.
  • Затем отредактируйте директиву remote, чтобы указать имя хоста / IP-адрес и номер порта сервера OpenVPN (если ваш OpenVPN-сервер будет работать на машине с одним NIC (network interface card, сетевой адаптер) позади файрвола/NAT-шлюза, используйте внешний IP-адрес шлюза и номер порта, которые настроены на шлюзе для пересылки на сервер OpenVPN).
  • Наконец, убедитесь, что директивы в файле конфигурации клиента соответствуют директивам, используемым в конфигурации сервера. В первую очередь необходимо обратить внимание на согласованность директив dev (tun или tap) и proto (UDP или TCP). Также убедитесь, что если вы используете директивы comp-lzo и fragment, то они должны присутствовать как в файле конфигурации клиента, так и сервера.

Запуск VPN и первоначальное тестирование подключения.

Запуск сервера

Во-первых, убедитесь что сервер OpenVPN будет доступен из Интернета. Это означает, что:

  • открыт 1194 UDP-порт на файрволе (или любой другой TCP/UDP-порт, который вы настроили), или
  • настроен переброс портов для перенаправления 1194 UDP-порта от файрвола/шлюза на машину с запущенным OpenVPN-сервером.

Далее, убедитесь, что TUN/TAP-интерфейс не фильтруется файрволом.

Для упрощения устранения неполадок лучше сначала запустить OpenVPN-сервер из командной строки (или щелкните правой кнопкой мыши на .ovpn-файле в Windows) вместо того чтобы запускать его как демон или службу:

openvpn [server config file]

Нормальный запуск сервера должен выглядеть примерно так (вывод будет различаться в зависимости от платформы):

Sun Feb  6 20:46:38 2005 OpenVPN 2.0_rc12 i686-suse-linux [SSL] [LZO] [EPOLL] built on Feb  5 2005
Sun Feb  6 20:46:38 2005 Diffie-Hellman initialized with 1024 bit key
Sun Feb  6 20:46:38 2005 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Sun Feb  6 20:46:38 2005 TUN/TAP device tun1 opened
Sun Feb  6 20:46:38 2005 /sbin/ifconfig tun1 10.8.0.1 pointopoint 10.8.0.2 mtu 1500
Sun Feb  6 20:46:38 2005 /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2
Sun Feb  6 20:46:38 2005 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:23 ET:0 EL:0 AF:3/1 ]
Sun Feb  6 20:46:38 2005 UDPv4 link local (bound): [undef]:1194
Sun Feb  6 20:46:38 2005 UDPv4 link remote: [undef]
Sun Feb  6 20:46:38 2005 MULTI: multi_init called, r=256 v=256
Sun Feb  6 20:46:38 2005 IFCONFIG POOL: base=10.8.0.4 size=62
Sun Feb  6 20:46:38 2005 IFCONFIG POOL LIST
Sun Feb  6 20:46:38 2005 Initialization Sequence Completed

Запуск клиента

Как и при конфигурации сервера, сначала лучше запустить OpenVPN-сервер из командной строки (или щелкнув правой кнопкой мыши на client.ovpn-файле в Windows), вместо того, чтобы запускать его как демон или как службу:

openvpn [client config file]

При обычном запуске клиента в Windows вывод будет похож на вывод сервера, приведенный выше, и должен заканчиваться сообщением Initialization Sequence Completed.

Теперь попробуйте запустить пинг от клиента через VPN. Если вы используете маршрутизацию (т.е. dev tun в файле конфигурации сервера), попробуйте:

ping 10.8.0.1

Если вы используете мост (т.е. dev tap в файле конфигурации сервера), попробуйте пинговать IP-адрес машины в Ethernet-сети сервера.

Если пинг успешно прошел, примите наши поздравления! Теперь у вас есть функционирующий VPN.

Поиск неисправностей

Если пинг не прошел или инициализация OpenVPN-клиента завершилась ошибкой, вот перечень основных симптомов и их решения:

  • Вы получаете сообщение об ошибке: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity). Эта ошибка указывает на то, что клиент не смог установить сетевое соединение с сервером.

    Решения:

    • Убедитесь в том, что клиент использует правильное имя хоста / IP-адрес и номер порта, которые позволят ему связаться с OpenVPN-сервером.
    • Если машина с OpenVPN-сервером имеет один сетевой интерфейс (single-NIC) и находится в защищенной локальной сети, убедитесь что вы корректно настроили правила переброса порта на шлюзе. Для примера предположим, что ваш OpenVPN-сервер имеет адрес 192.168.4.4 внутри защищенной файрволом сети и ожидает клиентских подключений на 1194 UDP-порту. NAT-шлюз обслуживает подсеть 192.168.4.x должен иметь правило проброса порта, которое говорит перебросить UDP-порт 1194 со своего общедоступного IP-адреса на 192.168.4.4.
    • Настройте файрвол сервера так, чтобы разрешить входящие подключения к UDP-порту 1194 (или любому другому TCP/UDP-порту, который вы указали в файле конфигурации OpenVPN-сервера).

  • Вы получаете сообщение об ошибке: Initialization Sequence Completed with errors -- Эта ошибка может произойти в Windows, если (а) у вас не работает служба DHCP-клиента, или (б) Вы используете некоторые сторонние персональные файрволы на XP SP2.

    Решение: Запустите службу DHCP-клиента и убедитесь, что вы используете персональный файрвол про который известно, что он корректно работает на XP SP2.

  • Вы получаете сообщение Initialization Sequence Completed, но пинг не проходит -- Как правило, это означает, что или на сервере или на клиенте файрвол блокирует сетевой трафик в VPN путем фильтрации на TUN/TAP-интерфейсе.

    Решение: Отключить в файрволе клиента (если таковой существует) фильтрацию на TUN/TAP интерфейсе на стороне клиента. Например, на Windows XP SP2 вы можете сделать это, перейдя в Центр обеспечения безопасности / Брандмауэр Windows / Дополнительно и сняв отметку на позиции, которая соответствует адаптеру TAP-Win32 (отключение в файрволе клиента фильтрации на TUN/TAP адаптере, как правило, разумно с точки зрения безопасности, так как вы, по существу, говорите файрволу не блокировать аутентифицированный VPN-трафик). Также убедитесь, что на сервере файрвол не фильтрует трафик (здесь речь идет о полном запрете на прохождение пакетов -- прим. перев.) на TUN/TAP-интерфейсе (сказав это, заметим, что избирательная фильтрация трафика с помощью файрвола на TUN/TAP-интерфейсе на стороне сервера может дать определенные преимущества в плане безопасности. Смотрите политики доступа ниже).

  • Процесс установки соединения останавливается при использовании в конфигурации proto udp, лог-файл сервера оканчивается такой строкой: 
    TLS: Initial packet from x.x.x.x:x, sid=xxxxxxxx xxxxxxxx

    однако, в лог-файле клиента нет соответствующей строки.

    Решение: У вас односторонняя связь от клиента к серверу. Направление от сервера к клиенту блокируется файрволом, обычно на стороне клиента. Файрвол может быть (а) личный программный файрвол, работающий на клиенте, или (б) шлюз (NAT-маршрутизатор) для клиента. Измените настройки файрвола, чтобы разрешить обратным UDP-пакетам сервера дойти до клиента.

Смотрите FAQ для получения дополнительной информации об устранении неполадок.

Настройка OpenVPN для автоматического запуска при старте системы

Отсутствие стандартов в этой области означает, что большинство операционных систем отличаются друг от друга в плане настройки автозапуска демонов/служб при загрузке системы. Лучшим способом иметь эту функцию настроенной по умолчанию является установка OpenVPN в виде пакета, например, с помощью RPM в Linux или с помощью программы установки в Windows.

Linux

При установке OpenVPN из RPM пакета в Linux будет установлен initsript. Initscript при своем запуске проведет поиск конфигурационных файлов с расширением .conf в /etc/openvpn, и, если они будут найдены, запустит отдельный демон OpenVPN для каждого файла.

Windows

В Windows инсталлятором будет установлен Service Wrapper, но его автозапуск будет по умолчанию отключен. Чтобы активировать его, зайдите в Панель управления / Администрирование / Службы, выберите службу OpenVPN, щелкните правой кнопкой мыши, выберите Свойства, и установите тип запуска Автоматический. Это настроит службу на автоматический запуск при следующей перезагрузке.

Будучи запущенным, OpenVPN Service Wrapper будет сканировать папку \Program Files\OpenVPN\Config на предмет наличия .ovpn-файлов конфигурации и запустит отдельный процесс OpenVPN для каждого файла.

Управление запущенным OpenVPN-процессом

Запуск в Linux/BSD/Unix

OpenVPN принимает несколько сигналов:

  • SIGUSR1 -- Условный перезапуск (Conditional restart), предназначенный для перезапуска без привилегий суперпользователя
  • SIGHUP -- Жесткий перезапуск (Hard restart)
  • SIGUSR2 -- Вывести статистику соединения в лог-файл или syslog
  • SIGTERM, SIGINT -- Выход

Чтобы знать куда отправлять сигнал, используйте директиву writepid для записи PID демона OpenVPN в файл (если вы запускаете OpenVPN с помощью initscript, то cценарий, возможно, уже добавил директиву --writepid в строку запуска OpenVPN).

Запуск в Windows как GUI

Смотрите OpenVPN GUI page.

Запуск в окне командной строки Windows

В Windows вы можете запустить OpenVPN, щелкнув правой кнопкой на файле конфигурации OpenVPN (.ovpn-файле) и выбрав "Start OpenVPN on this config file".

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

  • F1 -- Условный перезапуск (не закрывать/заново открывать TAP-адаптер)
  • F2 -- Показывает статистику соединения
  • F3 -- Жесткий перезапуск
  • F4 -- Выход

Запуск в Windows в качестве службы

Когда OpenVPN запускается в Windows как служба, им можно управлять:

  • С помощью менеджера управления службами (Панель управления / Администрирование / Службы), который дает контроль над запуском/остановкой.
  • Через интерфейс управления (см. ниже).

Изменение конфигурации работающего сервера

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

client-config-dir -- Эта директива устанавливает каталог конфигурации клиента, который OpenVPN сервер будет проверять при каждом входящем соединения, производя поиск клиент-специфичного файла конфигурации (см. man-страницу для получения дополнительной информации). Файлы в этом каталоге могут быть обновлены на лету, без перезагрузки сервера. Обратите внимание, что изменения в этом каталоге вступят в силу только для новых подключений, и не распространяются на существующие соединения. Если вы хотите, чтобы изменения в клиент-специфичном файле конфигурации немедленно вступили в силу для уже подключенного в настоящий момент клиента (или отключенного, но для которого сервер не уничтожил по тайтм-ауту соответствующий объект в памяти (but where the server has not timed-out its instance object)), уничтожьте объект клиента с помощью интерфейса управления (см. ниже). Это заставит клиента переподключится и сервером будет использован новый файл из client-config-dir.

crl-verify -- Эта директива указывает на файл, содержащий Список отозванных сертификатов (Certificate Revocation List), который описан ниже, в разделе Отзыв сертификатов. CRL-файл может быть изменен на лету, и для новых подключений изменения вступят в силу немедленно, а для существующих соединений это произойдет во время пересогласования SSL/TLS-канала (происходит по умолчанию раз в час). Если вы хотите отключить подключенного в настоящий момент клиента, чей сертификат только что был добавлен в CRL, используйте интерфейс управления (см. ниже).

Файл состояния

По умолчанию файл server.conf содержит строку

status openvpn-status.log

которая указывает OpenVPN выводить список текущих клиентских подключений в файл openvpn-status.log раз в минуту.

Использование интерфейса управления

Интерфейс управления OpenVPN позволяет получить больше контроля над работающим процессом OpenVPN. Вы можете использовать интерфейс управления непосредственно, подключаясь с помощью telnet к порту интерфейса управления или косвенно, с помощью OpenVPN GUI, который сам подключается к интерфейсу управления.

Чтобы включить интерфейс управления на любом сервере или клиенте OpenVPN, добавьте в файл конфигурации:

management localhost 7505

Эта директива предписывает OpenVPN ждать подключений к интерфейсу управления клиентами на TCP-порту 7505 (порт 7505 является произвольным выбором -- вы можете использовать любой свободный порт).

Как только OpenVPN запущен, вы можете подключиться к интерфейсу управления, используя telnet-клиент. Например:

ai:~ # telnet localhost 7505
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
>INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info
help
Management Interface for OpenVPN 2.0_rc14 i686-suse-linux [SSL] [LZO] [EPOLL] built on Feb 15 2005
Commands:
echo [on|off] [N|all]  : Like log, but only show messages in echo buffer.
exit|quit              : Close management session.
help                   : Print this message.
hold [on|off|release]  : Set/show hold flag to on/off state, or
                         release current hold and start tunnel.
kill cn                : Kill the client instance(s) having common name cn.
kill IP:port           : Kill the client instance connecting from IP:port.
log [on|off] [N|all]   : Turn on/off realtime log display
                         + show last N lines or 'all' for entire history.
mute [n]               : Set log mute level to n, or show level if n is absent.
net                    : (Windows only) Show network info and routing table.
password type p        : Enter password p for a queried OpenVPN password.
signal s               : Send signal s to daemon,
                         s = SIGHUP|SIGTERM|SIGUSR1|SIGUSR2.
state [on|off] [N|all] : Like log, but show state history.
status [n]             : Show current daemon status info using format #n.
test n                 : Produce n lines of output for testing/debugging.
username type u        : Enter username u for a queried OpenVPN username.
verb [n]               : Set log verbosity level to n, or show if n is absent.
version                : Show current version number.
END
exit
Connection closed by foreign host.
ai:~ #

Для получения дополнительной информации см. Документацию по OpenVPN Management Interface.

Расширение границ VPN для включения дополнительных машин из подсетей на стороне клиента или сервера.

Включение нескольких машин на стороне сервера при использовании маршрутизируемого VPN (dev tun)

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

Чтобы проиллюстрировать это примером, предположим, что в локальной сети на стороне сервера используется подсеть 10.66.0.0/24 и для пула VPN-адресов используется 10.8.0.0/24, о чем говорится в директиве server в файле конфигурации OpenVPN-сервера.

Во-первых, вы должны сообщить VPN-клиентам, что подсеть 10.66.0.0/24 доступна через VPN. Это легко можно сделать с помощью следующих директив в конфигурационном файле сервера:

push "route 10.66.0.0 255.255.255.0"

Далее, необходимо настроить на LAN-шлюзе в сети сервера маршрут для маршрутизации пакетов, предназначенных для подсети VPN-клиентов (10.8.0.0/24) через OpenVPN-сервер (это необходимо только тогда, когда сервер OpenVPN и LAN-шлюз -- разные машины).

Убедитесь, что вы включили пересылку для IP и TUN/TAP на машине OpenVPN-сервера.

Включение нескольких машин на стороне сервера при использовании VPN в режиме моста (dev tap)

Одним из преимуществ использования Ethernet-моста является то, что вы получите его просто так (бесплатно), без необходимости какой-либо дополнительной настройки.

Включение нескольких машин на стороне клиента при использовании маршрутизируемого VPN (dev tun)

В типичных сценариях подключения удаленного или мобильного клиента ("road-warrior" в оригинале -- прим. перев.) клиентская машина подключается к VPN как одна машина (single machine). Но, предположим, что клиентская машина является шлюзом для локальной сети (например, для домашнего офиса), и вы хотели бы, чтобы каждая машина в локальной сети клиента имела возможность использовать VPN.

Допустим, что локальная сеть клиента использует адреса 192.168.4.0/24 и что VPN-клиент использует сертификат с common name client2. Наша цель заключается в настройке VPN так, чтобы любая машина из сети клиента могла общаться с любой машиной в сети сервера через VPN.

Существуют некоторые основные предварительные требования, которые должны быть выполнены:

  • Подсеть клиента (192.168.4.0/24 в нашем примере) не должна быть экспортирована в VPN сервером или другим клиентом, сайты которых используют подсеть с таким же адресом. Каждая подсеть, которая соединяется с VPN с помощью маршрутизации, должна быть уникальной.
  • Клиент должен иметь уникальный Common Name в своем сертификате ("client2" в нашем примере), и флаг duplicate-cn не должен быть использован в файле конфигурации OpenVPN-сервера.

Во-первых, убедитесь, что на клиентской машине включена пересылка для IP и TUN/TAP.

Далее, мы совершим необходимые изменения в конфигурации на стороне сервера. Если файл конфигурации сервера в настоящее время не содержит директивы для определения каталога конфигурации клиента, добавьте её:

client-config-dir ccd

В приведенной выше директиве, ccd должно быть именем каталога, который был предварительно создан в рабочем каталоге по умолчанию демона OpenVPN-сервера. Как правило, в Linux это /etc/openvpn, в Windows -- \Program Files\OpenVPN\config. Когда новый клиент соединяется с сервером OpenVPN, демон будет проверять этот каталог на предмет наличия файла, имя которого соответствует common name подключающегося клиента. Если соответствующий файл найден, он будет прочитан и обработан для получения дополнительных конфигурационных директив, которые будут применены к этому клиенту.

Следующим шагом является создание файла с именем client2 в ccd-каталоге. Этот файл должен содержать строку:

iroute 192.168.4.0 255.255.255.0

Это скажет OpenVPN-серверу о том, что пакеты для подсети 192.168.4.0/24 должны быть направлены через client2 (should be routed to client2).

Затем добавьте следующую строку в основной конфигурационный файл сервера (не файл ccd/client2):

route 192.168.4.0 255.255.255.0

Вы можете спросить, зачем использовать избыточные объявления: route и iroute? Причина в том, что route управляет маршрутизацией от ядра к серверу OpenVPN (через интерфейс TUN), в то время как iroute контролирует маршрутизацию от сервера OpenVPN к удаленным клиентам. Необходимо и то, и другое.

Затем спросите себя, хотите ли вы разрешить прохождение сетевого трафика между подсетью клиента client2 (192.168.4.0/24) и другими клиентами сервера OpenVPN? Если да, то добавьте следующие строки в файл конфигурации сервера.

client-to-client
push "route 192.168.4.0 255.255.255.0"

Это приведет к тому, что OpenVPN-сервер будет сообщать о подсети клиента client2 другим подключаемым клиентам.

Последний шаг, (который часто забывают) -- это добавить на LAN-шлюзе сервера маршрут, который направит пакеты для сети 192.168.4.0/24 через машину с OpenVPN-сервером (это не нужно будет делать в том случае, если машина с OpenVPN-сервером является шлюзом для локальной сети сервера). Предположим, что вы пропустили этот шаг и пытаетесь пинговать машину в локальной сети сервера (не сам OpenVPN-сервер) с адресом 192.168.4.8. Исходящий пинг, вероятно, достигнет машины, но она не будет знать куда отправлять ответ на пинг, потому что не имеет понятия как достигнуть сети 192.168.4.0/24. Эмпирическое правило для таких случаев: если вы маршрутизируете через VPN пакеты для целой сети (когда VPN-сервер и LAN-шлюз не являются одной и той же машиной), убедитесь, что шлюз для локальной сети перенаправляет пакеты для всех VPN-подсетей на машину с VPN-сервером.

Аналогичным образом, если клиентская машина с запущенным OpenVPN также не является шлюзом для своей сети, тогда на шлюзе для локальной сети клиента должны присутствовать маршруты, которые направляют весь трафик для сетей, которые должны быть доступны через VPN на машину OpenVPN-клиента.

Включение нескольких машин на стороне клиента при использовании VPN в режиме моста (dev tap)

Для этого требуется более сложная настройка (может быть, не такая сложная на практике, но более сложная в объяснении):

Передача клиентам DHCP-опций

Сервер OpenVPN может передавать клиентам DHCP-опции, такие как адреса DNS- и WINS-серверов (с некоторыми оговорками). Windows-клиенты могут принимать DHCP-опции изначально, в то время как не-Windows-клиенты могут принимать их с помощью клиентского up-скрипта, который анализирует список переменных окружения foreign_option_n. Для получения документации и примеров скриптов по использованию foreign_option_n на не-Windows системах смотрите man-страницу или архивы листа рассылки openvpn-users.

Предположим, например, что вы хотите, чтобы подключающиеся клиенты использовали внутренний DNS-сервер с адресом 10.66.0.4 или 10.66.0.5 и WINS-сервер с адресом 10.66.0.8. Добавьте это к конфигурации OpenVPN-сервера:

push "dhcp-option DNS 10.66.0.4"
push "dhcp-option DNS 10.66.0.5"
push "dhcp-option WINS 10.66.0.8"

Чтобы проверить работоспособность этой функции в Windows, выполните следующее из окна командной строки после подключения машины к OpenVPN-серверу:

ipconfig /all

Для TAP-Win32-адаптера должны быть видны DHCP-опции, которые были переданы сервером.

Настройка клиент-специфичных правил и политик доступа

Предположим, мы создаем VPN в организации и хотели бы установить отдельные политики доступа для 3-х различных классов пользователей:

  • Системные администраторы - Полный доступ ко всем машинам в сети
  • Сотрудники - Доступ только к Samba и e-mail-серверу
  • Поставщики (Contractors) - Доступ к только специальному серверу

Основной подход, который мы будем применять это (а) изоляция каждого класса пользователей в свой собственный диапазон виртуальных IP-адресов, и (б) контроль доступа к машинам, устанавливая правила файрвола, которые ограничивают доступ на основании виртуального IP-адреса клиента.

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

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

Во-первых, давайте создадим карту распределения виртуальных IP-адресов в зависимости от класса пользователей:

Класс Виртуальный IP-диапазон Допустимый режим достапу к LAN Common Names
Сотрудники 10.8.0.0/24 Samba/email-сервер (10.66.4.4) [разные]
Системные администраторы 10.8.1.0/24 Вся подсеть (10.66.4.0/24) sysadmin1
Поставщики 10.8.2.0/24 Сервер для поставщиков (10.66.4.12) contractor1, contractor2

Далее, давайте переведем эту карту в конфигурацию OpenVPN-сервера. Прежде всего, убедитесь, что вы следовали указанным выше шагам для обеспечения доступности сети 10.66.4.0/24 для всех клиентов (сначала мы настроили маршрутизацию чтобы разрешить доступ клиентам ко всей подсети 10.66.4.0/24, затем мы будем накладывать ограничения на доступ, используя правила файрвола для реализации приведенной выше таблицы политик).

Во-первых, определим статический номер нашего tun-интерфейса, чтобы в будущем было возможно ссылаться на него в правилах файрвола (речь идет о цифре 0 в названии интерфейса -- прим. перев.):

dev tun0

Обозначим адресный пул для сотрудников в файле конфигурации сервера:

server 10.8.0.0 255.255.255.0

Добавим маршруты на диапазоны IP-адресов системного администратора и поставщиков:

route 10.8.1.0 255.255.255.0
route 10.8.2.0 255.255.255.0

Поскольку мы будем назначать фиксированные IP-адреса для конкретных системных администраторов и поставщиков, используем каталог конфигурации клиента (client configuration directory, ccd):

client-config-dir ccd

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

ccd/sysadmin1

ifconfig-push 10.8.1.1 10.8.1.2

ccd/contractor1

ifconfig-push 10.8.2.1 10.8.2.2

ccd/contractor2

ifconfig-push 10.8.2.5 10.8.2.6

Каждая пара адресов в Ifconfig-push соответствует виртуальным IP-адресам конечных точек (клиента и сервера). Чтобы сохранить совместимость с Windows-клиентами и драйвером TAP-Win32 эти адреса должны быть взяты из следующих друг за другом подсетей с маской /30 . В частности, последний октет в IP-адресе каждой пары конечных точек должен быть взят из этого набора:

[  1,  2] [  5,  6] [  9, 10] [ 13, 14] [ 17, 18]
[ 21, 22] [ 25, 26] [ 29, 30] [ 33, 34] [ 37, 38]
[ 41, 42] [ 45, 46] [ 49, 50] [ 53, 54] [ 57, 58]
[ 61, 62] [ 65, 66] [ 69, 70] [ 73, 74] [ 77, 78]
[ 81, 82] [ 85, 86] [ 89, 90] [ 93, 94] [ 97, 98]
[101,102] [105,106] [109,110] [113,114] [117,118]
[121,122] [125,126] [129,130] [133,134] [137,138]
[141,142] [145,146] [149,150] [153,154] [157,158]
[161,162] [165,166] [169,170] [173,174] [177,178]
[181,182] [185,186] [189,190] [193,194] [197,198]
[201,202] [205,206] [209,210] [213,214] [217,218]
[221,222] [225,226] [229,230] [233,234] [237,238]
[241,242] [245,246] [249,250] [253,254]

На этом конфигурирование OpenVPN окончено. Последним шагом является добавление правил файрвола для завершения построения политик доступа. В этом примере мы будем использовать синтаксис iptables:

#Правило для сотрудников
iptables -A FORWARD -i tun0 -s 10.8.0.0/24 -d 10.66.4.4 -j ACCEPT

# Правило для сисадмина
iptables -A FORWARD -i tun0 -s 10.8.1.0/24 -d 10.66.4.0/24 -j ACCEPT

# Правило для поставщиков
iptables -A FORWARD -i tun0 -s 10.8.2.0/24 -d 10.66.4.12 -j ACCEPT

Использование альтернативных методов аутентификации

OpenVPN 2.0 включает в себя функцию, которая позволяет OpenVPN-серверу безопасно получить имя пользователя и пароль от подключающегося клиента и использовать эту информацию в качестве основы для аутентификации клиента.

Чтобы использовать этот метод аутентификации, сначала добавьте в конфигурацию клиента директиву auth-user-pass. Она укажет OpenVPN-клиенту запросить у пользователя имя пользователя / пароль и передать его на сервер по защищенному TLS-каналу.

Затем настройте сервер на использование плагина аутентификации, который может быть скриптом, общим объектом (shared object) или DLL. Каждый раз, когда клиент VPN будет пытаться подключиться, сервер OpenVPN будет вызывать плагин, передавая ему имя пользователя / пароль, введенные на стороне клиента. Плагин аутентификации с помощью возвращаемого значения (неудача (1) или успех (0)) может управлять тем, позволит ли OpenVPN-сервер подключиться клиенту или нет.

Использование плагинов в виде скриптов

Плагины в виде скриптов можно использовать путем добавления в конфигурационный файл сервера директивы auth-user-pass-verify. Например:

auth-user-pass-verify auth-pam.pl via-file

укажет OpenVPN использовать perl-скрипт auth-pam.pl для аутентификации подключающихся клиентов по имени пользователя / паролю. Для получения дополнительной информации смотрите описание auth-user-pass-verify в man-странице.

Скрипт auth-pam.pl можно найти в каталоге sample-scripts в исходных текстах OpenVPN. Он выполняет проверку подлинности пользователей на Linux-сервере с помощью модуля PAM-аутентификации, которая, в свою очередь, реализует механизм теневых паролей, RADIUS- или LDAP-аутентификацию. auth-pam.pl предназначен в первую очередь для демонстрационных целей. Для реальной PAM-аутентификации используйте shared object плагин openvpn-auth-pam, описанный ниже.

Использование плагинов в виде общих объектов (Shared Object) или DLL

Плагины в виде общих объектов или DLL обычно представляют собой скомпилированные модули на Си, которые загружаются OpenVPN-сервером при запуске. Например, если вы используете OpenVPN в виде RPM-пакета в Linux, плагин openvpn-auth-pam должен быть уже собран. Чтобы его использовать, добавьте в конфигурационный файл сервера:

plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so login

Это скажет OpenVPN-серверу проверять имя пользователя / пароль, введенные клиентом, используя PAM-модуль login.

Для реального производственного использования лучше использовать openvpn-auth-pam-плагин, поскольку он имеет несколько преимуществ по сравнению со скриптом auth-pam.pl:

  • Плагин openvpn-auth-pam использует модель разделения привилегий при выполнении (split-privilege execution model) для большей безопасности. Это означает, что сервер OpenVPN может работать с пониженными привилегиями, используя директивы user nobody, group nobody и chroot, и при этом будет иметь возможность проверять подлинность пользователей в файле теневых (shadow) паролей, читать который может только root.
  • OpenVPN может передать имя пользователя / пароль плагину через виртуальную память, что является более правильным способом, нежели чем через файл или переменную окружения, поскольку это более предпочтительно для локальной безопасности на серверной машине.
  • Откомпилированные плагины, написанные на Си, обычно работают быстрее чем скрипты.

Если вы хотите получить дополнительную информацию о разработке собственных плагинов для работы с OpenVPN, см. файлы README в каталоге plugin в архиве с исходным кодом OpenVPN.

Чтобы в Linux собрать плагин openvpn-auth-pam, в каталоге с исходным кодом OpenVPN перейдите в каталог plugin/auth-pam и запустите make.

Использование имени пользователя / пароля в качестве единственной формы проверки подлинности клиента

По умолчанию при использовании на сервере auth-user-pass-verify или плагина для проверки имени пользователя / пароля происходит двойная аутентификация, требующая успешной аутентификации и по клиентскому сертификату, и по имени пользователя / паролю для того, чтобы клиенту пройти проверку подлинности.

Хотя это и не рекомендуется с точки зрения безопасности, есть возможность отключить использование клиентских сертификатов и использовать аутентификацию только по имени пользователя / паролю. На сервере:

client-cert-not-required

При такой конфигурации также обычно необходимо установить директиву:

username-as-common-name

которая скажет серверу использовать имя пользователя для целей индексирования, также как он использовал бы Common Name клиента, который был бы аутентифицирован с помощью клиентского сертификата.

Обратите внимание, что client-cert-not-required не устранит необходимость в сертификате сервера, поэтому клиент, подключающийся к серверу, который использует client-cert-not-required, может удалить директивы cert и key из файла конфигурации клиента, но не директиву ca, так как это необходимо клиенту для проверки сертификата сервера.

Как добавить двойную аутентификации в конфигурацию OpenVPN, используя клиентские смарт-карты

См. также статью: The OpenVPN Smartcard HOWTO

О двойной аутентификации

Двойная аутентификация представляет собой метод проверки подлинности, который сочетает в себе два элемента: "что-то у вас есть" и "что-то вы знаете".

"Что-то у вас есть" должно быть устройством, которое не может быть дублировано, такое устройство может быть криптографическим токеном, который содержит закрытый секретный ключ. Этот закрытый ключ генерируется внутри устройства и никогда не покидает его. Если пользователь, обладая этим токеном, пытается получить доступ к защищенному сервису в удаленной сети, то процесс авторизации, который разрешает или запрещает доступ к сети, с высокой степенью уверенности может установить, что пользователь, который хочет получить доступ, физически владеет известным, сертифицированным токеном.

"Что-то вы знаете" может быть паролем, который предоставлен криптографическим устройством. Не введя (не предоставив) правильный пароль вы не можете получить доступ к закрытому секретному ключу. Еще одна особенность криптографических устройств заключается в запрещении использования закрытого секретного ключа, если неправильный пароль был введен более чем допустимое число раз. Такое поведение гарантирует, что если пользователь потерял устройство, то для другого человека будет невозможно его использовать.

Криптографические устройства обычно называются "смарт-карты" (smart cards) или "токены" (tokens) и используются совместно с PKI. VPN сервер может проверить сертификат X.509 и убедиться, что пользователь имеет соответствующий закрытый секретный ключ. Так как устройство не может быть дублировано и требует правильный пароль, сервер имеет возможность проверить подлинность пользователя с высокой степенью достоверности.

Двойная аутентификация гораздо устойчивее чем аутентификация на основе пароля, потому что, в худшем случае, только один человек может одновременно использовать криптографический токен. Когда ресурсы защищены с помощью только парольной аутентификации, пароли могут быть угаданы и могут стать доступными другим пользователям, так что, в худшем случае, бесконечное число людей могут пытаться получить несанкционированный доступ.

Если вы храните секретный закрытый ключ в файле, ключ обычно зашифрован паролем. Проблемой такого подхода является то, что зашифрованный ключ уязвим перед атаками на расшифровку или перед шпионскими/вредоносными программами, запущенными на клиентской машине. В отличие от криптографического устройства, файл не может стереть себя автоматически после нескольких неудачных попыток расшифровки.

Что такое PKCS#11?

Этот стандарт определяет API-интерфейс, называемый Cryptoki, на устройства, которые содержат в себе криптографическую информацию и выполняют криптографические функции. Cryptoki (произносится как "crypto-key", является сокращением от cryptographic token interface (криптографический интерфейс токенов)), следует простому объектно-ориентированному подходу, который преследует цели технологической независимости (любого типа устройств) и совместного использования ресурсов (множество приложений получают доступ ко множеству устройств), предоставляя приложениям всеобщее, логическое представление устройств, называющихся криптографический токен.

Источник: компания RSA Security Inc http://www.rsasecurity.com/rsalabs/pkcs/pkcs-11.

Подводя итог, можно сказать, что PKCS#11 является стандартом, который может использоваться прикладным программным обеспечением для доступа к криптографическим токенам, таким как смарт-карты и другие устройства. Большинство производителей устройств предоставляют библиотеку, которая реализует интерфейс провайдера PKCS#11 -- эта библиотека может использоваться приложениями для доступа к этим устройствам. PKCS#11 является кросс-платформенным и независимым от производителя устройства стандартом.

Поиск библиотеки провайдера PKCS#11

Первое, что вам нужно сделать, это найти библиотеку провайдера (provider library), она должна быть установлена с драйверами устройства. Каждый производитель имеет свои собственные библиотеки. Например, в Unix провайдер OpenSC PKCS#11 находится в /usr/lib/pkcs11/opensc-pkcs11.so, а в Windows -- в opensc-pkcs11.dll.

Как настроить криптографический токен

Вы должны следовать процедуре регистрации:

  • Инициализируйте токен PKCS#11.
  • Сгенерируйте пару RSA-ключей в PKCS#11-токене.
  • Создайте запрос на сертификацию (certificate request) на основе пары ключей, чтобы сделать это вы можете использовать OpenSC и OpenSSL.
  • Отправьте запрос на сертификацию в центр сертификации и получите сертификат.
  • Загрузите сертификат на токен, обратив при этом внимание на то, что атрибуты идентификатор (id) и метка (label) у сертификата должны совпадать с такими же атрибутами у закрытого ключа.

Настроенный токен -- это токен, содержащий объект закрытого ключа и объект сертификата, у которых одинаковое значение атрибутов идентификатора и метки.

Easy-RSA 2.0 -- простая утилита регистрации (сертификатов), которая является частью OpenVPN 2.1. Следуйте инструкциям в файле README, а затем используйте pkitool для того, чтобы произвести регистрацию.

Инициализируйте токен с помощью следующей команды:

$ ./pkitool --pkcs11-slots /usr/lib/pkcs11/
$ ./pkitool --pkcs11-init /usr/lib/pkcs11/

Зарегистрируйте сертификат с помощью следующей команды:

$ ./pkitool --pkcs11 /usr/lib/pkcs11/

Как изменить конфигурацию OpenVPN так, чтобы использовать криптографические токены

Чтобы использовать функции PKCS#11 у вас должен быть OpenVPN 2.1 или выше. Вы можете получить последнюю бета-версию здесь: http://openvpn.net/download.html.

Определение нужного объекта

Каждый PKCS#11-провайдер может поддерживать несколько устройств. Для того, чтобы просмотреть список доступных объектов можно использовать следующую команду:

$ openvpn --show-pkcs11-ids /usr/lib/pkcs11/

The following objects are available for use. (Следующие объекты доступны для использования.)
Each object shown below may be used as parameter to (Каждый объект, показанный ниже, может быть использован в качестве параметра для)
--pkcs11-id option please remember to use single quote mark. (опции --pkcs11-id, пожалуйста, не забывайте использовать одинарные кавычки)

Certificate
       DN:             /CN=User1
       Serial:         490B82C4000000000075
       Serialized id:  aaaa/bbb/41545F5349474E415455524581D2A1A1B23C4AA4CB17FAF7A4600

Каждая пара сертификат/закрытый ключ обладают своей уникальной строкой "Serialized id". Строка "serialized id" запрашиваемого сертификата должна быть указана в опции pkcs11-id с использованием одинарных ковычек.

pkcs11-id 'aaaa/bbb/41545F5349474E415455524581D2A1A1B23C4AA4CB17FAF7A4600'

Использование OpenVPN с PKCS#11

Типичный набор опций OpenVPN для PKCS#11
pkcs11-providers /usr/lib/pkcs11/
pkcs11-id 'aaaa/bbb/41545F5349474E415455524581D2A1A1B23C4AA4CB17FAF7A4600'

При этом будет выбран объект, который соответствует строке pkcs11-id.

Расширенные опции OpenVPN для PKCS#11
pkcs11-providers /usr/lib/pkcs11/provider1.so /usr/lib/pkcs11/provider2.so
pkcs11-id 'aaaa/bbb/41545F5349474E415455524581D2A1A1B23C4AA4CB17FAF7A4600'
pkcs11-pin-cache 300
daemon
auth-retry nointeract
management-hold
management-signal
management 127.0.0.1 8888
management-query-passwords

Это позволит загрузить в OpenVPN два провайдера, использующих сертификат, указанный в опции pkcs11-id, и использовать интерфейс управления для запроса пароля. Демон будет переведен в остановленное состояние (resume into hold state) в случае если токен окажется недоступным. Токен будет использоваться в течение 300 секунд, после чего пароль будет повторно запрошен; сессия будет завершена в том случае, если будет завершена управляющая сессия.

Соображения по реализации PKCS#11

Многие провайдеры PKCS#11 используют потоки, поэтому если вы собираетесь использовать PKCS#11, то настоятельно рекомендется перейти на Native POSIX Thread Library (NPTL), включенную в glibc, чтобы избежать проблем, связанных с реализацией LinuxThreads (setuid, chroot) .

Провайдер OpenSC PKCS#11

OpenSC PKCS#11-провайдер находится в /usr/lib/pkcs11/opensc-pkcs11.so в Unix или в opensc-pkcs11.dll в Windows.

Разница между PKCS#11 и Microsoft Cryptographic API (CryptoAPI)

PKCS#11 является свободным, кросс-платформенным и не зависящим от производителя стандартом. CryptoAPI является Microsoft-специфичным API. Большинство производителей смарт-карт обеспечивают поддержку обоих интерфейсов. В Windows пользователь должен выбрать, какой интерфейс использовать.

Текущая реализация OpenVPN, используящая MS CryptoAPI (cryptoapicert-опцию) работает хорошо до тех пор, пока вы не запускаете OpenVPN как сервис. Если вы хотите запустить OpenVPN с правами администратора как сервис, то эта реализация (implementation) не будет работать с большинством смарт-карт из-за следующих причин:

  • Большинство провайдеров смарт-карт не загружают сертификаты в хранилище локального компьютера, так что реализация не сможет получить доступ к сертификату пользователя.
  • Если клиент OpenVPN работает как сервис без прямого взаимодействия с конечными пользователями, служба не может запросить у пользователя пароль для смарт-карты, в результате чего процесс проверки пароля в смарт-карте заканчивается ошибкой.

Используя интерфейс PKCS#11, вы можете использовать смарт-карты вместе с OpenVPN в любой реализации, так как PKCS#11 не обращается к хранилищам Microsoft и не требует обязательного прямого взаимодействия с конечным пользователем.

Маршрутизация всего клиентского трафика (включая веб-трафик) через VPN

Обзор

По умолчанию, когда клиент OpenVPN активен, только сетевой трафик к и от сайта OpenVPN-сервера идет через VPN. Например, обычный просмотр веб-страниц будет осуществляться через прямое подключение (к Интернету -- прим. перев.) в обход VPN.

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

Реализация

Добавьте следующие директивы в файл конфигурации сервера:

push "redirect-gateway def1"

Если ваш VPN работает через беспроводную сеть, где сервер и все клиенты находятся в одной и той же беспроводной подсети, добавьте флаг local:

push "redirect-gateway local def1"

Передача клиенту опции redirect-gateway заставит весь IP-трафик, порождаемый на клиентской машине, пройти через сервер OpenVPN. Сервер должен быть настроен обработку этого трафика каким-нибудь образом, например, путем отправки в Интернет через NAT, или маршрутизацию через HTTP-прокси сайта сервера.

В Linux вы можете использовать команду вроде этой, чтобы направить трафик клиента в Интернет через NAT:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Эта команда предполагает, что VPN-подсеть имеет адрес 10.8.0.0/24 (взято из директивы server конфигурации сервера OpenVPN) и что локальный интерфейс Ethernet является eth0.

Когда используется redirect-gateway, OpenVPN-клиенты будут направлять DNS-запросы через VPN и VPN-сервер должны уметь обрабатывать их. Это может быть достигнуто путем передачи подключающимся клиентам адреса DNS-сервера, который заменит их обычные настройки для DNS-сервера пока VPN будет активным. Например:

push "dhcp-option DNS 10.8.0.1"

настроит Windows-клиентов (или не-Windows-клиентов при дополнительной работе над скриптами на стороне сервера) на использование 10.8.0.1 в качестве DNS-сервера. Любой адрес, доступный для клиентов, может быть использован в качестве адреса DNS-сервера.

Предостережения

Перенаправление всего сетевого трафика через VPN не является совсем беспроблемным делом. Вот несколько типичных подводных камней, чтобы вы были в курсе:

  • Многие подсоединенные к Интернет машины с OpenVPN-клиентом будут периодически взаимодействовать с сервером DHCP, чтобы возобновить аренду своих IP-адресов. Опция redirect-gateway может мешать клиенту связаться с локальным DHCP-сервером (потому что DHCP-сообщения будут направляться через VPN), приводя к потере аренды IP-адреса.
  • Имеются проблемы в отношении передачи DNS-адресов Windows-клиентам.
  • Скорость просмотра веб-страниц на клиенте будет заметно медленнее.

Более подробную информацию о механике директивы redirect-gateway см. в man-странице.

Запуск OpenVPN-сервера на динамическом IP-адресе.

Хотя OpenVPN-клиенты с динамическим IP-адресом могут легко получить доступ к серверу без каких-либо специальных настроек, все становится интереснее, когда сам сервер находится на динамическом адресе. Хотя OpenVPN не имеет проблем с обработкой ситуации, когда у сервера динамический адрес, требуются некоторые дополнительные настройки.

Первым шагом будет получить динамический DNS-адрес, который может быть настроен «следовать» за сервером каждый раз, как изменится IP-адрес сервера. Существует несколько провайдеров службы динамического DNS, таких как dyndns.org.

Следующим шагом является создание механизма, который каждый раз, как только меняется IP-адрес сервера, быстро обновляет динамическое DNS-имя новым IP-адресом, что позволяет клиентам находить сервер на его новом IP-адресе. Есть два основных способа сделать это:

  • Использование NAT-маршрутизатора с поддержкой динамического DNS (например, Linksys BEFSR41). Большинство широко распространенных недорогих NAT-маршрутизаторов имеют возможность обновления динамического DNS-имени каждый раз, когда от Интернет-провайдера получена новая DHCP-аренда. Этот вариант идеально подходит когда машина с OpenVPN-сервером является машиной с одним NIC за файрволом.
  • Использование клиента динамического DNS, такого как ddclient, для обновления динамического DNS-адреса каждый раз, когда меняется IP-адрес сервера. Этот вариант идеально подходит в случае, когда машина с работающим OpenVPN имеет несколько сетевых карт и выступает в роли файрвола/шлюза для всего сайта. Для реализации этого варианта настройки OpenVPN вы должны создать скрипт, который будет запускаться вашим DHCP-клиентом каждый раз, когда происходит изменение IP-адреса. Этот скрипт должен (а) запускать ddclient для уведомления вашего провайдера динамического DNS о вашем новом IP-адресе и (б) перезапустить демона OpenVPN-сервера.

Если в конфигурации клиента используется директива remote, которая ссылается на динамическое имя DNS, то OpenVPN-клиент чувствителен к смене IP-адреса сервера. Обычная последовательность событий такая: (а) клиент OpenVPN не получает вовремя keepalive-сообщение со старого IP-адреса сервера, что вызывает перезапуск (соединения -- прим. перев.), и (б) перезапуск является причиной того, что DNS-имя в директиве remote разрешается заново, что позволяет клиенту подключиться к новому IP-адресу сервера.

Более подробную информацию можно найти в FAQ.

Подключение к OpenVPN-серверу через HTTP-прокси.

OpenVPN поддерживает соединения через HTTP-прокси с применением следующих режимов аутентификации:

  • Без аутентификации
  • Basic(обычная)-аутентификация
  • NTLM-аутентификация

Прежде всего, соединение через HTTP-прокси требует использования TCP в качестве транспортного протокола для туннеля. Поэтому добавьте следующие строки в конфигурациях клиента и сервера:

proto tcp

Убедитесь, что вы удалили все строки с proto udp в конфигурационных файлах.

Затем добавьте директиву http-proxy в файл конфигурации клиента (см. полное описание этой директивы в man-странице).

Например, предположим, что у вас есть сервер HTTP-прокси в локальной сети клиента с адресом 192.168.4.1, который ожидает соединений на порту 1080. Добавьте это в конфигурацию клиента:

http-proxy 192.168.4.1 1080

Предположим, что HTTP-прокси требует Basic-аутентификации:

http-proxy 192.168.4.1 1080 stdin basic

Предположим, что HTTP-прокси требует NTLM-аутентификации:

http-proxy 192.168.4.1 1080 stdin ntlm

В двух приведенных выше примерах при аутентификации OpenVPN будет запрашивать имя пользователя/пароль из стандартного ввода. Если вы вместо этого хотите поместить эти учетные данные в файл, замените stdin на имя файла и поместите имя пользователя в первой строке этого файла и пароль во второй строке.

Подключение к общему ресурсу Samba через OpenVPN

В этом примере мы покажем, как клиенты OpenVPN могут подключаться к общему ресурсу Samba через маршрутизируемый (routed) dev tun туннель. Если вы используете ethernet-мост (dev tap), вам, скорее всего, не нужно следовать этим инструкциям, поскольку OpenVPN-клиенты и без этого должны увидеть машины на стороне сервера в своем сетевом окружении.

В этом примере мы будем считать, что:

  • локальная сеть на стороне сервера использует адреса 10.66.0.0/24,
  • для пула IP-адресов VPN используется сеть 10.8.0.0/24 (как указано в директиве server в файле конфигурации сервера OpenVPN),
  • Samba-сервер имеет IP-адрес 10.66.0.4, и
  • сервер Samba уже настроен и доступен из локальной сети.

Если Samba и OpenVPN-сервер работают на разных компьютерах, убедитесь, что вы ознакомились с разделом Расширение границ VPN для включения дополнительных машин.

Далее, отредактируйте файл конфигурации Samba (smb.conf). Убедитесь в том, директива hosts allow позволит подключаться OpenVPN-клиентам из сети 10.8.0.0/24. Например:

hosts allow = 10.66.0.0/24 10.8.0.0/24 127.0.0.1

Если Samba и OpenVPN-сервер запущены на одной машине, у вас может возникнуть необходимость отредактировать директиву interfaces в файле smb.conf, чтобы принимать подключения на TUN-интерфейсе в сети 10.8.0.0/24:

interfaces  = 10.66.0.0/24 10.8.0.0/24

Если у вас Samba и OpenVPN-сервер работают на одной машине, подключайтесь с клиента OpenVPN к общим ресурсам Samba с использованием пути:

\\10.8.0.1\\sharename

Если у вас Samba и OpenVPN-сервер работают на разных машинах, подключайтесь с клиента OpenVPN к общим ресурсам Samba с использованием пути:

\\10.66.0.4\sharename

Например, из окна командной строки:

net use z: \\10.66.0.4\sharename /USER:myusername

Реализация конфигурации с балансировкой нагрузки/отказоустойчивостью (load-balancing/failover)

Клиент

В конфигурации OpenVPN-клиента можно указать несколько серверов для балансировки нагрузки и отказоустойчивости. Например:

remote server1.mydomain
remote server2.mydomain
remote server3.mydomain

эти директивы укажут OpenVPN-клиенту делать попытки связаться с server1, server2 и server3 в указанном порядке. Если существующее соединение разрывается, клиент OpenVPN будет пытаться подключиться к последнему серверу, с которым было соединение и если это не получится, перейдет к следующему серверу в списке. Вы также можете изменить порядок выбора серверов OpenVPN-клиентом на случайный, так что нагрузка от клиентов будет равномерно распределена по пулу серверов.

remote-random

Если вы хотите чтобы при сбое в разрешении DNS-имени OpenVPN-клиент переходил к очередному серверу в списке, добавьте следующее:

resolv-retry 60

Параметр 60 указывает OpenVPN-клиенту пробовать разрешить каждое DNS-имя в директиве remote в течение 60 секунд, прежде чем перейти к следующему серверу в списке.

Список серверов также может относиться к нескольким демонам OpenVPN-сервера, работающим на одном компьютере, каждый из которых принимает соединения на своем порту, например:

remote smp-server1.mydomain 8000
remote smp-server1.mydomain 8001
remote smp-server2.mydomain 8000
remote smp-server2.mydomain 8001

Если ваши серверы являются многопроцессорными машинами, запуск нескольких демонов OpenVPN на каждом сервере может быть выгодным с точки зрения производительности.

OpenVPN также поддерживает директиву remote, ссылающуюся на DNS-имя, которое имеет несколько A-записей в конфигурации зоны для домена. В этом случае клиент OpenVPN будет случайным образом выбирать одну из A-записей каждый раз, когда будет производиться разрешение имени.

Сервер

Простейшим подходом к конфигурации сервера с балансировкой нагрузки / отказоустойчивостью является использование одинаковых файлов конфигурации на каждом сервере в кластере, за исключением использования различных виртуальных IP-адресов для каждого сервера. Например:

server1

server 10.8.0.0 255.255.255.0

server2

server 10.8.1.0 255.255.255.0

server3

server 10.8.2.0 255.255.255.0

Повышение безопасности OpenVPN

Один из часто повторяемых принципов сетевой безопасности является то, что никогда не следует доверять какому-либо одному компоненту безопасности настолько сильно, что его отказ станет причиной катастрофической бреши в безопасности. OpenVPN предоставляет несколько механизмов для добавления дополнительных слоев безопасности, чтобы застраховаться от такого исхода.

tls-auth

Директива tls-auth добавляет дополнительную подпись HMAC ко всем пакетам рукопожатия SSL/TLS (SSL/TLS handshake packets) для проверки целостности. Любой UDP-пакет, не имеющий правильной HMAC-подписи, может быть отброшен без дальнейшей обработки. HMAC-подпись, устанавливаемая директивой tls-auth, обеспечивает повышенный уровень безопасности дополнительно к безопасности, предоставляемой протоколом SSL/TLS. Это может защитить от:

  • DoS-атак или флуда на UDP-порт OpenVPN.
  • Сканирования портов, предназначенного для определения прослушиваемых сервером UDP-портов.
  • Уязвимостей, связанных с переполнением буфера в реализации SSL/TLS.
  • Попыток инициации SSL/TLS-рукопожатия от несанкционированной машины (хотя, в конечном итоге, такие рукопожатия не пройдут аутентификацию, tls-auth может отсечь их на гораздо более ранней стадии).

Использование tls-auth требует, чтобы вы сгенерировали общий секретный ключ, который используется в дополнение к стандартному RSA-сертификату/ключу:

openvpn --genkey --secret ta.key

Эта команда создаст статический ключ OpenVPN и запишет его в файл ta.key. Этот ключ должен быть скопирован через уже существующий защищенный канал на сервер и клиентские машины. Он может быть размещен в том же каталоге, что и файлы RSA .key и .crt.

Добавьте в конфигурацию сервера:

tls-auth ta.key 0

Добавьте в конфигурацию клиента:

tls-auth ta.key 1

proto udp

Хотя OpenVPN позволяет использовать или TCP- или UDP-протокол в качестве носителя соединения VPN (as the VPN carrier connection), протокол UDP по сравнению с TCP будет обеспечить более надежную защиту от DoS-атак и сканирования портов:

proto udp

user/group (только не для Windows)

OpenVPN была очень тщательно разработан таким образом, чтобы привелегии суперпользователя могли быть сброшены после инициализации, и эта возможность всегда должна быть использована на Linux/BSD/Solaris. Работающий без привилегий суперпользователя демон OpenVPN-сервера является гораздо менее привлекательной целью для злоумышленника.

user nobody
group nobody

Непривилегированный режиме (только Linux)

В Linux OpenVPN может работать полностью непривилегированным. Эта конфигурация немного сложнее, но обеспечивает лучшую безопасность.

Для того чтобы работать с этой конфигурацией, OpenVPN должен быть настроен на использование iproute-интерфейса, это достигается путем указания --enable-iproute2 в configure-скрипте. На вашей системе также должен быть доступен пакет sudo.

В этой конфигурации используется возможность Linux изменять разрешения на устройство tun таким образом, чтобы обычный пользователь мог получить к нему доступ. Также, для того, чтобы свойства интерфейса и таблица маршрутизации могли быть изменены (непривилегированным пользователем -- прим. перев.) для запуска (execute) iproute используется sudo.

Конфигурация OpenVPN:

  • Поместите следующий скрипт в файл /usr/local/sbin/unpriv-ip (не забудьте установить на этот файл права на исполнение -- прим. перев.):
    • #!/bin/sh
    sudo /sbin/ip $*
  • Чтобы позволить пользователю 'user1' выполнять /sbin/ip запустите visudo и добавьте следующее:
    • user1 ALL=(ALL)  NOPASSWD: /sbin/ip
    Вы также можете разрешить группу пользователей с помощью следующей команды: 
    %users ALL=(ALL)  NOPASSWD: /sbin/ip
  • Добавьте следующее в вашу конфигурацию OpenVPN:
    • dev tunX/tapX
    iproute /usr/local/sbin/unpriv-ip
    Обратите внимание, что вы должны выбрать константу X и указать или tun или tap, но не оба.
  • Как root добавьте постоянный интерфейс и разрешите пользователю и/или группе управлять им, следующая команда создаст tunX (замените своим собственным) и разрешит пользователю user1 и группе users доступ к нему.
    • openvpn --mktun --dev tunX --type tun --user user1 --group users
  • Запустите OpenVPN в контексте непривилегированного пользователя.

Дальнейшие ограничения безопасности могут быть добавлены путем проверки параметров в скрипте /usr/local/sbin/unpriv-ip.

chroot (не для Windows)

Директива chroot позволяет заблокировать демон OpenVPN в так называемой изолированной тюрьме (chroot jail), где демон не сможет получить доступ к любой части файловой системе за исключением конкретного каталога, указанного в качестве параметра для директивы (подробнее см. man 1 chroot и man 2 chroot -- прим. перев.). Например,

chroot jail

приведет к тому, что демон OpenVPN перейдет в подкаталог jail при инициализации, а затем переориентирует (reorient) свою корневую файловую систему в этот каталог, так, чтобы впоследствии для демона OpenVPN было невозможно получить доступ к любым файлам за пределами каталога jail и дерева его подкаталогов. Это важно с точки зрения безопасности, потому что даже если злоумышленнику удалось скомпрометировать сервер с использованием инъекции кода, эксплоит будет заблокирован в пространстве, изолированном от большей части файловой системы сервера.

Предостережения: поскольку chroot переориентирует файловую систему (только с точки зрения демона), необходимо поместить в каталог jail любые файлы, которые могут понадобиться OpenVPN после инициализации, например:

  • файл crl-verify, или
  • каталог client-config-dir.

RSA-ключи большего размера

Размер ключа RSA находится под контролем переменной KEY_SIZE в файле easy-rsa/vars, которая должна быть установлена перед генерацией какого-либо ключа. В настоящее время эта переменная установлена в значение по умолчанию равное 1024, это значение может быть при необходимости увеличено до 2048 без какого-либо негативного влияния на производительность VPN-туннеля, за исключением немного более медленного рукопожатия (handshake) при пересогласовании SSL/TLS, которое происходит для каждого клиента раз в час, и гораздо медленнее при однократной генерации параметров Диффи—Хеллмана с использованием скрипта easy-rsa/build-dh.

Симметричные ключи большего размера

По умолчанию OpenVPN использует Blowfish -- 128-битный симметричный шифр (cipher).

OpenVPN автоматически поддерживает любой шифр, который поддерживается библиотекой OpenSSL, и поэтому может поддерживать шифры, которые используют большие размеры ключа. Например, можно использовать 256-разрядную версию AES (Advanced Encryption Standard), добавив в файлы конфигурации и сервера и клиента следующее:

cipher AES-256-CBC

Хранение корневого ключа (ca.key) на автономном компьютере без подключения к сети

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

Отзыв сертификатов

Термин отзыв сертификата означает процесс лишения законной силы (invalidate) ранее подписанного сертификата, так что он больше не может быть использован для целей аутентификации.

Типичные причины для отзыва сертификата включают в себя:

  • Закрытый ключ, связанный с сертификатом, скомпрометирован или украден.
  • Пользователь зашифрованного закрытого ключа забывает пароль на ключ.
  • Вы хотите закрыть (прекратить) доступ VPN-пользователю.

Пример

В качестве примера, мы будем отзывать сертификат client2, который мы сгенерировали выше, в разделе HOWTO "генерация ключей".

Сперва откройте оболочку (shell) или окно командной строки и перейдите в каталог easy-rsa, как вы делали выше в разделе "генерация ключей". На Linux/BSD/Unix:

. ./vars
./revoke-full client2

В Windows:

vars
revoke-full client2

Вы должны увидеть результат, похожий на этот:

Using configuration from /root/openvpn/20/openvpn/tmp/easy-rsa/openssl.cnf
DEBUG[load_index]: unique_subject = "yes"
Revoking Certificate 04.
Data Base Updated
Using configuration from /root/openvpn/20/openvpn/tmp/easy-rsa/openssl.cnf
DEBUG[load_index]: unique_subject = "yes"
client2.crt: /C=KG/ST=NA/O=OpenVPN-TEST/CN=client2/emailAddress=me@myhost.mydomain
error 23 at 0 depth lookup:certificate revoked

Обратите внимание на "error 23" в последней строке. Это то, что вы хотите увидеть, т.к. это указывает, что проверка действительности (verification) для отозванного сертификата провалилась (failed).

Скрипт revoke-full создаст CRL-файл (certificate revocation list, список отозванных сертификатов) с именем crl.pem в подкаталоге keys. Файл должен быть скопирован в каталог, в котором сервер OpenVPN может получить к нему доступ, затем проверка CRL должна быть включена в конфигурации сервера:

crl-verify crl.pem

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

Замечания о CRL

  • Когда в OpenVPN используется опция crl-verify, CRL-файл будет перечитан каждый раз когда подключается новый клиент или уже подключенный клиент пересогласовывает SSL/TLS-соединение (по умолчанию раз в час). Это означает, что вы можете обновить CRL-файл при запущенном демоне OpenVPN-сервера, и новый список вступает в силу немедленно для вновь подключающихся клиентов. Если клиент, чей сертификат вы отменили, уже подключен, вы можете перезапустить сервер с помощью сигнала (SIGUSR1 или SIGHUP) и сбросить (flush) всех клиентов, или вы можете подключиться с помощью telnet к интерфейсу управления и явно убить конкретный экземпляр объекта клиента на сервере, не мешая другим клиентам.
  • Хотя директива crl-verify может использоваться как на сервере OpenVPN, так и на клиентах, как правило, нет необходимости распространять CRL-файл клиентам, за исключением случая отзыва сертификата сервера. Клиенты не должны знать о других клиентских сертификатах которые были отменены, поскольку клиенты не должны принимать прямые соединения от других клиентов в первую очередь.
  • CRL-файл не является секретным, и должен быть доступен для чтения всем, чтобы демон OpenVPN смог прочитать его после сброса привилегий суперпользователя.
  • Если вы используете директиву chroot, удостоверьтесь, что поместили копию CRL-файла в chroot-каталог, поскольку в отличие от большинства других файлов, которые читает OpenVPN, CRL файл будет прочитан после того как будет сделан вызов chroot, не раньше.
  • Распространенной причиной отзыва сертификатов является случай, когда пользователь шифрует свой секретный ключ паролем, а затем забывает пароль. Отзывая первоначальный сертификат, можно сгенерировать новую пару сертификат/ключ с тем же самым common name.

Важное примечание о возможных атаках "Man-in-the-Middle" если клиенты не проверяют сертификат сервера к которому они подключаются.

Чтобы избежать возможных атак Man-in-the-Middle, когда авторизованный клиент пытается подключиться к другому клиенту, который выдет себя за сервер, убедитесь что сделали на клиентах проверку сертификата сервера. В настоящее время существует пять различных способов сделать это, они перечислены в порядке предпочтения:

  • [OpenVPN 2.1 и выше] Создайте свой сертификат сервера с определенными значениями полей key usage и extended key usage. RFC3280 определяет, что для TLS-соединений должны быть предоставлены следующие атрибуты:
    РежимЗначение key usageЗначение extended key usage
    Клиент digitalSignature TLS Web Client Authentication
    keyAgreement
    digitalSignature, keyAgreement
    Сервер digitalSignature, keyEncipherment TLS Web Server Authentication
    digitalSignature, keyAgreement

    Вы можете создать свой сертификат сервера скриптом build-key-server (см. документацию easy-rsa для получения более подробной информации). Этот скрипт обозначит сертификат в качестве сертификата только для сервера, установив правильные атрибуты. Теперь добавьте следующую строку в файл конфигурации клиента:

    remote-cert-tls server
  • [OpenVPN 2.0 и ниже] Создайте скриптом build-key-server свой сертификат сервера (см. документацию easy-rsa для получения более подробной информации). Этот скрипт обозначит сертификат в качестве сертификата только для сервера, установив nsCertType=server. Теперь добавьте следующую строку в файл конфигурации клиента: 
    ns-cert-type server

    Эта директива запрещает клиентам подключаться к любому серверу у которого в сертификате отсутствует nsCertType=server, даже если сертификат был подписан ca-файлом, на который ссылается файл конфигурации OpenVPN.

  • Используйте на клиенте директиву tls-remote, чтобы принять/отклонить соединение с сервером на основе common name в сертификата сервера.
  • Используйте tls-verify-скрипт или плагин, чтобы принять/отклонить соединение с сервером на основе пользовательской проверки X509-заголовков в сертификате сервера.
  • Подписывайте сертификаты серверов в одном CA, а клиентские сертификаты в другом CA. Директива ca в конфигурации клиента должна ссылаться на CA, подписавший сертификат для сервера, в то время как директива ca в конфигурации сервера должна ссылаться на CA-файл, которым были подписаны сертификаты клиентов.

Образцы файлов конфигурации OpenVPN 2.0

sample-config-files/server.conf

 
#################################################
# Пример файла конфигурации OpenVPN 2.0 для     #
# сервера + несколько клиентов.                 #
#                                               #
# Этот файл для серверной стороны               #
# конфигурации OpenVPN в случае                 #
# много-клиентов <-> один-сервер.               #
#                                               #
# OpenVPN также поддерживает                    #
# конфигурацию одна-машина <-> одна машина      #
# (См. страницу примеров на сайте для           #
# получения большей информации).                #
#                                               #
# Этот конфиг будет работать на Windows         #
# или Linux/BSD-системах.  Не забывайте на      #
# Windows заключать в кавычки пути и            #
# использовать двойные обратные слэши:          #
# "C:\\Program Files\\OpenVPN\\config\\foo.key" #
#                                               #
# Комментарии начинаются с '#' или ';'          #
#################################################

# На каком локальном адресе OpenVPN должен
# принимать соединения? (опционально)
;local a.b.c.d

# Какой TCP/UDP-порт должен слушать OpenVPN?
# Если вы хотите запустить несколько экземпляров OpenVPN
# на одной и той же машине, используйте отдельный номер 
# порта для каждого экземпляра.  Вам нужно будет
# открыть этот порт на файрволе.
port 1194

# TCP- or UDP-сервер?
;proto tcp
proto udp

# "dev tun" создаст маршрутизируемый (routed) IP-туннель,
# "dev tap" создат ethernet-туннель.
# Используйте "dev tap0" если вы хотите использовать ethernet-мост
# и у вас есть созданный заранее виртуальный интерфейс tap0
# который связан в мост с вашим ethernet-интерфейсом.
# Если вы хотите контролировать политики доступа
# через VPN, вы должны создать правила
# файрвола для TUN/TAP-интерфейса.
# На не-Windows системах вы должны явно
# указать номер устройства, например tun0.
# В Windows, используйте для этого "dev-node".
# На большинстве систем VPN не будет функционировать
# пока вы частично или полностью не отключите
# файрвол для TUN/TAP-интерфейса.
;dev tap
dev tun

# Для Windows необходимо имя TAP-Win32-адаптера
# из панели Сетевые подключения если у вас
# больше чем один такой адаптер.  В XP SP2 или выше
# вам, возможно, понадобиться выборочно отключить
# брандмауэр Windows для TAP-адаптера.
# Не-Windows системы обычно не требуют этого.
;dev-node MyTap

# Корневой сертификат SSL/TLS (ca), сертификат
# (cert), и закрытый ключ (key).  Каждый клиент
# и сервер должен иметь свои собственные файлы с сертификатом и 
# ключем.  Сервер и все клиенты будут
# использовать один и тот же ca-файл.
#
# См. в каталоге "easy-rsa" комплект
# скриптов для генерации RSA-сертификатов
# и закрытых ключей.  Не забывайте использовать
# уникальный Common Name для сертификатов сервера
# и каждого клиента.
#
# Может быть использована любая система управления ключами X509.
# OpenVPN также может использовать файлы ключей в формате PKCS#12
# (см. директиву "pkcs12" в man-странице).
ca ca.crt
cert server.crt
key server.key  # Этот файл должен храниться в секрете

# Параметры Диффи-Хеллмана.
# Сгенерируйте свой собственный файл:
#   openssl dhparam -out dh1024.pem 1024
# Замените 1024 на 2048, если вы используете
# 2048-битные ключи. 
dh dh1024.pem

# Настройка режима сервера и адреса VPN-сети, 
# из которой OpenVPN будет раздавать адреса клиентам.
# Сервер возьмет себе 10.8.0.1,
# остальные адреса будут доступны для клиентов.
# Каждый клиент сможет связаться с сервером по адресу
# 10.8.0.1. Закомментируйте эту строку, если вы используете
# ethernet-мост (ethernet bridging). См. man-страницу чтобы получить больше информации.
server 10.8.0.0 255.255.255.0

# Сопоставления клиент <-> виртуальный IP-адрес
# хранятся в этом файле.  Если OpenVPN упадет или 
# будет перезапущен, повторно подключающимся клиентам могут быть назначены
# из пула такие же виртуальные IP-адреса, которые были
# назначены им в прошлый раз.
ifconfig-pool-persist ipp.txt

# Настройка сервера для режима ethernet-моста (for ethernet bridging).
# Сначала вы должны использовать возможности вашей ОС в плане создания мостов
# для объединения в мост TAP-интерфейса с ethernet
# NIC-интерфейсом.  Затем вы должны вручную установить
# IP/маску сети для интерфейса моста, здесь мы 
# будем использовать 10.8.0.4/255.255.255.0.  В конце мы
# должны выделить IP-диапазон в этой подсети
# (начало=10.8.0.50 конец=10.8.0.100) для назначения 
# подключающимся клиентам.  Оставьте эту строку закомментированной
# если вы не используете ethernet-мост.
;server-bridge 10.8.0.4 255.255.255.0 10.8.0.50 10.8.0.100

# Передача клиенту маршрутов, чтобы позволить ему
# связаться с другими частными подсетями, расположенными за
# сервером.  Помните, что эти 
# частные подсети также должны
# знать как маршрутизировать пакеты к адресному пулу
# клиентов OpenVPN (10.8.0.0/255.255.255.0)
# через OpenVPN-сервер.
;push "route 192.168.10.0 255.255.255.0"
;push "route 192.168.20.0 255.255.255.0"

# Чтобы назначить определенные IP-адреса определенным
# клиентам или если подключающийся клиент имеет за собой
# частную сеть, которая также должна иметь VPN-доступ,
# используйте подкаталог "ccd" для клиент-специфичных
# конфигурационных файлов (см man-страницу чтобы получить больше информации).

# ПРИМЕР: Предположим, что клиент
# имеет сертификат с common name "Thelonious",
# а также имеет небольшую подсеть за подключаемой
# машиной, такую как 192.168.40.128/255.255.255.248.
# Во-первых, раскомментируйте эти строки:
;client-config-dir ccd
;route 192.168.40.128 255.255.255.248
# Затем создайте файл ccd/Thelonious, содержащий такую строку:
#   iroute 192.168.40.128 255.255.255.248
# Это позволит частной сети Thelonious'а
# иметь доступ к VPN.  Этот пример будет работать только
# если вы используете режим маршрутизации, а не режим моста, т.е. вы
# используете директивы "dev tun" и "server".

# Пример: Допустим, вы хотите выдать
# Thelonious'у в VPN фиксированный IP-адрес 10.9.0.1.
# Сначала раскомментируйте эти строки:
;client-config-dir ccd
;route 10.9.0.0 255.255.255.252
# Затем добавьте эту строку в ccd/Thelonious:
#   ifconfig-push 10.9.0.1 10.9.0.2

# Предположим, что вы хотите иметь различные
# политики доступа в файрволе для различных групп
# клиентов.  Есть два метода:
# (1)Запустить несколько демонов OpenVPN, по одному на 
#     каждую группу, и настроить TUN/TAP-интерфейс
#     для каждой группы/демона соответствующим образом.
# (2) (Продвинутый) создать скрипт, чтобы динамически
#     модифицировать правила файрвола под
#     каждого конкретного клиента.  Смотрите man-страницу
#     для получения большей информации по learn-address-скриптам.
;learn-address ./script

# Будучи активированной, это директива скажет
# всем клиентам перенаправить их шлюз
# по умолчанию через VPN, в результате чего
# весь IP-трафик, такой как просмотр веб-страниц и
# DNS-поиск пойдет через VPN
# (Машине с OpenVPN-сервером, возможно, потребуется NAT'ить
# весь трафик с TUN/TAP-интерфейса, идущий в Интернет,
# чтобы все это работало должным образом).
# Предостережение: Можно нарушить сетевую конфигурацию клиента
# если пакеты локального DHCP-сервера клиента будут направлены (get routed)
# через туннель.  Решение: убедитесь, что
# локальный DHCP-сервер клиента доступен через
# более определенный (specific) маршрут, чем маршрут по умолчанию
# -- 0.0.0.0/0.0.0.0.
;push "redirect-gateway"

# Некоторые Windows-специфичные сетевые настройки
# могут быть переданы клиентам, такие как адреса DNS-
# или WINS-серверов.  ПРЕДОСТЕРЕЖЕНИЕ:
# http://openvpn.net/faq.html#dhcpcaveats
;push "dhcp-option DNS 10.8.0.1"
;push "dhcp-option WINS 10.8.0.1"

# Раскомментируйте эту директиву, чтобы позволить различным
# клиентам "видеть" друг друга.
# По умолчанию клиенты будут видеть только сервер.
# Чтобы клиенты видели только сервер, вам
# также необходимо будет надлежащим образом
# настроить файрвол сервера для TUN/TAP-интерфейса.
;client-to-client

# Раскомментируйте эту директиву, если несколько клиентов
# могут подключаться с одинаковыми файлам сертификата/ключа
# или common names.  Это рекомендуется
# только в целях тестирования.  В промышленном использовании
# каждый клиент должен иметь свою собственную пару
# сертификат/ключ.
#
# ЕСЛИ У ВАС НЕ СГЕНЕРИРОВАННА ИНДИВИДУАЛЬНАЯ
# ПАРА СЕРТИФИКАТ/КЛЮЧ ДЛЯ КАЖДОГО КЛИЕНТА И
# КАЖДЫЙ КЛИЕНТ НЕ ИМЕЕТ СВОЕГО УНИКАЛЬНОГО "COMMON NAME",
# РАСКОММЕНТИРУЙТЕ ЭТУ СТРОКУ.
;duplicate-cn

# Директива проверки работоспособности, включающая отсылку
# ping-подобных сообщений туда и обратно через
# соединение для того, чтобы каждая сторона знала когда
# другая сторона внезапно пропадет (gone down).
# Пинг каждые 10 секунд, с предположением, что удаленный
# узел недоступен, если не получено на одного пинга за период времени
# равный 120 секундам.
keepalive 10 120

# Для еще большей безопасности чем предоставляет
# SSL/TLS, создайте "HMAC-файрвол",
# чтобы заблокировать DoS-атаки и UDP-флуд.
#
# Генерация:
#   openvpn --genkey --secret ta.key
#
# Сервер и каждый клиент должен иметь
# копию этого ключа.
# Второй параметр должен быть '0'
# на сервере и '1 'на клиентах.
;tls-auth ta.key 0 # Этот файл является секретным

# Выбор криптографического шифра (cipher).
# Этот элемент конфигурации также должен быть скопирован
# в конфигурацию клиента.
;cipher BF-CBC        # Blowfish (default)
;cipher AES-128-CBC   # AES
;cipher DES-EDE3-CBC  # Triple-DES

# Включить сжатие в VPN-соединении.
# Если вы включите его здесь, вы также должны
# включить его в файле конфигурации клиента.
comp-lzo

# Максимальное количество одновременно подключенных
# клиентов, которое мы хотим разрешить.
;max-clients 100

# Хорошая идеей будет уменьшить привилегии
# демона OpenVPN после инициализации.
#
# Вы можете раскомментировать это на
# не-Windows системах.
;user nobody
;group nobody

# persist-опции скажут OpenVPN при перезагрузке
#  воздерживаться от доступа к определенным ресурсам,
# которые могут быть недоступны по причине
# понижения привилегий.
persist-key
persist-tun

# Содержимое небольшого файла состояния, показывающего
# текущие соединения, усекается
# и перезаписывается раз в минуту.
status openvpn-status.log

# По умолчанию журнальные сообщения пойдут в syslog (или,
# в Windows, если OpenVPN запущен как сервис, они будут записываться в 
# каталог "\Program Files\OpenVPN\log").
# Используйте log или log-append для изменения этого поведения по умолчанию.
# "log" будет усекать файл журнала при запуске OpenVPN,
# в то время как "log-append" будет добавлять к нему.  Используйте один
# или другой (но не оба сразу).
;log         openvpn.log
;log-append  openvpn.log

# Установить соответствующий уровень детализации
# лог-файла.
#
# 0 -- молчаливый (silent), за исключением фатальных ошибок
# 4 -- разумно для обычного использования
# 5 и 6 помогут найти и устранить (debug) проблемы с соединением
# 9 -- чрезвычайно подробный
verb 3

# Не записывать повторяющиеся сообщения.  Не более 20
# последовательно идущих одинаковых сообщений
# будут выведены в лог.
;mute 20

sample-config-files/client.conf

 
##############################################
# Пример конфиг-файла клиента OpenVPN 2.0    #
# для соединения с мульти-клиентским сервером#
#                                            #
# Эта конфигурация может использоваться      #
# несколькими клиентами, но каждый клиент    #
# должен иметь свой сертификат и ключ.       #
#                                            #
# В Windows вы можете переименовать этот     #
# файл, чтобы он был с расширением .ovpn     #
##############################################

# Укажем, что мы являемся клиентом и что мы
# примем (pulling) определенные директивы конфигурации 
# от сервера.
client

# Используйте те же настройки, как вы используете на
# на сервере.
# В большинстве систем VPN не будет работать
# пока вы частично или полностью не отключите
# файрвол для TUN/TAP-интерфейса.
;dev tap
dev tun

# Для Windows необходимо имя TAP-Win32-адаптера
# из панели Сетевые подключения, если у вас
# больше чем один такой адаптер.  В XP SP2 или выше
# вам, возможно, понадобиться выборочно отключить
# брандмауэр Windows для TAP-адаптера.
;dev-node MyTap

# Мы подключаемся к TCP- или
# UDP-серверу?  Используйте тот же параметр что и
# на сервере.
;proto tcp
proto udp

# Имя хоста/IP и порт сервера.
# Вы можете иметь несколько remote-записей
# для распределения нагрузки между серверами.
remote my-server-1 1194
;remote my-server-2 1194

# Выбрать случайный хост из remote-списка
# для балансировки нагрузки.  В противном случае
# попробовать хосты в указанном порядке.
;remote-random

# Бесконечно пробовать разрешить
# имя хоста OpenVPN-сервера.  Очень полезно
# на машинах, которые не являются постоянно подключенными
# к интернету, например, для ноутбуков.
resolv-retry infinite

# Большинству клиентов не нужно привязываться (bind) к
# определенному локальному номеру порта.
nobind

# Понизить привилегии после инициализации (только для не-Windows)
;user nobody
;group nobody

# Стараться сохранять некоторые объекты (some state) между перезагрузками.
persist-key
persist-tun

# Если вы подключаетесь через
# HTTP-прокси, чтобы соедениться с OpenVPN-сервером
# укажите IP-адрес прокси-сервера и
# номер порта.  Смотрите man-страницу
# если прокси-сервер требует
# аутентификации.
;http-proxy-retry # повторять при ошибках соединения
;http-proxy [proxy server] [proxy port #]

# Беспроводные сети часто производят много
# дубликатов пакетов.  Установите этот флаг
#для того, чтобы отключить предупреждения о дублирующихся пакетах.
;mute-replay-warnings

# Параметры SSL/TLS.
# Смотрите файл конфигурации сервера для более
# подробного описания.  Лучше всего использовать
# отдельные пары .crt/.key-файлов
# для каждого клиента.  Один ca-файл
# может быть использован для всех клиентов.
ca ca.crt
cert client.crt
key client.key

# Проверка сертификата сервера путем контроля того,
# что в сертификате значение поля nsCertType
# установленным в значение "server".  Это
# важная меры предосторожности для защиты от
# потенциальной атаки, обсуждаемой здесь:
#  http://openvpn.net/howto.html#mitm
#
# Чтобы использовать эту функцию, вам необходимо сгенерировать
# ваш сертификат для сервера с полем nsCertType,
# установленным в значение "server".  Скрипт build-key-server
# в папке easy-rsa может сделать это.
;ns-cert-type server

# Если на сервере используется ключ tls-auth,
# то каждый клиент также должен иметь этот ключ.
;tls-auth ta.key 1

# Выбор криптографического шифра (cipher).
# Если опция cipher используется на сервере,
# то вы также должны указать её здесь.
;cipher x

# Включить сжатие в VPN-канале.
# Не включайте эту опцию, если если она
# не включена в конфигурационном файле сервера.
comp-lzo

# Установить степень многословия (verbosity) в лог-файле.
verb 3

# Не записывать повторяющиеся сообщения
;mute 20

Copyright © 2002-2008 by OpenVPN Technologies, Inc. OpenVPN is a trademark of OpenVPN Technologies, Inc.

Рейтинг@Mail.ru