Свет в конце тоннеля: OpenVPN + FreeBSD7
Vtund всем хорош, кроме одного – в глобальных сетях его использовать трудно. А что делать, если среда дюже недружелюбная (считай – зарезано все, кроме стандартных протоколов, и ipip провесить уже не выйдет). Наш выход – VPN. Тем более что OpenVPN поможет и влан прокинуть, и данные зашифрует, и вообще, позволит создать у пользователя уверенность, что удаленный филиал находится вовсе не в другом городе, а за стенкой (где б еще такой инет взять…)
Исходные данные:
Сервер: Linux 2.6.28.2
Клиент: FreeBSD 7.2-RELEASE-p8
OpenVPN 2.1.4
Задача: Организовать подключение таким образом, чтобы клиент, и сеть за ним могли видеть локальную сеть за сервером так, будто это два рядом стоящих маршрутизатора. Собственно, настройка занимает минут пятнадцать.
На клиенте:
cd /usr/ports/security/openvpn && make install clean
/etc/rc.conf
openvpn_enable="YES"
openvpn_if="tun"
openvpn_configfile="/usr/local/etc/openvpn/client.conf"
openvpn_dir="/usr/local/etc/openvpn"
Описание директив спер отсюда и отсюда
/usr/local/etc/openvpn/client.conf
#определяет какой использовать тип устройства tun или tap.
dev tun
#Возможные значения: udp, tcp, tcp-client, tcp-server. С первыми двумя все ясно,
#а на последних двух остановимся чуть подробнее:
#tcp-client - сам пытается установить соединение
#tcp-server - только ждет подключений
#Примечательно, что с использованием протокола udp VPN будет работать чуть быстрее,
#чем tcp. Но в плане стабильности работы лучше выбирать tcp
#(как показывает практика, VPN-соединение более устойчиво)
proto udp
#определяет удаленный конец туннеля. Могут использоваться записи IP и DNS.
remote 10.12.0.201
port 1194
#Роль - клиент или сервер
client
#если OpenVPN не удалось узнать имя удаленного хоста по DNS,
#то через указанное количество секунд попытаться переподключиться.
resolv-retry infinite
#Настройки сертификатов и безопасности
ca /usr/local/etc/openvpn/keys/ca.crt
cert /usr/local/etc/openvpn/keys/client.crt
key /usr/local/etc/openvpn/keys/client.key
tls-client
tls-auth /usr/local/etc/openvpn/keys/ta.key 1
#алгоритм хэширования
auth SHA512
#указываем алгоритм шифрования
cipher BF-CBC
ns-cert-type server
persist-key
persist-tun
#Настройки логов
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
#Уровень детализации логов
verb 3
#Маршрут на удаленную сеть, который поднимается при подключении
route 10.255.0.0 255.255.255.0
На стороне сервера:
/etc/openvpn/server.conf
local 10.12.0.201
port 1194
proto udp
dev tun10
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh1024.pem
#автоматически присваивает адреса всем клиентам (DHCP)
#в указанном диапазоне с маской сети.
#Данная опция заменяет ifconfig и может работаеть только с
#TLS-клиентами в режиме TUN, соответственно использование
#сертификатов обязательно. Например: server 10.3.0.0 255.255.255.0
#Подключившиеся клиенты получат адреса в диапазоне между 10.3.0.1 и 10.3.0.254.
server 10.255.1.112 255.255.255.248
#Статические маршруты, которые будут выдаваться клиенту
push "route 10.0.0.0 255.0.0.0"
push "route 92.50.243.0 255.255.255.0"
push "route 94.25.108.0 255.255.255.0"
push "route 46.8.128.0 255.255.128.0"
#Папка с дополнительными настройками клиента
client-config-dir ccd
#Статические маршруты на сеть за клиентом, которые поднимаются на сервере
route 10.255.1.112 255.255.255.252
route 10.12.4.0 255.255.255.0
route 10.12.5.0 255.255.255.0
route 10.12.51.0 255.255.255.0
client-to-client
keepalive 10 120
tls-server
tls-auth /etc/openvpn/keys/ta.key 0 # This file is secret
auth SHA512
cipher BF-CBC # Blowfish (default)
max-clients 10
#Пользователь и группа, от имени которых будет запускаться процесс
user openvpn
group openvpn
#Не перечитывать файлы с ключами при получении SIGUSR1 или --ping-restart.
#Эта опция может быть использована совместно с --user nobody,
#чтобы разрешить перезапуски вызываемые SIGUSR1.
#По умолчанию, если вы понижаете привелегии демона OpenVPN, то
#его нельзя перезапустить, так как невозможно заново прочитать защищенные файлы ключей.
persist-key
#Не закрывать и повторно открывать устройство TUN/TAP
#или запускать скрипты up/down при получении сигнала SIGUSR1 или перезапусков по --ping-restart.
#Сигнал SIGUSR1 схож с SIGHUP, но предоставляет более точный контроль над опциями перезапуска.
persist-tun
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3
Включаем, соединяемся… пиры друг друга пингуют. С клиента пингуется сеть за сервером, а вот наоборот – хрен. Курим гугл, находим решение:
Важное замечание, что если OpenVPN запускается в режиме server (см. комментарии п.2), то статический или динамический маршрут, даже который смотрит правильно и напрямую в интерфейс tun, ни к чему не приведет, работать не будет.
Т.к. в режиме server получается point-to-multipoint линк и именно поэтому серверу надо уже объяснять какому клиенту за ифейсом tun нужно отправлять трафик. Поэтому туннельные интерфейсы могут пинговаться, а любые подсети за OpenVPN-клиентом нет, т.к. трафик не уедет в туннель.
Это хорошо видно по tcpdump, если с OpenVPN-сервера попробовать попинговать любой адрес из подсети, которая находится ЗА OpenVPN-клиентом.
С одной стороны (со стороны OpenVPN-сервера) трафик в tun виден, а до другой стороны трафик просто не доходит, а если быть точнее, то на самом деле трафик с OpenVPN-сервера просто не отправляется.
Так что файлик /etc/openvpn/ccd/client будет примерно таким:
ifconfig-push 10.255.1.114 10.255.1.113
iroute 10.12.51.0 255.255.255.0
iroute 10.12.5.0 255.255.255.0
iroute 10.12.4.0 255.255.255.0
После этого все должно заработать. Маршруты появятся автоматически, как только установится соединение. Так же можно запускать сторонние скрипты с помощью директив up и down. Подробнее с примерами их использования можно ознакомиться по ссылкам выше.