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

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

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

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

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

Имеется сервер с 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 (один сервер и несколько клиентов), использующую для шифрования трафика SSL/TLS и обеспечивающую следующую политику маршрутизации:

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

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

Установка сервера 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               = sha1
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 Files\OpenVPN\config, если при установке OpenVPN (OpenVPN GUI) не был задан путь, отличный от предлагаемого по умолчанию. Рассмотрим файл конфигурации клиента client3, установленного на ноутбук с Windows XP. Клиент OpenVPN GUI установлен в каталог по умолчанию, а ключевые файлы, которые ранее были переписаны на дискету, сохранены на диске P: в папке OpenVPN (я предпочитаю шифровать этот диск). Для рассматриваемого случая файл конфигурация клиента OpenVPN имеет следующий вид:

client
dev          tun
proto        udp
remote       <IP-адрес сервера OpenVPN>
tls-client
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, ca — местонахождение самоподписного доверенного сертификата (CA), cert — местонахождение сертификата клиента, key — местонахождение закрытого ключа клиента, tls-auth — местонахождение статического ключа HMAC, comp-lzo, tun-mtu, mssfix и verb рассмотрены выше. Повторяю, файлы конфигурации FreeBSD-клиентов отличаются только форматом задания путей к файлам.

Заключение

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

Понравилась статья?

Подпишитесь на RSS или почтовую рассылку;

Поделитесь ссылкой в социальной сети или блоге:

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

Vital
23.11.2007 в 16:22 | Ответить
Очень понравилась статья по openvpn на сертификатах X509. Моих 3 офиса таким способом соединены между собой. Шлюзы правда на OpenBSD. Все работает отлично. Огромное Вам спасибо за Ваш труд!
- SergeySL
  23.11.2007 в 22:00 | Ответить
  Я очень рад, что статья оказалась полезной 🙂
  - Павел
    22.10.2013 в 13:35 | Ответить
    У меня есть вопрос по брандмауэру — ядро пересобирать с дивертом, ядерным натом, просто натом или как? У меня IPFW настроен сейчас просто без этих всех опций. Но я чувствую, что если реализовывать OpenVPN сервер, нужно будет все это настраивать.
    - SergeySL
      23.10.2013 в 13:17 | Ответить
      Обычно собираю ядро с опциями:
      options IPFIREWALL # Firewall options IPDIVERT # Divert sockets options DUMMYNET # dummynet(4) bandwidth limiter
      Хватает для маршрутизации, включая NAT, и ограничения полосы пропускания с помощью ipfw.
      - ttys
        23.10.2013 в 20:48 | Ответить
        на самом деле этого достаточно
        options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_FORWARD options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=50 options IPFIREWALL_NAT options LIBALIAS
        и диверт 100 лет уже не нужен
        
        SergeySL
        24.10.2013 в 06:40 | Ответить
        Я использую natd и верю man’ам, а там написано:
        …The natd utility provides a Network Address Translation facility for use with divert(4) sockets under FreeBSD…
        …To enable support for divert sockets, place the following lines in the kernel configuration file:
        options IPFIREWALL
        options IPDIVERT…
        На всякий случай, на рабочих серверах сейчас стоит 8.4-RELEASE-p4 FreeBSD 8.4-RELEASE-p4 #0 r255664,
        Дома 9.2-RELEASE FreeBSD 9.2-RELEASE #0 r256643, тоже все работает. А если так, то зачем изобретать велосипед?
        
        ttys
        24.10.2013 в 07:16 | Ответить
        если бы никто не изобретал велосипед — то досих пор все сидели бы на FreeBSD версии 4Х или 5Х
        натд уже давно труп
        рекомендую посмотреть на ng_nat вроде как интересная штука, сам не пробовал т.к. в основном юзаю pf
        
        SergeySL
        24.10.2013 в 07:22 | Ответить
        Пока все устраивает, поэтому пользуемся дедовскими способами 🙂
      - Павел
        23.10.2013 в 21:04 | Ответить
        Огромное спасибо, все получилось, все работает. Статья просто отличная, хотя я бы не сказал, что она будет слишком простой, особенно для новичков. К примеру, там где правила, нужно добавить ссылку на то, как правильно заполнять файл скрипта брандмауэра ipfw
        Но у меня остался еще очень важный вопрос. Дело в том, что если мне придется вдруг защитить ключ действующего сертификата паролем (build-key-pass). То есть мне придется отзывать существующий сертификат, и генерить его заново. Но где гарантия, что после отзыва серт сгенерится с таким же именем? Кроме того, если я захочу начать сначала всю историю сертификатов, мне придется сделать следующие действия (а возможно ли так вообще, не сломается ли программа?)
        1. Удалить из папки certs сертификаты 01.pem 02.pem и так далее
        2. Удалить из файла index.txt все его содержимое
        3. Сбросить счетчик в файле serial на 01
        
        SergeySL
        24.10.2013 в 07:00 | Ответить
        Огромное спасибо, все получилось, все работает.
        На здоровье!
        Статья просто отличная, хотя я бы не сказал, что она будет слишком простой, особенно для новичков. К примеру, там где правила, нужно добавить ссылку на то, как правильно заполнять файл скрипта брандмауэра ipfw
        Дайте ссылку на более простую статью, это раз, а два, может еще новичков зубы лечить научим простыми словами или дома многоэтажные строить?
        Но у меня остался еще очень важный вопрос. Дело в том, что если мне придется вдруг защитить ключ действующего сертификата паролем (build-key-pass). То есть мне придется отзывать существующий сертификат, и генерить его заново. Но где гарантия, что после отзыва серт сгенерится с таким же именем? Кроме того, если я захочу начать сначала всю историю сертификатов, мне придется сделать следующие действия (а возможно ли так вообще, не сломается ли программа?)
        1. Удалить из папки certs сертификаты 01.pem 02.pem и так далее
        2. Удалить из файла index.txt все его содержимое
        3. Сбросить счетчик в файле serial на 01
        Пароль ключа сертификата меняется без перегенерации. А вообще Вы очень веселый человек. Вам нужна гарантия, или может мне файлики попереименовывать/покорректировать?
        P.S.: Не понимаю, почему людей, написавших что-то совершенно безвозмездно, считают идиотами с экспертными знаниями, уймой времени и желанием помочь всем и каждому. Нет, ну правда, почему?
        
        Павел
        24.10.2013 в 12:35 | Ответить
        Сергей, я не считаю вас идиотом. Зачем мне это? Хотелось бы конечно узнать как ставить и менять пароль без перегенерации сертификата. А насчет того помочь или не помочь — это только ваше право. Можете помогать, можете не помогать. FreeBSD отличная, но сложная система, и мне приходится собирать знания со всего Интернета. Только по одному поводу недоумеваю — почему же я на столь чудесный относительно богатой информации блог наткнулся так поздно. Могу кстати поделиться файликами — скриптами резервного копирования конфигурационных файлов сервера, файлом rc.ipfw с аккуратно написанными правилами ipfw, конфигурационными файлами сервера pure-ftpd, некоторыми написанными самостоятельно правилами Fail2Ban, файлом sysctl.conf с заведенными туда опциями.
        
        SergeySL
        24.10.2013 в 19:10 | Ответить
        Сергей, я не считаю вас идиотом.
        Слава Богу 😀
        Хотелось бы конечно узнать как ставить и менять пароль без перегенерации сертификата.
        man openssl не предлагаю, прекрасно понимаю, что Вам лень вникать, а Google с Яндексом отменили? Что они говорят по поводу how change openvpn key passphrase? Причины моего негатива все еще не понятны?
        А насчет того помочь или не помочь — это только ваше право. Можете помогать, можете не помогать. FreeBSD отличная, но сложная система, и мне приходится собирать знания со всего Интернета. Только по одному поводу недоумеваю — почему же я на столь чудесный относительно богатой информации блог наткнулся так поздно.
        Я всегда с удовольствием помогаю заинтересованным людям, которые действительно искали доступную мне информацию, но не смогли ее найти. Вы же ничего не искали, даже комменты здесь не прочитали. В них есть ответы на все Ваши вопросы. Спасибо за лестный отзыв о блоге, к сожалению, я ничего не пишу уже два года (писанина требует времени, и ничего не дает взамен). Если Вы взялись за FreeBSD, придется вникнуть в основные моменты, которые не всегда сразу понятны и/или хорошо описаны. Зато после успешного прохождения данного этапа дальнейшие проблемы будут решаться все проще и проще.
        Могу кстати поделиться файликами — скриптами резервного копирования конфигурационных файлов сервера, файлом rc.ipfw с аккуратно написанными правилами ipfw, конфигурационными файлами сервера pure-ftpd, некоторыми написанными самостоятельно правилами Fail2Ban, файлом sysctl.conf с заведенными туда опциями.
        Да все это есть, только заточено под конкретные системы, поэтому вряд ли интересно широким массам.
iTango
26.01.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.01.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.01.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.01.2008 в 22:00 | Ответить
      Я понимаю, что PF и IPFW отличаются в принципе, но всё же хочеться настроить соединение с использованием PF… Гугление на эту тему результата не приносит… может Вы или кто из посетителей Вашего сайта сталкивались с подобной проблемой?…
      Внимательно посмотрите /etc/defaults/rc.conf на предмет опций, связанных с PF. Одной из них должно быть имя log-файла. Когда разберетесь, откройте еще одну консоль, запустите tail -f <имя log-файла PF> и смотрите, какие правила что гасят
bmv
05.04.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
  05.04.2008 в 22:00 | Ответить
  Я никогда не сталкивался с OpenBSD, поэтому не могу знать ее нюансов.
  4. Имя файла настройки клиента в каталоге ccd должно в точности, вплоть до регистра совпадать с Common Name, введенном на этапе создания сертификата. В Вашей статье имеется некоторая путаница (то в верхнем регистре, то в нижнем).
  В статье приведены шаблонные команды без указания реально используемых мной CName.
  По поводу тонкостей конфигурирования для конкретных ситуаций — просто уверен, что не существует идеальных решений, окончательную доводку придется делать применительно к конкретной сети. Четкая и однозначная организация скриптов запуска, каталогов и т.д. — один из многочисленных моментов, за которые я уважаю Фрю!
  P.S.: я очень рад, что статья Вам пригодилась. Спасибо за полезные (особенно для OpenBSD’шников) комментарии. Успехов!
bmv
05.04.2008 в 16:21 | Ответить
Вот что еще забыл спросить… С туннелями на основе ipsec не занимались? Имеется такая необходимость, но разобраться пока не могу… Конкретно нужно состыковать *BSD со шлюзом на основе LRP (т.н. Linux Riuter Project — сейчас уже не существует, преемником является проект LEAF). Там используется именно ipsec-туннель.
- SergeySL
  05.04.2008 в 22:00 | Ответить
  С туннелями на основе ipsec не занимались?
  Никогда не занимался
INStorm
16.04.2008 в 11:29 | Ответить
Доброе время суток.
Вопрос по OpenVPN. Есть шлюз FreeBSD & IPFW & OpenVPN, сеть за шлюзом 192.168.11.0/24. Есть желание попасть в туже подсеть что за шлюзом. Можно ли мне скинуть примерный конфиг для реализации этой задачи.
- SergeySL
  16.04.2008 в 22:00 | Ответить
  Есть шлюз FreeBSD & IPFW & OpenVPN, сеть за шлюзом 192.168.11.0/24. Есть желание попасть в туже подсеть что за шлюзом.
  Здравствуйте. VPN для этого и создавались.
  Можно ли мне скинуть примерный конфиг для реализации этой задачи.
  Описанный конфиг полностью подойдет. Естественно, придется подправить IP-адреса.
angel
02.05.2008 в 06:14 | Ответить
Спасибо за статью, все работает идеально, есть только один вопрос, а как настроить OpenVPN, чтобы DHCP выдавал не вразброс IP Адреса, а который я назначил клиенту… Заранее спасибо.
- SergeySL
  02.05.2008 в 12:00 | Ответить
  На здоровье
  как настроить OpenVPN, чтобы DHCP выдавал не вразброс IP Адреса, а который я назначил клиенту…
  Я не заморачивался назначением статических адресов клиентам. Попробуйте как написано Configuring client-specific rules and access policies, и, если можно, напишите, что получилось ❓
  - angel
    22.06.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.03.2009 в 12:00 | Ответить
      Возникла необходимость сделать статические адреса клиентам. Спасибо за справку. Все работает отлично
mirzo
26.05.2008 в 14:27 | Ответить
Привет! Я хотел бы узнать есть ли исходник или любая информация по созданию библиотеки шифрования потоков по алгоритму ГОСТ 28147-89 для Linux. Заранее Спасибо! 🙂
- SergeySL
  26.05.2008 в 22:00 | Ответить
  Я хотел бы узнать есть ли исходник или любая информация по созданию библиотеки шифрования потоков по алгоритму ГОСТ 28147-89 для Linux.
  Привет! У меня нет. Неужели вот так сложно?
  - mirzo
    30.05.2008 в 15:11 | Ответить
    Спасибо ещё раз!
    - SergeySL
      30.05.2008 в 22:00 | Ответить
      На здоровье
mind
10.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.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.11.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.11.2008 в 12:00 | Ответить
  Добрый вечер!
  Когда то бегло прочитав вашу первую редакцию, все прошло успешно. Сейчас видимо изменились требования к конфигурационному файлу openssl.cnf, точнее к его структуре. Я попытался почитать документацию с сайта но безуспешно. Не могли бы вы подсказать (используется ваш конфиг) куда рыть
  В настоящий момент установлена FreeBSD 7.0 RELEASE. OpenSSL родной (тот, который входит в состав системы). Специально проверил команду, все работает нормально. Думаю, что проблема в содержимом файла openssl.cnf, который в настоящий момент полностью соответсвует приведенному в статье. Аккуратненько скопируйте его. Этого должно быть достаточно.
  - zifert
    26.11.2008 в 00: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.11.2008 в 00: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.11.2008 в 00:41 | Ответить
        Прошу прощения что не уточнил, я имел в виду параметр не может находиться в секции расширений, а именно (в данном случае ваш конфиг):
        [ CA_extensions ] basicConstraints = CA:TRUE default_days = 3650
        
        SergeySL
        26.11.2008 в 12:00 | Ответить
        Спасибо за инфу. Пригодится при апгрейде системы 💡
