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

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

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

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

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

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

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

В процессе реализации того, что описано ниже, я руководствовался документом OpenBSD Installation (автор давно удалил из Сети) и материалами Форума OpenNET. Я использовал (и продолжаю использовать) пакет OpenSSL, входящий в состав операционной системы, и последнюю версию порта OpenVPN. За время существования виртуальной частной сети ОС сервера и клиентов постепенно обновлялись с версии 4.10 до версии 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               = md5
unique_subject           = yes
policy                   = policy_any
x509_extensions          = user_extensions
[ policy_any ]
organizationName         = match
organizationalUnitName   = optional
commonName               = supplied
[ req ]
default_bits             = 2048
default_keyfile          = privkey.pem
distinguished_name       = req_distinguished_name
x509_extensions          = CA_extensions
[ req_distinguished_name ]
organizationName         = Organization Name (must match CA)
organizationName_default = Company
organizationalUnitName   = Location Name
commonName               = Common User or Org Name
commonName_max           = 64
[ user_extensions ]
basicConstraints         = CA:FALSE
[ CA_extensions ]
basicConstraints         = CA:TRUE
default_days             = 3650
[ server ]
basicConstraints         = CA:FALSE
nsCertType               = server

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

openssl dhparam -out dh2048.pem 2048

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

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

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

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

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

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

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

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

Для создания списка отзыва сертификатов необходимо выполнить следующую команду, находясь в папке /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. Для рассматриваемого случая необходимо создать три файла конфигурации клиентов client1client3:

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 необходимо внести следующие изменения в настройки брандмауэра:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

