FreeBSD: Настройка OpenVPN с использованием сертификатов X.509

Опубликовано 12 декабря 2007 г. в рубрике FreeBSD » Виртуальные частные сети

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

Постановка задачи

Необходимо создать виртуальную частную сеть между несколькими офисами компании, подключенными к Интернет. Как известно, существует множество решений данного вопроса, которые многократно сравнивались по соотношениям функциональности / надежности / стоимости. Рекомендую Вам прочитать статью А. Бешкова Создаем кроссплатформенную виртуальную частную сеть VPN на основе OpenVPN. В ней описано очень простое, но достаточно надежное решение на базе бесплатного пакета OpenVPN, использующее статические ключи для шифрования трафика. OpenVPN позволяет разворачивать гораздо более гибкие конфигурации и использовать сертификаты TLS/SSL вместо статических ключей. В данной статье рассмотрена одна из таких конфигураций.

Исходные данные

Имеется сервер с FreeBSD, через который подсеть центрального офиса подключена к Интернет. На нем будет развернут сервер OpenVPN. Имеется два удаленных филиала, подсети которых также подключены к Интернет через серверы с FreeBSD (они будут клиентами OpenVPN) и компьютер системного администратора с Windows XP (он также будет клиентом OpenVPN). Локальная подсеть центрального офиса имеет адрес 192.168.0.0/24; локальная подсеть филиала № 1 – 192.168.1.0/24; локальная подсеть филиала № 2 – 192.168.2.0/24. Необходимо создать виртуальную частную сеть routed-типа (т.е. не пропускающую широковещательный трафик), с топологией Point-To-Multi-Point (один сервер и несколько клиентов), использующую для шифрования трафика TLS/SSL и обеспечивающую следующую политику маршрутизации:

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

При реализации описанного ниже я руководствовался документом OpenBSD Installation (в настоящее время документ по неизвестным причинам удален с сервера) и материалами Форума OpenNET. Я использовал (и продолжаю использовать) пакет OpenSSL, входящий в состав операционной системы, и последнюю версию порта OpenVPN. За время существования виртуальной частной сети ОС сервера и клиентов постепенно обновлялись с версии 4.10 до версии 7.1.

Установка сервера OpenVPN

Перед установкой сервера OpenVPN необходимо добавить в файл конфигурации ядра строку pseudo-device tun, если таковая отсутствует, пересобрать ядро и перезагрузить систему. Затем нужно установить OpenVPN из портов:

cd /usr/ports/security/openvpn
make install

Файлы конфигурация сервера OpenVPN хранятся в папке /usr/local/etc/openvpn. Для создания этой папки, а также всех необходимых вложенных папок и файлов необходимо выполнить следующую последовательность команд:

mkdir /usr/local/etc/openvpn
cd /usr/local/etc/openvpn
mkdir ccd
mkdir certs
mkdir crl
mkdir keys
mkdir private
mkdir req
chmod 700 keys private
echo "01" > serial
touch index.txt