hamel1on
02.06.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 cert C:\OpenVPN\CClient.pem key C:\OpenVPN\Kclient.pem tls-auth C:\OpenVPN\ta.key 1 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 cert C:\OpenVPN\CClient.pem key C:\OpenVPN\Kclient.pem tls-auth C:\OpenVPN\ta.key 1 ns-cert-type server comp-lzo tun-mtu 1500 mssfix 1450 verb 1
файл office1:
push "route 192.168.30.0 255.255.255.0" iroute 192.168.2.0 255.255.255.0
вот маршруты линукс
Destination Gateway Genmask Flags Metric Ref Use Iface 10.10.10.2 * 255.255.255.255 UH 0 0 0 tun0 212.46.12.224 * 255.255.255.240 U 0 0 0 eth0 192.168.2.0 10.10.10.2 255.255.255.0 UG 0 0 0 tun0 192.168.30.0 * 255.255.255.0 U 0 0 0 eth1 10.10.10.0 10.10.10.2 255.255.255.0 UG 0 0 0 tun0 169.254.0.0 * 255.255.0.0 U 0 0 0 eth1 default 212.46.12.225 0.0.0.0 UG 0 0 0 eth0
вот виндовые
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика 0.0.0.0 0.0.0.0 192.168.2.1 192.168.2.100 20 10.10.10.0 255.255.255.0 10.10.10.5 10.10.10.6 1 10.10.10.4 255.255.255.252 10.10.10.6 10.10.10.6 30 10.10.10.6 255.255.255.255 127.0.0.1 127.0.0.1 30 10.255.255.255 255.255.255.255 10.10.10.6 10.10.10.6 30 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.2.0 255.255.255.0 192.168.2.100 192.168.2.100 20 192.168.2.100 255.255.255.255 127.0.0.1 127.0.0.1 20 192.168.2.255 255.255.255.255 192.168.2.100 192.168.2.100 20 192.168.30.0 255.255.255.0 10.10.10.5 10.10.10.6 1 224.0.0.0 240.0.0.0 10.10.10.6 10.10.10.6 30 224.0.0.0 240.0.0.0 192.168.2.100 192.168.2.100 20 255.255.255.255 255.255.255.255 10.10.10.6 10.10.10.6 1 255.255.255.255 255.255.255.255 192.168.2.100 192.168.2.100 1 Основной шлюз: 192.168.2.1
- SergeySL
  03.06.2009 в 00: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
    03.06.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
      03.06.2009 в 15:26 | Ответить
      не работает для схемы линукс — интернет — роутер длинк — локалка (на одном из компов с вин хп стоит openvpn сервер.
      как сделать чтобы работала последняя схема? может всем компам дать второй ip, чтобы интернет работал на прямую через роутер а впн через вторую группу адресов шел?
      Всем компам точно не нужно ничего давать. Можно попробовать сделать проброс порта сервера OpenVPN через ДЛинк на внешний адрес (который видно из Инета) и поменять таблицу маршрутизации компа, на котором стоит сервер. Сам так не делал, т.к. это (имхо) изврат. Попробуйте, напишите, что получилось 😕
      и еще одна загвостка если интернет отключается то впн соединение заного клиент на вин хп не востанавливает как исправить?
      Внимательно почитайте описание параметра keepalive
      P.S.: Используйте теги при оформлении сообщений! 👿
DFC
04.06.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
  04.06.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
    04.06.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
      04.06.2009 в 21:18 | Ответить
      Последовал Вашему совету, привел свой конфиг к виду, похожему на Ваш, но ничего не изменилось…
      Файрволы отключены?
      - DFC
        05.06.2009 в 00:53 | Ответить
        да, и никогда не включались 🙂
        кстати, а демон routed должен быть запущен? Хотя, вроде и так и так пробовал…
        
        SergeySL
        05.06.2009 в 02:55 | Ответить
        По порядку:
        client-config-dir ccd tls-auth keys/ta.key 0
        Пропишите полные пути, начиная с / 😕
        tls-timeout 120 auth MD5 # cipher BF-CBC max-clients 5
        Эти строки чем-нибудь обоснованы, или как ❓
        а демон routed должен быть запущен?
        У меня он никогда не был запущен.
        
        DFC
        05.06.2009 в 14:21 | Ответить
        Прописал полные пути к конфиг и к ключу.
        tls-timeout 120
        auth MD5 #
        cipher BF-CBC
        max-clients 5
        Было взято из другой статьи, сейчас закоментировал.
        Результат тот же.
        
        SergeySL
        05.06.2009 в 17:25 | Ответить
        Результат тот же.
        Увеличиваете значение verb у клиента и сервера, а потом внимательно смотрите, что происходит в момент подключения. Туннель создается, маршруты вроде прописаны, файрволы не включены. Могу предположить только опечатку в именах файлов / путях или некорректные права доступа (для пользователя nobody:nobody, естественно). В логе обязательно будет написано, что не нашлось, не открылось и т.д. и т.п. С учетом приведенных в порядок конфигов (лучше еще раз внимательно проверьте, причем не по нескольким статьям, а по одной) больше ничего не могу подсказать 😕
        
        DFC
        15.06.2009 в 17:16 | Ответить
        Хорошо, с этим мы разобрались, подсети доступны. Но появилась другая неприятная вещь — пропадение пакетов. В связи с этим хотел задать вопрос — может ли это быть вызвано некорректной работой сервера или клиента? Или же это виноват Волгателеком? (физическое подключение у обоих офисов через adsl) И можно-ли как то это диагностировать, что бы быть уверенным?
        
        SergeySL
        15.06.2009 в 23:42
        Но появилась другая неприятная вещь – пропадение пакетов. В связи с этим хотел задать вопрос – может ли это быть вызвано некорректной работой сервера или клиента? Или же это виноват Волгателеком? (физическое подключение у обоих офисов через adsl) И можно-ли как то это диагностировать, что бы быть уверенным?
        Как раз ВолгаТелеком очень сильно грешит незамороченной шаблонной настройкой оборудования. Вполне возможно, что на одном из маршрутизаторов трафик через определенные порты ограничивается. Доказать это практически невозможно, т.к. никто не предоставит Вам конфиги и логи. Рекомендую использовать другой порт, а может и протокол TCP/IP. Лучшее решение можно найти только опытным путем 🙄
Илья
15.09.2009 в 11:31 | Ответить
Сергей!
После формирования клиентских сертификатов не удается простмотреть вот это:
openssl x509 -noout -text -in certs/CClient.pem
— файл certs/CClient.pem пустой. До этого этапа все четко по инструкции.
Спасибо.
- SergeySL
  16.09.2009 в 03:03 | Ответить
  А что выдает openssl ca -batch -config openssl.cnf -out certs/CClient.pem -infiles req/RClient.pem ?
  Судя по всему, должна выдавать сообщение об ошибке, с которой и следует разобраться 🙄
Илья
16.09.2009 в 11:32 | Ответить
То же самое что и при формировании серверного сертификата, за исключением нет строки update database. то есть без ошибок. еще не понятно с конфигурационным файлом openssl.cnf. По вашей статье я сделал файл в /usr/local/etc/openvpn а что сделать с /etc/ssl ? удалить его? при формировании сертификатов, запросов все равно openssl читает файл из etc/ssl
- SergeySL
  16.09.2009 в 17:38 | Ответить
  нет строки update database
  Это и есть ошибка. И связана она с некорректным файлом openssl.cnf. При необходимости путь к этому файлу задается ключиком -config. Если все делать под Фрей, находясь в папке /usr/local/etc/openvpn, то будет использоваться файл именно из этой папки. Трогать дефолтный конфиг OpenSSL, находящий в /etc/ssl, не нужно.
bvn13
02.11.2009 в 00:12 | Ответить
Спасибо за статью, очень интересная и познавательная, но у меня возникла проблема (т.к. я всего три дня сижу за Убунтой). Сервер на Убунте вроде поднялся (кста, как проверить), а вот клиент (Виста) не может к ней приконнектиться. Ошибка: WSATIMEOUT. Не получен ответ. Как можно поправить?
- bvn13
  02.11.2009 в 00:19 | Ответить
  Ошибся я.
  Ошибка: Connection reset by peer (WSAECONNRESET)
- SergeySL
  02.11.2009 в 00:36 | Ответить
  Если не знаете, как проверить, запущен ли сервер, и слушает ли он 1194 порт UDP, то для начала неплохо почитать мануалы или обратиться к специалистам 😉
  - bvn13
    02.11.2009 в 00:46 | Ответить
    ну так я вроде и обращаюсь к специалистам 😳 😉
    подскажите, плз, где почитать, что посмотреть? очень хочется изучить убунту…
    - SergeySL
      02.11.2009 в 01:03 | Ответить
      Вы мне льстите 😆 А если серьезно, за три дня такие вещи не учат. Понимаю, что хочется, но это невозможно. Азы, вещь скучная, но без них никуда 😉 . Теперь по серверу. С Ubuntu я не знаком, а под Фрёй можно проверить состояние сервера: /usr/local/etc/rc.d/openvpn status, можно найти процесс openvpn в списке процессов: ps -ax | grep openvpn, можно найти сокет openvpn в списке открытых сокетов: sockstat -4 | grep openvpn, можно посмотреть, что openvpn пишет в файл /var/log/messages. Кроме сервера, есть еще файлы конфигурации клиентов, брандмауэр и прочие мелочи. На Висте также может быть включен брандмауэр и/или антивирус. Не думаю, что Вам стало легче от моего ответа 🙄
bvn13
02.11.2009 в 01: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
  02.11.2009 в 01:49 | Ответить
  Слово «дурак» я не упоминал. Что обозначают ключи команд, которые я написал, можно посмотреть в FreeBSD Man Pages, а потом найти аналоги в man’е Ubuntu. Задайте отдельный лог в конфиге OpenVPN: log <имя файла>, увеличьте детальность лога, для начала: verb 4, выполните команду запуска сервера и посмотрите, что будет в этом логе. Должно стать теплее 😉
SergeySL
04.11.2009 в 14:34 | Ответить
Написал отдельную заметку о назначении статических IP-адресов клиентам OpenVPN.
Саня
08.03.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
  08.03.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 никто не настроит 😉
  - Саня
    09.03.2010 в 10:10 | Ответить
    ок попробую разобраться. я так понял ifconfig 10.20.30.1 255.255.255.0 это лишнее. На стороне винды ничего не трогал 10.20.30.6 я имел в виду что этот адрес мне автоматом присвоил сам openvpn. Я читал разные статьи)) не доходит пока, фаэрвол пытаюсь разрулить но у меня сейчас он все разрешает по умолчанки. И вопрос. Я так понял таблиц с маршрутами городить ненадо на фряхе?
    - SergeySL
      09.03.2010 в 11:19 | Ответить
      я так понял ifconfig 10.20.30.1 255.255.255.0
      Однозначно, лишнее.
      Я так понял таблиц с маршрутами городить не надо на фряхе?
      Нет.
      P.S.: с файрволом стоит разобраться. В дальнейшем очень пригодится. Рекомендую начать с handbook — IPFW и вообще этот сайт добавить в закладки.
      - Саня
        09.03.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.03.2010 в 00:03 | Ответить
        Ничего не понял:
        Сервак крутиться на 213, клиент и сетка офиса висели на 210. Ну и выход в инет на нем. Подключаю ноут с 210 айпи к сети офиса, рабочая группа офиса и клиента не совподаю (специально для теста разные).
Саня
10.03.2010 в 08:52 | Ответить
Вопрос тогда по-другому. Комп, на котором клиент openvpn крутиться, имеет рабочую группу home. Я захожу в сетевое окружение и вижу расшаренные папки офиса и компы совсем другой рабочей группы. Я так понимаю у меня значит VPN работает )). Но дома почему-то нифига. Может быть это из за провайдера?
- SergeySL
  10.03.2010 в 11:37 | Ответить
  Через такую VPN, как описана в статье, не видно рабочие группы (она не пропускает широковещательный трафик). Можно подключаться к TCP/IP или UDP службам, но не через сетевое окружение. Что и как Вы делаете, я не знаю, но судя по вопросам, ничего хорошего. Сделайте для начала одноранговую VPN. Там все намного проще.
  P.S.: Пожалуйста пишите аккуратнее, т.к. другие люди могут читать Вашу писанину 😉
chum
14.04.2010 в 15:12 | Ответить
Опять вопрос по маршрутизации. Только сеть проще, чем в статье.
Имеется выделенный сервер на FreeBSD 8, который смотрит только в инет. За ним нет никакой сети. Он является VPN сервером с конфигом:
port 1194 proto udp dev tun ca keys/ca.crt cert keys/server.crt key keys/server.key # This file should be kept secret dh keys/dh1024.pem server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt push "route 10.8.0.0 255.255.255.0" client-config-dir ccd route 192.168.0.0 255.255.255.0 client-to-client keepalive 10 120 comp-lzo user nobody group nobody persist-key persist-tun status /var/log/openvpn/openvpn-status.log log /var/log/openvpn/openvpn.log verb 3
Есть машина, которая находится в сети офиса, но не является шлюзом с ip 192.168.0.210. Сеть 192.168.0.0 с маской 255.255.255.0. Шлюз — 192.168.0.1. На ней установлена FreeBSD 8. Она является VPN клиентом. Для неё конфиг на сервере такой:
iroute 192.168.0.0 255.255.255.0
Firewall везде отключён. Проблема в том, что с сервера клиентская машина пингуется по ip 192.168.0.210, а вот другие машины этой сети нет. В чем может быть проблема?
- SergeySL
  14.04.2010 в 17:29 | Ответить
  Точно не в OpenVPN. Если Вы видите компьютер, находящийся за клиентом, значит маршрутизация настроена верно. Возможно, проблема в антивирусах или файрволах компьютеров в локальной сети. Кстати, сравните traceroute 192.168.0.210 с traceroute до любого другого компьютера, находящегося за клиентом.
  - chum
    14.04.2010 в 20:51 | Ответить
    вот результаты tracelog
    # traceroute to 192.168.0.210 (192.168.0.210), 64 hops max, 52 byte packets 1 192.168.0.210 (192.168.0.210) 24.404 ms 23.202 ms 19.891 ms
    # traceroute 192.168.0.201 traceroute to 192.168.0.201 (192.168.0.201), 64 hops max, 52 byte packets 1 * * * 2 * * * 3 * * * последня команда так до конца и не выполнилась.
    Что не сказал — что на клиенте (который в сети — 192.168.0.210) все машины сети пингуются.
    Завтра попробую на своей локальной отрубить фаервол и антивирус и отпишусь, получится ли.
  - chum
    15.04.2010 в 17:28 | Ответить
    Попробовал на рабочем месте отключить firewall и антивирус. Моя машина не пингуется (192.168.0.238). Пинговал с сервера VPN. Куда копать — ума не приложу.
    - SergeySL
      15.04.2010 в 21:08 | Ответить
      А что говорит netstat -nr на сервере OpenVPN?
      - chum
        16.04.2010 в 00:20 | Ответить
        говорит так:
        # netstat -nr netstat: kvm not available: /dev/mem: No such file or directory Routing tables rt_tables: symbol not in namelist
        Это VDS сервер — виртуальный выделенный сервер. В службе поддержки сказали, что она работать не будет. Вот дословно их слова:
        на VDS netstat -nr работать не будет - таково ограничение виртуализации. узнать маршрут до какого-то определенного хоста можно, например, при помощи route -n get IP_хоста
        Сейчас проверил подключение из дома. Результат: Рабочая машина из офиса пингуется и по виртуальному адресу, и по адресу сети офиса (192.168.0.210). Может ли быть проблема в том, что на этой машине не поднят NAT или ещё какая-либо служба???
        
        SergeySL
        16.04.2010 в 02:03 | Ответить
        VDS — философский вопрос (в смысле на чем, как и с какими ограничениями он настроен).
        Рабочая машина из офиса пингуется и по виртуальному адресу, и по адресу сети офиса (192.168.0.210).
        Я что-то не понял. VPN-клиент стоит на компьютере с IP-адресом 192.168.0.1 (офисном роутере), тогда откуда у компьютера с IP-адресом 192.168.0.210 взялся виртуальный адрес? Далее, для чего в конфиге сервера OpenVPN присутствует строка ifconfig-pool-persist ipp.txt?
        P.S.: Какова цель создания отдельно стоящего сервера OpenVPN? Может проще поднять сервер OpenVPN на офисном роутере?
        
        chum
        16.04.2010 в 02:48 | Ответить
        Постораюсь объяснить объяснить ситуацию.
        Есть рабочая сеть — 192.168.0.0 маска 255.255.255.0
        У неё есть шлюз — 192.168.0.1. К этой машине я не имею никакого отношения и не имею никакой возможности влиять на её конфигурацю.
        Есть рабочая станция 192.168.0.210 — на ней и стоит FreeBSD 8. Все компы сети выходят в инет, но!!! нет возможности принимать входящие соединения.
        Необходимо из вне соединяться с этой машиной (задача минимум) и иметь доступ к офисной сети (задача максимум). Для реализации этой цели был взят VDS на FreeBSD 8. Этот VDS имеет возможность принимать входящие соединения. Так вот он и является VPN сервером.
        Схема работы такова:
        на VDS поднимается VPN сервер.
        Машина из локальной сети (не шлюз!!!!) — 192.168.0.210 — клиент VPN.
        Остальные пользователи — тоже клиенты VPN.
        Такая вот сеть. Надеюсь понятно объяснил. Задача очень актуальна, когда есть админ, не пускающий из вне. Завтра попытаюсь нарисовать схемку, чтоб было понятнее. Но если не сложно, пришлите исходник. Я его подправлю под себя. Уж очень у Вас красиво получилось.
        Если поможет, то аська — 118035901 или на почту. Мне кажеться, задачка очень не стандартная и может многим помочь.
        
        SergeySL
        16.04.2010 в 10:56 | Ответить
        Теперь понял. Однозначно копайте в сторону файрволов/антивирусов на компьютерах локальной сети. Как только с ними все наладится, Ваша конфигурация должна на них заработать. Добьетесь этого, назначайте статические адреса всем клиентам и начинайте пользоваться VPN. Схемы, которая, кстати, нарисована в обычном Visio, давным-давно не существует.
        P.S.: Мне кажется, что route 192.168.0.0 255.255.255.0 из конфигурации VPN-сервера следует убрать, как и iroute 192.168.0.0 255.255.255.0 из файла конфигурации клиента.
