LiveStreet

Те, кто в первые слышат это словосочетание, могут обратиться к страницам wiki openvpn( но, думаю, такие здесь врятли есть), от себя могу лишь добавить, что настроить его гораздо проще, чем тот же ipsec, и его «проходимость» через nat(proxy) гораздо выше(без лишних проблем) и просто позволяет создать довольно гибкие конфигурации.

В данном случае будет описано как настроить openvpn в режиме сервера для соединения удаленных офисов с центральным (ну и при желании их также можно объединить в данной конфигурации через центральный офис). Обычно в таких случаях используют ipsec, но почему я использую openvpn — написано выше)

Пример настройки рассмотрим на упрошенной схеме на рисунке

Где соответственно «routerA» будет выполнять роль openvpn сервера
ipA — внешний ip адрес «routerA»
vpnIPA — внутренний vpn адрес «routerA»

«routerB» и «routerС» клиенты сервера
а vpnIPB и vpnIPC их внутренние адреса в vpn сети

Приступим к настройке

Для начала нужно сгенерировать клиентские сертификаты — не буду повторяться как это делается — это уже проскакивало на openlife, от себя могу лишь добавить, что рекомендуется генерировать клиентский и серверный сертификаты с разными корневыми сертификатами(при этом на сервере остается корневой сертификат клиента, а на клиенте корневой сертификат сервера), также имхо удобнее использовать единый файл формата pkcs12 для хранения клиентского сертификата, приватного ключа и корневого сертификата вместе, также дать права на чтение ключей и сертификатов только для рута, а openvpn стартовать с ограниченными правами.

./build-key-pkcs12 file_name
#Создаст клиентский ключ и сертификат и закинет все это в один файл с корневым сертификатом

Теперь более подробно рассмотрим конфигурационный файл сервера:

proto udp 
# Выбираем протокол, вообще openvpn сам следит за целостностью потока передаваемых данных 
# по этому не вижу смысла использовать tcp, но если у вас наблюдаются большие потери - можете попробовать 
# работу в режиме tcp
port 777  #Порт)
local 10.10.10.10 # На каком ip висим, без указания - слушаем все адреса
dev tun
# Используемый тип интерфейса tun- L3 тунель, tap - L2 тунель, в linux можно через этот же параметр явно 
# указать номер интерфейса (tun0, tap0) , в windows для привязки к интерфейсу используется параметр 
# dev-node
mode server # Включаем режим сервера
tls-server  # Включаем режим tls сервера 
topology subnet 
# Выбор топологии subnet- это плюшка появилась только с версии 2.1. Позволяет выделять клиенту /32 сеть 
# (работает и для windows клиентов), вместо /30 - имеет смысл включать только для tun.
# Хоть в документации написано что при включении этой опции на сервере она автоматически
# распространяется на клиенты, у меня не заработало - пришлось на клиентах прописывать.
ifconfig 172.16.0.1 255.255.255.0 
# Задает vpn-адрес нашего сервера или можно использовать параметр "server network netmask" для динамического 
# задания адреса сервера и клиентов( сервер всегда получит первый адрес в сети)- также клиентам сервер будет
# передан как next-hop для сетей описанных в параметре route (если в нем явно не указывать next-hop ) 
# или же использовать параметр "ifconfig-pool start-IP end-IP [netmask]" для динамической выдачи клиентам 
# адресов. Так как маршруты на сервере будут жестко прописаны с привязкой к ip клиента нет смысла 
# использовать динамическое назначение адресов.
route 192.168.0.0 255.255.255.0 172.16.0.2  # Прописываем маршруты до сетей за клиентом
route 192.168.20.0 255.255.255.0 172.16.0.3      
client-config-dir /etc/openvpn/ALL/clients # Папка с конфигами для клиентов
ca  /etc/openvpn/ALL/keys/ca.crt           # Корневой сертификат
cert /etc/openvpn/ALL/keys/server.crt     # Сертификат сервера
key  /etc/openvpn/ALL/keys/server.key    # Секретный ключ сервера
dh /etc/openvpn/ALL/keys/dh1024.pem    # Файл c  Diffie-Hellman-параметрами, нужен в режиме tls-server
crl-verify /etc/openvpn/ALL/keys/crl.pem  
# Файл, содержащий отозванные сертификаты. Указывать в случае, если уже были отозваны какие-либо
# сертификаты. Если просто создать пустой файл - будет ругаться на невозможность чтения файла.
# Отозвать сертификат можно командой ./revoke-full имя_сертификата.
tls-auth /etc/openvpn/ALL/keys/ta.key 
# Добавляет дополнительный уровень HMAC-аутентификации для защиты от DoS-атак
cipher BF-CBC # Шифровать пакеты заданным алгоритмом 
comp-lzo # Использовать сжатие

