Настраиваем OpenVPN сервер на подключение клиентов

Описание установки OpenVPN сервера, создание ключей для сервера и клиента и пример конфигурации клиента.
Tags:

2019-12-23 Опубликована свежая статья с упрощённым изложением OpenVPN - это просто

2014-08-04 Статья в процессе переделки и дополнений по мере освоения.

Дописать:

  • Использовать на одном сервере tun0 для объединения серверов и tun1 для подключения клиентов. Соответственно для серверов: iptables forward прозрачный для tun0 и запреты только на INPUT для соответствующих подсетей. Для рядовых клиентов tun1 запреты уже при входе в сеть. Например, только 3389 порт. Для админа пока отдельный gw.
  • TLS и DH индивидуальны для разных openvpn-серверов и подключающихся к ним клиентов. Ещё лучше TLS и DH разные для демона подключений серверов и демона подключений клиентов.
  • Для объединения серверов указывать исходящий порт?
  • Песочница для openvpn демона.
  • Разобраться с автоматическим mtu.
  • float для серверов из сетей с меняющимся ip.
  • Единая система именования выданных файлов: Орг-ca.crt (.key), ОргСрв-ta.key, ОргСрв-dh2048.pem, ОргСрв.crt (.key), ОргКлн.crt (.key). Маршруты проталкивать только клиентам. На серверах маршруты настраиваются без openvpn push.
  • Переделать всю статью. Может так: Центр сертификации отдельно. Генерация и настройка сервера отдельно. Генерация и настройка клиента отдельно.

Оглавление

Введение

Openvpn работает по схеме шифрования с открытыми ключами. Каждый участник openvpn-сети имеет открытый (public) и закрытый (private) ключ. Открытый ключ можно найти в файле-сертификате с расширением .crt. Закрытый (private) ключ лежит в файле с расширением .key. Я несколько лет назад прочитал отличную книгу по истории криптографии, поэтому тема мне знакома и здесь разжёвывать её сейчас не буду. (Найти книгу и привести название. “Книга шифров”?) Саймон Сингх: Книга шифров: Тайная история шифров и их расшифровки.

Если кратко, то сначала сервер и клиент обмениваются своими публичными ключами. Кстати, они несекретны и могут храниться открыто. Потом обеими сторонами проводится проверка полученных ключей на предмет легитимности, то есть срок действия, проверка подписи CA, проверка в списке отозванных ключей и т.д. Если всё отлично, то начинается обмен данными:

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

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

В идеальной конфигурации, для организации openvpn-сетки необходимо минимум два сервера. Один сервер, максимально защищённый от вторжений/не подключённый к интернету, имеет роль центра сертификации (CA) и не учавствует в организации удалённого доступа. Второй сервер (а при необходимости их может быть несколько) является openvpn-сервером и обеспечивает возможность подключения удалённых клиентов.

Центр сертификации представляет собой отдельную папку на винчестере, в которой лежат:

  • пара файликов ca.key и ca.crt – ключ и сертификат центра сертификации;
  • простейшая база данных из двух файлов:
    • файл serial – счётчик,
    • файл index.txt – список выданных сертификатов.
  • файлы уже выданных сертификатов (*.crt) для возможности их отзыва;
  • файл crl.pem, в котором накапливается информация об отозванных ключах;
  • несколько скриптов для генерации новых ключей и сертификатов.

При необходимости автоматизации выдачи ключей и сертификатов, к этой папке прикручивают web-морду (в инете я видел готовые конструкции различной степени сложности). Обычный человек изредка сталкивается с этими конструкциями, например, при работе с банк-клиентами, так как шифрование с открытыми ключами широко используется в ИТ.

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

Установка openvpn-сервера

Устанавливаем openvpn:

aptitude install openvpn

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