chum
16.04.2010 в 14:25 | Ответить
Вот картинка сети. Надеюсь понятнее станет.
Мне кажется, что route 192.168.0.0 255.255.255.0 из конфигурации VPN-сервера следует убрать, как и iroute 192.168.0.0 255.255.255.0 из файла конфигурации клиента.
Если это убрать, то перестаёт пинговаться «клиент VPN 1» по адресу (192…) с «сервера VPN». Задача в итоге сводиться к тому, чтобы попасть в сеть 192.168.0.0. Повторюсь, что фаерволов и антивирусов ни на VPN сервере, ни на VPN клиенте нет. На машинах в сети тоже.
- SergeySL
  16.04.2010 в 19:32 | Ответить
  Если это убрать, то перестаёт пинговаться “клиент VPN 1″ по адресу (192…) с “сервера VPN”. Задача в итоге сводиться к тому, чтобы попасть в сеть 192.168.0.0.
  Компьютеры локальной сети будут доступны по виртуальным адресам. Со 192.168.0.xx ничего не получится, если Вы не установите VPN-клиент на офисный роутер. Про присвоение конкретных адресов конкретным компьютерам я уже рассказывал.
chum
17.04.2010 в 01:25 | Ответить
Да, я уже понял, в чём косяк. На роутер доступа у меня нет. Но это решается настройкой NAT на клиенте vpn, который в офисной сети. Так что теперь изучать мне нат. Огромное спасибо. Статья отличная. Мне кажется, что надо добавить описание параметров, которые можно использовать в конфиге клиента и сервера + добавить FAQ. Сам хочу написать подробную статейку на эту тему. Если не против, то «сопру» часть материала отсюда, естественно с указанием источника.
- SergeySL
  17.04.2010 в 03:00 | Ответить
  На здоровье. С указанием источника «прите» хоть все 🙂
  NAT Вам не поможет, нельзя транслировать адреса в пределах одной подсети.
InG0d
24.04.2010 в 07:49 | Ответить
А как реализовать такую схему. Есть сервер freebsd он будет openVPN сервером для мобильных пользователей, но он также должен быть openVPN клиентом до центрального офиса.
- chum
  24.04.2010 в 09:28 | Ответить
  А какая проблема? Поднимайте 2 интерфейса и всё будет работать.
- SergeySL
  24.04.2010 в 15:33 | Ответить
  Ставьте одновременно клиент и сервер OpenVPN, вешайте их разные порты, делайте два туннеля, меняйте правила маршрутизации и настройки файрвола, все будет работать прекрасно 😉
sport
23.07.2010 в 14:02 | Ответить
Все делал как у вас по шагам ….. но не мгу запустить
openssl ca -batch -config openssl.cnf -extensions server -out certs/server.pem -infiles req/server.pem
выдает ошибку:
2461:error:0E06D06C:configuration file routines:NCONF_get_string:no value:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/conf/conf_lib.c:329:group= name=unique_subject 2461:error:0E06D06C:configuration file routines:NCONF_get_string:no value:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/conf/conf_lib.c:329:group=CA_default name=email_in_dn 2461:error:22097082:X509 V3 routines:DO_EXT_NCONF:unknown extension name:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/x509v3/v3_conf.c:124: 2461:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/x509v3/v3_conf.c:93:name=basicConstrains, value=CA:FALSE
- SergeySL
  23.07.2010 в 21:08 | Ответить
  А если почитать оставленные ранее комментарии? 😉
  - Sanya0413
    27.07.2010 в 19:27 | Ответить
    А если я настраивую OpenVPN на виртуалках они должны выходить в нет?
    - SergeySL
      27.07.2010 в 20:19 | Ответить
      На каких виртуалках, с какой целью? Задйте вопрос более подробно.
      - Sanya0413
        28.07.2010 в 17:55 | Ответить
        на FreeBSD 7.0 для модулирования построение опорной сети для ИС компании среднего масштаба с филиальной структурой
        
        SergeySL
        28.07.2010 в 18:26 | Ответить
        Зависит от ограничений виртуального сервера на количество сетевых интерфейсов. Думаю, что других препятствий не будет.
        
        Sanya0413
        30.07.2010 в 17:05 | Ответить
        на одной FreeBSD стоит сервер VPN на другой FreeBSD клиент между ними устонавливается тунель, но не могу пингануть друг друга.
        
        SergeySL
        31.07.2010 в 08:36 | Ответить
        Читайте статью и комментарии, разбирайтесь с брандмауэром.
        
        Sanya0413
        05.08.2010 в 20:40 | Ответить
        а какой IP у клиента1, сетевуха которая смотрит в нет?
        
        SergeySL
        06.08.2010 в 13:19
        Любой. Он ни на что не влияет.
Sergey
17.08.2010 в 17:35 | Ответить
есть сеть предприятия (10.1.1.0/24), шлюз предприятия FreeBSD (10.1.1.3) с выходом в инет;
есть сеть филиала (10.2.2.0/24), шлюз филиала (10.2.2.1) с выходом в инет;
на шлюзе предприятия крутиться опенвпн сервак вот его конфиг:
port 2000 proto udp dev tun ca /usr/local/etc/openvpn/keys/ca.crt cert /usr/local/etc/openvpn/keys/server.crt key /usr/local/etc/openvpn/keys/server.key dh /usr/local/etc/openvpn/keys/dh1024.pem server 10.0.0.0 255.255.255.0 push "route 10.0.0.0 255.255.255.0" route 10.2.2.0 255.255.255.0 client-config-dir ccd tls-server tls-auth /usr/local/etc/openvpn/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-status.log log /var/log/openvpn.log verb 3
содержание файла с настройками которые применяются при подключении клиента:
push "route 10.1.1.0 255.255.255.0" iroute 10.2.2.0 255.255.255.0
маршруты шлюза предприятия:
Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire 10.0.0.0/24 10.0.0.2 UGS 0 30 tun1 10.0.0.2 10.0.0.1 UH 2 7 tun1 10.1.1.0/24 link#1 UC 0 0 em0 10.2.2.0/24 10.0.0.2 UGS 0 67063 tun1
конфиг клиента (филиала):
client dev tun proto udp remote office.com 2000 resolv-retry infinite nobind persist-key persist-tun tun-mtu 1500 tun-mtu-extra 32 mssfix 1450 ca /tmp/openvpncl/ca.crt cert /tmp/openvpncl/client.crt key /tmp/openvpncl/client.key tls-client tls-auth /jffs/keys/ta.key 1 auth MD5 cipher BF-CBC ns-cert-type server comp-lzo
таблица маршрутизации клиента (филиала):
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.0.5 * 255.255.255.255 UH 0 0 0 tun0 10.0.0.1 10.0.0.5 255.255.255.255 UGH 0 0 0 tun0 10.0.0.0 10.0.0.5 255.255.255.0 UG 0 0 0 tun0 10.2.2.0 * 255.255.255.0 U 0 0 0 br0 10.1.1.0 10.0.0.5 255.255.255.0 UG 0 0 0 tun0 169.254.0.0 * 255.255.0.0 U 0 0 0 br0 127.0.0.0 * 255.0.0.0 U 0 0 0 lo
где ошибка не получается найти не могу зайти на удаленные машины филиала???? с сетки филиала пингается сеть предприятия, с сетки предприятия не пингается сетка филиала, с самого шлюза предприятия сетка филиала тоже не пингается. При этом что компьютеры из филиала успешно работают с базой на сервере предприятия
Да еще такой нюанс при поднятие туннеля между филиалом и центральным офисом, филиал получает IP 10.0.0.6
помогите разобраться плиз
- SergeySL
  17.08.2010 в 20:20 | Ответить
  Ответы на Ваши вопросы есть как в статье, так и в комментариях.
Sanya0413
12.09.2010 в 23:12 | Ответить
сеть 172.16.0.0/24 (172.16.0.1/24) VPNServer (10.1.0.1/24) (10.1.0.2/24) VPNClient (172.16.1.1/24) сеть 172.16.1.0/24
с клиента за впн сервером пинг доходит до 172.16.1.1/24
с клиента за впн клиентом пинг доходит до 172.16.0.1/24
server conf:
dev tun local 10.1.0.1 port 1194 proto udp server 10.0.0.0 255.255.255.0 push "route 10.0.0.0 255.255.255.0" route 172.16.0.0 255.255.255.0 ifconfig 10.1.0.1 10.1.0.2 ca /usr/local/etc/openvpn/keys/ca.crt cert /usr/local/etc/openvpn/keys/server.crt key /usr/local/etc/openvpn/keys/server.key dh /usr/local/etc/openvpn/keys/dh1024.pem #tls-timeout 120 #auth MD5 cipher BF-CBC keepalive 10 120 comp-lzo max-clients 100 user nobody group nobody persist-key persist-tun down /usr/local/etc/openvpn/openvpn_down.sh status /var/log/openvpn/openvpn-status.log log /var/log/openvpn/openvpn.log up /usr/local/etc/openvpn/openvpn_up.sh verb 3
/usr/local/etc/openvpn/openvpn_up.sh:
route add -net 172.16.1.0/24 10.1.0.2
client.conf:
dev tun proto udp remote 10.1.0.1 ifconfig 10.0.0.2 10.0.0.1 port 1194 tls-client tls-auth keys/ta.key 1 resolv-retry infinite ca keys/ca.crt cert keys/client.crt key keys/client.key #auth MD5 #cipher BF-CBC #ns-cert-type server comp-lzo persist-key persist-tun down /usr/local/etc/openvpn/openvpn_down.sh up /usr/local/etc/openvpn/openvpn_up.sh status /var/log/openvpn/openvpn-status.log log /var/log/openvpn/openvpn.log verb 3
/usr/local/etc/openvpn/openvpn_up.sh:
route add -net 172.16.0.0/24 10.1.0.1
наверно надо еще маршрут написать?
подскажите пожалуйста
- SergeySL
  13.09.2010 в 06:03 | Ответить
  1. Если Вы оставите еще один неформатированный комментарий, я Вас забаню. Кроме этого, ни мне, ни посетителям этого сайта не нужны закомментированые строки Ваших конфигурационных файлов.
  2. Для общего развития — IP-адреса компьютеров имеют маску 32, а то, что Вы написали — адрес сети класса C.
  3. Зачем Вы добавили в конфигурацию сервера строки:
  local 10.1.0.1 ifconfig 10.1.0.1 10.1.0.2 cipher BF-CBC max-clients 100 down /usr/local/etc/openvpn/openvpn_down.sh up /usr/local/etc/openvpn/openvpn_up.sh
  Они что-то улучшили? Или это очередная попытка изобрести велосипед?
  4. Зачем Вы добавили в конфигурацию клиента строки:
  remote 10.1.0.1 ifconfig 10.0.0.2 10.0.0.1 resolv-retry infinite down /usr/local/etc/openvpn/openvpn_down.sh up /usr/local/etc/openvpn/openvpn_up.sh
  Здесь не только непонятные опции, но еще и ошибка, remote — не виртуальный, а внешний IP-адрес VPN-сервера.
  6. Зачем Вы создали файлы up и down?
  7. Почему Вы не удосужились посмотреть в логи?
  8. С учетом семи предыдущих пунктов вообще ничего не должно пинговаться.
  P.S.: Неужели сложно скопировать мои файлы конфигурации, а затем изменить IP-адреса и имена ключей/файлов конфигурации клиентов, а потом, если что-то пошло не так, прочитать 91 комментарий к статье? Ничего личного, просто подход к делу у Вас ну совсем не админский 😉
Sugubo
02.01.2011 в 20:22 | Ответить
Здравствуйте!
Хотелось бы автоматизировать создание большого числа клиентских сертификатов. Пока накопал опцию -subj, которая позволяет это делать. Т.е. у меня текстовый файл с именами клиентов, которые передаются в build-key.bat. Как справится с ответом на вопросы типа Sign the certificate? [y/n]:y и 1 out of 1 certificate requests certified, commit? [y/n]? Или есть какой-либо ещё метод для подобной автоматизации?
- SergeySL
  03.01.2011 в 11:21 | Ответить
  Или есть какой-либо ещё метод для подобной автоматизации?
  Выполните man ca и поищите -batch 😉
  - Sugubo
    03.01.2011 в 12:09 | Ответить
    Большое спасибо. Куда присылать пиво?
    - SergeySL
      03.01.2011 в 12:18 | Ответить
      На здоровье! Этот блог для души, а за пиво платят клиенты 🙂