# Можно использовать параметр client-to-client -разрешать клиентам видеть друг друга, при этом придется 
# прописывать маршруты до всех (или только нужных) клиентских сетей на каждом клиенте, чтобы сети 
# за клиентами могли общаться между собой.
# Также можно добавить параметр daemon- то есть запускать в режиме демона, но,к примеру, в CentOS этот 
# параметр передается  через стартовый скрипт.
user openvpn  # Запускать с пониженными привилегиями пользователя
group openvpn # группы 

status /etc/openvpn/ALL/openvpn-status.log 
log    /etc/openvpn/ALL/openvpn.log

verb 5 # Уровень отладки
persist-tun 
# Не закрывать и не переоткрывать TUN/TAP устройство и не выполнять up/down скрипты при 
# SIGUSR1 или --ping-restart. Если пренебречь этим параметром- придется ручками перезапускать при падении 
# интернета в случае запуска openvpn с пониженными правами(в нашем случае)
persist-key # То же самое касательно ключей 
keepalive 5 15 
# Означает "пинговать" противоположную сторону туннеля раз в 5 сек; при отсутствии встречных
# пингов в течение 15 сек считать туннель упавшим и перезапускать; необходимо указывать на клиенте
# и на сервере 

В папке которую мы указали как client-config-dir создаем файлы с именами, соответствующими названиям клиентских сертификатов, примерно следующего содержания

ifconfig-push 172.16.0.3 255.255.255.0 # ip клиента
push "route 192.168.5.0 255.255.255.0 192.168.255.1" # Маршрут до сети за сервером
iroute 10.18.44.128 255.255.255.128 
# А вот это интересный параметр, появившийся опять же с версии 2.1.
# Он говорит openvpn серверу, что за данным клиентом располагается такая-то сеть. В режиме сервера 
# используется только один интерфейс, "p2p типа" (только сам интерфейс), и если просто пропишем маршрут 
# до сети клиента через ip-адрес клиента - ничего работать не будет, так как пакет просто будет послан 
# в интерфейс openvpn сервера, а тот в свою очередь не будет знать как его маршрутизировать.

Эти параметры будут передаваться клиенту

Теперь рассмотрим базовый конфигурационный файл клиента:

dev tun0
remote 10.10.10.10 
# К чему подключаться- можно указать ip-адрес или dns-имя, если использовать имя- то также лучше добавить
# параметр "resolv-retry n"- где n число секунд, после которых считать хост недоступным.
# По умолчанию выставлено "resolv-retry infinite", то есть пытаться определить ip-адрес бесконечно.
proto udp
port 777
tls-client
remote-cert-tls server 
# Защита от атаки "man-in-the-middle" со стороны другого клиента, притворяющегося сервером. 
# Говорит клиенту, что нужно проверять сертификат сервера на наличие поля "TLS Web Server Authentication"
topology subnet
pull # Принимать команды от сервера
pkcs12 /etc/openvpn/OSH/keys/client.p12 
# Корневой и клиентский сертификаты, а также приватный ключ клиента в формате pkcs12
tls-auth /etc/openvpn/OSH/keys/ta.key
cipher BF-CBC
comp-lzo
user openvpn
group openvpn

status /etc/openvpn/OSH/openvpn-status.log
log    /etc/openvpn/OSH/openvpn.log

verb 5
persist-tun
persist-key
keepalive 5 15

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

Ссылки по теме:
Сайт openvpn
Справка по всем параметрам
Howto
Хороший FAQ и ветка форума, правда информация там уже немного устарела.

PS Конструктивная критика и возможные дополнения(исправление ошибок — если таковые были допущены) приветствуються.
Ps2 Спасибо Boleg2 за литературную доработку статьи.