Одноразово создаём два файла центра сертификации, с помощью которых мы будем выдавать все прочие сертификаты и ключи для openvpn-серверов и клиентов:

  1. ca.crt – главный CA сертификат, этот файл нужен всем клиентам и всем openvpn-серверам (и центру сертификации? Ясен пень. Хотя бы для последующей раздачи клиентам.). С помощью него договаривающиеся стороны (сервер и клиент) проверяют подписи полученных публичных ключей на предмет принадлежности нашей организации;
  • ca.key – главный CA ключ. Этот файл нужен только центру сертификации, так как им подписываются все публичные ключи-сертификаты организации. Он не учавствует в обеспечении безопасного канала. Он нужен эпизодически только для выпуска ключей (шибко СЕКРЕТНЫЙ файл). Хочу заметить, что открытое хранение этого файла на openvpn-сервере позволит вероятному злоумышленнику украсть этот файл и выпустить произвольное количество ключей, с помощью которых можно будет беспрепятственно подключаться к нашим openvpn-серверам. Одноразово делаем файл для дополнительной безопасности openvpn-канала:
  • ta.key – TLS-ключ, который нужен и openvpn-клиентам и openvpn-серверам для пущей безопасности. Можно и без него, но он помогает блокировать DoS атаки и UDP флудинг на открытый порт сервера.

Ещё сделаем три файла для конкретного openvpn-сервера. Эти файлы необходимо сгенерировать для каждого openvpn-сервера в нашей сетке. В принципе, можно изменить имена этих файлов в соответствии с сетевыми именами openvpn-серверов. Но, как мне кажется, в целях унификации конфигурационного файла и прочих настроек, которые мы можем централизованно распространять на все openvpn-сервера, будет удобней не изменять имена этих файлов:

  1. server.crt – сертификат сервера, нужен только серверу;
  2. server.key – ключ сервера, нужен только серверу (СЕКРЕТНЫЙ файл);
  3. dh1024.pem – ключ имени Диффи и Хельмана. Этот файл нужен только серверу. Наверное, используется на этапе предварительного обмена открытыми ключами (сертификатами).

И ещё надо сгенерировать пару файлов для первого клиента. Обычно, имена этих файлов соответствуют имени клиента, указанному при генерации. Поэтому для удобства идентификации клиента, необходимо выработать систему присвоения имён, чтобы потом было проще ориентироваться в логах и прочих моментах. Например, в моём случае, я раздаю людям готовые openvpn-комплекты для каждого из их компьютеров. Поэтому придумываю имя исходя из такого правила – idорганизации-idклиента-idмашины. И когда приходит время отозвать ключи определённого юзера, то в папке с выданными сертификатами, при обычной сортировке по имени файла, я увижу все сертификаты юзера идущими по порядку. Ну а в данном опусе, не заморачиваясь, укажу:

  1. client.crt – сертификат клиента. Этот файл нужен клиенту для установки соединения с openvpn-сервером;
  2. client.key – ключ клиента, нужен только клиенту (СЕКРЕТНЫЙ файл).

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

Подготовка центра сертификации

Создаём необходимые папки и копируем сюда скрипты для генерации ключей, которые идут вместе с установленным комплектом openvpn. Замечу, что на FreeBSD я столкнулся с отсутствием скриптов в установленном пакете последней доступной версии программы openvpn. Следуя разъяснению на сайте openvpn.net, скрипты можно взять здесь – https://github.com/OpenVPN/easy-rsa/releases.

В общем случае, папка easy-rsa и является центром сертификации:

mkdir /etc/openvpn/easy-rsa
mkdir /etc/openvpn/easy-rsa/keys
touch /etc/openvpn/easy-rsa/keys/index.txt
echo "00">/etc/openvpn/easy-rsa/keys/serial

В этих двух файлах – index.txt и serial – будет накапливаться статистика по выданным ключам. И без этих файлов не будет работать выдача и аннулирование сертификатов и ключей.

Собственно копирование всего необходимого для дальнейшей работы:

cp /usr/share/doc/openvpn/examples/easy-rsa/2.0/* /etc/openvpn/easy-rsa

Редактируем соответствующие строки в конце файла /etc/openvpn/easy-rsa/vars, содержащего различные переменные, которые будут загружаться в командную оболочку перед каждым сеансом генерации сертификатов и ключей. По желанию меняем страну, город и прочее. Или оставляем всё, как есть, так как при генерации сертификатов всё равно будет запрос на изменение этих полей.

Для себя я ещё не решил по каким правилам заполнять эти поля. Вероятно проще будет указывать RU, Moscow, чем выяснять в каком городе чужой страны находится сервер. Да и данные эти не несут, в моём случае, полезной информации.

Переходим в папку /etc/openvpn/easy-rsa и смотрим наличие файла openssl.cnf, так как без этого файла, в некоторых случаях, генерация ключей невозможна.

Несколько раз я наблюдал четыре разных файла: openssl-0.9.6.cnf openssl-0.9.8.cnf openssl-1.0.0.cnf openssl-1.0.0.cnf-old-copy. Проверив командой aptitude show openssl версию установленной у меня библиотеки openssl, я сделал копию нужной версии файла: # cp openssl-1.0.0.cnf openssl.cnf

Интересно, что во FreeBSD 9 произошёл автоматический выбор правильного файла openssl*.cnf, вследствии отработки скрипта whichopensslcnf, без необходимости переименовывания! Вероятно, надо брать последнюю версию easy-rsa по ссылке с сайта openvpn?

Всё готово для генерации различных ключей и сертификатов.

Генерация файлов центра

Загружаем переменные source ./vars (или . ./vars — символ точка – синоним команды source, которая выполняет указанный файл сценария.)

(разобраться с правами на файлы и папки и написать подробно)

Создаём приватный ключ и сертификат центра сертификации, на основе которых будут сертифицироваться прочие выдаваемые ключи:

# ./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) [RU]:
State or Province Name (full name) [MO]:
Locality Name (eg, city) [Moscow]:
Organization Name (eg, company) [M]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) [L CA]:server-ca
Email Address [me ar) myhost [dot] mydomain]:

Поле “Common Name” обязательно к заполнению. 

В /etc/openvpn/easy-rsa/keys теперь лежат сертификат центра сертификации ca.crt и приватный ключ центра сертификации ca.key.

Сертификат центра сертификации находится как на стороне сервера, так и на стороне клиента и учавствует в создании туннеля. 

Приватный ключ центра сертификации чрезвычайно секретный и не должен попасть в чужие руки. В создании туннеля он не используется. Если я правильно понимаю, то приватным ключом центра сертификации подписываются ключи новых клиентов, поэтому файл ca.key желательно изымать из этой папки после окончания генерации ключей, затирая убитую копию shred’ом. Или же папку easy-rsa размещать в секретном криптохранилище, где и производить по необходимости эпизодические работы по выпуску ключей. Или отдельный компьютер для выпуска ключей. Кто во что горазд.

Генерация TLS ключа

Генерируем TLS ключ:

openvpn --genkey --secret /etc/openvpn/easy-rsa/keys/ta.key

Генерация ключа и сертификата openvpn сервера

Генерация ключей происходит в папке /etc/openvpn/easy-rsa. В дальнейшем, перед каждым сеансом генерации ключей не забываем загружать переменные в текущую командную оболочку:

source ./vars

Генерируем ключ сервера:

./build-key-server server1

Придумываем пароль и соглашаемся на подпись. Пароль не пригодится. Он используется, если я правильно понимаю, при использовании автоматизированного web-портала для запроса, генерации и выдачи ключей самими пользователями.

Может произойти ошибка wrong number of fields on line 1 (looking for field 6, got 1, '' left). Причина в не пустом файле /etc/openvpn/easy-rsa/keys/index.txt. Решение: cat /dev/null > /etc/openvpn/easy-rsa/keys/index.txt

Ключи для сервера сгенерированы. В директории keys появились новые файлы с запросом на сертификат, сертификатом и приватным ключом сервера.

В файле keys/index.txt появилась строка с описанием нашего выданного ключа. В keys/serial номер увеличился на единицу.

Генерация файл DH

Создаём параметр DH (Алгоритм Диффи — Хеллмана):

./build-dh

Generating DH parameters, 1024 bit long safe prime, generator 2
This is going to take a long time
..................................

Генерация сертификата и личного ключа клиента

Генерация ключей происходит в папке /etc/openvpn/easy-rsa. Перед каждым сеансом генерации ключей не забываем загружать переменные в память:

source ./vars

Генерируем безпарольный ключ клиента:

./build-key wks-1

или ключ с парольной защитой:

./build-key-pass ivan

или ключ в формате pkcs12 (таким пока не пользовался, но по слухам, его можно хранить в электронных хранилищах, например, в USB-токенах):

./build-key-pkcs12 sterva-on-wks-home

После данной процедуры клиенту передаются файлы:

  1. Сертификат сервера ca.crt;
  • Приватный ключ клиента wks-1.key;
  • Сертификат клиента (или правильнее сертификат к приватному ключу клиента?) wks-1.crt;
  • TLS-ключ сервера ta.key;

Файл настройки клиента, где должны быть указаны:

  1. адрес сервера;
  • порт, который слушает openvpn сервер;
  • использующийся шифр: BF-CBC или, например, AES-512-CBC.

Важно сохранить сертификаты клиентов (но не приватные ключи! клиентов) для возможности их последующего отзыва. Не забываем, что имя файла содержащего сертификат и имя сертификата могут отличаться. Естественно, проверить это соответствие можно простым просмотром файла. Проверить последствия ручного редактирования файла сертификата с целью изменения имени сертификата, чтобы ввести в заблуждение администратора. Как узнать реальное имя сертификата?

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

Настройка openvpn

Делаем отдельную папку keys в папке openvpn и копируем туда необходимые для работы сервера файлы:

mkdir /etc/openvpn/keys
cd /etc/openvpn/easy-rsa/keys/
cp ca.crt ca.key /etc/openvpn/keys/
mv server1.crt server1.key dh1024.pem ta.key /etc/openvpn/keys/

Запросы на генерацию сертификата можно удалить:

rm server1.csr

Копируем примерный файл настройки сервера openvpn:

gzip -cd /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz > /etc/openvpn/server.conf

В принципе, внутри этого файла всё описано. Если не знаешь английский, то смотри http://www.lissyara.su/doc/man/safety/openvpn/.

Естественно, можно сделать два или больше одновременно работающих openvpn-сервера добавлением конфигурационных файлов с разными именами. Надо только не забывать развешивать их по разным портам, использовать разные внутренние ip-подсети и файлы статуса.

Редактируем те опции, которые нам нужны. Будем использовать TUN-интерфейс, который умеет маршрутизировать ip-пакеты. TAP-интерфейс используется для маршрутизации не ip-протоколов или при необходимости рассылки широковещательных запросов, но TAP для своей работы требует больше ресурсов, чем TUN.

Вот мой пример:

# адрес на котором слушать входящие запросы.
# закомментированно, значит на всех
;local a.b.c.d
port 11194
proto udp
dev tun0
ca keys/ca.crt
cert keys/server1.crt
key keys/server1.key
dh keys/dh1024.pem
# Из этой сети – 192.168.1.0/24 – сервер возьмёт для своих нужд два ip-адреса
# 192.168.1.1 и 192.168.1.2, а оставшийся диапазон поделит на
# подсетки по 4 ip-адреса и будет отдавать клиентам.
# Первому клиенту будет отдана подсеть 192.168.1.4/30
# и назначен ip-адрес 192.168.1.6.
# Второму – 192.168.1.8/30 и назначен ip-адрес 192.168.1.10
server 192.168.1.0 255.255.255.0
# В этом файлике хранятся пары: имя клиента, ip-подсеть назначенная клиенту.
# Перед ручным вмешательством надо остановить демон.
ifconfig-pool-persist ipp.txt
# Тут мы проталкиваем клиенту маршрут в нашу внутреннюю подсеть:
push "route 192.168.0.0 255.255.255.0"
keepalive 10 120
tls-auth keys/ta.key 0
cipher BF-CBC
comp-lzo
max-clients 30
user nobody
group nogroup
persist-key
persist-tun
# В этом файлике мы будем видеть текущую картину подключений:
status openvpn-status.log
verb 3

На этом установка и настройка openvpn-сервера закончена и можно перезапустить сервис:

service openvpn restart

Объединение сетей

Исходная диспозиция:

  • Внешний ip-адрес неважен;
  • Наша внутренняя сеть – 192.168.0.0/24;
  • Наша openvpn-подсетка, из которой выделяются ip-адреса обычным openvpn-клиентам – 192.168.1.0/24;
  • К нашему серверу должен подключаться шлюз, который маршрутизирует пакеты в 192.168.10.0/24

Создаём папку, где будут храниться конфигурации для подключающихся серверов-шлюзов, за которыми есть подсети:

mkdir /etc/openvpn/ccd

В файл конфигурации нашего сервера /etc/openvpn/server.conf добавляем директиву, включающую способность назначать клиентам определённый ip-адрес из нашей openvpn-подсети  и определять для клиента целую подсеть: client-config-dir-ccd

Добавляем директивы, отвечающие за объявление клиентам списка сетей, которые подключаются к нашему openvpn-сервер: route 192.168.10.0 255.255.255.0 Этот раздел в процессе написания…

Отзыв сертификата openvpn-клиента

http://openvpn.net/index.php/open-source/documentation/howto.html#revoke

Так как на предварительном этапе установления связи, стороны обмениваются своими открытыми ключами (сертификатами), то существует возможность заблокировать скомпрометированные ключи и недопустить их использование.

Например, человека уволили и надо аннулировать его ключи. Приватный ключ wks1.key остался у юзера, но он нам и не нужен. У нас, в центре сертификации, в наличии есть открытый ключ-сертификат. Сертификат клиента wks1.crt лежит в  /etc/openvpn/easy-rsa/keys.

cd /etc/openvpn/easy-rsa
source ./vars
./revoke-full wks-1

Using configuration from /etc/openvpn/easy-rsa/openssl.cnf
Revoking Certificate 01.
Data Base Updated
Using configuration from /etc/openvpn/easy-rsa/openssl.cnf
wks1.crt: /C=RU/ST=MO/L=Moscow/O=L/CN=wks1/name=wks1/[email protected]
error 23 at 0 depth lookup:certificate revoked

Последняя строка с ошибкой означает успешный отзыв сертификата (проверка на легитимность вызвала ошибку). В файле /etc/openvpn/easy-rsa/keys/index.txt можно увидеть, что соответствующая строка видоизменилась.

Было:

V 210525072904Z 01 unknown /C=RU/ST=MO/L=Moscow/O=L/CN=wks1/name=wks1/[email protected]

Стало:

R 210525072904Z 120531133006Z 01 unknown /C=RU/ST=MO/L=Moscow/O=L/CN=wks1/name=wks1/[email protected]

В папке /etc/openvpn/easy-rsa/keys появился файлик crl.pem. В дальнейшем в этом файле будет накапливаться информация. Этот файл необходимо скопировать в:

cp /etc/openvpn/easy-rsa/keys/crl.pem /etc/openvpn/

Для включения на сервере проверки клиентов на благонадёжность, добавляем опцию crl-verify crl.pem в конфигурационный файл server.conf. Перезапускаем демон:

service openvpn restart

После включения опции проверки сертификатов на отзыв, уже не нужно перезапускать демон при изменении файла crl.pem, так как демон читает этот файл при каждом подключении клиента и, по умолчанию, один раз в час при установленной связи с клиентом? Естественно, если надо немедленно отключить ревокнутого клиента от сервера, то придётся перезапустить демон.

Краем глаза где-то зацепил, что если сертификата отключаемого клиента нет в наличии, то существует способ получить его на этапе аутентификации клиента на openvpn-сервере, запустив демон openvpn со специальными параметрами.

Отзыв сертификата openvpn-сервера

Отзыв сертификата сервера производится по аналогии с отзывом сертификата клиента. Ничего сложного нет, за исключением проблемы распространения файла crl.pem по клиентам и соответствующей настройки их конфигурационных файлов. В принципе, сам файл crl.pem, содержащий информацию об отозванных серверных и клиентских сертификатах, не секретный. Его можно разместить в публичном месте, откуда он может скачиваться каким-нибудь скриптом при запуске openvpn-программы на клиентском компьютере. Естественно, необходимо ещё на этапе раздачи клиентских настроечных пакетов предусмотреть использование этого файла в файле конфигурации.

Настройка файрвола для работы openvpn сервера

Далее настраиваем iptables для приёма входящих запросов и форвардинга во внутреннюю сеть. Например:

# eth0 - внутренний интерфейс 192.168.0.0/24
# tun  - сетка 192.168.1.0/24 для openvpn-клиентов
iptables -A INPUT  -p udp -m udp --dport 11194 -j ACCEPT
iptables -A OUTPUT -p udp -m udp --sport 11194 -j ACCEPT -m conntrack --ctstate ESTABLISHED,RELATED
iptables -A FORWARD -s 192.168.1.0/24 -d 192.168.0.0/24 -i tun+ -o eth0 -p icmp -j ACCEPT
iptables -A FORWARD -s 192.168.0.0/24 -d 192.168.1.0/24 -i eth0 -o tun+ -p icmp -j ACCEPT
iptables -A FORWARD -s 192.168.1.0/24 -d 192.168.0.0/24 -i tun+ -o eth0 -p tcp -m tcp -m multiport --dports 22,3389 -j ACCEPT
iptables -A FORWARD -s 192.168.0.0/24 -d 192.168.1.0/24 -i eth0 -o tun+ -p tcp -m tcp -m multiport --sports 22,3389 -j ACCEPT -m conntrack --ctstate ESTABLISHED,RELATED

Добавить ремарки для прозрачности, так как уже не помню зачем icmp из внутренней сетки, когда лучше разрешить icmp для определения максимального mtu из сетки tun? И насколько помню, то ныне, для правил с icmp необходимо указывать тип и код.

Клиента настраивать легко по аналогии…

Если в настроечном файле openvpn мы указали определённое название интерфейса tun (например, я, при использовании нескольких openvpn-демонов на одном сервере, присваиваю имя по номеру назначаемой сети: tun32 – 192.168.32.0/24), то и в iptables мы можем манипулировать этим именем, без использования tun+, подразумевающего под собой все интерфейсы, начинающиеся на tun. Это можно использовать, как один из способов разграничения подключающихся клиентов.

Я пока не заморачивался с запросами логинов/паролей при подключении openvpn-клиента и динамическом назначении для него определённых файрвольных правил.

Возникшие проблемы и пути их решения

На windows xp и windows server 2003 использовал http://openvpn.se/. На вин-сервере установил режим запуска службы openvpn в авто и после перезагрузки системы, windows 2003 автоматом присоединилась к дебиану. Выдёргивал кабели для проверки и через минуту или две связь восстанавливалась.

А в некоторых случаях вин2003 сервер конкретно подвисала и я попробовал:

Проблема при установленном RRAS на сервере: http://itdoc.com.ua/showthread.php?t=5

Не происходит добавление маршрута в таблицу маршрутизации, вероятно при включенной службе RRAS (чаще всего возникает на серверных ОС, например, Windows Server 2003, но встречал и на XP) - ошибка:

"NOTE: FlushIpNetTable failed on interface [2] {427E6BDF-F41F-4E7A-B8C4-4F12B25A6C11} (status=1413) : Invalid index."

Похоже дело в Win-довом глюке, по API-команде windows должна добавить маршрут, при этом если в конфиг OpenVPN вставить show-net-up, то OpenVPN запросит windows через API всю таблицу маршрутизации и выведет её в лог, там нужный маршрут будет. А если сделать route print, то маршрута не будет… Решение: route-method exe в конфиг.файле - это указывает OpenVPN-у, что добавление маршрута надо делать не через API, а через route.exe. Кроме того, может потребоваться небольшая задержка перед добавлением маршрута через route.exe (встречалось, что без задержки route.exe ещё не видит только что появившийся интерфейс и не добавляет маршрут), это делается route-delay 10 (на серверах лично меня “не напрягает” задержка 10 секунд, на клиентах можно уменьшить до экспериментально вычисленного предела)

Но это не помогло. Поэтому сделал левого юзера и из под него запускается батник с такой строкой:

openvpn --config "C:\Program Files\OpenVPN\config\client.ovpn"

Задача поставлена на запуск при загрузке системы. ОпенВПН сам переподключится при разрыве связи.

OpenVPN-клиент находящийся за NAT Один из openvpn-клиентов недоступен через openvpn-канал.

На шлюзе, через который клиент выходит в инет, если упрощённо, следующие правила iptables:

iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -o eth1 -j SNAT --to-source 192.168.1.2 #1.2 - внешний ip-адрес
iptables -A FORWARD -m state --state INVALID -j DROP
iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Добавил правило для ip-адреса этого клиента:

iptables -A FORWARD -d 192.168.10.2/32 -i eth1 -o eth0 -j ACCEPT

Клиент тут же запинговался и стал доступен. Видимо ``-m conntrack –ctstate RELATED,ESTABLISHED` отрубало необходимые пакеты.

Для безопасности в добавленном правиле надо прописать ip-адрес и шлюз openvpn-сервера:

iptables -A FORWARD -p udp -m udp -i eth1 -s 192.168.254.254 --sport 1194 -o eth0 -d 192.168.10.2 -j ACCEPT

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

Для заметки:

  • Можно использовать ключи для клиентов с запросом пароля.
  • Можно использовать ключи в формате pkcs12 для usb-хранилищ.

Смотрел поток wireshark’ом. Внешне обычные udp-пакеты с мешаниной в дата-сегменте. Если смотреть tun интерфейс, то тут уже видим человеческие пакеты.

Private-key – это личный закрытый секретный ключ, а public-key – это открытый ключ, строго соотносящийся с закрытым ключом. Сертификат – это подписанный каким-либо центром сертификации публичный ключ. CA - центр сертификации.

Если я правильно понимаю, то процесс создания клиентских ключа и сертификата, так и ключа и сертификата для сервера, состоит из нескольких этапов:

клиент с помощью математических операций генерирует закрытый файл-ключ (key); на основании этого приватного ключа (и публичного ключа центра сертификации?) клиент создаёт файл-запрос (csr), содержащий публичный ключ, к центру сертификации на выдачу сертификата; файл-запрос (csr) отправляется в центр сертификации; на основании полученного запроса центр сертификации создаёт файл-сертификат (crt) и подписывает его своим приватным ключом (тоже математика?); файл-сертификат (crt), содержащий открытый ключ, подписанный центром сертификации, отправляется клиенту. А значит, чисто гипотетически, достаточно иметь один неизвлекаемый приватный ключ в каком-нибудь рутокене. А открытый ключ, от этого закрытого ключа, направлять на подпись к различным центрам сертификации и, получив соответствующие сертификаты, подключаться к своему банку, к своему vpn-серверу, заходить в личный кабинет на госуслугах и т.д.

Гипотетически потому, что к разным “дверям” лучше иметь разные закрытые ключи. И ещё мне пока непонятно с алгоритмами шифрования. Можно ли подписать ГОСТовским закрытым ключом публичный ключ RSA.

…….статья в процессе написания

Ссылки: http://www.lissyara.su/articles/freebsd/security/openvpn/