San83
16.03.2011 в 04:05 | Ответить
Здравствуйте. Спасибо за статью.
Сразу хочу отметить некоторые не точности, на которые наткнулся при установке.
1. Перед тем как выполнить команду openvpn --genkey --secret ta.key желательно перезагрузиться, а то команду openvpn – не найдёт.
2. В примере конфигурационного файла клиента <FQDN сервера OpenVPN>, не там стоит. Должен стоять напротив строчки tls-remote, как описано у Вас дальше в тексте.
3. Желательно указать, что нужно самому создать группу и пользователя openvpn, т.к. автоматически они не создаются, как допустим при установке mysql.
4. Желательно указать в тексте основной статьи как запустить openvpn из командной строки. Типа
openvpn –daemon –config /usr/local/etc/openvpn/openvpn.conf или /usr/local/etc/rc.d/openvpn restart
Но это мелочи.
Дальше позвольте рассказать о процессе установке подробней.
Задача стояла совсем простенькая. Есть сервер в Дата Центре решил повысить на нём безопасность и заходить на него со своего домашнего компа по ssh, mysql и т.д. только через vpn туннель. На сервере FreeBSD на клиенте Винда XP. Долго думал, что выбрать mpd5 или OpenVPN. В итоге оценив Вашу статью на объём (Скроллинг меня испугал, потом только понимаешь, что в основном это комментарии) я выбрал OpenVPN. Да и то, что используется отдельный клиент с сертификатами, мне показалось более надёжным средством.
Весь день внимательно изучал Вашу статью и по пунктам выполнял команды. В итоге когда всё было готово перезагрузил сервер. Но, увы, чудо не произошло. Не долго ломая голову, полез искать логии. А в них говорилось, что openvpn не может найти внешний ip моего сервера. Дело в том, что сеть на сервере настраивалась по DHCP, а он инициализировался после openvpn. Ох и долго я пытался заставить dhclient выполниться перед openvpn. Прописывал всякие # REQUIRE в скриптах загрузки rc.d – всё тщетно.
В итоге плюнул и настроил как статический ip, всё равно он не менялся. И наконец-таки openvpn заработал. Ах да ещё пришлось ручками создать пользователя и группу openvpn.
Дальше приступил я к настройке фильтра пакетов, я использую PF. На время установки openvpn я его отключил, чтобы на него не думать в случае чего. Ну, тут я не долго мучился. На внешнем интерфейсе открыл только vpn туннель. А на туннеле всё остальное. Загрузил правила через командную строку и счастье случилось – Всё работало! Входить по SSH можно было теперь только через vpn туннель.
Я решил сделать контрольную перезагрузку и ещё раз всё проверить. Каково было моё разочарование, когда после перезагрузки PF перестал работать как надо – пропускал всё. Посмотрел список загруженных в него правил, а он пуст. Смотрю логии – ничего нет, хоть бы что-нибудь написал.
Получилось следующие: из командной строки PF запускался без проблем, со всеми правилами, а при старте системы правила были пусты. Ох, долго я ломал себе голову и «танцевал с бубном». И потом до меня дошло! Всё дело в злополучной очерёдности загрузки. PF загружается перед openvpn, поэтому «tun0» ещё не создан и PF не может его найти. Поэтому отбрасывал этот конфиг(pf.conf) как неправильный. Самое интересное, что в принципе openvpn и не должен загружаться перед PF – моё мнение. Поэтому я и не стал пытаться сделать это. Просто убрал из правил «tun0», хотя наверняка можно написать скрипт, который бы подгружал pf.conf после загрузки openvpn.
Вот мне интересно, как у Вас всё заработало на IPFW? Неужели у Вас IPFW загружается после openvpn?
- SergeySL
  16.03.2011 в 04:37 | Ответить
  Здравствуйте! На здоровье! Теперь по пунктам:
  Перед тем как выполнить команду openvpn --genkey --secret ta.key желательно перезагрузиться, а то команду openvpn – не найдёт
  Этот момент зависит от используемой shell и ее конфигурации. В случае bash, найдет, а в случае sh с настройками по умолчанию придется выполнить команду rehash или перезалогиниться.
  В примере конфигурационного файла клиента , не там стоит. Должен стоять напротив строчки tls-remote, как описано у Вас дальше в тексте.
  Прошу прощение за невнимательность. Исправил. Спасибо.
  Желательно указать, что нужно самому создать группу и пользователя openvpn, т.к. автоматически они не создаются, как допустим при установке mysql.
  В более старых версиях OpenVPN (а статье почти 4 года) пользователь и группа openvpn создавались автоматически, в последних версиях не создаются, поэтому можно воспользоваться, например, nobody:nobody.
  … Вот мне интересно, как у Вас всё заработало на IPFW? Неужели у Вас IPFW загружается после openvpn?
  Естественно, ipfw запускается раньше openvpn, все работает отлично. Я не знаком с pf, но, если все происходит так, как Вы написали, нужно добавить команды создания правил pf в файлы конфигурации клиентов.
freeasd
10.04.2011 в 23:04 | Ответить
При конекте к серверу постоянно выдает такую ошибку:
Sun Apr 10 22:39:52 2011 Restart pause, 2 second(s) Sun Apr 10 22:39:54 2011 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port. Sun Apr 10 22:39:54 2011 Re-using SSL/TLS context Sun Apr 10 22:39:54 2011 LZO compression initialized Sun Apr 10 22:39:54 2011 Control Channel MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ] Sun Apr 10 22:39:54 2011 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ] Sun Apr 10 22:39:54 2011 Local Options hash (VER=V4): '504e774e' Sun Apr 10 22:39:54 2011 Expected Remote Options hash (VER=V4): '14168603' Sun Apr 10 22:39:54 2011 UDPv4 link local: [undef] Sun Apr 10 22:39:54 2011 UDPv4 link remote: 23.2.23.161:1194 Sun Apr 10 22:39:54 2011 TLS: Initial packet from 23.2.23.161:1194, sid=2b044cc6 1e8eb83d Sun Apr 10 22:39:54 2011 VERIFY ERROR: depth=0, error=self signed certificate: /O=Company/CN=host.fvds.ru Sun Apr 10 22:39:54 2011 TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed Sun Apr 10 22:39:54 2011 TLS Error: TLS object -> incoming plaintext read error Sun Apr 10 22:39:54 2011 TLS Error: TLS handshake failed Sun Apr 10 22:39:54 2011 TCP/UDP: Closing socket Sun Apr 10 22:39:54 2011 SIGUSR1[soft,tls-error] received, process restarting
Видимо, дело в несоответствии данных сертификатов. При заполнении меняю только 3-е поле (Common name). В Certification Authority, CA: host.fvds.ru, Скртификат сервера: host.fvds.ru, клиентский сертификат: qwerty12345. Не понятно какие поля должны быть разными/совпадать.
- SergeySL
  11.04.2011 в 10:31 | Ответить
  Common Name сертификатов всего лишь должны соответствовать файлам конфигурации.
Евгений
26.04.2011 в 17:57 | Ответить
Доброго времени суток.
Руководствовался статьей, для решения своей задачи. С FreeBSD мало знаком, но приходится делать именно на нем. Попал в тупик, и все никак не могу найти решения. Есть 3 удаленные точки: 2 сети и FreeBSD сервер, через который надо осуществлять соединение. Напрямую нельзя. Оба клиента успешно конектятся к серверу, получают IP, но не могу заставить их друг друга видеть. Брандмавер открыт. Мб подскажете в какую сторону копать? буду очень благодарен!
Мой конфиг:
openvpn.conf FreeBSD сервер:
dev tun local x.x.x.x port 1194 proto tcp server 10.0.0.0 255.255.255.0 push "route 10.0.0.0 255.255.255.0" route 172.16.0.0 255.255.0.0 route 172.17.0.0 255.255.0.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 nobody group nobody verb 3
/usr/local/etc/openvpn/ccd/:
+++++++++ Client1 ++++++++ ifconfig-push 10.0.0.1 10.0.0.2 push "route 172.17.0.0 255.255.0.0" iroute 172.16.0.0 255.255.0.0 +++++++++ Client2 ++++++++ ifconfig-push 10.0.0.5 10.0.0.6 push "route 172.16.0.0 255.255.0.0" iroute 172.17.0.0 255.255.0.0
openvpn.ovpn клиентский конфиг:
client dev tun proto tcp remote x.x.x.x tls-client tls-remote servfreebsd ca "CA_cert.pem" cert "CClient1.pem" (CClient2.pem) key "KClient1.pem" (KClient2.pem) tls-auth "ta.key" 1 ns-cert-type server comp-lzo tun-mtu 1500 mssfix 1450 verb 3
- SergeySL
  26.04.2011 в 18:22 | Ответить
  С FreeBSD мало знаком, но приходится делать именно на нем.
  Может стоит привлечь тех, кто знаком?
  Оба клиента успешно конектятся к серверу, получают IP, но не могу заставить их друг друга видеть. Брандмавер открыт.
  При Вашей конфигурации будет возможна связь только между локальными сетями клиентов (сеть за сервером OpenVPN нигде не упоминается). Вам нужна именно такая конфигурация?
  - Евгений
    26.04.2011 в 18:29 | Ответить
    Может стоит привлечь тех, кто знаком?
    К сожалению, не располагаю такими знакомствами.
    При Вашей конфигурации будет возможна связь только между локальными сетями клиентов (сеть за сервером OpenVPN нигде не упоминается). Вам нужна именно такая конфигурация?
    Да, все верно. За сервером, сети нету.
    - SergeySL
      26.04.2011 в 18:38 | Ответить
      К сожалению, не располагаю такими знакомствами.
      Интернет есть. Можете ко мне обратиться, например, или к ребятам, ссылки на которых есть в сайдбаре, или на форум Лисяры 😉
      Теперь по делу. В Windows IP-маршрутизация включена? route print что выдает?
      - Евгений
        26.04.2011 в 18:55 | Ответить
        route print что выдает?
        =========================================================================== Активные маршруты: Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика 0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.101 20 10.0.0.0 255.255.255.252 10.0.0.1 10.0.0.1 30 10.0.0.0 255.255.255.0 10.0.0.2 10.0.0.1 1 10.0.0.1 255.255.255.255 127.0.0.1 127.0.0.1 30 10.255.255.255 255.255.255.255 10.0.0.1 10.0.0.1 30 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 172.16.0.0 255.255.255.0 10.0.0.2 10.0.0.1 1 192.168.1.0 255.255.255.0 192.168.1.101 192.168.1.101 20 192.168.1.101 255.255.255.255 127.0.0.1 127.0.0.1 20 192.168.1.255 255.255.255.255 192.168.1.101 192.168.1.101 20 224.0.0.0 240.0.0.0 10.0.0.1 10.0.0.1 30 224.0.0.0 240.0.0.0 192.168.1.101 192.168.1.101 20 255.255.255.255 255.255.255.255 10.0.0.1 10.0.0.1 1 255.255.255.255 255.255.255.255 192.168.1.101 192.168.1.101 1 Основной шлюз: 192.168.1.1 =========================================================================== Постоянные маршруты: Отсутствует
        
        SergeySL
        26.04.2011 в 19:01 | Ответить
        Клиенты VPN не подключены к Интернету напрямую?
        
        Евгений
        04.08.2011 в 13:09 | Ответить
        Да, клиенты внутри сети 🙂 Уже все реализовали и чудесно работает. Сэнк, что хоть пытались разобраться…
        
        SergeySL
        04.08.2011 в 13:21 | Ответить
        Я рад, что все получилось 🙂
Sergey
03.08.2011 в 21:44 | Ответить
День добрый. На сервере (FreeBSD, OpenVPN стоит на арендованном VDS сервере. Получилось что-то вроде хамачи) в настройках стоит client-to-client. Все клиенты подключившиеся к OpenVPN серверу могут пинговать друг друга, могут , при определенной сноровке, посмотреть открытые шары и т.д. Это не совсем нужно. Возможно как то фильтровать пакеты внутри OpenVPN? Допустим чтобы проходили пакеты на порт 3389. Пробовал отключить client-to-client. Выполнил на сервере sysctl net.inet.ip.forwarding=1, перезапустил OpenVPN:
tun0: flags=8051 metric 0 mtu 1500 options=80000 inet6 fe80::fc50:87ad:341d:3672% tun0 prefixlen 64 scopeid 0x3 inet 10.7.0.1 --> 10.7.0.2 netmask 0xffffffff nd6 options=3 Opened by PID 74924
Запустил клиента OpenVPN на компе, подключился, получил адрес 10.7.0.6, пинг на 10.7.0.1 проходит, пинг на 10.7.0.18 (терминальный сервер) не проходит. Пробовал на сервере выполнять route add -net 10.7.0.0 10.7.0.1 -netmask 255.255.0.0, не работает. Пробовал route add -host 10.7.0.18 10.7.0.1 не работает.
- SergeySL
  03.08.2011 в 22:52 | Ответить
  Доброй ночи!
  Все клиенты подключившиеся к OpenVPN серверу могут пинговать друг друга.
  Это достаточный признак корректной работы VPN, не нужно колдовать с форвардингом и прописыванием маршрутов (все, что касается нужных маршрутов, есть в статье).
  Возможно как то фильтровать пакеты внутри OpenVPN? Допустим чтобы проходили пакеты на порт 3389.
  Все правила доступа, ограничения скорости и балансировки трафика реализуются с помощью брандмауэра, в частности, ipfw умеет делать эти вещи без каких-либо проблем.
  - Sergey
    04.08.2011 в 07:51 | Ответить
    Все правила доступа, ограничения скорости и балансировки трафика реализуются с помощью брандмауэра, в частности, ipfw умеет делать эти вещи без каких-либо проблем.
    Я пробовал. Не работает. Такое ощущение что пакеты идут внутри OpenVPN.
    - SergeySL
      04.08.2011 в 13:19 | Ответить
      Я пробовал. Не работает. Такое ощущение что пакеты идут внутри OpenVPN.
      В статье и комментариях все подробно описано. Осталось ВНИМАЛЬНО изучить информацию, а затем устранить проблемы. Рекомендую начать с настройки без ограничений доступа. Когда все получится, можно будет подкорректировать правила брандмауэра.
      - Sergey
        04.08.2011 в 14:33 | Ответить
        Я попробую уточнить. OpenVPN сервер у меня работает на арендованном VDS сервере. ОС FreeBSD 8.2. Все пользователи подключаются к нему. Получилось что то типа виртуального хаба. Терминальный сервер тоже подключается как обычный клиент и имеет свой адрес, полученный от сервера 10.7.0.18. При включенном client-to-client клиенты легко заходят на терминальный сервер. Все работает. но так же легко они могут поглядеть шары друг у друга. Я пробовал в ipfw писать правила на ограничение трафика по портам, но пакеты до них не доходят.
        Весь трафик остается внутри правил:
        allow ip from any to any dst-port 1194 allow ip from any 1194 to any
        
        SergeySL
        04.08.2011 в 17:35 | Ответить
        Все пользователи подключаются к нему. Получилось что то типа виртуального хаба. Терминальный сервер тоже подключается как обычный клиент и имеет свой адрес, полученный от сервера 10.7.0.18.
        Вполне стандартная конфигурация, не отличающаяся от описанной в статье (терминальный сервер имеет такую же конфигурацию OpenVPN, как компьютер системного администратора).
        Я пробовал в ipfw писать правила на ограничение трафика по портам, но пакеты до них не доходят.
        Вы хотите ограничить доступ портом 3389/tcp но зачем-то пишете правила для порта 1149, да еще и с ошибками (ip = TCP,UDP и ICMP одновременно, поэтому не нужно указывать номера портов при его использовании). Посмотрите на картинку, еще раз прочитайте статью и комментарии, а также полистайте man ipfw. Это не только поможет решить задачу, но и много раз пригодится в будущем. Я не готов читать долгие лекции, поймите правильно. Как только будете готовы задавать конкретные вопросы, обязательно отвечу.
        
        Sergey
        04.08.2011 в 23:24 | Ответить
        Спасибо за подсказку. Я разобрался. Вот ответ.
        
        SergeySL
        05.08.2011 в 00:20 | Ответить
        Хорошо, что нашли готовое решение, но повторюсь, если связались с FreeBSD, стоит обязательно разобраться с ipfw 😉
        
        Sergey
        07.08.2011 в 20:38 | Ответить
        Это не готовое решение. Я сам его нашел. Сам написал. А сюда чтобы не копировать дал ссылку. Спасибо за помощь.
        
        SergeySL
        08.08.2011 в 12:41
        Ники не совпадают, поэтому я так написал.
