OpenVPN

OpenVPN

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

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

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

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

 # openvpn --genkey --secret static.key

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

Теперь сам конфиг:

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'е - успех или неуспех соединения, временные дисконнекты и т.п.

Аналогично приведу конфигурационный файл другой стороны:

#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 явно указан шлюз (третий параметр, он необязателен). В данном случае это мало что меняет, но полезно указать случай, когда его явное указание имеет важное значение.