client
dev          tun
proto        udp
remote       <IP-адрес сервера OpenVPN>
tls-client
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). Если в процессе настройки у Вас возникнут проблемы, внимательно анализируйте лог-файлы и читайте обсуждение cтатьи на форуме OpenNET. Если ничего не помогает, задавайте мне вопросы, попробуем решить проблему вместе.

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

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

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

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

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

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

      • У меня есть вопрос по брандмауэру — ядро пересобирать с дивертом, ядерным натом, просто натом или как? У меня IPFW настроен сейчас просто без этих всех опций. Но я чувствую, что если реализовывать OpenVPN сервер, нужно будет все это настраивать.

        • Обычно собираю ядро с опциями:

          options IPFIREWALL # Firewall
          options IPDIVERT   # Divert sockets
          options DUMMYNET   # dummynet(4) bandwidth limiter

          Хватает для маршрутизации, включая NAT, и ограничения полосы пропускания с помощью ipfw.

          • на самом деле этого достаточно

            options IPFIREWALL
            options IPFIREWALL_DEFAULT_TO_ACCEPT
            options IPFIREWALL_FORWARD
            options IPFIREWALL_VERBOSE
            options IPFIREWALL_VERBOSE_LIMIT=50
            options IPFIREWALL_NAT
            options LIBALIAS

            и диверт 100 лет уже не нужен

            • Я использую 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, тоже все работает. А если так, то зачем изобретать велосипед?

              • если бы никто не изобретал велосипед — то досих пор все сидели бы на FreeBSD версии 4Х или 5Х
                натд уже давно труп
                рекомендую посмотреть на ng_nat вроде как интересная штука, сам не пробовал т.к. в основном юзаю pf

          • Огромное спасибо, все получилось, все работает. Статья просто отличная, хотя я бы не сказал, что она будет слишком простой, особенно для новичков. К примеру, там где правила, нужно добавить ссылку на то, как правильно заполнять файл скрипта брандмауэра ipfw

            Но у меня остался еще очень важный вопрос. Дело в том, что если мне придется вдруг защитить ключ действующего сертификата паролем (build-key-pass). То есть мне придется отзывать существующий сертификат, и генерить его заново. Но где гарантия, что после отзыва серт сгенерится с таким же именем? Кроме того, если я захочу начать сначала всю историю сертификатов, мне придется сделать следующие действия (а возможно ли так вообще, не сломается ли программа?)

            1. Удалить из папки certs сертификаты 01.pem 02.pem и так далее
            2. Удалить из файла index.txt все его содержимое
            3. Сбросить счетчик в файле serial на 01

            • Огромное спасибо, все получилось, все работает.

              На здоровье!

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

              Дайте ссылку на более простую статью, это раз, а два, может еще новичков зубы лечить научим простыми словами или дома многоэтажные строить?

              Но у меня остался еще очень важный вопрос. Дело в том, что если мне придется вдруг защитить ключ действующего сертификата паролем (build-key-pass). То есть мне придется отзывать существующий сертификат, и генерить его заново. Но где гарантия, что после отзыва серт сгенерится с таким же именем? Кроме того, если я захочу начать сначала всю историю сертификатов, мне придется сделать следующие действия (а возможно ли так вообще, не сломается ли программа?)
              1. Удалить из папки certs сертификаты 01.pem 02.pem и так далее
              2. Удалить из файла index.txt все его содержимое
              3. Сбросить счетчик в файле serial на 01

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

              P.S.: Не понимаю, почему людей, написавших что-то совершенно безвозмездно, считают идиотами с экспертными знаниями, уймой времени и желанием помочь всем и каждому. Нет, ну правда, почему?

              • Сергей, я не считаю вас идиотом. Зачем мне это? Хотелось бы конечно узнать как ставить и менять пароль без перегенерации сертификата. А насчет того помочь или не помочь — это только ваше право. Можете помогать, можете не помогать. FreeBSD отличная, но сложная система, и мне приходится собирать знания со всего Интернета. Только по одному поводу недоумеваю — почему же я на столь чудесный относительно богатой информации блог наткнулся так поздно. Могу кстати поделиться файликами — скриптами резервного копирования конфигурационных файлов сервера, файлом rc.ipfw с аккуратно написанными правилами ipfw, конфигурационными файлами сервера pure-ftpd, некоторыми написанными самостоятельно правилами Fail2Ban, файлом sysctl.conf с заведенными туда опциями.

                • Сергей, я не считаю вас идиотом.

                  Слава Богу 😀

                  Хотелось бы конечно узнать как ставить и менять пароль без перегенерации сертификата.

                  man openssl не предлагаю, прекрасно понимаю, что Вам лень вникать, а Google с Яндексом отменили? Что они говорят по поводу how change openvpn key passphrase? Причины моего негатива все еще не понятны?

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

                  Я всегда с удовольствием помогаю заинтересованным людям, которые действительно искали доступную мне информацию, но не смогли ее найти. Вы же ничего не искали, даже комменты здесь не прочитали. В них есть ответы на все Ваши вопросы. Спасибо за лестный отзыв о блоге, к сожалению, я ничего не пишу уже два года (писанина требует времени, и ничего не дает взамен). Если Вы взялись за FreeBSD, придется вникнуть в основные моменты, которые не всегда сразу понятны и/или хорошо описаны. Зато после успешного прохождения данного этапа дальнейшие проблемы будут решаться все проще и проще.

                  Могу кстати поделиться файликами — скриптами резервного копирования конфигурационных файлов сервера, файлом rc.ipfw с аккуратно написанными правилами ipfw, конфигурационными файлами сервера pure-ftpd, некоторыми написанными самостоятельно правилами Fail2Ban, файлом sysctl.conf с заведенными туда опциями.

                  Да все это есть, только заточено под конкретные системы, поэтому вряд ли интересно широким массам.

  2. Вечер добрый!
    Есть ещё один вопрос относительно статьи.
    …дело в том, что пытаясь соединить две сети посредством 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) — НЕ ИДУТ!!!
    — — — — — — — — — —
    в чём может быть проблема??? 🙁

    • ПИНГИ (на Фряхах есть 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. Вот и все 🙂

      • Спасибо за ответ!.. 🙂
        Заработало ПОЧТИ всё!..
        Удалённые машины стали пинговаться после того, как были добавлены такие строки в конфигурацию 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… Гугление на эту тему результата не приносит… может Вы или кто из посетителей Вашего сайта сталкивались с подобной проблемой?…
        …Буду признателен за ответ!
        …Ещё раз благодарю за внимание…

        • Я понимаю, что PF и IPFW отличаются в принципе, но всё же хочеться настроить соединение с использованием PF… Гугление на эту тему результата не приносит… может Вы или кто из посетителей Вашего сайта сталкивались с подобной проблемой?…

          Внимательно посмотрите /etc/defaults/rc.conf на предмет опций, связанных с PF. Одной из них должно быть имя log-файла. Когда разберетесь, откройте еще одну консоль, запустите tail -f <имя log-файла PF> и смотрите, какие правила что гасят 😉

  3. Большое спасибо за статью по настройке 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 каталога). Да и пути в конфиге придется поправить.

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

    • Я никогда не сталкивался с OpenBSD, поэтому не могу знать ее нюансов.

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

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

      По поводу тонкостей конфигурирования для конкретных ситуаций — просто уверен, что не существует идеальных решений, окончательную доводку придется делать применительно к конкретной сети. Четкая и однозначная организация скриптов запуска, каталогов и т.д. — один из многочисленных моментов, за которые я уважаю Фрю!
      P.S.: я очень рад, что статья Вам пригодилась. Спасибо за полезные (особенно для OpenBSD’шников) комментарии. Успехов! 🙂

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

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

    • Есть шлюз FreeBSD & IPFW & OpenVPN, сеть за шлюзом 192.168.11.0/24. Есть желание попасть в туже подсеть что за шлюзом.

      Здравствуйте. VPN для этого и создавались.

      Можно ли мне скинуть примерный конфиг для реализации этой задачи.

      Описанный конфиг полностью подойдет. Естественно, придется подправить IP-адреса.

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

    • На здоровье 🙂

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

      Я не заморачивался назначением статических адресов клиентам. Попробуйте как написано Configuring client-specific rules and access policies, и, если можно, напишите, что получилось ❓

      • Как я обещал все решается очень просто. Постоянные статические 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

        У меня все работает 🙂

        • Возникла необходимость сделать статические адреса клиентам. Спасибо за справку. Все работает отлично 🙂

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

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

    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 и наоборот?
    Буду признателен, если поможете!

    • Добрый день!

      Вопрос как настроить маршрутизацию, чтобы подсеть 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

      Не забудьте добавить нужные правила брандмауэра, и все заработает 😉

  9. Добрый день.
    Спасибо за вашу статью «Настройка 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

    еще раз Спасибо!

    • Добрый вечер!

      Когда то бегло прочитав вашу первую редакцию, все прошло успешно. Сейчас видимо изменились требования к конфигурационному файлу openssl.cnf, точнее к его структуре. Я попытался почитать документацию с сайта но безуспешно. Не могли бы вы подсказать (используется ваш конфиг) куда рыть

      В настоящий момент установлена FreeBSD 7.0 RELEASE. OpenSSL родной (тот, который входит в состав системы). Специально проверил команду, все работает нормально. Думаю, что проблема в содержимом файла openssl.cnf, который в настоящий момент полностью соответсвует приведенному в статье. Аккуратненько скопируйте его. Этого должно быть достаточно.

      • Добрый вечер!
        В данный момент установлена 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

        и насколько они важны?
        Спасибо, что дочитали до конца! И извините за излишнюю назойливость.

        • Интересно какой версии ваш 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

          и насколько они важны?

          По параметрам тоже ничего не подскажу, не заморачивался 🙁

          • Прошу прощения что не уточнил, я имел в виду параметр не может находиться в секции расширений, а именно (в данном случае ваш конфиг):

            [ CA_extensions ]
            basicConstraints = CA:TRUE
            default_days = 3650

  10. Хорошая статья!!
    Поднял 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

    • Доброй ночи!

      Единственное не могу достучаться до локалки удаленного офиса.

      Для начала внимательно исправьте конфигурацию сервера. На вскидку:
      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.: Самое главное — будьте внимательнее 😉

      • конфиг сервера я указал не тот.
        вот правельный

        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, чтобы интернет работал на прямую через роутер а впн через вторую группу адресов шел?

        и еще одна загвостка если интернет отключается то впн соединение заного клиент на вин хп не востанавливает как исправить?

        • не работает для схемы линукс — интернет — роутер длинк — локалка (на одном из компов с вин хп стоит openvpn сервер.
          как сделать чтобы работала последняя схема? может всем компам дать второй ip, чтобы интернет работал на прямую через роутер а впн через вторую группу адресов шел?

          Всем компам точно не нужно ничего давать. Можно попробовать сделать проброс порта сервера OpenVPN через ДЛинк на внешний адрес (который видно из Инета) и поменять таблицу маршрутизации компа, на котором стоит сервер. Сам так не делал, т.к. это (имхо) изврат. Попробуйте, напишите, что получилось 😕

          и еще одна загвостка если интернет отключается то впн соединение заного клиент на вин хп не востанавливает как исправить?

          Внимательно почитайте описание параметра keepalive 😉

          P.S.: Используйте теги при оформлении сообщений! 👿

  11. Здравствуйте. У меня проблема, похожая на описанную комрадом 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

    • Добрый вечер!

      Прошу помощи, так как уже второй день никак ничего дельного не могу нагуглить 🙁 Буду благодарен любой помощи или подсказке. Содержимое файла настроек маршрутизации для клиента 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. Читайте внимательно, здесь есть ссылка на соответствующий документ и пример практической реализации ❗

      • Последовал Вашему совету, привел свой конфиг к виду, похожему на Ваш, но ничего не изменилось…
        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

        • Последовал Вашему совету, привел свой конфиг к виду, похожему на Ваш, но ничего не изменилось…

          Файрволы отключены?

          • да, и никогда не включались 🙂
            кстати, а демон routed должен быть запущен? Хотя, вроде и так и так пробовал…

            • По порядку:

              client-config-dir ccd
              tls-auth keys/ta.key 0

              Пропишите полные пути, начиная с / 😕

              tls-timeout 120
              auth MD5 #
              cipher BF-CBC
              max-clients 5

              Эти строки чем-нибудь обоснованы, или как ❓

              а демон routed должен быть запущен?

              У меня он никогда не был запущен.

              • Прописал полные пути к конфиг и к ключу.
                tls-timeout 120
                auth MD5 #
                cipher BF-CBC
                max-clients 5
                Было взято из другой статьи, сейчас закоментировал.
                Результат тот же.

                • Результат тот же.

                  Увеличиваете значение verb у клиента и сервера, а потом внимательно смотрите, что происходит в момент подключения. Туннель создается, маршруты вроде прописаны, файрволы не включены. Могу предположить только опечатку в именах файлов / путях или некорректные права доступа (для пользователя nobody:nobody, естественно). В логе обязательно будет написано, что не нашлось, не открылось и т.д. и т.п. С учетом приведенных в порядок конфигов (лучше еще раз внимательно проверьте, причем не по нескольким статьям, а по одной) больше ничего не могу подсказать 😕

                  • Хорошо, с этим мы разобрались, подсети доступны. Но появилась другая неприятная вещь — пропадение пакетов. В связи с этим хотел задать вопрос — может ли это быть вызвано некорректной работой сервера или клиента? Или же это виноват Волгателеком? (физическое подключение у обоих офисов через adsl) И можно-ли как то это диагностировать, что бы быть уверенным?

                    • Но появилась другая неприятная вещь – пропадение пакетов. В связи с этим хотел задать вопрос – может ли это быть вызвано некорректной работой сервера или клиента? Или же это виноват Волгателеком? (физическое подключение у обоих офисов через adsl) И можно-ли как то это диагностировать, что бы быть уверенным?

                      Как раз ВолгаТелеком очень сильно грешит незамороченной шаблонной настройкой оборудования. Вполне возможно, что на одном из маршрутизаторов трафик через определенные порты ограничивается. Доказать это практически невозможно, т.к. никто не предоставит Вам конфиги и логи. Рекомендую использовать другой порт, а может и протокол TCP/IP. Лучшее решение можно найти только опытным путем 🙄

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

    • А что выдает openssl ca -batch -config openssl.cnf -out certs/CClient.pem -infiles req/RClient.pem ?
      Судя по всему, должна выдавать сообщение об ошибке, с которой и следует разобраться 🙄

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

    • нет строки update database

      Это и есть ошибка. И связана она с некорректным файлом openssl.cnf. При необходимости путь к этому файлу задается ключиком -config. Если все делать под Фрей, находясь в папке /usr/local/etc/openvpn, то будет использоваться файл именно из этой папки. Трогать дефолтный конфиг OpenSSL, находящий в /etc/ssl, не нужно.

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

    • Если не знаете, как проверить, запущен ли сервер, и слушает ли он 1194 порт UDP, то для начала неплохо почитать мануалы или обратиться к специалистам 😉

      • ну так я вроде и обращаюсь к специалистам 😳 😉
        подскажите, плз, где почитать, что посмотреть? очень хочется изучить убунту…

        • Вы мне льстите 😆 А если серьезно, за три дня такие вещи не учат. Понимаю, что хочется, но это невозможно. Азы, вещь скучная, но без них никуда 😉 . Теперь по серверу. С Ubuntu я не знаком, а под Фрёй можно проверить состояние сервера: /usr/local/etc/rc.d/openvpn status, можно найти процесс openvpn в списке процессов: ps -ax | grep openvpn, можно найти сокет openvpn в списке открытых сокетов: sockstat -4 | grep openvpn, можно посмотреть, что openvpn пишет в файл /var/log/messages. Кроме сервера есть еще файлы конфигурации клиентов, брандмауэр и прочие мелочи. На Висте также может быть включен брандмауэр и/или антивирус. Не думаю, что Вам стало легче от моего ответа 🙄

  15. не, я не такой дурак, чтоб не понять то, что Вы написали… 🙂 Статус не получил, по процессам пишет вот это:
    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»

    • Слово «дурак» я не упоминал. Что обозначают ключи команд, которые я написал, можно посмотреть в FreeBSD Man Pages, а потом найти аналоги в man’е Ubuntu. Задайте отдельный лог в конфиге OpenVPN: log <имя файла>, увеличьте детальность лога, для начала: verb 4, выполните команду запуска сервера и посмотрите, что будет в этом логе. Должно стать теплее 😉

  16. Подскажите не могу решить проблему с 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 мс

    • Во-первых, зачем лишние огороды:

      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 никто не настроит 😉

      • ок попробую разобраться. я так понял ifconfig 10.20.30.1 255.255.255.0 это лишнее. На стороне винды ничего не трогал 10.20.30.6 я имел в виду что этот адрес мне автоматом присвоил сам openvpn. Я читал разные статьи)) не доходит пока, фаэрвол пытаюсь разрулить но у меня сейчас он все разрешает по умолчанки. И вопрос. Я так понял таблиц с маршрутами городить ненадо на фряхе?

        • я так понял ifconfig 10.20.30.1 255.255.255.0

          Однозначно, лишнее.

          Я так понял таблиц с маршрутами городить не надо на фряхе?

          Нет.
          P.S.: с файрволом стоит разобраться. В дальнейшем очень пригодится. Рекомендую начать с handbook — IPFW и вообще этот сайт добавить в закладки.

          • Сергей вроде разобрался и все заработало но только почему-то на работе. Такое может быть? Пример. Два белых 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]

            • Ничего не понял:

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

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

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

  18. Опять вопрос по маршрутизации. Только сеть проще, чем в статье.
    Имеется выделенный сервер на 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, а вот другие машины этой сети нет. В чем может быть проблема?

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

      • вот результаты 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) все машины сети пингуются.
        Завтра попробую на своей локальной отрубить фаервол и антивирус и отпишусь, получится ли.

      • Попробовал на рабочем месте отключить firewall и антивирус. Моя машина не пингуется (192.168.0.238). Пинговал с сервера VPN. Куда копать — ума не приложу.

          • говорит так:

            # 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 или ещё какая-либо служба???

            • 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 на офисном роутере?

              • Постораюсь объяснить объяснить ситуацию.
                Есть рабочая сеть — 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 или на почту. Мне кажеться, задачка очень не стандартная и может многим помочь.

                • Теперь понял. Однозначно копайте в сторону файрволов/антивирусов на компьютерах локальной сети. Как только с ними все наладится, Ваша конфигурация должна на них заработать. Добьетесь этого, назначайте статические адреса всем клиентам и начинайте пользоваться VPN. Схемы, которая, кстати, нарисована в обычном Visio, давным-давно не существует.
                  P.S.: Мне кажется, что route 192.168.0.0 255.255.255.0 из конфигурации VPN-сервера следует убрать, как и iroute 192.168.0.0 255.255.255.0 из файла конфигурации клиента.

  19. Вот картинка сети. Надеюсь понятнее станет.

    Мне кажется, что 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 клиенте нет. На машинах в сети тоже.

    • Если это убрать, то перестаёт пинговаться “клиент VPN 1″ по адресу (192…) с “сервера VPN”. Задача в итоге сводиться к тому, чтобы попасть в сеть 192.168.0.0.

      Компьютеры локальной сети будут доступны по виртуальным адресам. Со 192.168.0.xx ничего не получится, если Вы не установите VPN-клиент на офисный роутер. Про присвоение конкретных адресов конкретным компьютерам я уже рассказывал.

  20. Да, я уже понял, в чём косяк. На роутер доступа у меня нет. Но это решается настройкой NAT на клиенте vpn, который в офисной сети. Так что теперь изучать мне нат. Огромное спасибо. Статья отличная. Мне кажется, что надо добавить описание параметров, которые можно использовать в конфиге клиента и сервера + добавить FAQ. Сам хочу написать подробную статейку на эту тему. Если не против, то «сопру» часть материала отсюда, естественно с указанием источника.

    • На здоровье. С указанием источника «прите» хоть все 🙂
      NAT Вам не поможет, нельзя транслировать адреса в пределах одной подсети.

  21. А как реализовать такую схему. Есть сервер freebsd он будет openVPN сервером для мобильных пользователей, но он также должен быть openVPN клиентом до центрального офиса.

    • Ставьте одновременно клиент и сервер OpenVPN, вешайте их разные порты, делайте два туннеля, меняйте правила маршрутизации и настройки файрвола, все будет работать прекрасно 😉

  22. Все делал как у вас по шагам ….. но не мгу запустить
    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

  23. есть сеть предприятия (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
    помогите разобраться плиз

  24. сеть 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

    наверно надо еще маршрут написать?
    подскажите пожалуйста

    • 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 комментарий к статье? Ничего личного, просто подход к делу у Вас ну совсем не админский 😉

  25. Здравствуйте!

    Хотелось бы автоматизировать создание большого числа клиентских сертификатов. Пока накопал опцию -subj, которая позволяет это делать. Т.е. у меня текстовый файл с именами клиентов, которые передаются в build-key.bat. Как справится с ответом на вопросы типа Sign the certificate? [y/n]:y и 1 out of 1 certificate requests certified, commit? [y/n]? Или есть какой-либо ещё метод для подобной автоматизации?

  26. Здравствуйте. Спасибо за статью.
    Сразу хочу отметить некоторые не точности, на которые наткнулся при установке.
    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?

    • Здравствуйте! На здоровье! Теперь по пунктам:

      Перед тем как выполнить команду openvpn --genkey --secret ta.key желательно перезагрузиться, а то команду openvpn – не найдёт

      Этот момент зависит от используемой shell и ее конфигурации. В случае bash, найдет, а в случае sh с настройками по умолчанию действительно придется перезалогиниться.

      В примере конфигурационного файла клиента , не там стоит. Должен стоять напротив строчки tls-remote, как описано у Вас дальше в тексте.

      Прошу прощение за невнимательность. Исправил. Спасибо.

      Желательно указать, что нужно самому создать группу и пользователя openvpn, т.к. автоматически они не создаются, как допустим при установке mysql.

      В более старых версиях OpenVPN (а статье почти 4 года) пользователь и группа openvpn создавались автоматически, в последних версиях не создаются, поэтому можно воспользоваться, например, nobody:nobody.

      … Вот мне интересно, как у Вас всё заработало на IPFW? Неужели у Вас IPFW загружается после openvpn?

      Естественно, ipfw запускается раньше openvpn, все работает отлично. Я не знаком с pf, но, если все происходит так, как Вы написали, нужно добавить команды создания правил pf в файлы конфигурации клиентов.

  27. При конекте к серверу постоянно выдает такую ошибку:

    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. Не понятно какие поля должны быть разными/совпадать.

  28. Доброго времени суток.
    Руководствовался статьей, для решения своей задачи. С 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

    • С FreeBSD мало знаком, но приходится делать именно на нем.

      Может стоит привлечь тех, кто знаком?

      Оба клиента успешно конектятся к серверу, получают IP, но не могу заставить их друг друга видеть. Брандмавер открыт.

      При Вашей конфигурации будет возможна связь только между локальными сетями клиентов (сеть за сервером OpenVPN нигде не упоминается). Вам нужна именно такая конфигурация?

      • Может стоит привлечь тех, кто знаком?

        К сожалению, не располагаю такими знакомствами.

        При Вашей конфигурации будет возможна связь только между локальными сетями клиентов (сеть за сервером OpenVPN нигде не упоминается). Вам нужна именно такая конфигурация?

        Да, все верно. За сервером, сети нету.

        • К сожалению, не располагаю такими знакомствами.

          Интернет есть. Можете ко мне обратиться, например, или к ребятам, ссылки на которых есть в сайдбаре, или на форум Лисяры 😉
          Теперь по делу. В Windows IP-маршрутизация включена? route print что выдает?

          • 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
            ===========================================================================
            Постоянные маршруты:
            Отсутствует

  29. День добрый. На сервере (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 не работает.

    • Доброй ночи!

      Все клиенты подключившиеся к OpenVPN серверу могут пинговать друг друга.

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

      Возможно как то фильтровать пакеты внутри OpenVPN? Допустим чтобы проходили пакеты на порт 3389.

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

      • Все правила доступа, ограничения скорости и балансировки трафика реализуются с помощью брандмауэра, в частности, ipfw умеет делать эти вещи без каких-либо проблем.

        Я пробовал. Не работает. Такое ощущение что пакеты идут внутри OpenVPN.

        • Я пробовал. Не работает. Такое ощущение что пакеты идут внутри OpenVPN.

          В статье и комментариях все подробно описано. Осталось ВНИМАЛЬНО изучить информацию, а затем устранить проблемы. Рекомендую начать с настройки без ограничений доступа. Когда все получится, можно будет подкорректировать правила брандмауэра.

          • Я попробую уточнить. 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

            • Все пользователи подключаются к нему. Получилось что то типа виртуального хаба. Терминальный сервер тоже подключается как обычный клиент и имеет свой адрес, полученный от сервера 10.7.0.18.

              Вполне стандартная конфигурация, не отличающаяся от описанной в статье (терминальный сервер имеет такую же конфигурацию OpenVPN, как компьютер системного администратора).

              Я пробовал в ipfw писать правила на ограничение трафика по портам, но пакеты до них не доходят.

              Вы хотите ограничить доступ портом 3389/tcp но зачем-то пишете правила для порта 1149, да еще и с ошибками (ip = TCP,UDP и ICMP одновременно, поэтому не нужно указывать номера портов при его использовании). Посмотрите на картинку, еще раз прочитайте статью и комментарии, а также полистайте man ipfw. Это не только поможет решить задачу, но и много раз пригодится в будущем. Я не готов читать долгие лекции, поймите правильно. Как только будете готовы задавать конкретные вопросы, обязательно отвечу.

  30. Доброго дня! Вопрос следующий: возможно ли шифровать трафик в vpn канале по ГОСТу (сертифицированное решение не нужно, просто для себя тестируем)? Собрал openssl с поддержкой ГОСТ.

    [root@CentOS ~]$ openssl ciphers | tr -t ":" "\\n" | sort | grep GOST
    GOST2001-GOST89-GOST89
    GOST94-GOST89-GOST89

    Поддержка ГОСТовских алгоритмов имеется. Но при openvpn --show-ciphers вышеописанные алгоритмы не отображаются.

      • Хороший совет! А если серьезно? Реально ли прикрутить? Я то думал, что openvpn шифрует канал именно средствами openssl. Или где то не прав?

        • А если серьезно? Реально ли прикрутить?

          Я вполне серьезно говорю, что меня поражает и одновременно раздражает отношение таких людей, как Вы, к чему-то безвозмездному, данному совершенно чужим людям в силу, например, увлеченности любимым делом. С чего Вы взяли, что я должен изучать за Вас внутренности OpenVPN? Готовы платить, будет Вам ГОСТ, если OpenVPN его поддерживает, не готовы — разбирайтесь самостоятельно 😉

          Или где то не прав?

          Для начала, нужно запускать не openvpn --show-ciphers, а openvpn --show-tls 😉

          P.S.: man openvpn никто не отменял!

          • Хм, а я то думал,что разного рода тематические форумы и обсуждения созданы для того, чтобы люди безвозмездно могли получить консультации, обменяться опытом, получить совет. Man я конечно почитаю, но нельзя же так интересующемуся человеку давать от ворот поворот. Я не заставляю Вас за меня изучать внутренности openvpn, я просто спросил совета как у опытного админа.

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

              Во-первых. Вы абсолютно правы насчет ФОРУМОВ и СООБЩЕСТВ. Только здесь не форум и не сообщество, а блог, который ведется одним незаинтересованным человеком. Я не евангелист — проплаченный сотрудник, ведущий технически грамотный PR некоего продукта, а обычный сисадмин, делящийся скромным опытом. Вы можете использовать этот опыт так, как хотите, можете задавать вопросы о том, что НАПИСАНО В СТАТЬЕ, указывать недостатки и предлагать доработки, за что я буду Вам благодарен.
              Во-вторых. Вы спросили про ГОСТы, я ответил, что не знаю. Опять же, Вы не читали комментарии, в которых уже задавался данный вопрос.

              Но нельзя же так интересующемуся человеку давать от ворот поворот.

              Я открыл мануал OpenVPN, нашел ответ на Ваш вопрос и сообщил его Вам. По Вашему это и есть «от ворот поворот»?

              Я не заставляю Вас за меня изучать внутренности openvpn, я просто спросил совета как у опытного админа.

              Слава Богу, заставить меня что-либо сделать, Вы не сможете. Насчет «опытного админа» — спасибо за комплимент. При наличии возможности я обязательно даю совет человеку, который действительно пытался и старался. А те, кто даже не удосужился заглянуть в официальное руководство, вообще не должны лезть в наш огород (системное администрирование). Это мое твердое убеждение, на которое я имею полное право и, кстати, ни кому его не навязываю.

  31. На новом 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. В чем проблема?

    • А зачем Вы задаете этот вопрос здесь? VPN работает? Отлично! А с DNS-сами разбирайтесь или специалистов привлекайте 😉

    • Спасибо за ответ. Я даже не смотрел конфигурацию, т.к. считаю, что, если человек что-то добавил, то он осознает, зачем он это сделал 🙂

    • Не совсем понимаю ее смысл. Конкретно — зачем два сервера? Стандартный вариант, который здесь описан, — сервер и все клиенты подключены к Интернету, а дальше маршрутизация и правила доступа между ними по вкусу и потребностям.

  32. есть 2 разных опенвпн сервера, и они должны быть как серверы, вопрос в том как их соединить?

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

  33. Смысл двух серверов все равно не понимаю! Почему плавненько не перевести клиентов второго сервера на первый?

    Нельзя, т.к.разные конторы, а есть вариант один хост сделать клиентом сразу у двух серверов?

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

    Ну или так, но всё таки точно извращение =)

    • Нельзя, т.к.разные конторы

      Руководство обеих представляет, что за трафик идет через 1194 порт UDP? Другими словами — если трафик через VPN не очень большой, никто ничего не заметит. У меня именно так и происходит с колымными клиентами. Cервер VPN стоит на основной работе на нормальном канале, тариф безлимитный, все имеют доступ только к тому, к чему им положено, поэтому моя совесть абсолютно чиста 🙂

      А есть вариант один хост сделать клиентом сразу у двух серверов?

      Придется запустить на этом хосте 2 клиента OpenVPN. Я сам так не делал, но не вижу причин, почему это не должно работать.

  34. Добрый день, у нас настроен сервер с 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 в каталоге не появляется. Если у кого-то есть опыт решения такой проблемы, поделитесь. Спасибо.

  35. Здравствуйте, немного запутался и не могу своими силами решить проблему, буду благодарен любой подсказке, ситуация такая: две локальных сети: 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? При настройке добавлял в него несколько правил, но может этого не достаточно?
    Тыкните пжл в ошибку.

    • 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

      • Крутил вертел никак не могу заставить по прежнему. Со вторым клиентом чудеса происходят, он подключается но не пингует сервер, и сервер его не пингует.

        Имеется ввиду, что 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 подключаться и всех видеть, подскажите с помощью каких инструментов можно ошибку найти? Конфиги вроде правдоподобно выглядят?

        • Он динамический, но при подключении у клиента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.

          Конфиги вроде правдоподобно выглядят?

          Не знаю в какой по счету раз говорю — статья содержит рабочие конфиги. Не нужно их «дорабатывать» пока не разберетесь что к чему.

  36. Когда 2ой клиент подключился, я тоже с конфигом от 2ого клиента смог подключиться , это же не должно так быть? Если специальную строчку в конфиге не прописать?

  37. Доброго времени суток! Может вы поможете решить проблему такого характера: Есть сеть в головном офисе 192.168.0.0/16 и есть сеть в филиале 192.168.6.0/16 не удается их подружить так как маски одинаковые. Опенвпн выдает ошибку типа такая сеть уже используется. Если сменить маску в филиале на /24, то оттуда не видят никаких ресурсов в головном офисе. Пришлось временно сделать в филиале сеть 192.169.6.0/16 при этом связь работает, пинги ходят, РДП работает, расшаренные ресурсы видны, но некоторые программы не хотят устанавливаться в филиале типа другая сеть уже. Не подскжете решение проблемы?

    • Добрый вечер!
      Если использование маски /16 имеет смысл, то придется сделать как у Вас, если не имеет — и там и там /24 😕

  38. Ясно, спасибо. Жаль, что не получается сделать как хотелось. Маску /16 сделали не с проста.

  39. То есть, на физической сетевухе делаем сеть 192.168.6.0/16 а на виртуальной 192.168.1.0/24 и его связываем по ВПН так? И трафик с виртуальной автоматом идет на физическую сетевуху и все в шоколаде? Я просто с алиасами сетевух не сталкивался ниразу.

  40. Подскажите пожалуста, что делать если при запуске VPN вырубает инет? Буду признателен.

    • Для начала выбросить из файлов конфигурации OpenVPN всю отсебятину, которая отвечает за маршрутизацию 😉

  41. Здравствуйте.
    Мне нужно настроить доступ во внутреннюю сеть по 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 поставить, то толку от фаервола вроде как никакого…

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

  42. Есть VPS на котором поднят OpenVPN, все работает отлично. Появилась необходимость в дополнительном IP… IP на VPS добавил, у клиента в конфиге прописан, однако не работает. Подскажите пожалуйста как подлучить 2й IP для OpenVPN?

    • однако не работает

      Что именно не работает? Клиент получает IP? Маршруты добавляются? Брандмауэр пропускает нужный трафик?

  43. Сложно сказать. Я слабо в этом разбираюсь. Не подключается клиент по 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

    • Сложно сказать.

      Если сложно сказать, то представьте, на сколько сложно понять.

      Я слабо в этом разбираюсь.

      Это Ваша проблема. Никто не мешает почитать документацию.

      Не подключается клиент по 2му IP – 22.222.22.222.

      Я не знаю Вашу конфигурацию, поэтому данный вопрос получается из оперы «не отправляется на деревню дедушке».

      P.S.: Прошу задавать вопросы по существу, максимально кратко и точно. В противном случае забаню.

      • Сервер Centos — имеет 2ip 11.11.11.11 и 22.22.22.22
        Клиент — Windows 7, по первому ip работает VPN по 2му — нет.
        Как сделать чтобы работало по 2му ip?

          • В конфиге было:

            # 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].

            • Выдержка из 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-адреса на другой.

  44. ПОМОГИТЕ!!!
    на экзамене будет такой вопрос, напишите ответ, очень прошу!

    Опишите конфигурацию openvpn для простейшего случая с использованием статического ключа для организации доступа между двумя сетями 192.168.1.0/24 и 192.168.2.0/24, внешние адреса маршрутизаторов, соответственно, 1.1.1.1 и 2.2.2.2.

  45. Достался сервак от прошлого админа, все делаею как в статье только не хватает файла ta.key. Как его сгенерировать и если сгенерирую новый, будут ли действительны уже сгенерированные сертификаты/отвалятся ли у меня уже подключенные клиенты?

    • Сгенерировать файл ta.key можно также, как описано в этой статье, только его придется передать всем клиентам, прописать в их файлы конфигурации и перезапустить на них OpenVPN. Сертификаты не отвалятся.

  46. Спасибо за ответ, подойдет ли мне ранее сгенерированный и отправленный клиенту файлик ta.key, чтоб не генерировать новый?

  47. Рано я радовался, нарвался на проблему. Пробовал прописать маршруты а папке 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 и прокинуть маршрут через сервер до соседнего компьютера?

    • Кстати, у нас совершенно нет надобности использовать адреса типа 192.168.x.x подключение прямое.

      Не понял эту фразу ❓

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

      • Насчет непонятной фразы — у меня дома 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

        • Просто хотелось бы узнать как в этом случае пробросить маршрут, на сервере и на клиентах по одной сетевой карте, но оба клиента подключаются к серверу через белый 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. Нельзя тупо копировать конфиги, не вникая, что дает каждая строчка 😉

  48. Здравствуйте. Все вродебы правильно настроил(на мой взгляд 🙂 . На стороне сервера сеть 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
    Вобщем в логах ни на что не ругается, маршрутизация вродебы прописана, а доступа к реальным сетям нету ни с одной ни с другой стороны, только в виртуальной сети. Может у кого есть идеи?

    • Прошу прощения связь с сервером есть(192.168.0.50 пингуется) и как показывает tcpdump icmp пакеты приходят на адреса сети 192.168.0.0, а вот обратно не доходят. Немогу разобраться в чем дело :(. неужели на каждого клиента в сети нужно ставить OpenVPN

    • Извините, проблема решена, поспешил, прописал в роутере 192.168.0.1 маршрут Destination LAN NET 10.0.0.0 Subnet Mask 255.255.255.0 Gateway 192.168.0.50, и все заработало.

  49. Данная статья уже по факту является некой базой знаний по поводу использования 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.

  50. Опервпн запушен на домашнем роурете. С клиента не удается подсоединитсё с ошибкой: что делать?

    [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

    • Мне кажется, что в приведенном куске лога есть сообщения об ошибках? Разбирайтесь со всеми 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.: В следующий раз «слишком информативные» коменты отправятся в СПАМ.

  51. Спасибо за статью, но было бы здорово дописать конфигурации «клиентов»
    после тацев с бубнами заработало вот так. 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

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

      Например, в Windows 7 нужно добавлять:
      route-method exe
      route-delay 2

      в FreeBSD:
      nobind

      и т.д. и т.п. Кому нужно, разберутся, что Вы и подтвердили 🙂

  52. Благодарю за отличную статью и за блог вообще. Сделал все последовательно, получил ключи, подключился — все работает. Возникла необходимость написать скрипт, который будет генерить все необходимое для передачи клиенту потом и, в связи с этим, возникло пару вопросов:
    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 значения менять в обоих файлах, чтобы неизменяемые параметры (страна, организация) соответствовали потом?

  53. Вчера писал долго сообщение, вроде отправилось, но сегодня его нет, поэтому (уже вкратце):
    Сергей, огромное спасибо за статью и за блог.
    Пара вопросов:
    1. Почему при commonName optional и commonName_default = vasya запрос на сертификат выдает ошибку?
    2. Я правильно понял, что при запросе используется системный файл /etc/ssl/openssl.cnf, а при подписывании тот который в папке openvpn (-config openssl.cnf)?
    Буду очень признателен за ответы, т.к. застрял на этом при написании скрипта.

    • Вчера писал долго сообщение, вроде отправилось, но сегодня его нет, поэтому (уже вкратце):

      Было малость не до блога 🙂

      Сергей, огромное спасибо за статью и за блог.

      Спасибо, что читаете!

      Почему при commonName optional и commonName_default = vasya запрос на сертификат выдает ошибку?

      Не знаю, нужно разбираться 🙁

      Я правильно понял, что при запросе используется системный файл /etc/ssl/openssl.cnf, а при подписывании тот который в папке openvpn (-config openssl.cnf)?

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

      По поводу написания скриптов Вы зря мучаетесь. Статья писалась очень давно, когда все приходилось делать вручную, теперь в комплекте OpenVPN есть все необходимые скрипты.

  54. Спаибо за статью! все получается… почти.

    Вопрос по отозванным сертификатам. Сделал отзыв сертификата как у вас написано, но как-то ничего не изменилось. То есть сертификат числится в базе отозванных, а клиент как подключался так и подключается. А мне таки надо чтобы он не мог…

    Подскажите куда смотреть плз…

    • На здоровье! Перезапустите сервер OpenVPN, клиент с отозванным сертификатом больше не подключится.

  55. сам себе заля буратина. отозвать — отозвал, а базу не перестроил!
    так что тут все хорошо, спасибо 🙂

    есть другой трабл… если клиенту сказать рестарт, или не дай боже серверу — оно все говрит что лин сктоит, а капеты не худють…

    а вот если скахать дисконнект а потом обратно коннект — тогда все поднимается хорошо…

    буду завтра рыться…

      • вечно я невнятен…

        если со сторны клиента сказать рестарт соединению (через гуи)
        то соединеие установится, но роутинг не применяется почему-то… то есть надо разорвать и снова запустить, чтобы все ходило…

        если происходит рестарт сервера опенвпн (на фряхе)
        то со стороны клинета статус остается коннектед. а роутинг опять падает и пакеты не ходят… нужно переподключение…

        буду еще смотреть что-как… руки не доходят 🙁

        • VPN должна подниматься, не зависимо от того, кто инициировал рестарт. Покажите результат выполнения команды route print на компьютере с Windows.

          • А вот то-то оно и есть, что роута вываливается после «рестарт» на клиенте
            хотя на сервере пишет что все случилось… Выпушил на клинета роуту:

            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
            ===========================================================================
            Постоянные маршруты:
            Отсутствует

            Если добваить роуту руками - все оживает, ясное дело.
            При первичном подключении в логах клиента все то же самое, но роута появляется.

            • С рестартом сервера все еще печальнее…
              Сервер рестрартился, но клиент этого никак не почувствовал — в логах чисто.
              Роуты есть, но ничего никуда не ходит….

              Почему оно не отваливается — я не понимаю…

              А нет! Вру… Я просто не терпелив. Оно прочухалось через полторы минуты где-то и переподключилось… Роутинг при этом на клинете поднялся…

              • оно прочухалось через полторы минуты где-то и переподключилось…

                Точное время «прочухивания» определяется параметром keepalive 😉

  56. Доброго времени суток!
    Отличная статья. Жаль она мне сразу не попалась.
    Склеивал рабочий конфиг по обрывкам разных постов, но судя по тому, который указан в этой статье, вроде бы склеил правильно.
    Но вот достучаться внутрь подсетей за клиентами не выходит никак.
    Может Вы сможете подсказать где я ошибся.
    Имеются два клиента (условно А и Б) с подсетями. И сервер, без подсети.
    Клиенты видят друг друга и сервер без проблем. Пингуются один с другого как по 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

    Но обратно ничего не доходит.

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

      • Конфиг ваш скопировал, в итоге только cipher лишний. А вот проблемы похожие не мои в коментариях то решались, но как именно, никто толком не описывает к сожалению.

  57. Добрый вечер,
    Надеюсь на помощь профессионалов, проблема в создании сертификата клиента в 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

    • Добрый день! В представленных Вами строках нет сообщений об ошибках. Если Вы вводите уникальные CN для всех клиентов, все должно генерироваться и подписываться.

      • Добрый вечер Сергей,
        CN ввожу уникальные, для каждого клиента свой. Ошибки нигде не генерируются (я так думаю), т.к. ошибок нет, ситуация странная, последнее что я вижу на экране это «Using configuration from /etc/ssl/openssl.cnf» и все встает, прождал около 2 часов, ничего не изменилось. Вышел нажатием CTRL+Z. Может посоветуете какие логи можно посмотреть в такой ситуации или лучше все проделать сначала (сгенерировать все сертификаты заново)?

        • Ни разу не сталкивался с такими поведением openssl. Для начала добавьте к команде ключик --verbose. Если не поможет, попробуйте перенести рабочую папку со всем сгенерированным хозяйством и файлом openssl.cnf на другой компьютер и попробуйте на нем.

          • Добрый вечер,
            Ключик и перенос всего хозяйства на другой компьютер не помогли. Поведение было аналогичное. Очень и очень странно. Ранее до отключения параметра check-crl сертификаты генерировались. Придется наверное завтра все снести и сгенерировать заново. Вам большое спасибо, что откликнулись.

              • Сергей добрый вечер, с генерацией разобрался. спасибо за поддержку. все настройки делал по этой ссылке. Вся проблема оказалась из-за файла 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]

                Потом допёр, что цвет должен был быть прописан для этого блока в сайте. Убрал эти значения с квадратными скобками и все пошло.

  58. Доброе время суток. С FreeBSD только разбираюсь, так что…
    В наличии имеем: настроенные сервер vpn и клиентский vpn. На клиентской стороне два провайдера: радиоканал и adsl. Adsl для выхода в инет, радиоканал — для vpn. Можно ли настроить так, чтобы при отсутствии связи по радиоканалу vpn поднимался по Adsl автоматически?

    • Доброго! Можно, но после окончания «только разбираюсь». Есть нюансы с динамическим изменением маршрутов и правил брандмауэра, а такие вопросы без четкого понимания не решаются.

Оставить комментарий