Paul
04.08.2011 в 12:32 | Ответить
Доброго дня! Вопрос следующий: возможно ли шифровать трафик в vpn канале по ГОСТу (сертифицированное решение не нужно, просто для себя тестируем)? Собрал openssl с поддержкой ГОСТ.
[root@CentOS ~]$ openssl ciphers | tr -t ":" "\\n" | sort | grep GOST GOST2001-GOST89-GOST89 GOST94-GOST89-GOST89
Поддержка ГОСТовских алгоритмов имеется. Но при openvpn --show-ciphers вышеописанные алгоритмы не отображаются.
- SergeySL
  04.08.2011 в 13:23 | Ответить
  Добрый день! Может стоит направить Ваш вопрос разработчикам OpenVPN 😉
  - Paul
    04.08.2011 в 13:32 | Ответить
    Хороший совет! А если серьезно? Реально ли прикрутить? Я то думал, что openvpn шифрует канал именно средствами openssl. Или где то не прав?
    - SergeySL
      04.08.2011 в 13:46 | Ответить
      А если серьезно? Реально ли прикрутить?
      Я вполне серьезно говорю, что меня поражает и одновременно раздражает отношение таких людей, как Вы, к чему-то безвозмездному, данному совершенно чужим людям в силу, например, увлеченности любимым делом. С чего Вы взяли, что я должен изучать за Вас внутренности OpenVPN? Готовы платить, будет Вам ГОСТ, если OpenVPN его поддерживает, не готовы — разбирайтесь самостоятельно 😉
      Или где то не прав?
      Для начала, нужно запускать не openvpn --show-ciphers, а openvpn --show-tls 😉
      P.S.: man openvpn никто не отменял!
      - Paul
        04.08.2011 в 14:32 | Ответить
        Хм, а я то думал,что разного рода тематические форумы и обсуждения созданы для того, чтобы люди безвозмездно могли получить консультации, обменяться опытом, получить совет. Man я конечно почитаю, но нельзя же так интересующемуся человеку давать от ворот поворот. Я не заставляю Вас за меня изучать внутренности openvpn, я просто спросил совета как у опытного админа.
        
        SergeySL
        04.08.2011 в 17:06 | Ответить
        форумы и обсуждения созданы для того, чтобы люди безвозмездно могли получить консультации, обменяться опытом, получить совет.
        Во-первых. Вы абсолютно правы насчет ФОРУМОВ и СООБЩЕСТВ. Только здесь не форум и не сообщество, а блог, который ведется одним незаинтересованным человеком. Я не евангелист — проплаченный сотрудник, ведущий технически грамотный PR некоего продукта, а обычный сисадмин, делящийся скромным опытом. Вы можете использовать этот опыт так, как хотите, можете задавать вопросы о том, что НАПИСАНО В СТАТЬЕ, указывать недостатки и предлагать доработки, за что я буду Вам благодарен.
        Во-вторых. Вы спросили про ГОСТы, я ответил, что не знаю. Опять же, Вы не читали комментарии, в которых уже задавался данный вопрос.
        Но нельзя же так интересующемуся человеку давать от ворот поворот.
        Я открыл мануал OpenVPN, нашел ответ на Ваш вопрос и сообщил его Вам. По Вашему это и есть «от ворот поворот»?
        Я не заставляю Вас за меня изучать внутренности openvpn, я просто спросил совета как у опытного админа.
        Слава Богу, заставить меня что-либо сделать, Вы не сможете. Насчет «опытного админа» — спасибо за комплимент. При наличии возможности я обязательно даю совет человеку, который действительно пытался и старался. А те, кто даже не удосужился заглянуть в официальное руководство, вообще не должны лезть в наш огород (системное администрирование). Это мое твердое убеждение, на которое я имею полное право и, кстати, ни кому его не навязываю.
Rbotxxc
23.08.2011 в 03:38 | Ответить
На новом vds-сервере, куда я перенес Openvpn, начались проблемы с DNS. Конфиг:
dev tun71 local 82.146.48.230 port 1194 proto udp push "redirect-gateway def1" server 10.8.0.0 255.255.255.0 client-config-dir ccd client-to-client tls-server push "hcp-option DNS 8.8.8.8" push "hcp-option DNS 8.8.4.4" 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 tls-auth /usr/local/etc/openvpn/ta.key 0 crl-verify /usr/local/etc/openvpn/crl/crl.pem comp-lzo keepalive 10 120 tun-mtu 1500 mssfix 1450 persist-key persist-tun user on group on verb 3 log /var/log/vpn.log
Гугл работает нормально, но к дургим сайтам можно обращаться только по ip. В чем проблема?
- SergeySL
  23.08.2011 в 11:19 | Ответить
  А зачем Вы задаете этот вопрос здесь? VPN работает? Отлично! А с DNS-сами разбирайтесь или специалистов привлекайте 😉
Prouler
23.08.2011 в 13:33 | Ответить
push "hcp-option DNS 8.8.8.8" push "hcp-option DNS 8.8.4.4"
а не пробовали «d» к «hcp…» добавить?
- SergeySL
  23.08.2011 в 18:12 | Ответить
  Спасибо за ответ. Я даже не смотрел конфигурацию, т.к. считаю, что, если человек что-то добавил, то он осознает, зачем он это сделал 🙂
ttys
26.09.2011 в 21:22 | Ответить
Если схема такая?: [клиент]——инет——[сервер-клиент]——-инет——-[сервер]
- SergeySL
  26.09.2011 в 22:26 | Ответить
  Не совсем понимаю ее смысл. Конкретно — зачем два сервера? Стандартный вариант, который здесь описан, — сервер и все клиенты подключены к Интернету, а дальше маршрутизация и правила доступа между ними по вкусу и потребностям.
ttys
26.09.2011 в 23:27 | Ответить
есть 2 разных опенвпн сервера, и они должны быть как серверы, вопрос в том как их соединить?
- SergeySL
  26.09.2011 в 23:41 | Ответить
  Смысл двух серверов все равно не понимаю! Почему плавненько не перевести клиентов второго сервера на первый?
  Если хочется извращений, можно повесить клиент и сервер на разные порты и добавить нужные маршруты на нужные компьютеры.
ttys
26.09.2011 в 23:48 | Ответить
Смысл двух серверов все равно не понимаю! Почему плавненько не перевести клиентов второго сервера на первый?
Нельзя, т.к.разные конторы, а есть вариант один хост сделать клиентом сразу у двух серверов?
Если хочется извращений, можно повесить клиент и сервер на разные порты и добавить нужные маршруты на нужные компьютеры.
Ну или так, но всё таки точно извращение =)
- SergeySL
  26.09.2011 в 23:57 | Ответить
  Нельзя, т.к.разные конторы
  Руководство обеих представляет, что за трафик идет через 1194 порт UDP? Другими словами — если трафик через VPN не очень большой, никто ничего не заметит. У меня именно так и происходит с колымными клиентами. Cервер VPN стоит на основной работе на нормальном канале, тариф безлимитный, все имеют доступ только к тому, к чему им положено, поэтому моя совесть абсолютно чиста 🙂
  А есть вариант один хост сделать клиентом сразу у двух серверов?
  Придется запустить на этом хосте 2 клиента OpenVPN. Я сам так не делал, но не вижу причин, почему это не должно работать.
  - Sergey
    27.09.2011 в 07:33 | Ответить
    На одном клиенте может запускаться несколько подключений. Проверено на Windows и Ubuntu.
    - SergeySL
      27.09.2011 в 10:24 | Ответить
      Ну вот и отлично. Я не сомневался 🙂
    - ttys
      27.09.2011 в 22:58 | Ответить
      Один демон? Или надо несколько каждый со своим конфигом?
Алексей
17.10.2011 в 17:48 | Ответить
Добрый день, у нас настроен сервер с 2008 года. Работал до недавнего времени нормально. Все ключи для клиентов генерировали с помощью скрипта /usr/local/etc/openvpn/easy-rsa/todo.sh "имя клиента". Существующие сертификаты работают нормально, а новые перестали работать из-за того, что выпадает ошибка при новой генерации ключа сертификата клиента:
Using configuration from /usr/local/etc/openvpn/easy-rsa/openssl.cnf DEBUG[load_index]: unique_subject = "yes" entry 91: invalid expiry date cp: keys/ekat-sklad5.crt: No such file or directory adding: cfg/ (stored 0%) adding: cfg/ta.key (deflated 39%) adding: cfg/ca.crt (deflated 36%) adding: cfg/ekat-sklad5.key (deflated 22%) adding: cfg/ekat-sklad5.cfg (deflated 31%)
нужного файла с расширением crt в каталоге не появляется. Если у кого-то есть опыт решения такой проблемы, поделитесь. Спасибо.
- SergeySL
  18.10.2011 в 10:27 | Ответить
  entry 91: invalid expiry date
  Вот с этим разберитесь…
Константин
05.12.2011 в 13:13 | Ответить
Здравствуйте, немного запутался и не могу своими силами решить проблему, буду благодарен любой подсказке, ситуация такая: две локальных сети: 192.168.1.0 (2комп.1роутер) и 192.168.0.0 (2комп.1роутер). Нужно соединить их в одну через VPN. Настроил OpenVPN на FreeBSD сервере. Создал двух клиентов.
Результат при подключении:
client1: внешний IP меняется, локальный IP 10.8.0.6, сервер пингует клиента (сеть первая).
client2: внешний IP прежний, локальный IP 10.8.0.10, сервер не пингует клиента (сеть вторая).
Друг друга клиенты не пингуют.
Конфигурации:
==client1== push "route 192.168.0.0 255.255.255.0" iroute 192.168.1.0 255.255.255.0
==client2== push "route 192.168.1.0 255.255.255.0" iroute 192.168.0.0 255.255.255.0==server.conf== port 1194 proto udp dev tun ca /usr/local/etc/openvpn/keys/ca.crt cert /usr/local/etc/openvpn/keys/server.crt key /usr/local/etc/openvpn/keys/server.key dh /usr/local/etc/openvpn/keys/dh1024.pem server 10.8.0.0 255.255.255.0 push "redirect-gateway def1" push "dhcp-option DNS 10.8.0.1" push "dhcp-option WINS 10.8.0.1" push "route 10.8.0.0 255.255.255.0" route 192.168.1.0 255.255.0.0 route 192.168.0.0 255.255.0.0 ifconfig-pool-persist ipp.txt client-config-dir ccd client-to-client keepalive 10 120 comp-lzo max-clients 100 user nobody group nobody persist-key persist-tun status /var/log/openvpn/openvpn-status.log log /var/log/openvpn/openvpn.log verb 3
Может быть проблема в ipfw? При настройке добавлял в него несколько правил, но может этого не достаточно?
Тыкните пжл в ошибку.
- SergeySL
  05.12.2011 в 18:52 | Ответить
  client1: внешний IP меняется
  Имеется ввиду, что IP-адрес динамический? Если да, то не стОит обращать на это внимание.
  push "redirect-gateway def1" push "dhcp-option DNS 10.8.0.1" push "dhcp-option WINS 10.8.0.1" ifconfig-pool-persist ipp.txt max-clients 100
  Может сначала базовая настройка, а уже потом нюансы?
  verb 3
  На время отладки имеет смысл увеличить до 4-5.
  Может быть проблема в ipfw? При настройке добавлял в него несколько правил, но может этого не достаточно?
  Тыкните пжл в ошибку.
  Может быть. Я не видел Ваш конфиг ipfw и содержимое Вашего /var/log/security. На время отладки OpenVPN лучше всего привести /etc/rc.firewall примерно к такому виду:
  /sbin/ipfw -f flush /sbin/ipfw add pass all from any to any via lo0 /sbin/ipfw add pass all from any to any via tun0 /sbin/ipfw add divert natd ip from any to any via ${natd_interface} /sbin/ipfw add pass all from any to any
  Это если нужен NAT, а в противном случае хватит:
  /sbin/ipfw -f flush /sbin/ipfw add pass all from any to any
  - Константин
    07.12.2011 в 21:42 | Ответить
    Крутил вертел никак не могу заставить по прежнему. Со вторым клиентом чудеса происходят, он подключается но не пингует сервер, и сервер его не пингует.
    Имеется ввиду, что IP-адрес динамический?
    Он динамический, но при подключении у клиента1 внешний IP меняется на внешний IP сервера, так вроде и должно быть?
    вот состояние ipfw:
    00010 20152 3514248 nat 123 ip from 10.8.0.0/24 to any 00020 797261 114146960 nat 123 ip from any to 82.146.43.79 00100 3123 286079 allow ip from any to any via lo0 00200 0 0 allow ip from any to any via tun0 00300 0 0 divert 8668 ip from any to any via 0.0.0.0 00400 621622 158600823 allow ip from any to any 65535 6329667 901112538 allow ip from any to any
    Не могу заставить клиента2 подключаться и всех видеть, подскажите с помощью каких инструментов можно ошибку найти? Конфиги вроде правдоподобно выглядят?
    - SergeySL
      08.12.2011 в 02:28 | Ответить
      Он динамический, но при подключении у клиента1 внешний IP меняется на внешний IP сервера, так вроде и должно быть?
      Что курили? Отсыпите? А если по делу, то прочитайте и поймите, что Вы написали!
      вот состояние ipfw:
      00010 20152 3514248 nat 123 ip from 10.8.0.0/24 to any 00020 797261 114146960 nat 123 ip from any to 82.146.43.79 00100 3123 286079 allow ip from any to any via lo0 00200 0 0 allow ip from any to any via tun0 00300 0 0 divert 8668 ip from any to any via 0.0.0.0 00400 621622 158600823 allow ip from any to any 65535 6329667 901112538 allow ip from any to any
      Перед настройкой ipfw имеет смысл понять, как он работает, а если понять пока не получается, то скопировать то, что пишут те, кто знает. Сравните свой ipfw show с правилами, которые я написал, а лучше почитайте, что такое NAT, и как работает ipfw.
      Конфиги вроде правдоподобно выглядят?
      Не знаю в какой по счету раз говорю — статья содержит рабочие конфиги. Не нужно их «дорабатывать» пока не разберетесь что к чему.
Константин
07.12.2011 в 22:20 | Ответить
Когда 2ой клиент подключился, я тоже с конфигом от 2ого клиента смог подключиться , это же не должно так быть? Если специальную строчку в конфиге не прописать?
- SergeySL
  08.12.2011 в 02:31 | Ответить
  это в man openvpn достаточно подробно освещено.
  - Константин
    08.12.2011 в 09:06 | Ответить
    Ладно, пошел читать и гуглить 🙂
    - SergeySL
      08.12.2011 в 14:42 | Ответить
      Вот это правильно! Попадется что-нибудь интересное, обязательно поделитесь. Будем очень признательны 🙂
Сергей
11.01.2012 в 15:21 | Ответить
Доброго времени суток! Может вы поможете решить проблему такого характера: Есть сеть в головном офисе 192.168.0.0/16 и есть сеть в филиале 192.168.6.0/16 не удается их подружить так как маски одинаковые. Опенвпн выдает ошибку типа такая сеть уже используется. Если сменить маску в филиале на /24, то оттуда не видят никаких ресурсов в головном офисе. Пришлось временно сделать в филиале сеть 192.169.6.0/16 при этом связь работает, пинги ходят, РДП работает, расшаренные ресурсы видны, но некоторые программы не хотят устанавливаться в филиале типа другая сеть уже. Не подскжете решение проблемы?
- SergeySL
  11.01.2012 в 18:11 | Ответить
  Добрый вечер!
  Если использование маски /16 имеет смысл, то придется сделать как у Вас, если не имеет — и там и там /24 😕
