OpenVPN

OpenVPN

Пришло время описать OpenVPN. Так как эта статья является второй после IPSec, то писать введение считаю необязательным.

Простая симметричная схема

С точки зрения организации соединения, клиент и сервер поднимают между собой туннель. Функционально клиент от сервера не отличается. Однако применение дополнительных команд push '...' в конфигурационном файле одной стороны избавляет от явного их написания на другой. Рассмотрим простейший случай с авторизацией по статическому ключу. Рисунок прилагается.

Сначала создадим этот самый ключ:

 # openvpn --genkey --secret static.key

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

Теперь сам конфиг ( /etc/openvpn/server.conf ):

dev tun
port 1194
ifconfig 10.10.10.1 10.10.10.2
secret /etc/openvpn/static.key

# Use compression on the VPN link
comp-lzo

# Make the link more resistent to connection failures
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
 
# Run OpenVPN as a daemon and drop privileges to user/group nobody
user nobody
group nobody
daemon
 
# Allow client to reach entire server subnet
route 192.168.0.0 255.255.255.0

# Set logging
log-append /var/log/openvpn.log
status /var/log/openvpn-status.log
verb 3

Комментарии:

• Некоторые опции являются умолчательными, например порт: 1194 - его можно и не указывать. Кстати, по записям, используется протокол UDP, если указан dev tun, или TCP в случае dev tap. Это важно для правил файерволла, но явно это не проверялось.
• ifconfig поднимает виртуальные интерфейсы в пространстве tun, т.е. виртуальные шлюзы, на которые должны роутиться запросы из соединяемых в vpn подсетей.
• Применяемое сжатие и дополнительные записи для пингования - стандартны. Скопировано не глядя.
• Пользователь nobody должен быть в системе, коль мы его указываем. Обычно, так оно и есть, но можно использовать и другой аккаунт, в чем смысла особого нет.
• Строка route указывает нашему "серверу", какая реальная подсеть доступна на другой стороне. Без этого окажется доступным только непосредственно "клиентский" компьютер, но не другие в его подсети. (Явно не проверялось).
• Логи - не сильная сторона OpenVPN. Надо попробовать verb 5 в следующий раз. А на 3-м уровне информация кое-какая есть, но о природе ошибок, с которыми столкнулись, судить (особенно с непривычки) трудно. В status обновляется статистика по трафику, а в log'е - успех или неуспех соединения, временные дисконнекты и т.п.

Аналогично приведу конфигурационный файл другой стороны ( /etc/openvpn/client.conf ):

#remote de01.eterhost.ru
remote 144.76.183.114
port 1194
dev tun
ifconfig 10.10.10.2 10.10.10.1
secret /etc/openvpn/static.key

# Use compression on the VPN link
comp-lzo

# Make the link more resistent to connection failures
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
 
# Run OpenVPN as a daemon and drop privileges to user/group nobody
user nobody
group nobody
daemon
  
# Allow client to reach entire server subnet
route 192.168.1.0 255.255.255.0 10.10.10.1

  
# Set logging
log-append /var/log/openvpn.log
status /var/log/openvpn-status.log
verb 3

Отличия минимальны:

• remote - явно указывает к кому подключаемся. Аналогичную команду можно применить и на "сервере", если у обеих сторон внешние фиксированные ip.
• Обратите внимание: адреса в ifconfig поменялись порядком.
• Здесь в команде route явно указан шлюз (третий параметр, он необязателен). В данном случае это мало что меняет, но полезно указать случай, когда его явное указание имеет важное значение.

Особенности OpenVZ

Если мы поднимаем OpenVPN внутри контейнера, то необходимо ему дать возможность работать с tun-устройством. Кратко (выполнить на стороне хоста):

modprobe tun

CTID=250

vzctl set $CTID --devnodes net/tun:rw --save
vzctl set $CTID --devices c:10:200:rw --save
vzctl set $CTID --capability net_admin:on --save
vzctl exec $CTID mkdir -p /dev/net
vzctl exec $CTID mknod /dev/net/tun c 10 200

Проблемы доступа в подсети

После запуска OpenVPN службы при данных настройках машины стали успешно пинговаться. Причем по разным ip: как из адресного пространства tun (10.10.10.x), так и реальных ip: 192.168.x.y. Однако, это касается только случая когда я делал пинги с машины, на которой поднят OpenVPN-клиент, на машину, где тоже поднят OpenVPN-клиент. Что до других машин - то попытка пинговать или подключиться по ssh к другим машинам подсетей (в обоих направлениях) к успеху не привела: молчание в ответ... Причина оказалась в том, что клиенты VPN подняты НЕ НА ШЛЮЗОВЫХ компьютерах подсетей. Это приводит к тому, что когда, машина получает ping, она должна ответить на него, но куда ? Выяснилось, что на tun-адрес 10.10.10.x, но на неклиентских машинах подсетей нет никакой информации о том, где эти ip находятся, поэтому они отсылают ответ на default gateway. Которые тоже ничего о ни не знают.

To be continued...