OpenVPN HOWTOВведение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 1.x HOWTOОригинальный OpenVPN 1.x HOWTO по-прежнему доступен и остается актуальным для конфигураций точка-точка или конфигураций с использованием статических ключей. Статьи по OpenVPNДополнительную документацию смотрите на странице статей на сайте OpenVPN. Быстрый запуск OpenVPNНесмотря на то что этот документ научит вас настраивать масштабируемый клиент-серверный VPN с использованием X509 PKI (инфраструктура публичных ключей с использованием сертификатов и закрытых ключей), это может быть излишним, если вам необходимо сделать несложную установку VPN с сервером, который может обслуживать одного клиента. Вы можете перейти к Static Key Mini-HOWTO, если хотите получить работающий VPN быстро и с минимальной конфигурацией. Преимущества использования статического ключа
Недостатки использования статического ключа
Установка OpenVPNOpenVPN можно скачать здесь. В целях обеспечения безопасности будет хорошей идеей проверить сигнатуру файла с релизом после загрузки. Исполняемые файлы 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-пакета необходимо удовлетворить зависимости:
Кроме того, если вы собираете свой собственный бинарный RPM-пакет, существуют несколько дополнительных зависимостей:
Файл 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 Замечания для WindowsOpenVPN для Windows можно установить из самоустанавливающегося исполняемого файла, который необходимо взять на странице загрузки OpenVPN. Помните, что OpenVPN будет работать только на Windows 2000 и выше. Также следует отметить, что OpenVPN необходимо устанавливать и запускать под пользователем, имеющим права администратора (это ограничение накладывается Windows, а не OpenVPN). Ограничение можно обойти путем запуска OpenVPN в фоновом режиме в качестве службы, в этом случае даже без административных прав пользователи смогут получить доступ к VPN, когда он будет установлен. Более подробное обсуждение вопроса OpenVPN + ограничения в Windows. OpenVPN также может быть установлен в Windows с графическим интерфейсом с помощью установочного пакета Mathias'а Sundman'а, который устанавливает и OpenVPN и GUI для Windows. После окончания работы инсталлятора (в Windows) OpenVPN будет готов к использованию, а файлы с расширением . ovpn будут ассоциированы с OpenVPN. Запустить OpenVPN можно несколькими способами:
Для Windows-версии OpenVPN также доступен графический интерфейс (GUI). Дополнительные замечания по установке в Windows. Замечания для Mac OS XAngelo Laub и Dirk Theisen разработали OpenVPN GUI для OS X. Другие операционные системыНекоторые примечания для конкретных операционных систем доступны в файле INSTALL. В общем случае может быть использован метод ./configure или вы можете поискать порт или пакет OpenVPN, специфичный для вашей ОС (операционной системы) или дистрибутива. Определение в каком режиме использовать VPN: в режиме моста или в режиме маршрутизацииСмотрите в FAQ обзор вопроса "Маршрутизация vs. Ethernet-мост" (Routing vs. Ethernet Bridging). Посмотрите также страницу о Ethernet-мостах в OpenVPN для получения более детальной информации. В целом, для большинства маршрутизация будет являться наилучшим выбором, так как она является более эффективной и более простой в настройке (в плане конфигурирования OpenVPN), чем мост (bridging). Также, маршрутизация предоставляет более широкие возможности для выборочного контроля прав доступа на основе данных клиентов. Я бы рекомендовал всегда использовать маршрутизацию, кроме случаев когда вам необходимы специальные функции, требующие моста, такие как:
Нумерация частных подсетейНастройка VPN часто влечет за собой объединение частных сетей (private subnets), расположенных в разных местах. Internet Assigned Numbers Authority (IANA) зарезервировала следующие три блока адресного пространства IP для частных сетей (описанные в RFC 1918):
Хотя адреса из этих блоков, как правило, могут без проблем использоваться в конфигурациях VPN, важно выбрать адреса, которые минимизируют вероятность конфликтов IP-адресов или подсетей между собой. Виды конфликтов, которые необходимо предотвратить:
В качестве примера предположим, что вы используете популярный диапазон 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 состоит из:
OpenVPN поддерживает двунаправленную аутентификацию на основе сертификатов, это означает что клиент должен проверять подлинность сертификата сервера, а сервер должен проверять подлинность сертификата клиента до того как они начнут доверять друг другу. И сервер и клиент будет аутентифицировать друг друга, сначала проверив что представленный сертификат подписан центром сертификации (CA), а затем путем проверки информации в заголовках уже аутентифицированного сертификата, таких как "common name" сертификата (этот термин оставлен в тексте "как есть" по причине отсутствия общеупотрбительного варианта перевода, само же понятие в общем случае обозначает имя объекта, котрому выдается сертификат -- прим. перв.) сертификата и тип сертификата (клиент или сервер). Эта модель безопасности с точки зрения VPN имеет ряд желательных функций:
Создание главного сертификата и ключа в 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 В Windows: vars Последняя команда (build-ca) создаст сертификат и ключ центра сертификации (CA), вызвав интерактивную команду openssl: ai:easy-rsa # ./build-ca Обратите внимание, что в указанной выше последовательности большинство запрошенных параметров установлены в значения по умолчанию, взятые из файлов 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 В Windows: build-key client1 Замените использованный выше скрипт на 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 Основные файлыТеперь мы найдем наши вновь созданные ключи и сертификаты в подкаталоге keys. Вот разъяснение соответствующих файлов:
Последний шаг в процессе создания ключа -- скопировать на каждую машину необходимые для неё файлы, позаботившись о том, чтобы секретные файлы копировались по защищенному каналу. У вас может возникнуть один вопрос. Есть ли возможность настроить PKI без заранее созданного безопасного канала? Ответ явно "да". В приведенном выше примере, мы для краткости сгенерировали все секретные ключи в одном и том же месте. С немного большими усилиями мы могли бы сделать это по-другому. Например, вместо создания клиентских сертификатов и ключей на сервере, клиенты могли бы сгенерировать свой закрытый ключ локально, а затем отправить запрос на подпись сертификата (Certificate Signing Request, CSR) на машину с ключем для подписи (key-signing machine). В свою очередь, машина с ключем для подписи могла бы обработать CSR и вернуть клиенту подписанный сертификат. Это можно было сделать даже не требуя, чтобы секретный .key-файл покидал жесткий диск машины, на которой он был сгенерирован. Создание конфигурационных файлов для сервера и клиентовПолучение образцов файлов конфигурацииЛучше всего использовать примеры конфигурационных файлов OpenVPN в качестве отправной точки для создания своей собственной конфигурации. Эти файлы могут также быть найдены в
Следует отметить, что в 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. На данный момент файл конфигурации сервера уже можно использовать, тем не менее, у вас может появиться желание еще больше приспособить его под свои задачи:
Есть возможность запустить несколько экземпляров OpenVPN на одной машине, каждый из которых использует отдельный файл конфигурации, если вы:
Редактирование файлов конфигурации клиентаПример конфигурационного файла клиента (client.conf на Linux/BSD/Unix или client.ovpn на Windows) содержит те же значения для директив, которые встречаются в примере конфигурационного файла сервера.
Запуск VPN и первоначальное тестирование подключения.Запуск сервераВо-первых, убедитесь что сервер 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 Запуск клиентаКак и при конфигурации сервера, сначала лучше запустить 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-клиента завершилась ошибкой, вот перечень основных симптомов и их решения:
Смотрите 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/UnixOpenVPN принимает несколько сигналов:
Чтобы знать куда отправлять сигнал, используйте директиву writepid для записи PID демона OpenVPN в файл (если вы запускаете OpenVPN с помощью initscript, то cценарий, возможно, уже добавил директиву --writepid в строку запуска OpenVPN). Запуск в Windows как GUIСмотрите OpenVPN GUI page. Запуск в окне командной строки WindowsВ Windows вы можете запустить OpenVPN, щелкнув правой кнопкой на файле конфигурации OpenVPN (.ovpn-файле) и выбрав "Start OpenVPN on this config file". После запуска таким способом доступно несколько клавиатурных команд:
Запуск в 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 Для получения дополнительной информации см. Документацию по 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. Существуют некоторые основные предварительные требования, которые должны быть выполнены:
Во-первых, убедитесь, что на клиентской машине включена пересылка для 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 Это приведет к тому, что 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" Чтобы проверить работоспособность этой функции в Windows, выполните следующее из окна командной строки после подключения машины к OpenVPN-серверу: ipconfig /all Для TAP-Win32-адаптера должны быть видны DHCP-опции, которые были переданы сервером. Настройка клиент-специфичных правил и политик доступаПредположим, мы создаем VPN в организации и хотели бы установить отдельные политики доступа для 3-х различных классов пользователей:
Основной подход, который мы будем применять это (а) изоляция каждого класса пользователей в свой собственный диапазон виртуальных IP-адресов, и (б) контроль доступа к машинам, устанавливая правила файрвола, которые ограничивают доступ на основании виртуального IP-адреса клиента. В нашем примере мы предположим, что у нас есть переменное число сотрудников, но только один системный администратор и два поставщика. Наш подход к распределению IP-адресов будет заключаться в том, чтобы поместить всех сотрудников в пул IP-адресов, а затем выделить фиксированные IP-адреса для системного администратора и для поставщиков. Обратите внимание, что одно из предварительных требований для этого примера заключается в том, что вам необходимо иметь файрвол на машине с OpenVPN-сервером, который даст вам возможность определить конкретные правила фильтрации пакетов. В нашем случае мы будем считать, что файрволом является iptables в Linux. Во-первых, давайте создадим карту распределения виртуальных IP-адресов в зависимости от класса пользователей:
Далее, давайте переведем эту карту в конфигурацию 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 Поскольку мы будем назначать фиксированные IP-адреса для конкретных системных администраторов и поставщиков, используем каталог конфигурации клиента (client configuration directory, ccd): client-config-dir ccd Теперь поместите специальные файлы конфигурации в ccd-подкаталог, чтобы назначить фиксированные IP-адреса для каждого VPN-клиента, который не является сотрудником. ccd/sysadmin1ifconfig-push 10.8.1.1 10.8.1.2 ccd/contractor1ifconfig-push 10.8.2.1 10.8.2.2 ccd/contractor2ifconfig-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] На этом конфигурирование OpenVPN окончено. Последним шагом является добавление правил файрвола для завершения построения политик доступа. В этом примере мы будем использовать синтаксис iptables: #Правило для сотрудников Использование альтернативных методов аутентификации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, см. файлы 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. Как настроить криптографический токенВы должны следовать процедуре регистрации:
Настроенный токен -- это токен, содержащий объект закрытого ключа и объект сертификата, у которых одинаковое значение атрибутов идентификатора и метки. Easy-RSA 2.0 -- простая утилита регистрации (сертификатов), которая является частью OpenVPN 2.1. Следуйте инструкциям в файле README, а затем используйте pkitool для того, чтобы произвести регистрацию. Инициализируйте токен с помощью следующей команды: $ ./pkitool --pkcs11-slots /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/ Каждая пара сертификат/закрытый ключ обладают своей уникальной строкой "Serialized id". Строка "serialized id" запрашиваемого сертификата должна быть указана в опции pkcs11-id с использованием одинарных ковычек. pkcs11-id 'aaaa/bbb/41545F5349474E415455524581D2A1A1B23C4AA4CB17FAF7A4600' Использование OpenVPN с PKCS#11Типичный набор опций OpenVPN для PKCS#11pkcs11-providers /usr/lib/pkcs11/ При этом будет выбран объект, который соответствует строке pkcs11-id. Расширенные опции OpenVPN для PKCS#11pkcs11-providers /usr/lib/pkcs11/provider1.so /usr/lib/pkcs11/provider2.so Это позволит загрузить в 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#11OpenSC 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) не будет работать с большинством смарт-карт из-за следующих причин:
Используя интерфейс 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 не является совсем беспроблемным делом. Вот несколько типичных подводных камней, чтобы вы были в курсе:
Более подробную информацию о механике директивы redirect-gateway см. в man-странице. Запуск OpenVPN-сервера на динамическом IP-адресе.Хотя OpenVPN-клиенты с динамическим IP-адресом могут легко получить доступ к серверу без каких-либо специальных настроек, все становится интереснее, когда сам сервер находится на динамическом адресе. Хотя OpenVPN не имеет проблем с обработкой ситуации, когда у сервера динамический адрес, требуются некоторые дополнительные настройки. Первым шагом будет получить динамический DNS-адрес, который может быть настроен «следовать» за сервером каждый раз, как изменится IP-адрес сервера. Существует несколько провайдеров службы динамического DNS, таких как dyndns.org. Следующим шагом является создание механизма, который каждый раз, как только меняется IP-адрес сервера, быстро обновляет динамическое DNS-имя новым IP-адресом, что позволяет клиентам находить сервер на его новом IP-адресе. Есть два основных способа сделать это:
Если в конфигурации клиента используется директива remote, которая ссылается на динамическое имя DNS, то OpenVPN-клиент чувствителен к смене IP-адреса сервера. Обычная последовательность событий такая: (а) клиент OpenVPN не получает вовремя keepalive-сообщение со старого IP-адреса сервера, что вызывает перезапуск (соединения -- прим. перев.), и (б) перезапуск является причиной того, что DNS-имя в директиве remote разрешается заново, что позволяет клиенту подключиться к новому IP-адресу сервера. Более подробную информацию можно найти в FAQ. Подключение к OpenVPN-серверу через HTTP-прокси.OpenVPN поддерживает соединения через HTTP-прокси с применением следующих режимов аутентификации:
Прежде всего, соединение через 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-клиенты и без этого должны увидеть машины на стороне сервера в своем сетевом окружении. В этом примере мы будем считать, что:
Если 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 эти директивы укажут OpenVPN-клиенту делать попытки связаться с server1, server2 и server3 в указанном порядке. Если существующее соединение разрывается, клиент OpenVPN будет пытаться подключиться к последнему серверу, с которым было соединение и если это не получится, перейдет к следующему серверу в списке. Вы также можете изменить порядок выбора серверов OpenVPN-клиентом на случайный, так что нагрузка от клиентов будет равномерно распределена по пулу серверов. remote-random Если вы хотите чтобы при сбое в разрешении DNS-имени OpenVPN-клиент переходил к очередному серверу в списке, добавьте следующее: resolv-retry 60 Параметр 60 указывает OpenVPN-клиенту пробовать разрешить каждое DNS-имя в директиве remote в течение 60 секунд, прежде чем перейти к следующему серверу в списке. Список серверов также может относиться к нескольким демонам OpenVPN-сервера, работающим на одном компьютере, каждый из которых принимает соединения на своем порту, например: remote smp-server1.mydomain 8000 Если ваши серверы являются многопроцессорными машинами, запуск нескольких демонов 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. Это может защитить от:
Использование 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 Непривилегированный режиме (только Linux)В Linux OpenVPN может работать полностью непривилегированным. Эта конфигурация немного сложнее, но обеспечивает лучшую безопасность. Для того чтобы работать с этой конфигурацией, OpenVPN должен быть настроен на использование iproute-интерфейса, это достигается путем указания --enable-iproute2 в configure-скрипте. На вашей системе также должен быть доступен пакет sudo. В этой конфигурации используется возможность Linux изменять разрешения на устройство tun таким образом, чтобы обычный пользователь мог получить к нему доступ. Также, для того, чтобы свойства интерфейса и таблица маршрутизации могли быть изменены (непривилегированным пользователем -- прим. перев.) для запуска (execute) iproute используется sudo. Конфигурация OpenVPN:
#!/bin/sh Вы также можете разрешить группу пользователей с помощью следующей команды:user1 ALL=(ALL) NOPASSWD: /sbin/ip %users ALL=(ALL) NOPASSWD: /sbin/ip Обратите внимание, что вы должны выбрать константу X и указать или tun или tap, но не оба.dev tunX/tapX openvpn --mktun --dev tunX --type tun --user user1 --group users Дальнейшие ограничения безопасности могут быть добавлены путем проверки параметров в скрипте /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 после инициализации, например:
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) ранее подписанного сертификата, так что он больше не может быть использован для целей аутентификации. Типичные причины для отзыва сертификата включают в себя:
ПримерВ качестве примера, мы будем отзывать сертификат client2, который мы сгенерировали выше, в разделе HOWTO "генерация ключей". Сперва откройте оболочку (shell) или окно командной строки и перейдите в каталог easy-rsa, как вы делали выше в разделе "генерация ключей". На Linux/BSD/Unix: . ./vars В Windows: vars Вы должны увидеть результат, похожий на этот: Using configuration from /root/openvpn/20/openvpn/tmp/easy-rsa/openssl.cnf Обратите внимание на "error 23" в последней строке. Это то, что вы хотите увидеть, т.к. это указывает, что проверка действительности (verification) для отозванного сертификата провалилась (failed). Скрипт revoke-full создаст CRL-файл (certificate revocation list, список отозванных сертификатов) с именем crl.pem в подкаталоге keys. Файл должен быть скопирован в каталог, в котором сервер OpenVPN может получить к нему доступ, затем проверка CRL должна быть включена в конфигурации сервера: crl-verify crl.pem Теперь сертификаты всех клиентов при подключении будут проверены в CRL, и при любом положительном совпадении соединение будет закрыто . Замечания о CRL
Важное примечание о возможных атаках "Man-in-the-Middle" если клиенты не проверяют сертификат сервера к которому они подключаются.Чтобы избежать возможных атак Man-in-the-Middle, когда авторизованный клиент пытается подключиться к другому клиенту, который выдет себя за сервер, убедитесь что сделали на клиентах проверку сертификата сервера. В настоящее время существует пять различных способов сделать это, они перечислены в порядке предпочтения:
Образцы файлов конфигурации OpenVPN 2.0
#################################################
############################################## Copyright © 2002-2008 by OpenVPN Technologies, Inc. OpenVPN is a trademark of OpenVPN Technologies, Inc. Источник статьи |