Сергей
12.01.2012 в 07:58 | Ответить
Ясно, спасибо. Жаль, что не получается сделать как хотелось. Маску /16 сделали не с проста.
- SergeySL
  12.01.2012 в 09:39 | Ответить
  Может попробовать алиасы сетевым карточкам назначить и уже их указать в настройках OpenVPN 😕
Сергей
12.01.2012 в 16:13 | Ответить
То есть, на физической сетевухе делаем сеть 192.168.6.0/16 а на виртуальной 192.168.1.0/24 и его связываем по ВПН так? И трафик с виртуальной автоматом идет на физическую сетевуху и все в шоколаде? Я просто с алиасами сетевух не сталкивался ниразу.
- SergeySL
  12.01.2012 в 18:45 | Ответить
  Да. Думаю, что стоит попробовать. Если не сложно, напишИте, что получится…
Ярослав
11.05.2012 в 03:35 | Ответить
Подскажите пожалуста, что делать если при запуске VPN вырубает инет? Буду признателен.
- SergeySL
  11.05.2012 в 04:30 | Ответить
  Для начала выбросить из файлов конфигурации OpenVPN всю отсебятину, которая отвечает за маршрутизацию 😉
Николай
19.06.2012 в 12:40 | Ответить
Здравствуйте.
Мне нужно настроить доступ во внутреннюю сеть по openvpn из интернета. Копаюсь с фаервольными правилами. Не могу понять вот эти правила:
/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}
У Вас в первом филиале сеть жёстко задана — 192.168.1.0/24, а в моём случае у разных провайдеров сети могут быть какими угодно… А, если any поставить, то толку от фаервола вроде как никакого…
- SergeySL
  19.06.2012 в 21:47 | Ответить
  Эти правила определяют взаимодействие между сетью за сервером и за одним из клиентов (разрешают любой трафик в любом направлении). Они не имеют ничего общего с публичными адресами клиента и сервера, которые могут быть любыми, в т.ч. динамическими.
Andrey
22.06.2012 в 21:38 | Ответить
Есть VPS на котором поднят OpenVPN, все работает отлично. Появилась необходимость в дополнительном IP… IP на VPS добавил, у клиента в конфиге прописан, однако не работает. Подскажите пожалуйста как подлучить 2^й IP для OpenVPN?
- SergeySL
  22.06.2012 в 21:47 | Ответить
  однако не работает
  Что именно не работает? Клиент получает IP? Маршруты добавляются? Брандмауэр пропускает нужный трафик?
Andrey
22.06.2012 в 21:59 | Ответить
Сложно сказать. Я слабо в этом разбираюсь. Не подключается клиент по 2^му IP — 22.222.22.222. Лог клиента:
Fri Jun 22 10:53:52 2012 OpenVPN 2.2.2 Win32-MSVC++ [SSL] [LZO2] [PKCS11] built on Dec 15 2011 Fri Jun 22 10:53:52 2012 WARNING: No server certificate verification method has been enabled. See _http://openvpn.net/howto.html#mitm for more info. Fri Jun 22 10:53:52 2012 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables Fri Jun 22 10:53:52 2012 LZO compression initialized Fri Jun 22 10:53:52 2012 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ] Fri Jun 22 10:53:52 2012 Socket Buffers: R=[8192->8192] S=[8192->8192] Fri Jun 22 10:53:52 2012 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ] Fri Jun 22 10:53:52 2012 Local Options hash (VER=V4): '41690919' Fri Jun 22 10:53:52 2012 Expected Remote Options hash (VER=V4): '530fdded' Fri Jun 22 10:53:52 2012 UDPv4 link local: [undef] Fri Jun 22 10:53:52 2012 UDPv4 link remote: 22.222.22.222:1194
- SergeySL
  22.06.2012 в 22:23 | Ответить
  Сложно сказать.
  Если сложно сказать, то представьте, на сколько сложно понять.
  Я слабо в этом разбираюсь.
  Это Ваша проблема. Никто не мешает почитать документацию.
  Не подключается клиент по 2му IP – 22.222.22.222.
  Я не знаю Вашу конфигурацию, поэтому данный вопрос получается из оперы «не отправляется на деревню дедушке».
  P.S.: Прошу задавать вопросы по существу, максимально кратко и точно. В противном случае забаню.
  - Andrey
    22.06.2012 в 22:37 | Ответить
    Сервер Centos — имеет 2ip 11.11.11.11 и 22.22.22.22
    Клиент — Windows 7, по первому ip работает VPN по 2му — нет.
    Как сделать чтобы работало по 2му ip?
    - SergeySL
      22.06.2012 в 23:14 | Ответить
      Другое дело! Убрать строчку local из файла конфигурации сервера 🙂
      - Andrey
        22.06.2012 в 23:37 | Ответить
        В конфиге было:
        # Which local IP address should OpenVPN # listen on? (optional) ;local a.b.c.d
        Заменил на:
        local 22.22.22.22
        У клиента стало подключаться, однако IP всеравно 11.11.11.11
        Если убрать local, то Starting openvpn: [FAILED].
        
        SergeySL
        22.06.2012 в 23:50 | Ответить
        Выдержка из mana’а OpenVPN 2.2 на официальном сайте:
        —local host
        Local host name or IP address for bind. If specified, OpenVPN will bind to this address only. If unspecified, OpenVPN will bind to all interfaces.
        Возможно, OpenVPN для CentOS имеет какие-то особенности (сильно сомневаюсь), поэтому стоит зайти на сервер и изучить man openvpn на предмет local. Если обойтись без local не получится, придется запустить два сервера OpenVPN на разных IP-адресах или пробросить порт OpenVPN с одного IP-адреса на другой.
Илья
18.06.2013 в 10:21 | Ответить
ПОМОГИТЕ!!!
на экзамене будет такой вопрос, напишите ответ, очень прошу!
Опишите конфигурацию openvpn для простейшего случая с использованием статического ключа для организации доступа между двумя сетями 192.168.1.0/24 и 192.168.2.0/24, внешние адреса маршрутизаторов, соответственно, 1.1.1.1 и 2.2.2.2.
- SergeySL
  19.06.2013 в 21:31 | Ответить
  В начале статьи есть ссылка на такую конфигурацию.
LSP
17.09.2013 в 19:06 | Ответить
Достался сервак от прошлого админа, все делаею как в статье только не хватает файла ta.key. Как его сгенерировать и если сгенерирую новый, будут ли действительны уже сгенерированные сертификаты/отвалятся ли у меня уже подключенные клиенты?
- SergeySL
  17.09.2013 в 22:17 | Ответить
  Сгенерировать файл ta.key можно также, как описано в этой статье, только его придется передать всем клиентам, прописать в их файлы конфигурации и перезапустить на них OpenVPN. Сертификаты не отвалятся.
LSP
18.09.2013 в 06:58 | Ответить
Спасибо за ответ, подойдет ли мне ранее сгенерированный и отправленный клиенту файлик ta.key, чтоб не генерировать новый?
- SergeySL
  19.09.2013 в 00:58 | Ответить
  Я бы начал с генерации ta.key на сервере. Кто может знать, что у Вас там за файлик?
Павел
23.10.2013 в 22:36 | Ответить
Рано я радовался, нарвался на проблему. Пробовал прописать маршруты а папке ccd, и даже после того, как я файлы с клиентами удалил, теперь возникает такая ошибка, и даже после перезапуска сервера:
Oct 24 00:02:19 test openvpn[977]: /sbin/route delete -net 11.0.0.0 11.0.0.2 255.255.255.0 Oct 24 00:02:19 test openvpn[977]: ERROR: FreeBSD route delete command failed: external program exited with error status: 77 Oct 24 00:02:19 test openvpn[977]: Closing TUN/TAP interface Oct 24 00:02:19 test openvpn[977]: /sbin/ifconfig tun0 destroy Oct 24 00:02:19 test kernel: tun0: link state changed to DOWN Oct 24 00:02:19 test openvpn[977]: FreeBSD 'destroy tun interface' failed (non-critical): external program exited with error status: 1 Oct 24 00:02:19 test openvpn[977]: SIGTERM[hard,] received, process exiting
Я совершенно не понимаю, в чем дело. При этом клиент вообще не подключается с Windows, просто висит пустой лог и все. Как можно решить проблему? Кстати, у нас совершенно нет надобности использовать адреса типа 192.168.x.x подключение прямое. Когда я только имел возможность подключаться до ошибки, соседнему компьютеру присвоился адрес 11.0.0.10 с моего компьютера, где адрес 11.0.0.6 пинг до него вообще не шел, шел только до сервера 11.0.0.1. Как решить проблему — починить OpenVPN и прокинуть маршрут через сервер до соседнего компьютера?
- SergeySL
  24.10.2013 в 06:51 | Ответить
  Кстати, у нас совершенно нет надобности использовать адреса типа 192.168.x.x подключение прямое.
  Не понял эту фразу ❓
  Также не знаю конфигурацию сети, не видел конфигурации сервера и клиентов, ну и даром телепатии не обладаю. Не сочтите за бестактность, но видеть и вникать не хочу. Некогда, честное слово. В статье и коментах есть вся нужная информация, осталось не торопиться, и все получится.
  - Павел
    24.10.2013 в 09:12 | Ответить
    Насчет непонятной фразы — у меня дома IP адрес 11.0.0.6, на сервере 11.0.0.1 на втором клиенте 11.0.0.10. Пинг с моего домашнего до 11.0.0.1 идет, а вот до 11.0.0.6 через сервер не идет. Просто хотелось бы узнать как в этом случае пробросить маршрут, на сервере и на клиентах по одной сетевой карте, но оба клиента подключаются к серверу через белый IP.
    Насчет ошибки в логах — косвенно удалось вроде решить. Когда убираю в конфиге строчки
    user openvpn group openvpn
    Проблема вроде решается. Как снимаю комментарии, проблема снова появляется. Пробовал chown -R openvpn:openvpn /usr/local/etc/openvpn проблема остается. Конфигурация в точности соответствует Вашей, кроме строчек
    route 192.168.1.0 255.255.255.0 route 192.168.2.0 255.255.255.0
    в конфиге openvpn.conf
    - SergeySL
      24.10.2013 в 10:40 | Ответить
      Просто хотелось бы узнать как в этом случае пробросить маршрут, на сервере и на клиентах по одной сетевой карте, но оба клиента подключаются к серверу через белый IP.
      Звучит еще мутнее… Маршрут к VPN-туннелю пробрасывать никуда не надо. Пробрасываются маршруты к сетям за сервером и клиентами, если таковые сети существуют. Сетевые карты и белые адреса тут при чем?
      Насчет ошибки в логах – косвенно удалось вроде решить. Когда убираю в конфиге строчки
      user openvpn group openvpnПроблема вроде решается. Как снимаю комментарии, проблема снова появляется. Пробовал chown -R openvpn:openvpn /usr/local/etc/openvpn проблема остается. Конфигурация в точности соответствует Вашей, кроме строчек
      route 192.168.1.0 255.255.255.0 route 192.168.2.0 255.255.255.0в конфиге openvpn.conf
      Плохо, что полностью соответствует. Статья 2007 года, а делалось это все в 2006м. Тогда при установке OpenVPN создавались пользователь openvpn и группа openvpn, последние несколько лет все работает от имени nobody:nogroup. Нельзя тупо копировать конфиги, не вникая, что дает каждая строчка 😉