Указанные команды создают папку /usr/local/etc/openvpn; вложенные в нее папки: ccd (конфигурации удаленных клиентов), certs (сертификаты клиентов и сервера), crl (списки отзыва сертификатов), keys (закрытые ключи сертификатов клиентов и сервера), private (закрытый ключ самоподписного доверенного сертификата (CA), req (запросы на сертификаты); ограничивают права доступа к папкам keys и private; создают базу данных сертификатов (файлы serial и index.txt).

Файл конфигурации OpenSSL

По умолчанию OpenSSL использует файл конфигурации /etc/ssl/openssl.cnf. Я рекомендую создать отдельный файл конфигурации OpenSSL в папке /usr/local/etc/openvpn. Данный файл должен называться openssl.cnf и иметь следующее содержимое:

[ ca ]
default_ca               = CA_default
[ CA_default ]
dir                      = /usr/local/etc/openvpn
crl_dir                  = $dir/crl
database                 = $dir/index.txt
new_certs_dir            = $dir/certs
certificate              = $dir/CA_cert.pem
serial                   = $dir/serial
crl                      = $dir/crl/crl.pem
private_key              = $dir/private/CA_key.pem
RANDFILE                 = $dir/private/.rand
default_days             = 3650
default_crl_days         = 365
default_md               = md5
unique_subject           = yes
policy                   = policy_any
x509_extensions          = user_extensions
[ policy_any ]
organizationName         = match
organizationalUnitName   = optional
commonName               = supplied
[ req ]
default_bits             = 2048
default_keyfile          = privkey.pem
distinguished_name       = req_distinguished_name
x509_extensions          = CA_extensions
[ req_distinguished_name ]
organizationName         = Organization Name (must match CA)
organizationName_default = Company
organizationalUnitName   = Location Name
commonName               = Common User or Org Name
commonName_max           = 64
[ user_extensions ]
basicConstraints         = CA:FALSE
[ CA_extensions ]
basicConstraints         = CA:TRUE
default_days             = 3650
[ server ]
basicConstraints         = CA:FALSE
nsCertType               = server

Создание самоподписного доверенного сертификата (CA)

Для создания самоподписного доверенного сертификата (Certification Authority, CA) и закрытого ключа для него необходимо выполнить следующую команду, находясь в папке /usr/local/etc/openvpn:

openssl req -new -nodes -x509 -keyout private/CA_key.pem -out CA_cert.pem -days 3650

Команда req заставляет OpenSSL создать сертификат, ключи: -new – cоздать запрос на сертификат, -nodes – не шифровать закрытый ключ, -x509 (совместно с -new) – создать самоподписной сертификат (CA), -keyout – задает местонахождение закрытого ключа, -out – задает местонахождение самоподписного сертификата, -days – задает время действия сертификата (365×10 дней, что приблизительно равно десяти годам). В процессе выполнения команды на экран будут выданы запросы о вводе таких параметров как: Country Name, State or Province Name; Locality Name; Organization Name; Organizational Unit Name; Common Name; Email Address. Самым важным параметром является значение Common Name. В данном случае оно должно совпадать с FQDN-именем сервера. Для просмотра результата генерации самоподписного сертификата и закрытого ключа необходимо выполнить следующую команду, находясь в папке /usr/local/etc/openvpn:

openssl x509 -noout -text -in CA_cert.pem       (для сертификата)
openssl rsa -noout -text -in private/CA_key.pem (для закрытого ключа)

Создание сертификата сервера

Перед созданием сертификата сервера необходимо создать запрос на сертификат сервера и закрытый ключ сервера. Для этого необходимо выполнить следующую команду, находясь в папке /usr/local/etc/openvpn:

openssl req -new -nodes -keyout keys/server.pem -out req/server.pem

Команда и ключи OpenSSL рассмотрены выше. В процессе выполнения комнды Вам опять придется ответить на вопросы. Ответы должны соответствовать ответам из предыдущего пункта. В ответ на дополнительные запросы "A challenge password []:" и "An optional company name []:" необходимо просто нажать <Enter>. Для просмотра результата генерации запроса на сертификат и закрытого ключа сервера необходимо выполнить следующую команду, находясь в папке /usr/local/etc/openvpn:

openssl req -noout -text -in req/server.pem  (для запроса на сертификат)
openssl rsa -noout -text -in keys/server.pem (для закрытого ключа)

Для создания сертификата сервера необходимо подписать запрос на сертификат сервера самоподписным доверенным сертификатом (CA). Для этого необходимо выполнить следующую команду, находясь в папке /usr/local/etc/openvpn:

openssl ca -batch -config openssl.cnf -extensions server -out certs/server.pem -infiles req/server.pem

Команда ca заставляет OpenSSL подписать запрос на сертификат, ключи: -config задает местонахождение файла конфигурации OpenSSL, -extensions – задает секцию файла конфигурации OpenSSL, содержащую дополнительные параметры генерируемого сертификата, -out – задает местонахождение генерируемого сертификата, -infiles – задает местонахождение запроса на сертификат, -batch – избавляет Вас от ответов на дополнительные вопросы. В процессе выполнения команды Вам будет задан вопрос "Sign the certificate? [y/n]:", на который нужно ответить утвердительно, после чего произойдет генерация сертификата и обновление базы данных сертификатов (файлов index.txt и serial). Для просмотра результата генерации сертификата необходимо выполнить следующую команду, находясь в папке /usr/local/etc/openvpn:

openssl x509 -noout -text -in certs/server.pem

Создание файла параметров Диффи-Хэлмана

Для создания файла параметров Диффи-Хэлмана, предназначенного для обеспечения более надежной защиты данных при установке соединения клиента с сервером, необходимо выполнить следующую команду, находясь в папке /usr/local/etc/openvpn:

openssl dhparam -out dh2048.pem 2048

Команда dhparam приказывает OpenSSL создать файл параметров Диффи-Хэлмана, число 2048 определяет разрядность в битах. Внимание: данная команда выполняется достаточно медленно даже на очень мощных компьютерах.

Создание клиентских сертификатов

Процедура создания клиентских запросов на сертификаты и закрытых ключей, подписания запросов на сертификаты и генерации сертификатов, а также просмотра запросов на сертификаты, сертификатов и закрытых ключей полностью аналогична соответствующей процедуре для сервера. Сделаю одно небольшое замечание: запросы на сертификаты, закрытые ключи и сертификаты должны иметь шаблонные имена, например, вида: req/RClient для запросов на сертификаты, keys/KClient для закрытых ключей и certs/CClient для сертификатов, соответственно. Слово Client должно быть заменено именем клиента, которое обязательно должно соответствовать значению параметра Common Name, вводимого при генерации запроса на сертификат для соответствующего клиента. Возможность дублирования Common Name у нескольких клиентов определяется конфигурацией сервера. Для генерации запроса на сертификат и закрытого ключа, а также подписания запроса на сертификат и генерации сертификата для клиента Client необходимо выполнить следующие команды, находясь в папке /usr/local/etc/openvpn:

openssl req -new -nodes -keyout keys/KClient.pem -out req/RClient.pem
openssl ca -batch -config openssl.cnf -out certs/CClient.pem -infiles req/RClient.pem

Для просмотра сгенерированных запроса на сертификат, закрытого ключа и сертификата клиента Client необходимо выполнить следующие команды, находясь в папке /usr/local/etc/openvpn:

openssl req -noout -text -in req/RClient.pem    (для запроса на сертификат)
openssl rsa -noout -text -in keys/KClient.pem   (для закрытого ключа)
openssl x509 -noout -text -in certs/CClient.pem (для сертификата)

На данном этапе для рассматриваемого случая необходимо создать три групы, состоящих из запроса на сертификат / закрытого ключа / сертификата, с именами Rclient1 / Kclient1 / Cclient1, Rclient2 / Kclient2 / Cclient2 и Rclient3 / Kclient3 / Cclient3 для филиала № 1 (Common Name – client1), для филиала № 2 (Common Name – client2) и для системного администратора (Common Name – client3), соответственно.

Создание списка отзыва сертификатов

Для создания списка отзыва сертификатов необходимо выполнить следующую команду, находясь в папке /usr/local/etc/openvpn:

openssl ca -config openssl.cnf -gencrl -out crl/crl.pem

Команда ca с ключем -gencrl заставляет OpenSSL создать список отзыва сертификатов, ключи: -config рассмотрен выше, -out – задает местонахождение списка отзыва сертификатов. Данная команда создает пустой список отзыва сертификатов. Для того, чтобы отозвать сертификат клиента Client необходимо выполнить следующую команду, находясь в папке /usr/local/etc/openvpn:

openssl ca -config openssl.cnf -revoke certs/CClient.pem

Команда ca с ключем -revoke заставляет OpenSSL отозвать заданный сертификат, ключ -config рассмотрен выше. Для просмотра списка отозванных сертификатов необходимо выполнить следующую команду, находясь в папке /usr/local/etc/openvpn:

openssl crl -noout -text -in crl/crl.pem

Создание статического ключа HMAC

Для создания статического ключа HMAC, обеспечивающего дополнительную защиту от DoS-атак и флудинга UDP-портов, необходимо выполнить следующую команду, находясь в папке /usr/local/etc/openvpn:

openvpn --genkey --secret ta.key

Файл конфигурации сервера

По умолчанию конфигурация сервера OpenVPN хранится в файле openvpn.conf, который должен находится в папке /usr/local/etc/openvpn. В рассматриваемом случае файл конфигурации имеет следующий вид:

dev               tun
local             <Внешний IP-адрес сервера>
port              1194
proto             udp
server            10.0.0.0 255.255.255.0
push              "route 10.0.0.0 255.255.255.0"
route             192.168.1.0 255.255.255.0
route             192.168.2.0 255.255.255.0
client-config-dir ccd
client-to-client
tls-server
dh                /usr/local/etc/openvpn/dh2048.pem
ca                /usr/local/etc/openvpn/CA_cert.pem
cert              /usr/local/etc/openvpn/certs/server.pem
key               /usr/local/etc/openvpn/keys/server.pem
crl-verify        /usr/local/etc/openvpn/crl/crl.pem
tls-auth          /usr/local/etc/openvpn/ta.key 0
comp-lzo
keepalive         10 120
tun-mtu           1500
mssfix            1450
persist-key
persist-tun
user              openvpn
group             openvpn
verb              3

В данном файле заданы следующие значения параметров сервера OpenVPN: dev – интерфейс OpenVPN, local и port – IP-адрес и порт, на которых OpenVPN принимает входящие соединения, proto – протокол (в данном случае UDP), server – пул IP-адресов, выделенный для виртуальной частной сети и автоматически распределяемый между клиентами, push – команда OpenVPN, передаваемая клиенту и выполняемая клиентом (в данном случае "route 10.0.0.0 255.255.255.0" добавляет на стороне клиента маршрут к виртуальной частной сети), route – добавляет на стороне сервера маршруты к локальным подсетям, находящимся за клиентами, client-config-dir – папка с файлами конфигурации клиентов, client-to-client – разрешение клиентам “видеть” друг друга (естественно, при наличии соответствующих правил маршрутизации), tls-server – включение поддержки TLS; dh – местонахождение файла параметров Диффи-Хэлмана, ca – местонахождение самоподписного доверенного сертификата (CA), cert – местонахождение сертификата сервера, key – местонахождение закрытого ключа сервера, crl-verify – местонахождение списка отзыва сертификатов, tls-auth – местонахождение статического ключа HMAC, comp-lzo – использование LZO-компрессии трафика, keeplive – поддержание соединения (в данном случае отправка пингов каждые 10 секунд, и закрытие соединения через две минуты после отсутствия ответных пакетов, как сервером, так и клиентами), tun-mtu и mssfix – параметры передачи данных по тоннелю, persist-tun – не закрывать / открывать по-новой tun-устройство при получении сигнала SIGUSR1 (перезапуск без привилегий root) или при выполнении ping-restarts, user и group – пользователь и группа, от имени которых работает OpenVPN после запуска (запуск выполняется под root’ом), verb – уровень детализации сообщений, выдаваемых OpenVPN в /var/log/messages.

Файлы конфигурации клиентов

Файлы конфигурации клиентов являются текстовыми файлами и содержат команды, выполняемые сервером при подключении клиентов. Имена файлов конфигурации клиентов должны соответствовать Common Name клиентов, т.е. при подключении клиента с Common Name client1 сервер выполнит команды, заданные в файле client1 и т.д. Файлы конфигурации клиентов должны находиться в папке /usr/local/etc/openvpn/ccd. Для рассматриваемого случая необходимо создать три файла конфигурации клиентов client1-client3:

cd /usr/local/etc/openvpn/ccd
touch client1 client2 client3

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

push "route 192.168.0.0 255.255.255.0"
iroute 192.168.1.0 255.255.255.0

Файл client2 аналогичен файлу client1 за исключением адреса локальной подсети, находящейся за клиентом:

push "route 192.168.0.0 255.255.255.0"
iroute 192.168.2.0 255.255.255.0

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

push "route 192.168.0.0 255.255.255.0"
push "route 192.168.1.0 255.255.255.0"
push "route 192.168.2.0 255.255.255.0"

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

Автоматический запуск сервера

Для автоматического запуска сервера OpenVPN при загрузке операционной системы необходимо добавить строку openvpn_enable="YES" в файл /etc/rc.conf.

Замечания по настройке брандмауэров

Для корректной работы сервера OpenVPN необходимо внести следующие изменения в настройки брандмауэра:

Разрешить прохождение любого трафика через интерфейс OpenVPN;
Разрешить прохождение UDP-трафика на внешний адрес сервера порт 1194;
Разрешить прохождение любого трафика из виртуальной частной сети в локальную подсеть;
Разрешить прохождение любого трафика из локальной подсети в виртуальную частную сеть;
Разрешить прохождение любого трафика из локальной подсети филиала № 1 в локальную подсеть;
Разрешить прохождение любого трафика из локальной подсети в локальную подсеть филиала № 1;
Разрешить прохождение любого трафика из локальной подсети филиала № 2 в локальную подсеть;
Разрешить прохождение любого трафика из локальной подсети в локальную подсеть филиала № 2.

Для ipfw (мой случай) нужно добавить следующие правила:

/sbin/ipfw -q add pass ip from any to any via ${vif}
/sbin/ipfw -q add pass udp from any to ${oip} 1194 in via ${oif}
/sbin/ipfw -q add pass ip from ${vnet} to ${inet} out via ${iif}
/sbin/ipfw -q add pass ip from ${inet} to ${vnet} in via ${iif}
/sbin/ipfw -q add pass ip from 192.168.1.0/24 to ${inet} out via ${iif}
/sbin/ipfw -q add pass ip from ${inet} to 192.168.1.0/24 in via ${iif}
/sbin/ipfw -q add pass ip from 192.168.2.0/24 to ${inet} out via ${iif}
/sbin/ipfw -q add pass ip from ${inet} to 192.168.2.0/24 in via ${iif}

Переменные shell имеют следующие значения: oip – внешний IP-адрес сервера, inet – адрес локальной подсети (в нашем случае – 192.168.0.0/24), vnet – адрес виртуальной частной сети (в нашем случае 10.0.0.0/24), iif – имя внутреннего интерфейса сервера (например, rl1), oif – имя внешнего интерфейса сервера (например, rl0), vif – имя интерфейса OpenVPN (например, tun0).
Настройка брандмауэров клиентов выполняется аналогично. Правила, начиная с пятого, зависят от реализованной политики маршрутизации. Для нашего случая правила ipfw для клиента client1 будут иметь вид (не забудьте, что теперь переменная shell inet определяет адрес локальной подсети клиента client1 – 192.168.1.0/24):

/sbin/ipfw -q add pass ip from any to any via ${vif}
/sbin/ipfw -q add pass udp from any to ${oip} 1194 in via ${oif}
/sbin/ipfw -q add pass ip from ${vnet} to ${inet} out via ${iif}
/sbin/ipfw -q add pass ip from ${inet} to ${vnet} in via ${iif}
/sbin/ipfw -q add pass ip from 192.168.0.0/24 to ${inet} out via ${iif}
/sbin/ipfw -q add pass ip from ${inet} to 192.168.0.0/24 in via ${iif}

Правила ipfw для клиента client2 не отличаются от правил для клиента client1 (не забудьте, что теперь переменная shell inet определяет адрес локальной подсети клиента client2 – 192.168.2.0/24).

Передача ключевых файлов клиенту

Для передачи файлов клиенту лучше использовать какой-либо твердый носитель, например дискету, но ни в коем случае не сеть Интернет. Чтобы скопировать файлы, необходимые клиенту Client, на дискету, нужно выполнить следующую последовательность команд:

mount -t msdos /dev/fd0 /mnt
cd /usr/local/etc/openvpn
cp certs/CClient.pem /mnt
cp keys/KClient.pem /mnt
cp CA_cert.pem /mnt
cp ta.key /mnt
umount /mnt

Данные команды монтируют дискету к папке /mnt, копируют сертификат клиента, закрытый ключ клиента, самоподписной доверенный сертификат (CA) и статический ключ HMAC на дискету, а затем размонтируют ее.

Клиентское программное обеспечение

Если клиент работает под FreeBSD, то установка клиента OpenVPN ничем не отличается от установки сервера (используется тот же самый порт), если под Windows, есть два варианта – OpenVPN и OpenVPN GUI. Первый вариант больше подходит для постоянно включенных серверов (OpenVPN может быть установлена как служба Windows), второй – для мобильных клиентов, периодически подключающихся к корпоративной сети. Например, я использую на домашнем ноутбуке OpenVPN GUI, когда мне нужно подключиться к корпоративной сети. Во всех перечисленных случаях файлы конфигурации имеют один и тот же формат. Внимание: в случае использовании Windows-клиентов не забывайте использовать в файлах конфигурации двойные бэкслэши вместо одинарных слэшей, используемых в файлах конфигурации Unix-клиентов.

Файл конфигурации клиентского программного обеспечения

Конфигурация клиента OpenVPN хранится в файле openvpn.conf, который должен находится в папке /usr/local/etc/openvpn, если мы имеем дело с FreeBSD-клиентом, или в файле с произвольным именем и расширением .ovpn, который должен находиться в папке C:Program FilesOpenVPNconfig, если при установке OpenVPN (OpenVPN GUI) не был задан путь, отличный от предлагаемого по умолчанию. Рассмотрим файл конфигурации клиента client3, установленного на ноутбук с Windows XP. Клиент OpenVPN GUI установлен в каталог по умолчанию, а ключевые файлы, которые ранее были переписаны на дискету, сохранены на диске P: в папке OpenVPN (я предпочитаю шифровать этот диск). Для рассматриваемого случая файл конфигурация клиента OpenVPN имеет следующий вид:

client
dev          tun
proto        udp
remote       <IP-адрес сервера OpenVPN>
tls-client   <FQDN сервера OpenVPN>
tls-remote
ca           "P:\\OpenVPN\\CA_cert.pem"
cert         "P:\\OpenVPN\\Ссlient3.pem"
key          "P:\\OpenVPN\\Kсlient3.pem"
tls-auth     "P:\\OpenVPN\\ta.key" 1
ns-cert-type server
comp-lzo
tun-mtu      1500
mssfix       1450
verb         3

В данном файле заданы следующие значения параметров клиента OpenVPN: client – упрощенный вариант указания того, что это файл конфигурации клиента, dev – устройство OpenVPN, proto – протокол (в данном случае UDP), remote – IP-адрес сервера OpenVPN, tls-client – включение поддержки TLS, tls-remote – Common Name сервера OpenVPN, ca – местонахождение самоподписного доверенного сертификата (CA), cert – местонахождение сертификата клиента, key – местонахождение закрытого ключа клиента, tls-auth – местонахождение статического ключа HMAC, comp-lzo, tun-mtu, mssfix и verb рассмотрены выше. Повторяю, файлы конфигурации FreeBSD-клиентов отличаются только форматом задания путей к файлам.

Заключение

С помощью описанной виртуальной частной сети ежедневно осуществляется работа как со службами Windows (Remote Administrator и Terminal Services), так и со службами Unix (FTP, NFS, SSH и Telnet). Если в процессе настройки у Вас возникнут проблемы, внимательно анализируйте лог-файлы и читайте обсуждение cтатьи на форуме OpenNET. Если ничего не помогает, задавайте мне вопросы, попробуем решить проблему вместе.

Теги: OpenVPN, TLS/SSL, X.509

Подписка на новости

Если Вам понравилась эта публикация, подпишитесь на RSS или E-mail рассылку, канал Twitter, где я сообщаю об интересных событиях в мире OpenSource, канал FriendFeed, где я делюсь ссылками на полезные публикации по администрированию Linux/Unix. Спасибо за визит!

Другие публикации в рубрике ‘FreeBSD » Виртуальные частные сети’

FreeBSD: Назначение статических IP-адресов клиентам OpenVPN

63 комментария

Vital, 23 ноября 2007 г. в 16:22

Очень понравилась статья по openvpn на сертификатах X509. Моих 3 офиса таким способом соединены между собой. Шлюзы правда на OpenBSD. Все работает отлично. Огромное Вам спасибо за Ваш труд!

Ответить на этот комментарий
- SergeySL, 23 ноября 2007 г. в 22:00
  
  Я очень рад, что статья оказалась полезной
  
  Ответить на этот комментарий
iTango, 26 января 2008 г. в 23:37

Вечер добрый!
Есть ещё один вопрос относительно статьи.
…дело в том, что пытаясь соединить две сети посредством VPN, реализована схема:
local-1 -> FreeBSD(server) -> ::Inet:: <- FreeBSD(client) <- local-2
в роли VPN-сервера выступает фря, на которой поднят конфиг, аналогичный тому, который описывается в статье…
а вот вторая сеть “local-2″ пытается “увидеть” сеть “local-1″ миную тоже роутер с Фряхой, на которой поднят VPN, но с конфигом клиента…
так вот тунель образуется удачно! НО!!!
ПИНГИ (на Фряхах есть PF, но он в отрубе!..):
- от FreeBSD(client) к FreeBSD(server) – ИДУТ!
- от FreeBSD(client) к любой машине за FreeBSD(server) – ИДУТ!
- от любой мащины за FreeBSD(client) к FreeBSD(server) – НЕ ИДУТ!!!
- от любой мащины за FreeBSD(client) к любой мащине за FreeBSD(server) – НЕ ИДУТ!!!
- – - – - – - – - -
в чём может быть проблема???

Ответить на этот комментарий
- SergeySL, 27 января 2008 г. в 12:00
  
  ПИНГИ (на Фряхах есть PF, но он в отрубе!..):
  - от FreeBSD(client) к FreeBSD(server) – ИДУТ!
  - от FreeBSD(client) к любой машине за FreeBSD(server) – ИДУТ!
  - от любой мащины за FreeBSD(client) к FreeBSD(server) – НЕ ИДУТ!!!
  - от любой мащины за FreeBSD(client) к любой мащине за FreeBSD(server) – НЕ ИДУТ!!!
  
  Есть всего два направления, которые стоит внимательно посмотреть. Во-первых, это таблицы маршрутизации, во-вторых, – настройки брандмауэров клиента и сервера. Таблицы маршрутизации можно посмотреть командой netstat -nr. Где находятся пакеты, отброшенные PF, я не знаю. Сам пользуюсь IPFW. Вся информация об отброшенных им пакетах пишется в /var/log/security. Еще, мне кажется, что у Вас некорректно прописаны конфигурации клиентов, находящиеся в папке openvpn/ccd сервера. В частности, в них скорее всего отсутствуют описания сетей, находящихся за клиентами (смотрите iroute в man’е OpenVPN)
  
  По поводу первого вопроса, заданного мылом:
  
  ВОПРОС: на каком этапе КЛИЕНТ обращается к своему КОНФИГУ и где определяется в конфигурации клиента к какому из этих 3-х файлов обращаться именно ему???
  
  Клиент не обращается к этим файлам. Их использует сервер. Например, когда к серверу подключается клиент с CN=client1, сервер выполняет команды, записанные в файл openvpn/ccd/client1. Вот и все
  
  Ответить на этот комментарий
  - iTango, 27 января 2008 г. в 20:15
    
    Спасибо за ответ!..
    Заработало ПОЧТИ всё!..
    Удалённые машины стали пинговаться после того, как были добавлены такие строки в конфигурацию PF-фильтра клиента:
    vpn_if="tun1" ... nat on $vpn_if from $office_net to any -> ($vpn_if) ... pass quick from any to $vpn_net keep state pass quick from $vpn_net to any keep state ...
    Всё прекрасно работает при условии, что PF-фильтр на стороне VPN-сервера ВЫКЛЮЧЕН
    Я понимаю, что PF и IPFW отличаются в принципе, но всё же хочеться настроить соединение с использованием PF… Гугление на эту тему результата не приносит… может Вы или кто из посетителей Вашего сайта сталкивались с подобной проблемой?…
    …Буду признателен за ответ!
    …Ещё раз благодарю за внимание…
    
    Ответить на этот комментарий
    - SergeySL, 27 января 2008 г. в 22:00
      
      Я понимаю, что PF и IPFW отличаются в принципе, но всё же хочеться настроить соединение с использованием PF… Гугление на эту тему результата не приносит… может Вы или кто из посетителей Вашего сайта сталкивались с подобной проблемой?…
      
      Внимательно посмотрите /etc/defaults/rc.conf на предмет опций, связанных с PF. Одной из них должно быть имя log-файла. Когда разберетесь, откройте еще одну консоль, запустите tail -f <имя log-файла PF> и смотрите, какие правила что гасят
      
      Ответить на этот комментарий
bmv, 5 апреля 2008 г. в 16:16

Большое спасибо за статью по настройке OpenVPN! Сразу не заработало, но в конце-концов разобрался. У меня была связка OpenBSD 4.2 + OpenVPN 2.0.9 + WinXP. Вот некоторые замечания:

1. На OpenBSD не существует устройства tun, поэтому в конфиге сервера нужно прописывать tunX (в моем случае было tun0). В отличие от FreeBSD, имя пользователя и группы, на правах которых работает демон, в OpenBSD предваряется подчеркиванием (_openvpn вместо openvpn).

2. Параметр clien-config-dir лучше прописать с полным путем, например /etc/openvpn/ccd, хотя если запускать демон с опцией --cd /etc/openvpn, это не обязательно.

3. Мои “добавки” к конфигу сервера:
daemon # старт в виде демона log /var/log/vpn.log # удобно для разборок writepid /var/run/vpn.pid # хранить pid по этому пути # чтобы остановить сервер, достаточно будет ввести # kill `cat /var/run/vpn.pid` (тоже для удобства)

4. Имя файла настройки клиента в каталоге ccd должно в точности, вплоть до регистра совпадать с Common Name, введенном на этапе создания сертификата. В Вашей статье имеется некоторая путаница (то в верхнем регистре, то в нижнем).

5. Моя “добавка” в конфиг клиента на WinXP (на Win2000 SP4 тоже работает):
ip-win32 netsh
Судя по проведенным экспериментам, с этой опцией клиент шустрее коннектится к серверу.

6. Ну и наконец, способ запуска демона при старте системы. Я прописал в /etc/rc.local следующую команду:
/usr/local/sbin/openvpn --cd /etc/openvpn --config openvpn.conf
(у меня все настройки в /etc/openvpn в отличие от статьи).

P.S. Можно также запустить демон в “параноидальном” режиме с использованием опции --chroot. Тогда он будет ограничен каталогом, указанным в данной опции. Например:
/usr/local/sbin/openvpn --chroot /etc/openvpn --config openvpn.conf
Однако в этом случае нельзя указывать каталоги (например для лога и pid’a вне chrooted каталога). Да и пути в конфиге придется поправить.

Вроде все… Еще раз спасибо за полезную статью.

Ответить на этот комментарий
- SergeySL, 5 апреля 2008 г. в 22:00
  
  Я никогда не сталкивался с OpenBSD, поэтому не могу знать ее нюансов.
  
  4. Имя файла настройки клиента в каталоге ccd должно в точности, вплоть до регистра совпадать с Common Name, введенном на этапе создания сертификата. В Вашей статье имеется некоторая путаница (то в верхнем регистре, то в нижнем).
  
  В статье приведены шаблонные команды без указания реально используемых мной CName.
  
  По поводу тонкостей конфигурирования для конкретных ситуаций – просто уверен, что не существует идеальных решений, окончательную доводку придется делать применительно к конкретной сети. Четкая и однозначная организация скриптов запуска, каталогов и т.д. – один из многочисленных моментов, за которые я уважаю Фрю!
  P.S.: я очень рад, что статья Вам пригодилась. Спасибо за полезные (особенно для OpenBSD’шников) комментарии. Успехов!
  
  Ответить на этот комментарий
bmv, 5 апреля 2008 г. в 16:21

Вот что еще забыл спросить… С туннелями на основе ipsec не занимались? Имеется такая необходимость, но разобраться пока не могу… Конкретно нужно состыковать *BSD со шлюзом на основе LRP (т.н. Linux Riuter Project – сейчас уже не существует, преемником является проект LEAF). Там используется именно ipsec-туннель.

Ответить на этот комментарий
- SergeySL, 5 апреля 2008 г. в 22:00
  
  С туннелями на основе ipsec не занимались?
  
  Никогда не занимался
  
  Ответить на этот комментарий
INStorm, 16 апреля 2008 г. в 11:29

Доброе время суток.
Вопрос по OpenVPN. Есть шлюз FreeBSD & IPFW & OpenVPN, сеть за шлюзом 192.168.11.0/24. Есть желание попасть в туже подсеть что за шлюзом. Можно ли мне скинуть примерный конфиг для реализации этой задачи.

Ответить на этот комментарий
- SergeySL, 16 апреля 2008 г. в 22:00
  
  Есть шлюз FreeBSD & IPFW & OpenVPN, сеть за шлюзом 192.168.11.0/24. Есть желание попасть в туже подсеть что за шлюзом.
  
  Здравствуйте. VPN для этого и создавались.
  
  Можно ли мне скинуть примерный конфиг для реализации этой задачи.
  
  Описанный конфиг полностью подойдет. Естественно, придется подправить IP-адреса.
  
  Ответить на этот комментарий
angel, 2 мая 2008 г. в 6:14

Спасибо за статью, все работает идеально, есть только один вопрос, а как настроить OpenVPN, чтобы DHCP выдавал не вразброс IP Адреса, а который я назначил клиенту… Заранее спасибо.

Ответить на этот комментарий
- SergeySL, 2 мая 2008 г. в 12:00
  
  На здоровье
  
  как настроить OpenVPN, чтобы DHCP выдавал не вразброс IP Адреса, а который я назначил клиенту…
  
  Я не заморачивался назначением статических адресов клиентам. Попробуйте как написано Configuring client-specific rules and access policies, и, если можно, напишите, что получилось
  
  Ответить на этот комментарий
  - angel, 22 июня 2008 г. в 23:02
    
    Как я обещал все решается очень просто. Постоянные статические IP адреса.
    В /usr/local/etc/openvpn/ccd при создании файла с настройками для клиента помните:
    ifconfig-push 10.10.200.2 10.10.200.1
    этой строкой организуем езернет-тун с сеткой 10.10.200.0, 2-мя тачками с айпишнегами 10.10.200.2 и 10.10.200.1 и броадкастом 10.10.200.3
    Соответственно, при создании 2-го, 3-го и т.д. клиента – строка должна принимать вид:
    ifconfig-push 10.10.200.6 10.10.200.5 ifconfig-push 10.10.200.10 10.10.200.9
    
    Да, чуть не забыл. В конфиг сервера надо добавить строчку такую:
    #задаем IP-адрес сервера и маску подсети # (виртуальной сети) - можно произвольную, (я выбрал такую) server 10.10.200.0 255.255.255.0 # добавляем маршрут сервер-клиент route 10.10.200.0 255.255.255.252
    У меня все работает
    
    Ответить на этот комментарий
    - SergeySL, 15 марта 2009 г. в 12:00
      
      Возникла необходимость сделать статические адреса клиентам. Спасибо за справку. Все работает отлично
      
      Ответить на этот комментарий
mirzo, 26 мая 2008 г. в 14:27

Привет! Я хотел бы узнать есть ли исходник или любая информация по созданию библиотеки шифрования потоков по алгоритму ГОСТ 28147-89 для Linux. Заранее Спасибо!

Ответить на этот комментарий
- SergeySL, 26 мая 2008 г. в 22:00
  
  Я хотел бы узнать есть ли исходник или любая информация по созданию библиотеки шифрования потоков по алгоритму ГОСТ 28147-89 для Linux.
  
  Привет! У меня нет. Неужели вот так сложно?
  
  Ответить на этот комментарий
  - mirzo, 30 мая 2008 г. в 15:11
    
    Спасибо ещё раз!
    
    Ответить на этот комментарий
    - SergeySL, 30 мая 2008 г. в 22:00
      
      На здоровье
      
      Ответить на этот комментарий
mind, 10 октября 2008 г. в 13:47

Добрый день! Недавно прочитал Вашу статью. Статья хорошая, только я все равно не могу понять, как настроить маршрутизацию между сетями. В моем случае ситуация такая:

Comp1(server) OS: OpenSUSE 11:
eth1 Link encap:Ethernet HWaddr 00:E1:25:10:03:91 inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::2e1:25ff:fe10:391/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:424674 errors:0 dropped:0 overruns:0 frame:0 TX packets:388566 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:73713300 (70.2 Mb) TX bytes:257978990 (246.0 Mb) Interrupt:21 Base address:0x6c00
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:192.168.3.1 P-t-P:192.168.3.2 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
server.conf: writepid /var/openvpn/pid status /var/openvpn/status 10 local aa.aa.aa.aa port 1194 proto udp dev tun0 comp-lzo ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/server.crt key /etc/openvpn/keys/server.key dh /etc/openvpn/keys/dh1024.pem tls-auth /etc/openvpn/keys/ta.key 0 server 192.168.3.0 255.255.255.0 push "route 192.168.1.0 255.255.255.0" keepalive 10 120 auth SHA1 cipher AES-256-CBC max-clients 10 log-append /var/log/openvpn.log verb 3 mute 20 user _openvpn group _openvpn persist-key persist-tun #chroot /var/empty
Comp2(client): OS Win2003:
client.ovpn: client dev tun remote proto udp resolv-retry infinite nobind pull comp-lzo persist-key persist-tun verb 3 ca "C:\Documents and Settings\Администратор\Рабочий стол\admin\client1\ca.crt" cert "C:\Documents and Settings\Администратор\Рабочий стол\admin\client1\client1.crt" key "C:\Documents and Settings\Администратор\Рабочий стол\admin\client1\client1.key" tls-auth "C:\Documents and Settings\Администратор\Рабочий стол\admin\client1\ta.key" 1 ns-cert-type server auth SHA1 cipher AES-256-CBC
Подключение по локальной сети - Ethernet адаптер: DNS-суффикс этого подключения . : IP-адрес . . . . . .. . . . . . : 192.168.0.100 Маска подсети . . . . . . . . . : 255.255.255.0 Основной шлюз . . . . . . . . . : 192.168.0.2
Подключение по локальной сети 3 - Ethernet адаптер: -vpn DNS-суффикс этого подключения . : IP-адрес . . . . . .. . . . . . : 192.168.3.6 Маска подсети . . . . . . . . . : 255.255.255.252 Основной шлюз . . . . . . . . . :
Канал поднимается, клиент и сервер пингуются в этой подсети 192.168.3.0/24.
Вопрос как настроить маршрутизацию, чтобы подсеть 192.168.0.0/24 имела доступ к 192.168.1.0/24 и наоборот?
Буду признателен, если поможете!

Ответить на этот комментарий
- SergeySL, 10 октября 2008 г. в 22:00
  
  Добрый день!
  
  Вопрос как настроить маршрутизацию, чтобы подсеть 192.168.0.0/24 имела доступ к 192.168.1.0/24 и наоборот?
  
  Даже не стоило запускать ifconfig и ipconfig. Ваша проблема кроется в отсутствии файлов конфигурации клиентов (все правила маршрутизации прописываются в них). Создайте в папке с файлами конфигурации сервера OpenVPN папку ccd и добавьте в файл конфигурации сервера строку client-config-dir ccd. После этого создайте в папке ccd файл конфигурации нужного клиента (имя файла должно быть таким же, как CN клиента!). Для Вашего случая в данном файле необходимо указать сеть, которая находится за клиентом (192.168.0.0/24) и за сервером (192.168.3.0/24):
  push "route 192.168.3.0 255.255.255.0" iroute 192.168.0.100 255.255.255.0
  Не забудьте добавить нужные правила брандмауэра, и все заработает
  
  Ответить на этот комментарий
zifert, 25 ноября 2008 г. в 10:35

Добрый день.
Спасибо за вашу статью “Настройка OpenVPN…”. Не для красного словца будет сказано, но мне кажется что ваша статья на сегодняшний день самая лучшая в рунете, а может быть была бы лучшей и в английской интерпретации.
Когда то бегло прочитав вашу первую редакцию, все прошло успешно. Сейчас видимо изменились требования к конфигурационному файлу openssl.cnf, точнее к его структуре. Я попытался почитать документацию с сайта но безуспешно. Не могли бы вы подсказать (используется ваш конфиг) куда рыть:
openssl req -config /etc/openvpn/openssl.cnf -new -nodes -x509 -keyout private/CA_key.pem -out CA_cert.pem -days 3650: Error Loading extension section CA_extensions 2405:error:22097082:X509 V3 routines:DO_EXT_NCONF:unknown extension name:v3_conf.c:124: 2405:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:v3_conf.c:93:name=default_days, value=3650
еще раз Спасибо!

Ответить на этот комментарий
- SergeySL, 25 ноября 2008 г. в 12:00
  
  Добрый вечер!
  
  Когда то бегло прочитав вашу первую редакцию, все прошло успешно. Сейчас видимо изменились требования к конфигурационному файлу openssl.cnf, точнее к его структуре. Я попытался почитать документацию с сайта но безуспешно. Не могли бы вы подсказать (используется ваш конфиг) куда рыть
  
  В настоящий момент установлена FreeBSD 7.0 RELEASE. OpenSSL родной (тот, который входит в состав системы). Специально проверил команду, все работает нормально. Думаю, что проблема в содержимом файла openssl.cnf, который в настоящий момент полностью соответсвует приведенному в статье. Аккуратненько скопируйте его. Этого должно быть достаточно.
  
  Ответить на этот комментарий
  - zifert, 26 ноября 2008 г. в 0:37
    
    Добрый вечер!
    В данный момент установлена Slackware 12.1 все пакеты из “коробки” (включая ядро).
    Текущая версия OpenSSL:
    root@storm:/etc/ssl# openssl version: OpenSSL 0.9.8i 15 Sep 2008
    до этого была предшествующая 0.9.8g
    Дело в том, что в конфиге по умолчанию секция [v3_ca], на которую ссылается секция [req], по ману openssl не может содержать параметр default_days = 3650.
    Я удалил этот параметр из вашего конфига и все пошло на ура! (естествено, конфиг по дефолту при генерации сертификата и ключа CA тоже не ругается). На другом маршрутизаторе у меня стоит версия OpenSSL:
    root@hcsrouter:~# openssl version: OpenSSL 0.9.8a 11 Oct 2005
    То есть мне кажется, что с этого времени что то изменилось. Интересно какой версии ваш OpenSSL пакет?
    Последний вопрос – не могли бы вы сказать, какую смысловую нагрузку несут в себе два параметра:
    subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always,issuer:always
    и насколько они важны?
    Спасибо, что дочитали до конца! И извините за излишнюю назойливость.
    
    Ответить на этот комментарий
    - SergeySL, 26 ноября 2008 г. в 0:39
      
      Интересно какой версии ваш OpenSSL пакет?
      
      openssl version: OpenSSL 0.9.8e 23 Feb 2007
      
      Я удалил этот параметр из вашего конфига и все пошло на ура!
      
      Файл openssl.cnf совсем не мой. Он взят из англоязычного документа “OpenBSD Installation”, вместо которого в настоящий момент выдается “The page cannot be found”
      
      Последний вопрос – не могли бы вы сказать, какую смысловую нагрузку несут в себе два параметра:
      subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always,issuer:always
      и насколько они важны?
      
      По параметрам тоже ничего не подскажу, не заморачивался
      
      Ответить на этот комментарий
      - zifert, 26 ноября 2008 г. в 0:41
        
        Прошу прощения что не уточнил, я имел в виду параметр не может находиться в секции расширений, а именно (в данном случае ваш конфиг):
        [ CA_extensions ] basicConstraints = CA:TRUE default_days = 3650
        
        Ответить на этот комментарий
        
        SergeySL, 26 ноября 2008 г. в 12:00
        
        Спасибо за инфу. Пригодится при апгрейде системы
        
        Ответить на этот комментарий
hamel1on, 2 июня 2009 г. в 19:53

Хорошая статья!!
Поднял openvpn, вот настройки
клиент на винде хп.
client dev tun proto udp remote 212.46.12.227 tls-client office1 tls-remote mtb ca C:\OpenVPN\CA_cert.pem ns-cert-type server comp-lzo tun-mtu 1500 mssfix 1450 verb 1
сервер на линуксах
client dev tun proto udp remote 212.46.12.227 tls-client office1 tls-remote mtb ca C:\OpenVPN\CA_cert.pem ns-cert-type server comp-lzo tun-mtu 1500 mssfix 1450 verb 1
файл office1:
push "route 192.168.30.0 iroute 192.168.2.0 255.255.255.0
вот маршруты линукс
Destination Gateway 10.10.10.2 * 212.46.12.224 * 192.168.2.0 10.10.10.2 192.168.30.0 * 10.10.10.0 10.10.10.2 169.254.0.0 * default 212.46.12.225
вот виндовые
Сетевой адрес 0.0.0.0 10.10.10.0 255.255.255.0 10.10.10.4 255.255.255.252 10.10.10.6 255.255.255.255 10.255.255.255 255.255.255.255 127.0.0.0 192.168.2.0 192.168.2.100 255.255.255.255 192.168.2.255 255.255.255.255 192.168.30.0 255.255.255.0 224.0.0.0 224.0.0.0 255.255.255.255 255.255.255.255 255.255.255.255 255.255.255.255 Основной шлюз: работает. Единственное не могу достучаться до локалки удаленного офиса. с удаленного офиса в главнфый запросы проходят. файрвол не причем, отключал его совсем.
/> /> /> /> /> /> 255.255.255.0"
Genmask Flags Metric Ref Use Iface
255.255.255.255 UH 0 0 0 tun0
255.255.255.240 U 0 0 0 eth0
255.255.255.0 UG 0 0 0 tun0
255.255.255.0 U 0 0 0 eth1
255.255.255.0 UG 0 0 0 tun0
255.255.0.0 U 0 0 0 eth1
0.0.0.0 UG 0 0 0 eth0
Маска сети Адрес шлюза Интерфейс Метрика
0.0.0.0 192.168.2.1 192.168.2.100 20
10.10.10.5 10.10.10.6 1
10.10.10.6 10.10.10.6 30
127.0.0.1 127.0.0.1 30
10.10.10.6 10.10.10.6 30
255.0.0.0 127.0.0.1 127.0.0.1 1
255.255.255.0 192.168.2.100 192.168.2.100 20
127.0.0.1 127.0.0.1 20
192.168.2.100 192.168.2.100 20
10.10.10.5 10.10.10.6 1
240.0.0.0 10.10.10.6 10.10.10.6 30
240.0.0.0 192.168.2.100 192.168.2.100 20
10.10.10.6 10.10.10.6 1
192.168.2.100 192.168.2.100 1
192.168.2.1

Ответить на этот комментарий
- SergeySL, 3 июня 2009 г. в 0:56
  
  Доброй ночи!
  
  Единственное не могу достучаться до локалки удаленного офиса.
  
  Для начала внимательно исправьте конфигурацию сервера. На вскидку:
  1. Добавьте определение VPN, например, server 10.0.0.0 255.255.255.0;
  2. Добавьте команду отправки клиенту маршрута к VPN, например: push "route 10.0.0.0 255.255.255.0";
  3. Добавьте маршрут к сети за клиентом, в Вашем случае: route 192.168.2.0 255.255.255.0;
  4. Расскажите серверу, где лежит файл office1, добавив параметр client-config-dir.
  P.S.: Самое главное – будьте внимательнее
  
  Ответить на этот комментарий
  - hamel1on, 3 июня 2009 г. в 14:05
    
    конфиг сервера я указал не тот.
    вот правельный
    dev tun daemon log /var/log/vpn.log local 212.46.12.227 port 1194 proto udp server 10.10.10.0 255.255.255.0 push "route 10.10.10.0 255.255.255.0" route 192.168.2.0 255.255.255.0 client-config-dir /usr/local/etc/openvpn/ccd/ client-to-client tls-server mtb dh /usr/local/etc/openvpn/dh2048.pem ca /usr/local/etc/openvpn/CA_cert.pem cert /usr/local/etc/openvpn/certs/server.pem key /usr/local/etc/openvpn/keys/server.pem crl-verify /usr/local/etc/openvpn/crl/crl.pem tls-auth /usr/local/etc/openvpn/ta.key 0 comp-lzo keepalive 10 120 tun-mtu 1500 mssfix 1450 persist-key persist-tun user openvpn group openvpn verb 3
    выяснилось данный конфиг работает для схемы линукс – интернет – сервер на виндах 2 сетевые карты одна для локалки другая для интернета- локальная сеть.
    не работает для схемы линукс – интернет – роутер длинк – локалка (на одном из компов с вин хп стоит openvpn сервер.
    как сделать чтобы работала последняя схема? может всем компам дать второй ip, чтобы интернет работал на прямую через роутер а впн через вторую группу адресов шел?
    
    и еще одна загвостка если интернет отключается то впн соединение заного клиент на вин хп не востанавливает как исправить?
    
    Ответить на этот комментарий
    - SergeySL, 3 июня 2009 г. в 15:26
      
      не работает для схемы линукс – интернет – роутер длинк – локалка (на одном из компов с вин хп стоит openvpn сервер.
      как сделать чтобы работала последняя схема? может всем компам дать второй ip, чтобы интернет работал на прямую через роутер а впн через вторую группу адресов шел?
      
      Всем компам точно не нужно ничего давать. Можно попробовать сделать проброс порта сервера OpenVPN через ДЛинк на внешний адрес (который видно из Инета) и поменять таблицу маршрутизации компа, на котором стоит сервер. Сам так не делал, т.к. это (имхо) изврат. Попробуйте, напишите, что получилось
      
      и еще одна загвостка если интернет отключается то впн соединение заного клиент на вин хп не востанавливает как исправить?
      
      Внимательно почитайте описание параметра keepalive
      
      P.S.: Используйте теги при оформлении сообщений!
      
      Ответить на этот комментарий
DFC, 4 июня 2009 г. в 17:42

Здравствуйте. У меня проблема, похожая на описанную комрадом hamellon – никак не могу разобраться с маршрутизацией. После подключения клиента к серверу оба могут пинговать друг друго по виртуальным IP, но по реальным (внутренним) IP – только клиент может пинговать сервер (и только его, другие машины из его подсети не доступны), а сервер клиента – нет. Хочется чтобы машины из клиентской подсети видели машины из серверной подсети и наоборот. Прошу помощи, так как уже второй день никак ничего дельного не могу нагуглить Буду благодарен любой помощи или подсказке.

Сети:
192.168.20.7 – внутренний IP сервера OpenVPN
192.168.2.2 – внутренний IP клиента
10.10.200.0 – виртуальная сеть для tun0
Cервер на FreeBSD 7.0, клиент – FreeBSD 7.2, порты свежие.

Конфиг сервера:
port 2000 proto udp dev tun0 ca /usr/local/etc/openvpn/keys/ca.crt cert /usr/local/etc/openvpn/keys/freebsd.crt key /usr/local/etc/openvpn/keys/freebsd.key dh /usr/local/etc/openvpn/keys/dh1024.pem server 10.10.200.0 255.255.255.0 push "route 192.168.20.0 255.255.255.0" client-config-dir ccd route 10.10.200.0 255.255.255.0 route 192.168.2.0 255.255.255.0 tls-server tls-auth keys/ta.key 0 tls-timeout 120 auth MD5 # cipher BF-CBC keepalive 10 120 comp-lzo max-clients 5 user nobody group nobody persist-key persist-tun status /var/log/openvpn/openvpn-status.log log /var/log/openvpn/openvpn.log

содержимое файла настроек маршрутизации для клиента alfa
ifconfig-push "10.10.200.6 10.10.200.1" iroute 192.168.2.0 255.255.255.0

конфиг клиента
dev tun proto udp remote port 2000 client resolv-retry infinite ca keys/ca.crt cert keys/alfa.crt key keys/alfa.key tls-client tls-auth keys/ta.key 1 auth MD5 cipher BF-CBC ns-cert-type server comp-lzo persist-key persist-tun #up /usr/local/etc/openvpn/openvpn_up.sh status /var/log/openvpn/openvpn-status.log log /var/log/openvpn/openvpn.log

Ответить на этот комментарий
- SergeySL, 4 июня 2009 г. в 19:12
  
  Добрый вечер!
  
  Прошу помощи, так как уже второй день никак ничего дельного не могу нагуглить Буду благодарен любой помощи или подсказке. Содержимое файла настроек маршрутизации для клиента alfa:
  ifconfig-push "10.10.200.6 10.10.200.1" iroute 192.168.2.0 255.255.255.0
  
  Если статические адреса клиентов не обязательны, делайте, как написано в статье. В противном случае – адреса, указанные в ifconfig-push, должны попадать под маску 255.255.255.252. Если с адресами и масками не очень, выполните под Виндой openvpn --show-valid-subnets. Эта команда выдаст список валидных пар адресов:
  ... [ 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]
  P.S. ниже я уже обсуждал вопрос статических адресов с angel. Читайте внимательно, здесь есть ссылка на соответствующий документ и пример практической реализации
  
  Ответить на этот комментарий
  - DFC, 4 июня 2009 г. в 20:26
    
    Последовал Вашему совету, привел свой конфиг к виду, похожему на Ваш, но ничего не изменилось…
    server.conf
    port 2000 proto udp dev tun0 ca /usr/local/etc/openvpn/keys/ca.crt cert /usr/local/etc/openvpn/keys/freebsd.crt key /usr/local/etc/openvpn/keys/freebsd.key dh /usr/local/etc/openvpn/keys/dh1024.pem server 10.10.200.0 255.255.255.0 push "route 10.10.200.0 255.255.255.0" client-config-dir ccd route 192.168.2.0 255.255.255.0 tls-server tls-auth keys/ta.key 0 tls-timeout 120 auth MD5 # cipher BF-CBC keepalive 10 120 comp-lzo max-clients 5 user nobody group nobody persist-key persist-tun status /var/log/openvpn/openvpn-status.log log /var/log/openvpn/openvpn.log
    ccd/alfa:
    push "route 192.168.20.0 255.255.255.0" iroute 192.168.2.0 255.255.255.0
    
    Ответить на этот комментарий
    - SergeySL, 4 июня 2009 г. в 21:18
      
      Последовал Вашему совету, привел свой конфиг к виду, похожему на Ваш, но ничего не изменилось…
      
      Файрволы отключены?
      
      Ответить на этот комментарий
      - DFC, 5 июня 2009 г. в 0:53
        
        да, и никогда не включались
        кстати, а демон routed должен быть запущен? Хотя, вроде и так и так пробовал…
        
        Ответить на этот комментарий
        
        SergeySL, 5 июня 2009 г. в 2:55
        
        По порядку:
        
        client-config-dir ccd tls-auth keys/ta.key 0
        
        Пропишите полные пути, начиная с /
        
        tls-timeout 120 auth MD5 # cipher BF-CBC max-clients 5
        
        Эти строки чем-нибудь обоснованы, или как
        
        а демон routed должен быть запущен?
        
        У меня он никогда не был запущен.
        
        Ответить на этот комментарий
        
        DFC, 5 июня 2009 г. в 14:21
        
        Прописал полные пути к конфиг и к ключу.
        tls-timeout 120
        auth MD5 #
        cipher BF-CBC
        max-clients 5
        Было взято из другой статьи, сейчас закоментировал.
        Результат тот же.
        
        Ответить на этот комментарий
        
        SergeySL, 5 июня 2009 г. в 17:25
        
        Результат тот же.
        
        Увеличиваете значение verb у клиента и сервера, а потом внимательно смотрите, что происходит в момент подключения. Туннель создается, маршруты вроде прописаны, файрволы не включены. Могу предположить только опечатку в именах файлов / путях или некорректные права доступа (для пользователя nobody:nobody, естественно). В логе обязательно будет написано, что не нашлось, не открылось и т.д. и т.п. С учетом приведенных в порядок конфигов (лучше еще раз внимательно проверьте, причем не по нескольким статьям, а по одной) больше ничего не могу подсказать
        
        Ответить на этот комментарий
        
        DFC, 15 июня 2009 г. в 17:16
        
        Хорошо, с этим мы разобрались, подсети доступны. Но появилась другая неприятная вещь – пропадение пакетов. В связи с этим хотел задать вопрос – может ли это быть вызвано некорректной работой сервера или клиента? Или же это виноват Волгателеком? (физическое подключение у обоих офисов через adsl) И можно-ли как то это диагностировать, что бы быть уверенным?
        
        Ответить на этот комментарий
        
        SergeySL, 15 июня 2009 г. в 23:42
        
        Но появилась другая неприятная вещь – пропадение пакетов. В связи с этим хотел задать вопрос – может ли это быть вызвано некорректной работой сервера или клиента? Или же это виноват Волгателеком? (физическое подключение у обоих офисов через adsl) И можно-ли как то это диагностировать, что бы быть уверенным?
        
        Как раз ВолгаТелеком очень сильно грешит незамороченной шаблонной настройкой оборудования. Вполне возможно, что на одном из маршрутизаторов трафик через определенные порты ограничивается. Доказать это практически невозможно, т.к. никто не предоставит Вам конфиги и логи. Рекомендую использовать другой порт, а может и протокол TCP/IP. Лучшее решение можно найти только опытным путем
Mem Secur | Воспаленная логика., 6 июля 2009 г. в 14:03

[...] FreeBSD —> http://www.sergeysl.ru/openvpn-x509/ [...]

Ответить на этот комментарий
Илья, 15 сентября 2009 г. в 11:31

Сергей!
После формирования клиентских сертификатов не удается простмотреть вот это:
openssl x509 -noout -text -in certs/CClient.pem
- файл certs/CClient.pem пустой. До этого этапа все четко по инструкции.
Спасибо.

Ответить на этот комментарий
- SergeySL, 16 сентября 2009 г. в 3:03
  
  А что выдает openssl ca -batch -config openssl.cnf -out certs/CClient.pem -infiles req/RClient.pem ?
  Судя по всему, должна выдавать сообщение об ошибке, с которой и следует разобраться
  
  Ответить на этот комментарий
Илья, 16 сентября 2009 г. в 11:32

То же самое что и при формировании серверного сертификата, за исключением нет строки update database. то есть без ошибок. еще не понятно с конфигурационным файлом openssl.cnf. По вашей статье я сделал файл в /usr/local/etc/openvpn а что сделать с /etc/ssl ? удалить его? при формировании сертификатов, запросов все равно openssl читает файл из etc/ssl

Ответить на этот комментарий
- SergeySL, 16 сентября 2009 г. в 17:38
  
  нет строки update database
  
  Это и есть ошибка. И связана она с некорректным файлом openssl.cnf. При необходимости путь к этому файлу задается ключиком -config. Если все делать под Фрей, находясь в папке /usr/local/etc/openvpn, то будет использоваться файл именно из этой папки. Трогать дефолтный конфиг OpenSSL, находящий в /etc/ssl, не нужно.
  
  Ответить на этот комментарий
bvn13, 2 ноября 2009 г. в 0:12

Спасибо за статью, очень интересная и познавательная, но у меня возникла проблема (т.к. я всего три дня сижу за Убунтой). Сервер на Убунте вроде поднялся (кста, как проверить), а вот клиент (Виста) не может к ней приконнектиться. Ошибка: WSATIMEOUT. Не получен ответ. Как можно поправить?

Ответить на этот комментарий
- bvn13, 2 ноября 2009 г. в 0:19
  
  Ошибся я.
  Ошибка: Connection reset by peer (WSAECONNRESET)
  
  Ответить на этот комментарий
- SergeySL, 2 ноября 2009 г. в 0:36
  
  Если не знаете, как проверить, запущен ли сервер, и слушает ли он 1194 порт UDP, то для начала неплохо почитать мануалы или обратиться к специалистам
  
  Ответить на этот комментарий
  - bvn13, 2 ноября 2009 г. в 0:46
    
    ну так я вроде и обращаюсь к специалистам
    подскажите, плз, где почитать, что посмотреть? очень хочется изучить убунту…
    
    Ответить на этот комментарий
    - SergeySL, 2 ноября 2009 г. в 1:03
      
      Вы мне льстите А если серьезно, за три дня такие вещи не учат. Понимаю, что хочется, но это невозможно. Азы, вещь скучная, но без них никуда . Теперь по серверу. С Ubuntu я не знаком, а под Фрёй можно проверить состояние сервера: /usr/local/etc/rc.d/openvpn status, можно найти процесс openvpn в списке процессов: ps -ax | grep openvpn, можно найти сокет openvpn в списке открытых сокетов: sockstat -4 | grep openvpn, можно посмотреть, что openvpn пишет в файл /var/log/messages. Кроме сервера есть еще файлы конфигурации клиентов, брандмауэр и прочие мелочи. На Висте также может быть включен брандмауэр и/или антивирус. Не думаю, что Вам стало легче от моего ответа
      
      Ответить на этот комментарий
bvn13, 2 ноября 2009 г. в 1:25

не, я не такой дурак, чтоб не понять то, что Вы написали… Статус не получил, по процессам пишет вот это:
2735 pts/0 S+ 0:00 grep --color=auto openvpn
сокеты глянул вот так (на вашу строчку ругается):
sockstat -P process openvpn USER PROCESS PID PROTO SOURCE ADDRESS FOREIGN ADDRESS STATE
в логах ничего нету по поиску “openvpn” и “vpn”

Ответить на этот комментарий
- SergeySL, 2 ноября 2009 г. в 1:49
  
  Слово “дурак” я не упоминал. Что обозначают ключи команд, которые я написал, можно посмотреть в FreeBSD Man Pages, а потом найти аналоги в man’е Ubuntu. Задайте отдельный лог в конфиге OpenVPN: log <имя файла>, увеличьте детальность лога, для начала: verb 4, выполните команду запуска сервера и посмотрите, что будет в этом логе. Должно стать теплее
  
  Ответить на этот комментарий
SergeySL, 4 ноября 2009 г. в 14:34

Написал отдельную заметку о назначении статических IP-адресов клиентам OpenVPN.

Ответить на этот комментарий
Саня, 8 марта 2010 г. в 11:13

Подскажите не могу решить проблему с OpenVPN. Есть офис-сервер freebsd 7.2 поднял OpenVPN server.conf:
port 443 proto tcp dev tun keepalive 20 240 server 10.20.30.0 255.255.255.0 route 10.20.30.0 255.255.255.0 push "route 192.168.21.0 255.255.255.0" ifconfig-pool-persist ipp.txt ifconfig 10.20.30.1 255.255.255.0 #server-bridge 10.20.30.1 255.255.255.0 10.20.30.253 client-to-client ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/server.crt key /etc/openvpn/keys/server.key dh /etc/openvpn/keys/dh1024.pem tls-auth /etc/openvpn/keys/ta.key 0 tls-timeout 120 cipher BF-CBC persist-key persist-tun user nobody group nobody comp-lzo max-clients 10 log /var/log/openvpn/openvpn.log status /var/log/openvpn/openvpn-status.log verb 4 mute 10
Сетка в офисе 192.168.21.0. Виртуальный IP-адрес дома 10.20.30.6. И туда и обратно пинг идет, т.е. OpenVPN 10.20.30.1 отвечает. Проблема не вижу сеть офиса? И не понимаю как сконфигурить правила в фаэрволе. При тесте на стороне клиента вижу. Пытаюсь достучаться к сети офиса и вот что вижу
C:\Documents and Settings\Серж>tracert -d 192.168.21.3 Трассировка маршрута к 192.168.21.3 с максимальным числом прыжков 30 1 <1 мс <1 мс <1 мс 10.44.30.1 2 <1 мс <1 мс

Ответить на этот комментарий
- SergeySL, 8 марта 2010 г. в 16:08
  
  Во-первых, зачем лишние огороды:
  
  ifconfig-pool-persist ipp.txt
  ifconfig 10.20.30.1 255.255.255.0
  tls-timeout 120
  cipher BF-CBC
  mute 10
  
  Во-вторых, дома не должно быть ни каких виртуальных адресов (их раздает сервер OpenVPN), просто должно стоять Получать IP-адрес автоматически, другими словами – настройки Tap32-интерфейса под Виндой трогать не нужно.
  В-третьих, про файрвол у меня написано ОЧЕНЬ подробно + выше я уже отвечал, как его настроить.
  Будьте внимательнее, за Вас Вашу VPN никто не настроит
  
  Ответить на этот комментарий
  - Саня, 9 марта 2010 г. в 10:10
    
    ок попробую разобраться. я так понял ifconfig 10.20.30.1 255.255.255.0 это лишнее. На стороне винды ничего не трогал 10.20.30.6 я имел в виду что этот адрес мне автоматом присвоил сам openvpn. Я читал разные статьи)) не доходит пока, фаэрвол пытаюсь разрулить но у меня сейчас он все разрешает по умолчанки. И вопрос. Я так понял таблиц с маршрутами городить ненадо на фряхе?
    
    Ответить на этот комментарий
    - SergeySL, 9 марта 2010 г. в 11:19
      
      я так понял ifconfig 10.20.30.1 255.255.255.0
      
      Однозначно, лишнее.
      
      Я так понял таблиц с маршрутами городить не надо на фряхе?
      
      Нет.
      P.S.: с файрволом стоит разобраться. В дальнейшем очень пригодится. Рекомендую начать с handbook – IPFW и вообще этот сайт добавить в закладки.
      
      Ответить на этот комментарий
      - Саня, 9 марта 2010 г. в 22:43
        
        Сергей вроде разобрался и все заработало но только почему-то на работе. Такое может быть? Пример. Два белых ip в офисе х.х.х.210 и .213 Сервак крутиться на 213. Клиент и сетка офиса висели на 210. ну и выход в инет на нем. Подключаю ноут с 210 айпи к сети офиса, рабочая группа офиса и клиента не совподаю (специально для теста разные). запускаю openvpn, через пару мгновений уже вижу в сетевом окружении рабочую сеть и все необходимое. В логах все чисто. Раз рабочая группа клиента и офиса разные но общие сетевые ресурсы вижу то значит vpn работает в логах то же все чисто. Как только пытаю из дома доцепиться то сетки не видит. в логах такая вот бодяга:
        Tue Mar 9 22:22:37 2010 us=233239 212.45.15.3:1044 [client] Peer Connection Initiated with 212.45.15.3:1044 Tue Mar 9 22:22:37 2010 us=233405 client/212.45.15.3:1044 OPTIONS IMPORT: reading client specific options from: ccd/client Tue Mar 9 22:22:37 2010 us=233656 client/212.45.15.3:1044 MULTI: Learn: 10.20.30.6 -> client/212.45.15.3:1044 Tue Mar 9 22:22:37 2010 us=233690 client/212.45.15.3:1044 MULTI: primary virtual IP for client/212.45.15.3:1044: 10.20.30.6 Tue Mar 9 22:22:37 2010 us=233721 client/212.45.15.3:1044 MULTI: internal route 192.168.21.0/24 -> client/212.45.15.3:1044 Tue Mar 9 22:22:37 2010 us=233754 client/212.45.15.3:1044 MULTI: Learn: 192.168.21.0/24 -> client/212.45.15.3:1044 Tue Mar 9 22:22:37 2010 us=233797 client/212.45.15.3:1044 REMOVE PUSH ROUTE: 'route 192.168.21.0 255.255.255.0' Tue Mar 9 22:22:37 2010 us=233836 client/212.45.15.3:1044 REMOVE PUSH ROUTE: 'route 192.168.21.0 255.255.255.0' Tue Mar 9 22:22:38 2010 us=199479 client/212.45.15.3:1044 PUSH: Received control message: 'PUSH_REQUEST' Tue Mar 9 22:22:38 2010 us=199642 client/212.45.15.3:1044 SENT CONTROL [client]: 'PUSH_REPLY,route 192.168.21.2 255.255.255.2 Tue Mar 9 22:25:57 2010 us=112680 client/212.45.15.3:1044 MULTI: Learn: 192.168.21.2 -> client/212.45.15.3:1044 Tue Mar 9 22:29:52 2010 us=416851 client/212.45.15.3:1044 Connection reset, restarting [-1]
        
        Ответить на этот комментарий
        
        SergeySL, 10 марта 2010 г. в 0:03
        
        Ничего не понял:
        
        Сервак крутиться на 213, клиент и сетка офиса висели на 210. Ну и выход в инет на нем. Подключаю ноут с 210 айпи к сети офиса, рабочая группа офиса и клиента не совподаю (специально для теста разные).
        
        Ответить на этот комментарий
Саня, 10 марта 2010 г. в 8:52

Вопрос тогда по-другому. Комп, на котором клиент openvpn крутиться, имеет рабочую группу home. Я захожу в сетевое окружение и вижу расшаренные папки офиса и компы совсем другой рабочей группы. Я так понимаю у меня значит VPN работает )). Но дома почему-то нифига. Может быть это из за провайдера?

Ответить на этот комментарий
- SergeySL, 10 марта 2010 г. в 11:37
  
  Через такую VPN, как описана в статье, не видно рабочие группы (она не пропускает широковещательный трафик). Можно подключаться к TCP/IP или UDP службам, но не через сетевое окружение. Что и как Вы делаете, я не знаю, но судя по вопросам, ничего хорошего. Сделайте для начала одноранговую VPN. Там все намного проще.
  P.S.: Пожалуйста пишите аккуратнее, т.к. другие люди могут читать Вашу писанину
  
  Ответить на этот комментарий

SergeySL homepage