FreeBSD OpenVPN | Subnets.ru blog

Метки статьи: ‘FreeBSD OpenVPN’

Поднятие туннеля OpenVPN на FreeBSD

Добро пожаловать в блог! Надеемся, что Вы еще вернетесь.

Делалось по статье http://tuxnotes.ru/articles.php?a_id=18
Тут приведу её полностью, со своими комментариями и дополнениями [в квадратных скобках].

В конце статьи будут приведены мои конфиги сервера и клиента.
—————————————————————————————————————

Создание сервера OpenVPN в FreeBSD

Однажды передо мной предстала задача реализации безопасного доступа из внешнего мира к внутренней корпоративной сети. На выходе из корпоративной сети стоял FreeBSD 7.0, в качестве реализации был выбран OpenVPN.
В данной статье я на примере из личной практики опишу процесс создания OpenVPN сервера на системе FreeBSD, с возможностью подключения к нему удаленных пользователей (с различных операционных систем: Windows, Linux, MacOS etc.).

Настройка проводилась на системе FreeBSD версии 7.0, настройка на других версиях аналогична данной.

Адрес внутренней сети — 192.168.1.0/24

1. Установка OpenVPN, создание сертификатов и ключей

Устанавливаем OpenVPN из портов:

cd /usr/ports/security/openvpn
make install clean

Далее создаем сертификаты и ключи:

cd /usr/local/share/doc/openvpn/easy-rsa/
[при моей инсталляции требуемые файлы лежали в /usr/local/share/doc/openvpn/easy-rsa/2.0]

Редактируем файл vars, содержащий переменные окружения:

chmod +w vars
vi vars
[также нужно отчмодить и скрипты в каталоге, за исключением файлов *.cnf и текстовых Makefile и README]

затем добавляем в файле vars к переменной export KEY_DIR=$D/keys еще каталог server (для удобства). Должно получиться так:

export KEY_DIR=$D/keys/server
[я не добавлял дополнительный каталог]

Загружаем переменные в оболочку:

sh
. ./vars
[таким образом переменные у меня не загрузились и чтобы не терять время на разборы, я сделал экспорт всех переменных вручную. они нужны только для создания файлов сертификации и т.д.]

создаем каталог keys и в нем подкаталог server

mkdir -p keys/server

создаем сертификат для сервера:

chmod +x build-ca
./build-ca

Пример ввода данных:

#./build-ca
Generating a 1024 bit RSA private key
....................++++++
...++++++
writing new private key to 'ca.key'
----- You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----