AndreyV
02.12.2013 в 21:02 | Ответить
Здравствуйте. Все вродебы правильно настроил(на мой взгляд 🙂 . На стороне сервера сеть 192.168.0.0 gate 192.168.0.1, на стороне клиента сеть 192.168.3.1. Соединяется и со стороны клиента и со стороны сервера пингуется только 10.0.0.1, в сети за впном не пускает :(. Фаервол(PF) отключен в rc.conf. И у клиента. Конфиг идентичен за исключением:
route 192.168.3.0 255.255.255.0 user root group wheelи поставил комментарий на строке local ccd:
push "route 192.168.0.0 255.255.255.0" iroute 192.168.3.0 255.255.255.0
Конфиг клиента отличается только строкой
remote xxx.dyndns.org #Использую динамический адрес
Выдержка из лога сервера:
SERVER openvpn[1087]: Client/217.118.81.18:50861 MULTI: primary virtual IP for Client/217.118.81.18:50861: 10.0.0.6 SERVER openvpn[1087]: Client/217.118.81.18:50861 MULTI: internal route 192.168.3.0/24 -> Client/217.118.81.18:50861 SERVER openvpn[1087]: Client/217.118.81.18:50861 MULTI: Learn: 192.168.3.0/24 -> Client/217.118.81.18:50861 SERVER openvpn[1087]: Client/217.118.81.18:50861 SENT CONTROL [Client]: 'PUSH_REPLY,route 10.0.0.0 255.255.255.0,route 10.0.0.0 255.255.255.0 SERVER openvpn[1087]: MULTI: Learn: 192.168.3.1 -> Client/217.118.81.18:50861
Выдержка лога клиента:
C:\WINDOWS\system32\route.exe ADD 192.168.0.0 MASK 255.255.255.0 10.0.0.5
Вобщем в логах ни на что не ругается, маршрутизация вродебы прописана, а доступа к реальным сетям нету ни с одной ни с другой стороны, только в виртуальной сети. Может у кого есть идеи?
- AndreyV
  02.12.2013 в 21:45 | Ответить
  Прошу прощения связь с сервером есть(192.168.0.50 пингуется) и как показывает tcpdump icmp пакеты приходят на адреса сети 192.168.0.0, а вот обратно не доходят. Немогу разобраться в чем дело :(. неужели на каждого клиента в сети нужно ставить OpenVPN
- AndreyV
  02.12.2013 в 23:56 | Ответить
  Извините, проблема решена, поспешил, прописал в роутере 192.168.0.1 маршрут Destination LAN NET 10.0.0.0 Subnet Mask 255.255.255.0 Gateway 192.168.0.50, и все заработало.
Владимир
19.12.2013 в 09:06 | Ответить
Данная статья уже по факту является некой базой знаний по поводу использования OpenVpn и FreeBsd. Решил внести свою скормную лепту.
Ситуация: боевой сервер FreeBSD 9.2 (до этого обновлялся с 8 ветки, обновлялись порты и в том числе openvpn) долго и праведно работал как openvpn сервер (связывал филиалы с центральным офисом) и никто его не трогал. Но возникла необходимость сгенерироваь новый клиетский сертификат. Команда
openssl ca -batch -config openssl.cnf -out certs/Cbom.pem -infiles req/Rbom.pem
закончилась ошибкой
failed to update database TXT_DB error number 2
Права на запись в файл имелись. Предварительный поиск по Инету советовал обнулить файл index.txt, в котором хранится информация о существующих сертификатах и сгенерировать новые сертификаты сервера. Последствия от таких действий очевидны: более 10 филиалов теряют связь с центральным офисом, а мне рубят голову.
Решение проблемы следующее. В файле /usr/local/etc/openvpn/index.txt.attr необходимо изменить значение параметра unique_subject на no.
- SergeySL
  19.12.2013 в 12:00 | Ответить
  Я сам не сталкивался, но все равно спасибо за полезный коммент!
File
02.03.2014 в 07:28 | Ответить
Опервпн запушен на домашнем роурете. С клиента не удается подсоединитсё с ошибкой: что делать?
[root@localhost et]# openvpn --cd /home/one/openvpn/et --config opclient.conf Sun Mar 2 07:03:28 2014 DEPRECATED OPTION: --tls-remote, please update your configuration Sun Mar 2 07:03:28 2014 OpenVPN 2.3.2 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Sep 12 2013 Sun Mar 2 07:03:28 2014 Control Channel Authentication: using '/home/one/openvpn/et/ta.key' as a OpenVPN static key file Sun Mar 2 07:03:28 2014 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Sun Mar 2 07:03:28 2014 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Sun Mar 2 07:03:28 2014 Socket Buffers: R=[124928->131072] S=[124928->131072] Sun Mar 2 07:03:28 2014 UDPv4 link local (bound): [undef] Sun Mar 2 07:03:28 2014 UDPv4 link remote: [AF_INET]192.168.1.1:1194 Sun Mar 2 07:03:28 2014 TLS: Initial packet from [AF_INET]192.168.1.1:1194, sid=2b727168 3bda78d0 Sun Mar 2 07:03:32 2014 VERIFY ERROR: depth=0, error=self signed certificate: /O=Company/CN=client1 Sun Mar 2 07:03:32 2014 TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed Sun Mar 2 07:03:32 2014 TLS Error: TLS object -> incoming plaintext read error Sun Mar 2 07:03:32 2014 TLS Error: TLS handshake failed Sun Mar 2 07:03:32 2014 SIGUSR1[soft,tls-error] received, process restarting Sun Mar 2 07:03:32 2014 Restart pause, 2 second(s) Sun Mar 2 07:03:34 2014 Control Channel Authentication: using '/home/one/openvpn/et/ta.key' as a OpenVPN static key file Sun Mar 2 07:03:34 2014 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Sun Mar 2 07:03:34 2014 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Sun Mar 2 07:03:34 2014 Socket Buffers: R=[124928->131072] S=[124928->131072] Sun Mar 2 07:03:34 2014 UDPv4 link local (bound): [undef] Sun Mar 2 07:03:34 2014 UDPv4 link remote: [AF_INET]192.168.1.1:1194 Sun Mar 2 07:03:34 2014 TLS Error: Unroutable control packet received from [AF_INET]192.168.1.1:1194 (si=3 op=P_CONTROL_V1) Sun Mar 2 07:03:34 2014 TLS: Initial packet from [AF_INET]192.168.1.1:1194, sid=8e95e41c 70c250ba Sun Mar 2 07:03:39 2014 TLS Error: Unroutable control packet received from [AF_INET]192.168.1.1:1194 (si=3 op=P_CONTROL_V1) Sun Mar 2 07:03:39 2014 TLS Error: Unroutable control packet received from [AF_INET]192.168.1.1:1194 (si=3 op=P_CONTROL_V1) Sun Mar 2 07:03:39 2014 TLS Error: Unroutable control packet received from [AF_INET]192.168.1.1:1194 (si=3 op=P_CONTROL_V1) Sun Mar 2 07:03:39 2014 TLS Error: Unroutable control packet received from [AF_INET]192.168.1.1:1194 (si=3 op=P_CONTROL_V1) Sun Mar 2 07:03:39 2014 VERIFY ERROR: depth=0, error=self signed certificate: /O=Company/CN=client1 Sun Mar 2 07:03:39 2014 TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed Sun Mar 2 07:03:39 2014 TLS Error: TLS object -> incoming plaintext read error Sun Mar 2 07:03:39 2014 TLS Error: TLS handshake failed Sun Mar 2 07:03:39 2014 SIGUSR1[soft,tls-error] received, process restarting Sun Mar 2 07:03:39 2014 Restart pause, 2 second(s) Sun Mar 2 07:03:41 2014 Control Channel Authentication: using '/home/one/openvpn/et/ta.key' as a OpenVPN static key file Sun Mar 2 07:03:41 2014 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Sun Mar 2 07:03:41 2014 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Sun Mar 2 07:03:41 2014 Socket Buffers: R=[124928->131072] S=[124928->131072] Sun Mar 2 07:03:41 2014 UDPv4 link local (bound): [undef] Sun Mar 2 07:03:41 2014 UDPv4 link remote: [AF_INET]192.168.1.1:1194 Sun Mar 2 07:03:41 2014 TLS Error: Unroutable control packet received from [AF_INET]192.168.1.1:1194 (si=3 op=P_CONTROL_V1) Sun Mar 2 07:03:42 2014 TLS Error: Unroutable control packet received from [AF_INET]192.168.1.1:1194 (si=3 op=P_CONTROL_V1) Sun Mar 2 07:03:43 2014 TLS Error: Unroutable control packet received from [AF_INET]192.168.1.1:1194 (si=3 op=P_CONTROL_V1) Sun Mar 2 07:03:43 2014 TLS Error: Unroutable control packet received from [AF_INET]192.168.1.1:1194 (si=3 op=P_CONTROL_V1) Sun Mar 2 07:03:43 2014 TLS Error: Unroutable control packet received from [AF_INET]192.168.1.1:1194 (si=3 op=P_ACK_V1) Sun Mar 2 07:03:44 2014 TLS Error: Unroutable control packet received from [AF_INET]192.168.1.1:1194 (si=3 op=P_CONTROL_V1) Sun Mar 2 07:03:44 2014 TLS Error: Unroutable control packet received from [AF_INET]192.168.1.1:1194 (si=3 op=P_CONTROL_V1) Sun Mar 2 07:03:45 2014 TLS Error: Unroutable control packet received from [AF_INET]192.168.1.1:1194 (si=3 op=P_CONTROL_V1) Sun Mar 2 07:03:45 2014 TLS Error: Unroutable control packet received from [AF_INET]192.168.1.1:1194 (si=3 op=P_CONTROL_V1) ^CSun Mar 2 07:03:46 2014 event_wait : Interrupted system call (code=4) Sun Mar 2 07:03:46 2014 SIGINT[hard,] received, process exiting
- SergeySL
  04.03.2014 в 13:01 | Ответить
  Мне кажется, что в приведенном куске лога есть сообщения об ошибках? Разбирайтесь со всеми ERROR, начиная с:
  Sun Mar 2 07:03:32 2014 TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
  и будет счастье.
  P.S.: В следующий раз «слишком информативные» коменты отправятся в СПАМ.
Winsik
16.03.2014 в 02:53 | Ответить
Спасибо за статью, но было бы здорово дописать конфигурации «клиентов»
после тацев с бубнами заработало вот так. client.conf:
dev tun proto udp remote THERE_IP_OPENVPN_SERVER 1194 client tls-client tls-auth /usr/local/etc/openvpn/ta.key 1 ca /usr/local/etc/openvpn/CA_cert.pem cert /usr/local/etc/openvpn/certs/Cclient.pem key /usr/local/etc/openvpn/keys/Kclient.pem comp-lzo persist-key persist-tun verb 3
- SergeySL
  16.03.2014 в 20:02 | Ответить
  Спасибо, что прочитали. Дописывать статью не вижу смысла (кроме удаления устаревшего ключа tls-remote), т.к. настройки сильно зависят от ОС клиента.
  Например, в Windows 7 нужно добавлять:route-method exe route-delay 2
  в FreeBSD:nobind
  и т.д. и т.п. Кому нужно, разберутся, что Вы и подтвердили 🙂
AndreyL
27.03.2014 в 05:34 | Ответить
Благодарю за отличную статью и за блог вообще. Сделал все последовательно, получил ключи, подключился — все работает. Возникла необходимость написать скрипт, который будет генерить все необходимое для передачи клиенту потом и, в связи с этим, возникло пару вопросов:
1. Если в секции [ policy_any ] commonName = supplied, то он его запрашивает, если ставлю optional, а скриптом в секции [ req_distinguished_name ] в commonName_default подставляю нужное значение, то выдает ошибку:
error, no objects specified in config file
problems making Certificate Request
Не подскажете где туплю или это такое ограничение, что commonName должен быть введен вручную?
2. Насколько я понял, при генерации запроса на сертификат и ключа используется системный файл /etc/ssl/openssl.cnf, а при подписании, тот что в каталоге /usr/local/etc/openvpn (судя по опции -config)? Т.е мне для моего скрипта нужно _default значения менять в обоих файлах, чтобы неизменяемые параметры (страна, организация) соответствовали потом?
AndreyL
27.03.2014 в 12:26 | Ответить
Вчера писал долго сообщение, вроде отправилось, но сегодня его нет, поэтому (уже вкратце):
Сергей, огромное спасибо за статью и за блог.
Пара вопросов:
1. Почему при commonName optional и commonName_default = vasya запрос на сертификат выдает ошибку?
2. Я правильно понял, что при запросе используется системный файл /etc/ssl/openssl.cnf, а при подписывании тот который в папке openvpn (-config openssl.cnf)?
Буду очень признателен за ответы, т.к. застрял на этом при написании скрипта.
- SergeySL
  28.03.2014 в 01:45 | Ответить
  Вчера писал долго сообщение, вроде отправилось, но сегодня его нет, поэтому (уже вкратце):
  Было малость не до блога 🙂
  Сергей, огромное спасибо за статью и за блог.
  Спасибо, что читаете!
  Почему при commonName optional и commonName_default = vasya запрос на сертификат выдает ошибку?
  Не знаю, нужно разбираться 🙁
  Я правильно понял, что при запросе используется системный файл /etc/ssl/openssl.cnf, а при подписывании тот который в папке openvpn (-config openssl.cnf)?
  Не совсем. Используется один файл конфигурации, указанный с помощью ключа -config, там, где нет данного ключа, все нужные параметры указываются в командной строке.
  По поводу написания скриптов Вы зря мучаетесь. Статья писалась очень давно, когда все приходилось делать вручную, теперь в комплекте OpenVPN есть все необходимые скрипты.
oD
23.04.2014 в 23:23 | Ответить
Спаибо за статью! все получается… почти.
Вопрос по отозванным сертификатам. Сделал отзыв сертификата как у вас написано, но как-то ничего не изменилось. То есть сертификат числится в базе отозванных, а клиент как подключался так и подключается. А мне таки надо чтобы он не мог…
Подскажите куда смотреть плз…
- SergeySL
  25.04.2014 в 13:35 | Ответить
  На здоровье! Перезапустите сервер OpenVPN, клиент с отозванным сертификатом больше не подключится.
oD
24.04.2014 в 00:20 | Ответить
сам себе заля буратина. отозвать — отозвал, а базу не перестроил!
так что тут все хорошо, спасибо 🙂
есть другой трабл… если клиенту сказать рестарт, или не дай боже серверу — оно все говрит что лин сктоит, а капеты не худють…
а вот если скахать дисконнект а потом обратно коннект — тогда все поднимается хорошо…
буду завтра рыться…
- SergeySL
  25.04.2014 в 13:38 | Ответить
  Сорри, не понял 😕
  - oD
    29.04.2014 в 17:17 | Ответить
    вечно я невнятен…
    если со сторны клиента сказать рестарт соединению (через гуи)
    то соединеие установится, но роутинг не применяется почему-то… то есть надо разорвать и снова запустить, чтобы все ходило…
    если происходит рестарт сервера опенвпн (на фряхе)
    то со стороны клинета статус остается коннектед. а роутинг опять падает и пакеты не ходят… нужно переподключение…
    буду еще смотреть что-как… руки не доходят 🙁
    - SergeySL
      29.04.2014 в 19:28 | Ответить
      VPN должна подниматься, не зависимо от того, кто инициировал рестарт. Покажите результат выполнения команды route print на компьютере с Windows.
      - oD
        30.04.2014 в 11:35 | Ответить
        А вот то-то оно и есть, что роута вываливается после «рестарт» на клиенте
        хотя на сервере пишет что все случилось… Выпушил на клинета роуту:
        Apr 30 11:02:14: TLS: new session incoming connection from [AF_INET]c.c.c.c:1194 Apr 30 11:02:14: CRL CHECK OK: C=RU, ST=Cloud, O=konstanta, CN=s.s.s.s Apr 30 11:02:14: VERIFY OK: depth=1, C=RU, ST=Cloud, O=konstanta, CN=s.s.s.s Apr 30 11:02:14: CRL CHECK OK: O=konstanta, CN=od Apr 30 11:02:14: VERIFY OK: depth=0, O=konstanta, CN=od Apr 30 11:02:14: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key Apr 30 11:02:14: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Apr 30 11:02:14: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key Apr 30 11:02:14: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Apr 30 11:02:14: TLS: move_session: dest=TM_ACTIVE src=TM_UNTRUSTED reinit_src=1 Apr 30 11:02:14: TLS: tls_multi_process: untrusted session promoted to semi-trusted Apr 30 11:02:14: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA Apr 30 11:02:16: PUSH: Received control message: 'PUSH_REQUEST' Apr 30 11:02:16: send_push_reply(): safe_cap=940 Apr 30 11:02:16: SENT CONTROL [od]: 'PUSH_REPLY,route 192.168.77.0 255.255.255.0,route 10.10.77.1,topology net30,ping 10,ping-restart 120,ifconfig 10.10.77.6 10.10.77.5' (status=1)
        В логах клиента ошибка…. но роута вроде как есть, а в системе — фигвам, пропала:
        Wed Apr 30 11:02:13 2014 OpenVPN 2.0.5 Win32-MinGW [SSL] [LZO] built on Nov 2 2005 .... Wed Apr 30 11:02:14 2014 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA Wed Apr 30 11:02:14 2014 [s.s.s.s] Peer Connection Initiated with s.s.s.s:1194 Wed Apr 30 11:02:15 2014 SENT CONTROL [s.s.s.s]: 'PUSH_REQUEST' (status=1) Wed Apr 30 11:02:15 2014 PUSH: Received control message: 'PUSH_REPLY,route 192.168.77.0 255.255.255.0,route 10.10.77.1,topology net30,ping 10,ping-restart 120,ifconfig 10.10.77.6 10.10.77.5' Wed Apr 30 11:02:15 2014 Options error: Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:3: topology (2.0.5)
        Чего это оно?
        Wed Apr 30 11:02:15 2014 OPTIONS IMPORT: timers and/or timeouts modified Wed Apr 30 11:02:15 2014 OPTIONS IMPORT: --ifconfig/up options modified Wed Apr 30 11:02:15 2014 OPTIONS IMPORT: route options modified Wed Apr 30 11:02:15 2014 TAP-WIN32 device [Подключение по локальной сети 6] opened: \\.\Global\{D3FB18AC-B5C5-4CFF-A663-CE7DE2C71FAA}.tap Wed Apr 30 11:02:15 2014 TAP-Win32 Driver Version 8.1 Wed Apr 30 11:02:15 2014 TAP-Win32 MTU=1500 Wed Apr 30 11:02:15 2014 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.10.77.6/255.255.255.252 on interface {D3FB18AC-B5C5-4CFF-A663-CE7DE2C71FAA} [DHCP-serv: 10.10.77.5, lease-time: 31536000] Wed Apr 30 11:02:15 2014 Successful ARP Flush on interface [131076] {D3FB18AC-B5C5-4CFF-A663-CE7DE2C71FAA} Wed Apr 30 11:02:15 2014 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up Wed Apr 30 11:02:15 2014 route ADD 192.168.77.0 MASK 255.255.255.0 10.10.77.5 Wed Apr 30 11:02:15 2014 Route addition via IPAPI succeeded Wed Apr 30 11:02:15 2014 route ADD 10.10.77.1 MASK 255.255.255.255 10.10.77.5 Wed Apr 30 11:02:15 2014 Route addition via IPAPI succeeded SYSTEM ROUTING TABLE 0.0.0.0 0.0.0.0 192.168.52.1 p=0 i=2 t=4 pr=3 a=2289542 h=0 m=20/-1/-1/-1/-1 10.10.77.1 255.255.255.255 10.10.77.5 p=0 i=131076 t=4 pr=3 a=0 h=0 m=1/-1/-1/-1/-1 10.10.77.4 255.255.255.252 10.10.77.6 p=0 i=131076 t=3 pr=2 a=143 h=0 m=30/-1/-1/-1/-1 10.10.77.6 255.255.255.255 127.0.0.1 p=0 i=1 t=3 pr=2 a=143 h=0 m=30/-1/-1/-1/-1 10.255.255.255 255.255.255.255 10.10.77.6 p=0 i=131076 t=3 pr=2 a=143 h=0 m=30/-1/-1/-1/-1 31.8.48.163 255.255.255.255 192.168.52.1 p=0 i=2 t=2 pr=4 a=1963037 h=0 m=20/-1/-1/-1/-1 80.232.148.147 255.255.255.255 192.168.52.1 p=0 i=2 t=2 pr=4 a=137599 h=0 m=20/-1/-1/-1/-1 95.24.5.243 255.255.255.255 192.168.52.1 p=0 i=2 t=2 pr=4 a=91407 h=0 m=20/-1/-1/-1/-1 127.0.0.0 255.0.0.0 127.0.0.1 p=0 i=1 t=3 pr=2 a=2289543 h=0 m=1/-1/-1/-1/-1 128.70.4.127 255.255.255.255 192.168.52.1 p=0 i=2 t=2 pr=4 a=65515 h=0 m=20/-1/-1/-1/-1 176.65.40.213 255.255.255.255 192.168.52.1 p=0 i=2 t=2 pr=4 a=439232 h=0 m=20/-1/-1/-1/-1 178.18.14.6 255.255.255.255 192.168.52.1 p=0 i=2 t=2 pr=4 a=87293 h=0 m=20/-1/-1/-1/-1 188.233.61.67 255.255.255.255 192.168.52.1 p=0 i=2 t=2 pr=4 a=800151 h=0 m=20/-1/-1/-1/-1 192.168.52.0 255.255.255.0 192.168.52.10 p=0 i=2 t=3 pr=2 a=2289542 h=0 m=20/-1/-1/-1/-1 192.168.52.10 255.255.255.255 127.0.0.1 p=0 i=1 t=3 pr=2 a=2289542 h=0 m=20/-1/-1/-1/-1 192.168.52.255 255.255.255.255 192.168.52.10 p=0 i=2 t=3 pr=2 a=2289542 h=0 m=20/-1/-1/-1/-1 192.168.77.0 255.255.255.0 10.10.77.5 p=0 i=131076 t=4 pr=3 a=0 h=0 m=1/-1/-1/-1/-1
        А почему бы?
        Активные маршруты:Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика 0.0.0.0 0.0.0.0 192.168.52.1 192.168.52.10 20 10.10.77.4 255.255.255.252 10.10.77.6 10.10.77.6 30 10.10.77.6 255.255.255.255 127.0.0.1 127.0.0.1 30 10.255.255.255 255.255.255.255 10.10.77.6 10.10.77.6 30 31.8.48.163 255.255.255.255 192.168.52.1 192.168.52.10 20 80.232.148.147 255.255.255.255 192.168.52.1 192.168.52.10 20 95.24.5.243 255.255.255.255 192.168.52.1 192.168.52.10 20 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 128.70.4.127 255.255.255.255 192.168.52.1 192.168.52.10 20 176.65.40.213 255.255.255.255 192.168.52.1 192.168.52.10 20 178.18.14.6 255.255.255.255 192.168.52.1 192.168.52.10 20 188.233.61.67 255.255.255.255 192.168.52.1 192.168.52.10 20 192.168.52.0 255.255.255.0 192.168.52.10 192.168.52.10 20 192.168.52.10 255.255.255.255 127.0.0.1 127.0.0.1 20 192.168.52.255 255.255.255.255 192.168.52.10 192.168.52.10 20 224.0.0.0 240.0.0.0 10.10.77.6 10.10.77.6 30 224.0.0.0 240.0.0.0 192.168.52.10 192.168.52.10 20 255.255.255.255 255.255.255.255 10.10.77.6 10.10.77.6 1 255.255.255.255 255.255.255.255 192.168.52.10 192.168.52.10 1 Основной шлюз: 192.168.52.1 =========================================================================== Постоянные маршруты: Отсутствует
        Если добваить роуту руками - все оживает, ясное дело.
        При первичном подключении в логах клиента все то же самое, но роута появляется.
        
        oD
        30.04.2014 в 11:50 | Ответить
        С рестартом сервера все еще печальнее…
        Сервер рестрартился, но клиент этого никак не почувствовал — в логах чисто.
        Роуты есть, но ничего никуда не ходит….
        Почему оно не отваливается — я не понимаю…
        —
        А нет! Вру… Я просто не терпелив. Оно прочухалось через полторы минуты где-то и переподключилось… Роутинг при этом на клинете поднялся…
        
        SergeySL
        30.04.2014 в 15:19 | Ответить
        оно прочухалось через полторы минуты где-то и переподключилось…
        Точное время «прочухивания» определяется параметром keepalive 😉
Cup
24.04.2014 в 16:50 | Ответить
Доброго времени суток!
Отличная статья. Жаль она мне сразу не попалась.
Склеивал рабочий конфиг по обрывкам разных постов, но судя по тому, который указан в этой статье, вроде бы склеил правильно.
Но вот достучаться внутрь подсетей за клиентами не выходит никак.
Может Вы сможете подсказать где я ошибся.
Имеются два клиента (условно А и Б) с подсетями. И сервер, без подсети.
Клиенты видят друг друга и сервер без проблем. Пингуются один с другого как по VPN адресу так и по локальному.
Конфиг файл:
port 1498 proto udp dev tun ca /etc/openvpn/ca.crt cert /etc/openvpn/server.crt key /etc/openvpn/server.key dh /etc/openvpn/dh1024.pem server 10.105.51.0 255.255.255.0 ifconfig-pool-persist ipp.txt push "route 10.105.51.0 255.255.255.0" keepalive 10 120 client-config-dir /etc/openvpn/ccd route 192.168.1.0 255.255.255.0 route 192.168.51.0 255.255.255.0 client-to-client comp-lzo cipher BF-CBC persist-key persist-tun status /etc/openvpn/status_server.log verb 3
Имеются ccd файлы:
push "route 192.168.1.0 255.255.255.0" iroute 192.168.51.0 255.255.255.0
и
push "route 192.168.51.0 255.255.255.0" iroute 192.168.1.0 255.255.255.0
Если попинговать машину за одним из клиентов, видно что пакеты на нее приходят, и она даже отправляет ответ.
16:43:49.112917 IP 10.105.51.6 > 192.168.1.3: ICMP echo request, id 16063, seq 83, length 64 16:43:49.112959 IP 192.168.1.3 > 10.105.51.6: ICMP echo reply, id 16063, seq 83, length 64
Но обратно ничего не доходит.
- SergeySL
  25.04.2014 в 13:46 | Ответить
  Дам стандартный ответ — отключите файрволы, удалите из конфигов непонятные параметры, типа, cipher и т.п., все остальное многократно пережевано в комментариях. Ничего принципиального не изменилось. Не стоит первый раз в жизни состыковывать несколько конфигов, гораздо разумнее и быстрее взять любой готовый вариант, а уже после его успешного запуска колдовать над улучшениями.
  - Cup
    29.04.2014 в 17:50 | Ответить
    Конфиг ваш скопировал, в итоге только cipher лишний. А вот проблемы похожие не мои в коментариях то решались, но как именно, никто толком не описывает к сожалению.
Zhake
04.07.2014 в 19:19 | Ответить
Добрый вечер,
Надеюсь на помощь профессионалов, проблема в создании сертификата клиента в freebsd сервере.
Начну сначала, по инструкции создал вначале корневой сертификат, затем сертификат сервера и создал пару сертификатов на разных клиентов. Все это делалось для доступа к сети Wifi, но вначале не удавалось войти в сеть, в логах радиуса была ругань на ca сертификат. Как обычно через гугл на форуме (не помню ссылку) было написано что можно в настройках eap.conf выставить check_crl=no, выставил, и все заработало. Сертификаты клиентов которые я создал ранее могут входить в сеть. но что странно, теперь я не могу создавать сертификаты клиентов. Ступарит на том месте где ввожу всю информацию о клиенте (т.е. ввожу CN=client.domain.local и ввожу название компании) нажимаю ввод и все. Может кто-нибудь встречался с такой проблемой?
Для образного понимания скопировал с окна создания место где все ступарится.
Common Name (eg, YOUR name) []:client.domain.local Email Address []:client@domain.kz Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:1234567890 An optional company name []:companyname Using configuration from /etc/ssl/openssl.cnf
- SergeySL
  05.07.2014 в 16:12 | Ответить
  Добрый день! В представленных Вами строках нет сообщений об ошибках. Если Вы вводите уникальные CN для всех клиентов, все должно генерироваться и подписываться.
  - Zhake
    05.07.2014 в 20:33 | Ответить
    Добрый вечер Сергей,
    CN ввожу уникальные, для каждого клиента свой. Ошибки нигде не генерируются (я так думаю), т.к. ошибок нет, ситуация странная, последнее что я вижу на экране это «Using configuration from /etc/ssl/openssl.cnf» и все встает, прождал около 2 часов, ничего не изменилось. Вышел нажатием CTRL+Z. Может посоветуете какие логи можно посмотреть в такой ситуации или лучше все проделать сначала (сгенерировать все сертификаты заново)?
    - SergeySL
      05.07.2014 в 21:14 | Ответить
      Ни разу не сталкивался с такими поведением openssl. Для начала добавьте к команде ключик --verbose. Если не поможет, попробуйте перенести рабочую папку со всем сгенерированным хозяйством и файлом openssl.cnf на другой компьютер и попробуйте на нем.
      - Zhake
        07.07.2014 в 16:08 | Ответить
        Добрый вечер,
        Ключик и перенос всего хозяйства на другой компьютер не помогли. Поведение было аналогичное. Очень и очень странно. Ранее до отключения параметра check-crl сертификаты генерировались. Придется наверное завтра все снести и сгенерировать заново. Вам большое спасибо, что откликнулись.
        
        SergeySL
        07.07.2014 в 18:11 | Ответить
        Так, может быть, не отключать check-crl на время генерации сертификатов?
        
        Zhake
        08.07.2014 в 16:46 | Ответить
        Сергей добрый вечер, с генерацией разобрался. спасибо за поддержку. все настройки делал по этой ссылке. Вся проблема оказалась из-за файла xpextensions.
        Было:
        [color=green] # # For use with the 'CA.all' script. # [ xpclient_ext] extendedKeyUsage = 1.3.6.1.5.5.7.3.2 [ xpserver_ext] extendedKeyUsage = 1.3.6.1.5.5.7.3.1 [/color]
        Потом допёр, что цвет должен был быть прописан для этого блока в сайте. Убрал эти значения с квадратными скобками и все пошло.
        
        SergeySL
        08.07.2014 в 18:39 | Ответить
        Поздравляю. Нужно аккуратнее копипастить файлы конфигурации 🙂
Alex_Rav
10.12.2014 в 19:21 | Ответить
Доброе время суток. С FreeBSD только разбираюсь, так что…
В наличии имеем: настроенные сервер vpn и клиентский vpn. На клиентской стороне два провайдера: радиоканал и adsl. Adsl для выхода в инет, радиоканал — для vpn. Можно ли настроить так, чтобы при отсутствии связи по радиоканалу vpn поднимался по Adsl автоматически?
- SergeySL
  12.12.2014 в 21:57 | Ответить
  Доброго! Можно, но после окончания «только разбираюсь». Есть нюансы с динамическим изменением маршрутов и правил брандмауэра, а такие вопросы без четкого понимания не решаются.
Николай
19.06.2017 в 06:45 | Ответить
Автору спасибо за статью! Данный метод (руками через openssl) проще гораздо, нежели через easy-rsa.
Все(!) сделал как в статье. Есть два вопроса:
1. MD5 уже не рекомендуют к использованию (присутствует в openssl.cnf). Что можно заместо него прописать в конфиге?
2. Отзываю сертификат, но при просмотре crl.pem в выводе пишется, что No Revoked Certificates. Это нормально? При повторной попытке отозвать сертификат получаю сообщение, мол сертификат уже отозван.
P.S. Спасибо за статьи! Выручали не раз.
- SergeySL
  19.06.2017 в 10:07 | Ответить
  На здоровье! Спасибо за добрые слова!
  1. Замените md5 на sha1.
  2. Это не нормально. Сертификат не просрочен?
  P.S.: Все, что здесь написано, до сих пор работает, но некоторые моменты пора изменить. Скоро обновлю статью, а потом отдельно расскажу про использование easy-rsa.
  - Николай
    19.06.2017 в 11:56 | Ответить
    Не просрочен — все делалось на свежесозданном.
    Создал сначала сертификат client как в статье, создал crl и отозвал сертификат. openssl.cnf полностью из статьи.
    - SergeySL
      19.06.2017 в 12:14 | Ответить
      В index.txt что-нибудь меняется после отзыва?
      - Николай
        19.06.2017 в 12:17 | Ответить
        Там стоит R напротив сертификата.
        
        SergeySL
        19.06.2017 в 12:26 | Ответить
        Получается, что команда revoke срабатывает, но список отзывов не обновляется?
        После команды revoke выполнена команда gencrl?
        
        Николай
        19.06.2017 в 12:54 | Ответить
        Да. Сначала создан список отзыва, затем добавлен в него сертификат.
        Все делалось по шагам из статьи.
        
        SergeySL
        19.06.2017 в 13:08 | Ответить
        После выполнения revoke нужно заново сгенерировать список отзывов. Похоже, что я пропустил этот момент. Исправил статью. Спасибо за полезное замечание!
Станислав
21.05.2018 в 15:36 | Ответить
Может сталкивались, каким образом подправить конфиг клиента, чтобы подключаться к нескольким OpenVPN серверам одновременно? Все машины на FreeBSD.
- SergeySL
  21.05.2018 в 17:12 | Ответить
  Вам нужно создать отдельные файлы конфигурации клиентов OpenVPN для каждого сервера. В каждом таком файле конфигурации должны быть указаны уникальные tun/tap-интерфейсы и наборы сертификатов/ключей. Здесь написано, как обеспечить автоматический запуск этого хозяйства.
Станислав
22.05.2018 в 20:46 | Ответить
Спасибо разобрался, все верно только не обязательно указывать уникальные tun/tap, поднимаются автоматически, например tun0 и tun1.
- SergeySL
  22.05.2018 в 22:19 | Ответить
  На здоровье! Отлично, что разобрались!