Country Name (2 letter code) [UA]:UA
State or Province Name (full name) [Kiev]:Kharkov
Locality Name (eg, city) [Kiev]:Kharkov
Organization Name (eg, company) [x]:server
Organizational Unit Name (eg, section) []:server
Common Name (eg, your name or your server's hostname) []:server
Email Address [root@localhost]:

Создаем файлы index.txt и serial:

touch /usr/local/share/doc/openvpn/easy-rsa/keys/server/index.txt
echo «00»>/usr/local/share/doc/openvpn/easy-rsa/keys/server/serial

Затем создаем сертификат X.509 для сервера. Всё необходимо заполнить аналогично и добавить строки с указанием пароля и имени организации:

chmod +x build-key-server
./build-key-server server

#./build-key-server server
Country Name (2 letter code) [UA]:UA
State or Province Name (full name) [Kiev]:Kharkov
Locality Name (eg, city) [Kiev]:Kharkov
Organization Name (eg, company) [x]:server
Organizational Unit Name (eg, section) []:server
Common Name (eg, your name or your server's hostname) []:server
Email Address [root@localhost]:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []: your_password
An optional company name []:server

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

Создаём ключ для клиента:

chmod +x build-key
./build-key client

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

Стоит заметить, что поле organizationName должно совпадать с тем, которое мы ввели при создании сертификата сервера. В нашем случае это будет имя server.

Создаем ключ Диффи-Хелмана (необходим для безопасной авторизации двух сторон):

chmod +x build-dh
./build-dh

выходим из sh:

exit

Создаем ключ для tls-аутентификации:

openvpn —genkey —secret keys/server/ta.key

создаем каталоги для нашего openvpn-сервера:

cd /usr/local/etc/
mkdir openvpn
cd openvpn/
mkdir keys
mkdir ccd

Переходим в каталог /usr/local/etc/openvpn/keys и копируем в него необходимые для сервера ключи и сертификаты:

cd /usr/local/etc/openvpn/keyscp /usr/local/share/doc/openvpn/easy-rsa/keys/server/ca.crt
cp /usr/local/share/doc/openvpn/easy-rsa/keys/server/dh1024.pem
cp /usr/local/share/doc/openvpn/easy-rsa/keys/server/server.crt
cp /usr/local/share/doc/openvpn/easy-rsa/keys/server/server.key
cp /usr/local/share/doc/openvpn/easy-rsa/keys/server/ta.key

Когда сертификаты и ключи созданы, переходим к настройке OpenVPN-сервера.

2. Настройка сервера

в каталоге /usr/local/etc/openvpn создаем файл конфигурации нашего openvpn-сервера

touch server.conf

#указываем порт, на котором будет работать наш сервер
port 2000
# протокол будет использоваться udp (по идее он работает быстрее чем tcp)
proto udp
# используемый тип устройства и номер
dev tun0
#указываем файл CA
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

#задаем виртуальный IP-адрес сервера и маску подсети, которые будут использоваться в нашем туннеле между сервером и удаленным клиентом
server 10.0.0.0 255.255.255.0

#указываем клиенту маршрут к серверу по виртуальному интерфейсу
push «route 10.0.0.0 255.255.255.0»

# указываем где хранятся файлы с настройками клиентов
client-config-dir ccd

# включаем TLS аутентификацию
tls-server
# указываем tls-ключ, и указываем 0 для сервера, а 1 для клиента
tls-auth keys/ta.key 0
# таймаут до реконекта
tls-timeout 120
auth MD5
# включаем шифрацию пакетов с использованием алгоритма симметричного шифрования Blowfish. Пока не было известно ни одно случая взлома данного алгоритма + он быстрее DES
cipher BF-CBC
[в моём случае шифрование не использовалась и поэтому этот пункт закомменчен]

#указывем, что каждые 10 секунд пинговать удаленный хост, и в случае если, в течении 120 секунд не будет ответа — то разрывать соединение
keepalive 10 120

# сжатие трафика
comp-lzo
[если эта опция используется на одной из сторон, она должна обязательно использоваться и другой стороной. иначе коннект будет рваться на этапе согласования MTU туннеля
между сервером и клиентом]

# максимум клиентов
max-clients 100

#по умолчанию используется аутентификация пользователей по файлам сертификатов, то есть пользователь у себя хранит файлы сертификатов, соответственно пароль в таком случае не используется. На мой взгляд это не совсем безопасно (т.к. если кому-то удастся заполучить эти сертификаты, то он легко сможет получить доступ к нашей корпоративной сети). Я решил добавить к аутентификации по сертификатам еще и аутентификацию по паролю. Будет использоваться пара логин/пароль пользователя в системе FreeBSD ( которого необходимо заранее создать).
[разумеется, используется пользователь с паролем и без шелла — /usr/sbin/nologin
в случае автора эти логин-пароль при установлении соединения нужно ввести вручную, как сделать это автоматически рассмотрено ниже]

Для добавления аутентификации по паролю подключаем плагин openvpn-auth-pam (который обычно идет вместе с пакетом OpenVPN):

plugin /usr/local/lib/openvpn-auth-pam.so loginuser nobody
group nobody
# Не перечитывать ключи после получения
# SIGUSR1 или ping-restart
persist-key
# Не закрывать и переоткрывать TUN\TAP
# устройство, после получения
# SIGUSR1 или ping-restart
persist-tun
# логирование (не забудьте создать дирректорию /var/log/openvpn/)
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
# Уровень информации для отладки
verb 3

затем создаем в каталоге ccd файл с настройками удаленного клиента (имя файла должно строго совпадать с именем сертификата, то есть в нашем случае это имя client) следующего содержания:

push «route 192.168.1.0 255.255.255.0»

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

добавляем в файл /etc/rc.conf следующие строчки, для атоматического запуска openvpn-сервера при загрузке системы

openvpn_enable=»YES»
openvpn_if=»tun»
openvpn_configfile=»/usr/local/etc/openvpn/server.conf»
openvpn_dir=»/usr/local/etc/openvpn»

Если у вас стоит фаервол, то не забудьте открыть в нем порт. У меня стоит pf, я добавляю следующие правила:

set skip on tun0
pass in inet proto udp from any to $ext_if port 2000 keep state
pass quick on tun0

Не забудьте указать в /etc/rc.conf:

gateway_enable=»YES»

для того, что что бы ваше сервер мог перенаправлять пакеты.

[если до этого момента gateway_enable не было в /etc/rc.conf, то что бы применить изменения без перезагрузки выполните: sysctl net.inet.ip.forwarding=1]

Все. На этом настройка нашего сервера закончена.

3. Настройка клиента

С сервера необходимо скопировать созданные ранее сертификаты, но не все, а только необходимые пользователю, а именно: ca.crt, client.crt, client.key, dh1024.pem, ta.key.

В рабочем каталоге OpenVPN на стороне клиента создаем папку keys, куда и копируем вышеприведенные файлы. Затем создаем конфигурационный файл с любым именем, например client.ovpn, со следующим содержимым:

dev tun
proto udp
remote 11.11.11.11 #(вместо 11.11.11.11 необходимо указать внешний IP вашего сервера)
port 2000 #(порт к которому устанавливать соединение)
client
resolv-retry infinite
ca keys/ca.crt
cert keys/client.crt
key keys/client.key
tls-client
tls-auth keys/ta.key 1
auth MD5
auth-user-pass # команда, указывающая клиенту использовать авторизацию по паролю
cipher BF-CBC
ns-cert-type server
comp-lzo
persist-key
persist-tun

#proxy 192.168.1.50:3128 #Раскомментируйте эту строчку, если вы работаете через прокси-сервер

status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3

На этом настройка закончена. Все конфиги брались с рабочего сервера.
Процесс создания OpenVPN-сервера на других системах (Debian, Gentoo, Slackware, *BSD) будет аналогичен данному.
Тем и хорош OpenVPN.

Алексей Михайлов
Специально для tuxnotes.ru

[Мои конфиги сервера и клиента]

——————————————————————————-

Сервер:

local 77.87.200.10
port 2000
proto tcp
dev tun0
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 172.20.20.0 255.255.255.0 #примечание: сервер забирает себе при организации тунеля первые два адреса из подсети
push «route 172.20.20.0 255.255.255.0»
client-config-dir ccd
tls-server
tls-auth keys/ta.key 0
tls-timeout 120
auth MD5
#cipher BF-CBC
keepalive 10 120
comp-lzo
max-clients 1
plugin /usr/local/lib/openvpn-auth-pam.so login
user nobody
group nobody
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3
#tun-mtu 1450 #примечание: можно регулировать размер MTU (должен быть одинаковым на сервере и на клиенте)

Клиент:

dev tun
proto tcp
remote 77.87.200.10
port 2000
client
resolv-retry infinite
ca keys/ca.crt
cert keys/client.crt
key keys/client.key
tls-client
tls-auth keys/ta.key 1
auth MD5
auth-user-pass
#cipher BF-CBC
ns-cert-type server
comp-lzo
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3
#tun-mtu 1450 #примечание: см. сервер
auth-user-pass keys/account #примечание: в текстовом файле account двумя отдельными строками хранятся логин и пароль
auth-nocache #примечание: чтобы логин-пароль не оставались на клиентской стороне в памяти

=========================================================================

[Конфиги OpenVPN (в режиме server) для сервера и клиента под Windows]

——————————————————————————-

Качаем OpenVPN клиента под Windows: http://swupdate.openvpn.net/community/releases/openvpn-2.1.4.tar.gz

Конфиг клиента Windows

C:\Program Files\OpenVPN\config\config.ovpn:

auth-user-pass
remote 191.XXX.XXX.1
port 2000
dev tun
dev-node MyTap
proto tcp
client
resolv-retry infinite
ca C:/Progra~1/OpenVPN/keys/ca.crt
cert C:/Progra~1/OpenVPN/keys/client.crt
key C:/Progra~1/OpenVPN/keys/client.key
tls-client
tls-auth C:/Progra~1/OpenVPN/keys/ta.key 1
auth MD5
cipher BF-CBC
ns-cert-type server
persist-key
persist-tun
verb 3
route-method exe
route-delay 30
ping 5
ip-win32 netsh

Конфиг клиента FreeBSD

/usr/local/etc/openvpn/server.conf:

local 191.XXX.XXX.1
port 2000
proto tcp
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
topology subnet
server 10.8.0.0 255.255.255.0
route 10.8.0.0 255.255.255.248
client-config-dir ccd
tls-server
tls-auth keys/ta.key 0
tls-timeout 120
auth MD5
#cipher BF-CBC
keepalive 10 20
#ping-restart 20
#comp-lzo
max-clients 2
ifconfig-pool-persist ipp.txt 0
plugin /usr/local/lib/openvpn-auth-pam.so login
user nobody
group nobody
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
#log /var/log/openvpn/openvpn.log
verb 3
log-append /var/log/openvpn/openvpn.log
duplicate-cn
tun-mtu 1500
mssfix
#for udp packets
#fragment 1300

В этом файле мы назначаем нашим 2м клиентам (логины client и client2) статические IP-адреса, /usr/local/etc/openvpn/ipp.txt:
client,10.8.0.3
client2,10.8.0.2

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

/usr/local/etc/openvpn/ccd/client
push «ip-win32 manual»
ifconfig-push 10.8.0.3 255.255.255.248

/usr/local/etc/openvpn/ccd/client2
push «ip-win32 manual»
ifconfig-push 10.8.0.2 255.255.255.248

При этом в vipw клиенты заведены так:

client:$1$SOigCh/z$Kj8.cP166D9ecve5XoJMh0:65530:65530::0:0:account for openvpn client:/nonexistent:/usr/sbin/nologin
client2:$1$SOigCh/z$Kj8.cP166D9ecve5XoJMh0:65531:65531::0:0:account for openvpn client2:/nonexistent:/usr/sbin/nologin

При использовании Windows XP SP#2 может понадобиться следущее:

http://michaelellerbeck.com/2008/10/27/openvpn-client-hangs-on-dhcp-renewal-gets-apipa-address-instead/

1. Отключить windows firewall на TAP интерфейсе, через «Сетевое окружение» в свойствах соединения
2. Скачать devcon.exe с сайта Microsoft http://support.microsoft.com/kb/311272
3. Переименовать TAP ифейс в «сетевом окружении» в MyTap
4. Через консоль войти в папку с devcon.exe и выполнить:

devcon hwids =net @root\NET\*

Обычно выдаст имя tap0901, которое будет использоваться ниже.
5. Создать два файла .bat в папке OpenVPN\config, название файлов должны начинаться с названия файла конфига (в моем примере это config.ovpn):
C:\Program Files\OpenVPN\config\config_pre.bat:
devcon enable tap0901
C:\Program Files\OpenVPN\config\config_down.bat:
devcon disable tap0901

Gui OpenVPN`а будет запускать эти два файла при старте и закрытии соединения.

6. IP-адреса клиентов явно прописать на TAP интерфейсе MyTap (через «Сетевое окружение» в свойствах соединения) с маской как указано в конфиге сервера.

=========================================================================

[Конфиги OpenVPN (в режиме P2P) для сервера FreeBSD и клиента FreeBSD]

10.8.0.1 — тунельный IP-адрес сервера

10.8.0.2 — тунельный IP-адрес клиента

Конфиг сервера

local 191.XXX.XXX.1
port 2000
proto udp
dev tun0
ca keys/ca.crt
cert keys/server.crt
key keys/server.key
dh keys/dh1024.pem

ifconfig 10.8.0.1 10.8.0.2
topology p2p
tls-server
tls-auth keys/ta.key 0
tls-timeout 120
auth MD5
#cipher BF-CBC
keepalive 10 20
#ping-restart 20
#comp-lzo
max-clients 1
plugin /usr/local/lib/openvpn-auth-pam.so login
user nobody
group nobody
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
verb 3
log-append /var/log/openvpn/openvpn.log
#duplicate-cn #указывается если мы хотим что бы под одним сертификатом могло ходить несколько клиентов
tun-mtu 1500
mssfix
#for udp packets
fragment 1300

#Назначаем нашему клиенту IP-адрес

push «ifconfig 10.8.0.2 10.8.0.1»

Конфиг клиента

dev tun0
proto udp
remote 191.XXX.XXX.1
port 2000
client

# Т.к. в конфиге сервера мы уже назначили клиенту IP-адрес, то строчку с ifocnfig тут можно закоментить

#ifconfig 10.8.0.2 10.8.0.1

resolv-retry infinite
ca keys/ca.crt
cert keys/client.crt
key keys/client.key
tls-client
tls-auth keys/ta.key 1
auth MD5
auth-user-pass
#cipher BF-CBC
keepalive 10 20
ns-cert-type server
#comp-lzo
persist-key
persist-tun
status /var/log/openvpn/openvpn_client-status.log
verb 3
auth-user-pass account
#auth-nocache
user nobody
group nobody
log-append /var/log/openvpn/openvpn_client.log
mssfix
tun-mtu 1500
fragment 1300

у OpenVPN есть два режима работы: а) p2p (point to point).
б) server mode.P2P режим был предусмотрен в OpenVPN изначально с самых ранних версий. Он предназначен только для одного соединения типа «точка — точка». Для примера можно привести ситуацию, в которой посредством OpenVPN необходимо соединить два офиса (возможно это как раз ситуация, аналогичная Вашей). В этом случае tun/tap, интерфейс OpenVPN соединения можно сравнить с обычным PPP интерфейсом, а для межсетевого обмена трафиком между peer’ами необходимо просто поднять на каждом из них соответсвующие маршруты через опцию route.

Server mode — это относительно новая фича, которая поддерживается в OpenVPN начиная с версии 2.0. Именно этот режим Вы и выбрали, включив в конфигурационный файл своего сервера опцию «server 10.8.0.0 255.255.255.0». Попробую объяснить в чем суть этого режима. OpenVPN работает через tun или tap интерфейсы. В отличие от p2p, server mode позволяет работать нескольким клиентам (peer’ам) одновременно c одним и тем же сервером, причем через один и тот же tun/tap интерфейс. В связи с этим изменяется и механизм межсетевой маршрутизации. На стороне клиента никаких изменений нет, но на стороне сервера добавляется дополнительный уровень инкапсуляции. Это значит, что при отправке пакета в клиентскую сеть, серверу недостаточно просто бросить его в tun0. Необходимо также каким-то образом указать какому именно клиенту данный пакет предназначен. Стандартным параметром route уже не обойтись т.к. он только направляет пакеты в tun0 к OpenVPN не указывая на конкретного peer’а-адресата. Здесь необходим дополнительный уровень маршрутизации. Эта маршрутизация реализована в OpenVPN посредством опции iroute совместно с опцией client-config-dir (см. ниже).

3. Если после коннекта в логах клиента:

SENT CONTROL [server]: ‘PUSH_REQUEST’ (status=1)

а в логах сервера:

PUSH: Received control message: ‘PUSH_REQUEST’

и далее ничего не происходит, а строчки повторяются и повторяются, но адреса на туннеле со стороны клиента не появляются, то попробуйте на сервере (в конфиге) push`уть любую строчку, если там ничего не push`иться (например IPшник клиента (ifcоnfig)), то можно push`уть например:

push «dhcp-option DNS 8.8.8.8»

4. Важное замечание, что если OpenVPN запускается в режиме server (см. комментарии п.2), то статический или динамический маршрут, даже который смотрит правильно и напрямую в интерфейс tun, ни к чему не приведет, работать не будет.

Т.к. в режиме server получается point-to-multipoint линк и именно поэтому серверу надо уже объяснять какому клиенту за ифейсом tun нужно отправлять трафик. Поэтому туннельные интерфейсы могут пинговаться, а любые подсети за OpenVPN-клиентом нет, т.к. трафик не уедет в туннель.

Это хорошо видно по tcpdump, если с OpenVPN-сервера попробовать попинговать любой адрес из подсети, которая находится ЗА OpenVPN-клиентом.

С одной стороны (со стороны OpenVPN-сервера) трафик в tun виден, а до другой стороны трафик просто не доходит, а если быть точнее, то на самом деле трафик с OpenVPN-сервера просто не отправляется.

Ответ кроется в этом:

By default, when an OpenVPN client is active, only network traffic to and from the OpenVPN server site will pass over the VPN.

Что бы решить данную проблему нужно или переходить на режим p2p или прописать route и iroute на стороне OpenVPN-сервера (см. http://openvpn.net/index.php/open-source/documentation/howto.html):

Including multiple machines on the client side when using a routed VPN (dev tun)In a typical road-warrior or remote access scenario, the client machine connects to the VPN as a single machine. But suppose the client machine is a gateway for a local LAN (such as a home office), and you would like each machine on the client LAN to be able to route through the VPN.For this example, we will assume that the client LAN is using the 192.168.4.0/24 subnet, and that the VPN client is using a certificate with a common name of client2. Our goal is to set up the VPN so that any machine on the client LAN can communicate with any machine on the server LAN through the VPN.

Before setup, there are some basic prerequisites which must be followed:
The client LAN subnet (192.168.4.0/24 in our example) must not be exported to the VPN by the server or any other client sites which are using the same subnet. Every subnet which is joined to the VPN via routing must be unique.
The client must have a unique Common Name in its certificate («client2» in our example), and the duplicate-cn flag must not be used in the OpenVPN server configuration file.

First, make sure that IP and TUN/TAP forwarding is enabled on the client machine.

Next, we will deal with the necessary configuration changes on the server side. If the server configuration file does not currently reference a client configuration directory, add one now:
client-config-dir ccd

In the above directive, ccd should be the name of a directory which has been pre-created in the default directory where the OpenVPN server daemon runs. On Linux this tends to be /etc/openvpn and on Windows it is usually \Program Files\OpenVPN\config. When a new client connects to the OpenVPN server, the daemon will check this directory for a file which matches the common name of the connecting client. If a matching file is found, it will be read and processed for additional configuration file directives to be applied to the named client.

The next step is to create a file called client2 in the ccd directory. This file should contain the line:
iroute 192.168.4.0 255.255.255.0

This will tell the OpenVPN server that the 192.168.4.0/24 subnet should be routed to client2.

Next, add the following line to the main server config file (not the ccd/client2 file):
route 192.168.4.0 255.255.255.0

Why the redundant route and iroute statements, you might ask? The reason is that route controls the routing from the kernel to the OpenVPN server (via the TUN interface) while iroute controls the routing from the OpenVPN server to the remote clients. Both are necessary.

Next, ask yourself if you would like to allow network traffic between client2’s subnet (192.168.4.0/24) and other clients of the OpenVPN server. If so, add the following to the server config file.
client-to-client
push «route 192.168.4.0 255.255.255.0»

This will cause the OpenVPN server to advertise client2’s subnet to other connecting clients.

The last step, and one that is often forgotten, is to add a route to the server’s LAN gateway which directs 192.168.4.0/24 to the OpenVPN server box (you won’t need this if the OpenVPN server box is the gateway for the server LAN). Suppose you were missing this step and you tried to ping a machine (not the OpenVPN server itself) on the server LAN from 192.168.4.8? The outgoing ping would probably reach the machine, but then it wouldn’t know how to route the ping reply, because it would have no idea how to reach 192.168.4.0/24. The rule of thumb to use is that when routing entire LANs through the VPN (when the VPN server is not the same machine as the LAN gateway), make sure that the gateway for the LAN routes all VPN subnets to the VPN server machine.

Similarly, if the client machine running OpenVPN is not also the gateway for the client LAN, then the gateway for the client LAN must have a route which directs all subnets which should be reachable through the VPN to the OpenVPN client machine.

Т.е. возмем наш пример с конфигурацией в режиме server (рассмотренный выше) и допустим что за OpenVPN-клиентом, за его вторым интерфейсом с IP-адресом 192.168.1.1/24, находится подсеть 192.168.1.0/24.

Вот туннель установился, туннельные адреса прекрасно пингуются с обеих сторон, но вот мы берем и прописываем на OpenVPN-сервере маршрут:

route add 192.168.1.0/24 -iface tun0

запускаем пинг до 192.168.1.1 и….. и ничего, пинга нет…… Почему ?

Для того что бы он появился ещё раз вникните в то, что написано выше и выполните следующие действия:

На OpenVPN-сервере в файле /usr/local/etc/openvpn/ccd/client (где, напомню вам, что название файла соответствует логину клиента) допишем:

iroute 192.168.1.0 255.255.255.0

Затем, там же на OpenVPN-сервере, поправим основной конфиг (server.conf) и добавим в него:

route 192.168.1.0 255.255.255.0

Перезапускайте OpenVPN с обоих сторон и запускайте пинг до 192.168.1.1 и он будет в наличии.

Все конечно хорошо и здорово, НО есть нюанс…. А что если за OpenVPN-клиентом находится клиент подключенный по BGP и у него куча подсетей ??? Даже не смотря на то, что BGP сессия между OpenVPN-сервером и OpenVPN-клиентом установилась и маршруты приходят, трафик до подсетей анонсированых OpenVPN-клиентом через OpenVPN-сервер не пойдет, т.к. отсутствуют строчки с route и iroute в настройках OpenVPN-сервера. Варианта 2: а) переходить с режима server в режим p2p б) каждый раз описывать на OpenVPN-сервере route и iroute с подсетями клиента.

Как мне кажется, что если вы все же озадачились поднятием BGP через тунель OpenVPN, то проще будет перевести OpenVPN-сервер в режим p2p.