Comp lzo openvpn что это

OpenVPN, о котором вы так мало знали

OpenVPN, как много в этом слове. Мультиплатформенный, гибко настраиваемый, бесплатный VPN сервер с открытым исходным кодом, являющийся фактически стандартом «defacto» для организации доступа к внутренним корпоративным сетям. Большинство администраторов используют его с настройками по умолчанию или с типовыми конфигурациями широко описанными в разных HOW-TO. Но так ли прост OpenVPN, как он кажется на первый взгляд? В данной статье мы рассмотрим скрытые от глаз внутренние механизмы OpenVPN, которые кардинально меняют представление о его возможностях.

OpenVPN сервер распространяется в виде исходного кода или готовых к установке скомпилированных пакетов для различных операционных систем. В качестве библиотеки обеспечивающей шифрование используется OpenSSL.

Большинство конфигураций для связи клиентов с сервером, а также между серверами, предполагает использование связки приватных или приватно/публичных ключей для обеспечения безопасности внутреннего трафика. Для корпоративных сетей в режиме MultiPoint-To-SinglePoint обычно используется свой центр сертификации PKI, который легко строится либо при помощи easy-rsa, либо на основе XCA. Для межсервенной коммуникации типа Point-to-point, в основном используется конфигурация с общим ключом. Вспомним основные, всем известные механизмы и возможности.

Основные механизмы и возможности

Сертификатная аутентификация

Приватные point-to-point ключи

Во всех случаях подключения для безопасности «рукопожатия» handshake между клиентом и сервером используется протокол Diffie-Hellmann.

Внешняя аутентификация пользователей

Для упрощения контроля за подключением пользователей, вместо схемы со своим PKI, можно использовать схему с внешней аутентификацией пользователей по логину/паролю. Данная схема удобна для аутентификации пользователей скажем по доменному логину/паролю. Для подключения к серверу в конфигурационный файл клиента добавляется сертификат сервера и ключ подписи передаваемых пакетов HARDENING OPENVPN SECURITY.
пример клиентского конфига

dev tun proto udp # Внешний IP сервера OpenVPN remote 172.16.111.166 # Port сервера port 1200 client resolv-retry infinite tls-client key-direction 1 auth SHA1 cipher BF-CBC #comp-lzo persist-key persist-tun # auth-user-pass c:/temp/pass.txt # # just create a file with name pass.txt # and put to it two lines # ------------- #username #password # ------------- #auth-user-pass verb 3 -----BEGIN CERTIFICATE----- MIIE5jCCA86gAwIBAgIJAOt3kFH7PxA0MA0GCSqGSIb3DQEBCwUAMIGjMQswCQYD . -----END CERTIFICATE----- -----BEGIN OpenVPN Static key V1----- 83ddd29fa82212f3059d85a41490134c . a4f2c7df3a22364a49093bca102dedeb -----END OpenVPN Static key V1----- 

Часть серверного конфига для аутентификации клиентов через файл
Using alternative authentication methods

verify-client-cert none #client-cert-not-required username-as-common-name tls-server tls-auth /usr/local/etc/openvpn/ssl/tlsauth.key key-direction 0 tls-timeout 120 auth SHA1 cipher BF-CBC auth-user-pass-verify /usr/local/etc/openvpn/auth/auth-static-file.pl via-file

PAM

Для повышения безопасности можно использовать подключаемые модули обеспечивающие проверку логина/пароля во внешних системах. Самым распространённым методом является системный PAM(Pluggable Authentication Modules).
В конфигурационный файл OpenVPN необходимо добавить строку

plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so login

Маршрутизация

На этом «штатные» широкоиспользуемые возможности заканчиваются и начинается локальная кастомизация для каждого конкретного случая.

Дополнительные возможности OpenVPN

Рассмотрим дополнительные возможности OpenVPN, о которых может кто-то и слышал, но в реальности не видел или не использовал.

Безопасность сетей/Packet Filtering

Т.к. OpenVPN маршрутизирует трафик, у него есть два штатных взаимоисключающих друг друга режима работы. Первый режим это маршрутизация внутри OpenVPN сервера, второй режим это межинтерфейсная ядерная маршрутизация. В первом случае за коммутацию и фильтрацию пакетов между клиентами/сетями отвечает сам OpenVPN, во втором любой поддерживаемый на хосте системный пакетный фильтр(pf, iptables, etc).
Мало кто знает, что OpenVPN имеет встроенный пакетный фильтр, который позволяет разрешить или изолировать соединения между пользователями и сетями.
Да, да. Вы правильно прочитали. OpenVPN имеет свой собственный встроенный пакетный фильтр. Возможность фильтрации трафика была реализована еще в далёком 2010 году.
Пакетный фильтр OpenVPN управляется либо через management-interface, либо через подключаемые к OpenVPN плагины.
Управление правилами трафика происходит через файл. Формат файла прост.

[CLIENTS DROP|ACCEPT] <+|->common_name1 <+|->common_name2 . . . [SUBNETS DROP|ACCEPT] <+|->subnet1 <+|->subnet2 . . . [END]

Директивы блока (ACCEPT/DENY) задают действие по умолчанию для всех клиентов не указанных внутри блока.
Например файл для клиента user2

[CLIENTS DROP] +user1 [SUBNETS DROP] [END]

Или другой пример.
Отключить всё кроме доступа между пользователями и DNS сервером находящимся в локальной сети и тестовым контуром в сети 192.168.0.0/24

[CLIENTS DROP] +user1 +user2 [SUBNETS DROP] +10.150.0.1 +10.150.1.1 +192.168.0.0/24 [END]

Механизм фильтрации активируется через конфигурационный файл, либо при подключении плагина «выставившего» флаг «OPENVPN_PLUGIN_ENABLE_PF».
Данную возможность мы обсудим позже.
Вторым режимом фильтрации трафика является встроенный в систему пакетный фильтр. Для его активации в конфиге не должно быть директивы «client-to-client». С точки зрения автоматизации включения/выключения необходимых правил при подключении/отключении клиентов удобнее всего использовать отдельные вставки в список правил, реализуемые либо через CHAINS в Iptables(Linux), либо в Anchors в PF(FreeBSD). Активация/деактивация правил обычно осуществляется через директивы client-connect/client-disconnect в конфигурационном файле сервера, вызывающие соответствующие скрипты при подключении/отключении пользователя.

Расширенная PAM аутентификация

Под расширенной PAM аутентификацией подразумевается изменение логики работы проверки логина и пароля пользователя. Достигается это либо установкой соответствующих плагинов для OpenVPN, обеспечивающих чтение и проверку данных во внешних источниках, либо подключением в систему библиотек позволяющих скриптовать любую логику. Одной из такой библиотек является pam_python, которая помогает скриптовать любую логику проверки логина/пароля через Python скрипты.
В случае её использования строка проверки пользователя меняется следующим образом.

plugin openvpn-plugin-auth-pam.so pam_python login USERNAME password PASSWORD domain mydomain.com

«Отложенная» аутентификация

Плагины OpenVPN

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

#define OPENVPN_PLUGIN_FUNC_SUCCESS 0 #define OPENVPN_PLUGIN_FUNC_ERROR 1 #define OPENVPN_PLUGIN_FUNC_DEFERRED 2

Остановимся поподробнее на каждой группе. Логику работы мы будем рассматривать на основе парольной аутентификации пользователя.
При старте сервера, после чтения конфигурационного файла, сервер вызывает функции OPENVPN_PLUGIN_UP и OPENVPN_PLUGIN_ROUTE_UP. В переменном окружении вызываемых функций передаются основные параметры запущенного сервера.

OPENVPN_PLUGIN_UP < "route_netmask_1":"255.255.0.0", "daemon_start_time":"1545994898", "ifconfig_remote":"10.150.0.2", "local_1":"172.16.100.139", "script_context":"init", "config":"/usr/local/etc/openvpn/server150.conf", "link_mtu":"1622", "ifconfig_local":"10.150.0.1", "tun_mtu":"1500", "verb":"2", "daemon_pid":"626", "route_vpn_gateway":"10.150.0.2", "proto_1":"udp", "daemon_log_redirect":"1", "daemon":"1", "route_net_gateway":"172.16.100.1", "dev_type":"tun", "route_gateway_1":"10.150.0.2", "remote_port_1":"1200", "dev":"tun150", "pluginid":"0", "local_port_1":"1200", "route_network_1":"10.150.0.0" >

OPENVPN_PLUGIN_ROUTE_UP < "route_netmask_1":"255.255.0.0", "daemon_start_time":"1545994898", "redirect_gateway":"0", "ifconfig_remote":"10.150.0.2", "local_1":"172.16.100.139", "script_context":"init", "config":"/usr/local/etc/openvpn/server150.conf", "link_mtu":"1622", "ifconfig_local":"10.150.0.1", "tun_mtu":"1500", "verb":"2", "daemon_pid":"626", "route_vpn_gateway":"10.150.0.2", "proto_1":"udp", "daemon_log_redirect":"1", "daemon":"1", "route_net_gateway":"172.16.100.1", "dev_type":"tun", "route_gateway_1":"10.150.0.2", "remote_port_1":"1200", "dev":"tun150", "pluginid":"2", "local_port_1":"1200", "route_network_1":"10.150.0.0" >

Данные функции можно использовать для оповещений при старте сервера либо смене конфигурации.
При подключении клиента, OpenVPN запрашивает возможность активации внутреннего пакетного фильтра.

OPENVPN_PLUGIN_ENABLE_PF < "route_netmask_1":"255.255.0.0", "daemon_start_time":"1545994898", "redirect_gateway":"0", "ifconfig_remote":"10.150.0.2", "local_1":"172.16.100.139", "script_context":"init", "config":"/usr/local/etc/openvpn/server150.conf", "link_mtu":"1622", "pf_file":"/tmp/openvpn_pf_b7a18ca8fac838679ca87ada6b8a356.tmp", "ifconfig_local":"10.150.0.1", "tun_mtu":"1500", "verb":"2", "daemon_pid":"626", "route_vpn_gateway":"10.150.0.2", "proto_1":"udp", "route_net_gateway":"172.16.100.1", "daemon":"1", "daemon_log_redirect":"1", "dev_type":"tun", "route_gateway_1":"10.150.0.2", "remote_port_1":"1200", "dev":"tun150", "pluginid":"11", "local_port_1":"1200", "route_network_1":"10.150.0.0" >

Как видно из дампа, появилась переменная pf_file. В данном файле должны находиться правила внутреннего пакетного фильтра для текущей обрабатываемой сессии.
Далее проверяется логин и пароль пользователя в функции OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY

OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY < "route_netmask_1":"255.255.0.0", "route_gateway_1":"10.150.0.2", "IV_NCP":"2", "IV_COMP_STUB":"1", "daemon_start_time":"1545994898", "IV_LZ4":"1", "redirect_gateway":"0", "ifconfig_remote":"10.150.0.2", "untrusted_port":"1200", "IV_LZ4v2":"1", "local_1":"172.16.100.139", "script_context":"init", "untrusted_ip":"172.16.111.168", "config":"/usr/local/etc/openvpn/server150.conf", "username":"fa56bf61-90da-11e8-bf33-005056a12a82-1234568", "link_mtu":"1622", "pf_file":"/tmp/openvpn_pf_b7a18ca8fac838679ca87ada6b8a356.tmp", "ifconfig_local":"10.150.0.1", "tun_mtu":"1500", "auth_control_file":"/tmp/openvpn_acf_a3d0650a43b88ca1b5f305ce2c8f682.tmp", "daemon":"1", "IV_COMP_STUBv2":"1", "verb":"2", "IV_PLAT":"win", "daemon_pid":"626", "password":"12312312312312", "route_vpn_gateway":"10.150.0.2", "proto_1":"udp", "route_net_gateway":"172.16.100.1", "IV_PROTO":"2", "daemon_log_redirect":"1", "dev_type":"tun", "IV_VER":"2.4.3", "IV_LZO":"1", "remote_port_1":"1200", "dev":"tun150", "pluginid":"5", "local_port_1":"1200", "IV_TCPNL":"1", "route_network_1":"10.150.0.0" >

Это единственное место где пароль в переменном окружении присутствует в открытом виде.
Результатом работы данной функции должны быть три варианта ответа.

#define OPENVPN_PLUGIN_FUNC_SUCCESS 0 #define OPENVPN_PLUGIN_FUNC_ERROR 1 #define OPENVPN_PLUGIN_FUNC_DEFERRED 2

Если сервер получает ответ OPENVPN_PLUGIN_FUNC_DEFERRED, то в работу вступает механизм «отложенной» аутентификации. Как мы видим, в переменном окружении появилась переменная «auth_control_file», содержимое данной переменной содержит имя файла, в котором будет ожидаться ответ от системы аутентификации. Ответом является помещённый в указанный файл символ 0(для разрешения доступа), 1(для запрета доступа). Параметр сервера «hand-window» определяет таймаут в секундах, в течении которого сервер будет ожидать ответ. Во время ожидания трафик от других клиентов не прерывается.

Так как мы работаем с парольной аутентификацией, то функции проверки сертификатов OPENVPN_PLUGIN_TLS_VERIFY не вызывается. Вместо этого сразу вызывается OPENVPN_PLUGIN_TLS_FINAL, подтверждающий установление сессии.

OPENVPN_PLUGIN_TLS_FINAL < "route_netmask_1":"255.255.0.0", "route_gateway_1":"10.150.0.2", "IV_NCP":"2", "IV_COMP_STUB":"1", "daemon_start_time":"1545994898", "IV_LZ4":"1", "redirect_gateway":"0", "ifconfig_remote":"10.150.0.2", "untrusted_port":"1200", "IV_LZ4v2":"1", "local_1":"172.16.100.139", "script_context":"init", "untrusted_ip":"172.16.111.168", "config":"/usr/local/etc/openvpn/server150.conf", "username":"fa56bf61-90da-11e8-bf33-005056a12a82-1234568", "link_mtu":"1622", "pf_file":"/tmp/openvpn_pf_b7a18ca8fac838679ca87ada6b8a356.tmp", "ifconfig_local":"10.150.0.1", "tun_mtu":"1500", "auth_control_file":"/tmp/openvpn_acf_a3d0650a43b88ca1b5f305ce2c8f682.tmp", "daemon":"1", "IV_COMP_STUBv2":"1", "verb":"2", "IV_PLAT":"win", "daemon_pid":"626", "route_vpn_gateway":"10.150.0.2", "proto_1":"udp", "route_net_gateway":"172.16.100.1", "IV_PROTO":"2", "daemon_log_redirect":"1", "dev_type":"tun", "IV_VER":"2.4.3", "IV_LZO":"1", "remote_port_1":"1200", "dev":"tun150", "pluginid":"10", "local_port_1":"1200", "IV_TCPNL":"1", "route_network_1":"10.150.0.0" >

Далее срабатывает вызов OPENVPN_PLUGIN_IPCHANGE, вызываемый перед сменой ip адреса клиента.

OPENVPN_PLUGIN_IPCHANGE < "route_netmask_1":"255.255.0.0", "route_gateway_1":"10.150.0.2", "trusted_ip":"172.16.111.168", "link_mtu":"1622", "IV_COMP_STUB":"1", "daemon_start_time":"1547319280", "IV_LZ4":"1", "redirect_gateway":"0", "common_name":"fa56bf61-90da-11e8-bf33-005056a12a82-1234568", "ifconfig_remote":"10.150.0.2", "IV_NCP":"2", "untrusted_port":"1200", "IV_LZ4v2":"1", "local_1":"172.16.100.139", "script_context":"init", "untrusted_ip":"172.16.111.168", "config":"/usr/local/etc/openvpn/server150.conf", "username":"fa56bf61-90da-11e8-bf33-005056a12a82-1234568", "trusted_port":"1200", "pf_file":"/tmp/openvpn_pf_4fcad505693b33f97c4fe105df8681cb.tmp", "ifconfig_local":"10.150.0.1", "tun_mtu":"1500", "auth_control_file":"/tmp/openvpn_acf_321bb12075dc0e1b5440d227220bac5d.tmp", "daemon":"1", "IV_COMP_STUBv2":"1", "verb":"3", "IV_PLAT":"win", "daemon_pid":"52435", "route_vpn_gateway":"10.150.0.2", "proto_1":"udp", "route_net_gateway":"172.16.100.1", "IV_PROTO":"2", "daemon_log_redirect":"1", "dev_type":"tun", "IV_VER":"2.4.3", "IV_LZO":"1", "remote_port_1":"1200", "dev":"tun150", "pluginid":"3", "local_port_1":"1200", "IV_TCPNL":"1", "route_network_1":"10.150.0.0" >

Функция OPENVPN_PLUGIN_CLIENT_CONNECT_V2, вызывается при установке IP адреса внутренним DHCP сервером.

OPENVPN_PLUGIN_CLIENT_CONNECT_V2 < "route_netmask_1":"255.255.0.0", "route_gateway_1":"10.150.0.2", "trusted_ip":"172.16.111.168", "link_mtu":"1622", "IV_COMP_STUB":"1", "daemon_start_time":"1547319280", "IV_LZ4":"1", "dev":"tun150", "common_name":"fa56bf61-90da-11e8-bf33-005056a12a82-1234568", "time_ascii":"Sat Jan 12 18:54:48 2019", "ifconfig_remote":"10.150.0.2", "IV_NCP":"2", "untrusted_port":"1200", "IV_LZ4v2":"1", "local_1":"172.16.100.139", "script_context":"init", "untrusted_ip":"172.16.111.168", "config":"/usr/local/etc/openvpn/server150.conf", "username":"fa56bf61-90da-11e8-bf33-005056a12a82-1234568", "trusted_port":"1200", "pf_file":"/tmp/openvpn_pf_4fcad505693b33f97c4fe105df8681cb.tmp", "ifconfig_local":"10.150.0.1", "tun_mtu":"1500", "auth_control_file":"/tmp/openvpn_acf_321bb12075dc0e1b5440d227220bac5d.tmp", "daemon":"1", "IV_COMP_STUBv2":"1", "verb":"3", "IV_PLAT":"win", "daemon_pid":"52435", "time_unix":"1547319288", "redirect_gateway":"0", "route_vpn_gateway":"10.150.0.2", "proto_1":"udp", "route_net_gateway":"172.16.100.1", "IV_PROTO":"2", "daemon_log_redirect":"1", "dev_type":"tun", "IV_VER":"2.4.3", "IV_LZO":"1", "remote_port_1":"1200", "ifconfig_pool_local_ip":"10.150.0.5", "pluginid":"9", "ifconfig_pool_remote_ip":"10.150.0.6", "local_port_1":"1200", "IV_TCPNL":"1", "route_network_1":"10.150.0.0" >

В переменном окружении появляются переменные содержащие параметры туннеля «ifconfig_pool_local_ip» и «ifconfig_pool_remote_ip».

Функция OPENVPN_PLUGIN_LEARN_ADDRESS вызывается при обучении OpenVPN сервером, связки IP адресов и маршрутов к ним. После выхода из этой функции активируется процедура применения настроек пакетного фильтра из файла. Переменное окружение OPENVPN_PLUGIN_LEARN_ADDRESS при этом соответствует фазе OPENVPN_PLUGIN_CLIENT_CONNECT_V2.

fa56bf61-. /172.16.111.168:1200 ----- pf_check_reload : struct pf_context ----- fa56bf61-. /172.16.111.168:1200 enabled=1 fa56bf61-. /172.16.111.168:1200 filename='/tmp/openvpn_pf_343330698e4acdea34c8a8c7fb87d861.tmp' fa56bf61-. /172.16.111.168:1200 file_last_mod=1547319124 fa56bf61-. /172.16.111.168:1200 n_check_reload=1 fa56bf61-. /172.16.111.168:1200 reload=[1,15,1547319125] fa56bf61-. /172.16.111.168:1200 ----- struct pf_set ----- fa56bf61-. /172.16.111.168:1200 kill=0 fa56bf61-. /172.16.111.168:1200 ----- struct pf_subnet_set ----- fa56bf61-. /172.16.111.168:1200 default_allow=ACCEPT fa56bf61-. /172.16.111.168:1200 ----- struct pf_cn_set ----- fa56bf61-. /172.16.111.168:1200 default_allow=DROP fa56bf61-. /172.16.111.168:1200 12345678-90da-11e8-bf33-005056a12a82-1234567 ACCEPT fa56bf61-. /172.16.111.168:1200 fa56bf61-90da-11e8-bf33-005056a12a82-1234567 ACCEPT fa56bf61-. /172.16.111.168:1200 ---------- fa56bf61-. /172.16.111.168:1200 fa56bf61-90da-11e8-bf33-005056a12a82-1234567 ACCEPT fa56bf61-. /172.16.111.168:1200 12345678-90da-11e8-bf33-005056a12a82-1234567 ACCEPT fa56bf61-. /172.16.111.168:1200 --------------------

При отключении клиента вызывается функция OPENVPN_PLUGIN_CLIENT_DISCONNECT.

OPENVPN_PLUGIN_CLIENT_DISCONNECT < "route_netmask_1":"255.255.0.0", "route_gateway_1":"10.150.0.2", "trusted_ip":"172.16.111.168", "link_mtu":"1622", "IV_COMP_STUB":"1", "daemon_start_time":"1547319280", "IV_LZ4":"1", "dev":"tun150", "common_name":"fa56bf61-90da-11e8-bf33-005056a12a82-1234568", "time_ascii":"Sat Jan 12 18:54:48 2019", "bytes_received":"30893", "IV_NCP":"2", "untrusted_port":"1200", "ifconfig_remote":"10.150.0.2", "IV_LZ4v2":"1", "local_1":"172.16.100.139", "script_context":"init", "untrusted_ip":"172.16.111.168", "config":"/usr/local/etc/openvpn/server150.conf", "username":"fa56bf61-90da-11e8-bf33-005056a12a82-1234568", "trusted_port":"1200", "pf_file":"/tmp/openvpn_pf_4fcad505693b33f97c4fe105df8681cb.tmp", "ifconfig_local":"10.150.0.1", "tun_mtu":"1500", "auth_control_file":"/tmp/openvpn_acf_4bdddbada2885cde42cd3cb1b85d77e5.tmp", "daemon":"1", "IV_COMP_STUBv2":"1", "verb":"3", "IV_PLAT":"win", "daemon_pid":"52435", "time_unix":"1547319288", "redirect_gateway":"0", "route_vpn_gateway":"10.150.0.2", "proto_1":"udp", "route_net_gateway":"172.16.100.1", "IV_PROTO":"2", "daemon_log_redirect":"1", "time_duration":"3781", "dev_type":"tun", "IV_VER":"2.4.3", "IV_LZO":"1", "bytes_sent":"22684", "remote_port_1":"1200", "ifconfig_pool_local_ip":"10.150.0.5", "pluginid":"7", "ifconfig_pool_remote_ip":"10.150.0.6", "local_port_1":"1200", "IV_TCPNL":"1", "route_network_1":"10.150.0.0" >

В переменном окружении добавляются длительность соединения и трафик пользователя.

Как вы успели заметить, в связи с обилием данных в разных вызовах, написание и отладка плагина на языке программирования C(C++) будет довольно трудоёмкой задачей.
Для расширения функционала было решено сделать «чудо» сначала для внутреннего проекта, а потом выложить его в свободный доступ 🙂
После долгого чтения исходных кодов OpenVPN и различных примеров узкоспециализированных плагинов, был написан проект, который в качестве языка программирования логики обработки сессии использует Python. Код представляет собой подключаемый к OpenVPN плагин на языке C, который все запросы поступающие в плагин, отправляет в Python модуль через c-api reference.

Почему Python модуль ?

Python c-api reference работая с python файлами напрямую, некорректно работает с загрузкой python библиотек.

Как это работает ?

При инициализации плагина в OpenVPN, плагин возвращает масочный список всех функций, которые может обслужить. При наступлении очередной фазы подключения или внутреннего события, OpenVPN вызывает соответствующие функции из плагина. Плагин преобразует переменное окружение и параметры переданные функции в структуру, инициализирует python и передаёт структуру в соответствующую процедуру python модуля. Процедура возвращает плагину один из трёх ответов (0 — Success, 1 — Error, 2 — Deferred). Ответ транформируется и возвращается OpenVPN.

Обратите внимание, что все вызовы модуля являются «stateless», это означает, что процедуры не помнят и не знают, что происходило ранее в других вызовах. Ориентироваться можно только на переменное окружение передаваемое плагину из OpenVPN.

Внутри python модуля вы можете реализовать любую логику, подключая нужные библиотеки и ресурсы. Если вы не уверены в скорости выполнения проверок, то используйте «отложенные» подтверждения.

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

Во время тестирования проекта был разработан механизм генерации паролей, аналогичный jwt токенам, но имеющим меньший размер.

Суть проста. Токен содержит в себе идентификатор клиента и срок окончания доступа. Для подписи токена используется HMAC_SHA1 с закрытым ключом. После подписи токена, текстовое содержимое ксорится подписью и конвертится в base64. Таким образом получается «запечатывание» токена. «Запечатанный» токен используется в качестве пароля пользователя. При несанкционированном изменении блока с данными, поломается xor, если поломается xor, значит поломается проверка подписи. Без закрытого ключа подпись изменить не получится.

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

Надеюсь информация в данной статье была вам полезна.
Спасибо за потраченное на её прочтение время.
Если есть вопросы, попробую ответить на что смогу.

© Aborche 2019

�� Основные параметры OpenVPN

Подробности использования команд и их параметры — man openvpn.

remote < host >— определяет удаленный конец туннеля. Могут использоваться записи IP и DNS.

local < host >— определяет локальный ip или имя хоста, на котором будет работать OpenVPN. Актуально, если на локальной машине несколько адресов.

dev < device >— определяет какой использовать тип устройства tun или tap. Например:

При одном из таких указаний будет использован свободный интерфейс tun или tap. Так же можно явно указывать номер виртуального интрефейса, например tun0.

port < port number >— указывает на каком порту будет работать OpenVPN (локально и удаленно).

proto < proto >— какой протокол будет использоваться. Возможные значения: udp, tcp, tcp-client, tcp-server.

• tcp-client — сам пытается установить соединение
• tcp-server — только ждет подключений

С использованием протокола udp VPN будет работать быстрее, чем tcp, но в плане стабильности работы лучше выбирать tcp (как показывает практика, VPN-соединение более устойчиво).

remote-random — если указана данная опция и в random перечисленно несколько удаленных хостов, то OpenVPN в случайном порядке будет к ним подключаться. Применяется для балансировки нагрузки.

float — позволяет удаленному хосту изменять IP во время работы туннеля. Соединение при этом не разрывается.

ipchange < cmd >— выполняет скрипт или команду указанную в < cmd >, если IP сменился. Пример:
ipchange script-ip.sh

connect-retry < seconds >— пробует переподключиться через указанное время в секундах, если соединение было разорвано.

connect-retry-max < n >— максимальное количество повторов если соединение было разорвано

resolv-retry < seconds >— если OpenVPN не удалось узнать имя удаленного хоста по DNS, то через указанное количество секунд попытаться переподключиться.

lport < port >— указывает на локальный порт для использования OpenVPN

rport < port >— аналогично для удаленного порта. Пример:
rport 8000 — OpenVPN будет пытаться подключится к удаленному порту 8000

nobind — использовать динамический порт для подключения (только для клиента)

shaper < bytes >— указывает скорость передачи данных в байтах для исходящего трафика (только для клиента)

tun-mtu < mtu size >— устанавливает максимальный размер MTU. По умолчанию tun-mtu равен 1500. Использование:
tun-mtu 1200

dev-node < interface name >— устанавливает имя виртуального интерфейса. Например:

dev-node openvpn1

ifconfig — устанавливает локальный IP и маску подсети для туннельного интерфейса. Например:

ifconfig 10.3.0.0 255.255.255.0

server < network > < mask >— автоматически присваивает адреса всем клиентам (DHCP) в указанном диапазоне с маской сети. Данная опция заменяет ifconfig и может работаеть только с TLS-клиентами в режиме TUN, соответственно использование сертификатов обязательно. Например:

server 10.3.0.0 255.255.255.0

Подключившиеся клиенты получат адреса в диапазоне между 10.3.0.3 и 10.3.0.254. Адрес 10.3.0.1 сервер оставит себе.

server-bridge < gateway > < mask > < pool >— сервер в режиме моста для TAP устройств. Пример:

server bridge 10.3.0.1 255.255.255.0 10.3.0.128 10.3.0.254

Клиентам будут выданы адреса в диапазоне 10.3.0.128 — 10.3.0.254, в качестве шлюза будет указан 10.3.0.1.

mode server — переключает OpenVPN в режим сервера (начиная с 2-й версии)

mode p2p — данная опция идет по умолчанию.

push < options >— передача клиенту конфигурационных параметров. Пример:

push "route 192.168.0.0 255.255.255.0"

Аналогично с помощью push клиенту могут передаваться следующие параметры:

route route-gateway route-delay redirect-gateway inactive ping, ping-exit, ping-restart persist-key, persist-tun comp-lzo dhcp-option ip-win32

Последние две опции применимы только для Window-клиентов.

comp-lzo — параметр сжатия трафика, идущего через виртуальный туннель. Может принимать значения yes, no, adaptive.

• comp-lzo yes — принудительно включить сжатие
• comp-lzo no — принудительно отключить сжатие
• comp-lzo adaptive — адаптивный режим.

route < network >— устанавливает указанную маршрутизацию на VPN-хосте, после успешного запуска туннеля. Пример:
route 10.0.10.0 255.255.255.252

route-gateway < IP >— устанавливает шлюз на VPN-хосте. Пример:
route-gateway 192.168.0.22
После успешного запуска виртуального туннеля клиенту будет задан шлюз 192.168.0.22

route-delay < seconds >— указывает подождать n-секунд перед установкой маршрутов. Пример:
route-delay 5
Т.е. через 5 секунд после установки туннеля будут заданы маршруты.

route-up < cmd >— выполнить скрипт или программу < cmd >после установки маршрутов. Пример:
route-up /script.sh

redirect-gateway — установить шлюзом по умолчанию удаленный сервер. Т.е. когда удаленный пользователь подключается к нашему серверу, то ему будет задан шлюз по умолчанию на наш сервер.

ping < seconds >— указывает отсылать ping на удаленный конец тунеля после указанных n-секунд, если по туннелю не передавался никакой трафик. Пример:
ping 10

ping-restart < seconds >— если за указанное время не было получено ни одного пакета с удаленной стороны, то перезапускать туннель. Пример:
ping-restart 60 — если в течении 60 секунд не было получено ни одного пакета, то туннель будет перезапущен.

ping-timer-rem — позволяет перезапускать туннель, только когда указан удаленный адрес.

persist-tun — данная опция оставляет без изменения устройства tun/tap при перезапуске OpenVPN.

persist-key — указывает не перечитавать файлы ключей при перезапуске туннеля.

resolv-retry < seconds >— устанавливает время в секундах для запроса об удаленном имени хоста. Актуально только если используется DNS-имя удаленного хоста. Пример:
resolv-retry 86400
inactive < seconds >— после n-секунд неактивности устройство TUN/TAP автоматически отключется. Пример:
inactive 120

ping-exit < seconds >— если за указанные n-секунд не было получено ни одного пакета, то отключать OpenVPN. Пример:
ping-exit 120

keepalive < seconds > < seconds >— является совмещением сразу двух команд — ping и ping-restart. Использует сразу два параметра в секундах, перечисленных через пробел. Пример:
keepalive 10 180
Означает следующее: каждые 10 секунд посылать ping на удаленный хост, и, если за 180 секунд не было получено ни одного пакета — то перезапускать туннель.

persist-local-ip < IP >— оставлять неизменными локальный IP адрес и номер порт, если туннель был перезапущен.

persist-remote-ip < IP >— оставлять неизменными удаленный IP адрес и номер порт, если туннель был перезапущен.
persist-remote-ip 192.168.50.1

�� Похожие статьи на сайте

• Исправляем ошибку Resource temporarily unavailable (errno=11)
• Ошибка при работе OpenVPN: error=CRL has expired
• Ошибка 0E065068:configuration file routines:STR_COPY:variable has no value:conf_def
• Установка OpenVPN в Debian/Ubuntu/Mint из стандартных репозиториев проекта OpenVPN
• OpenVPN против WireGuard: краткое сравнение
• TLS: soft reset — что означает это сообщение в логах OpenVpn
• Как отозвать клиентский сертификат OpenVPN?
• Создание инфраструктуры открытых ключей OpenVPN (easy-rsa)
• Основные параметры OpenVPN

OpenVPN

OpenVPN — свободная реализация технологии Виртуальной Частной Сети (VPN) с открытым исходным кодом для создания зашифрованных каналов типа точка-точка или сервер-клиенты между компьютерами. Она позволяет устанавливать соединения между компьютерами, находящимися за NAT-firewall, без необходимости изменения их настроек.

Варианты применения данной статьи

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

Хотим иметь доступ в рабочую локальную сеть из дома или в поездке

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

Исходные данные

Локальная сеть 1

192.168.1.0/24 192.168.1.1 Белый внешний IP (здесь будет сервер OpenVPN) Внутренний IP сервера OpenVPN - 192.168.1.100

Локальная сеть 2

192.168.0.0/24 192.168.0.1 Динамический IP (или даже серый - не важно для клиента OpenVPN) Внутренний IP клиента OpenVPN - 192.168.0.100. Клиент в данном случае будет являться шлюзом для устройств в своей подсети.

Настройка OpenVPN

Все действия проводятся с правами суперпользователя root.

sudo -i

Установка

И на сервере и на клиенте ставим один и тот же пакет.

apt-get install openvpn

Создание сервера

Создание ключей и сертификатов

Защита соединения в OpenVPN в данном случае строится на использовании сертификатов и ключей для сервера и для клиентов.

apt-get install easy-rsa

mkdir /etc/openvpn/easy-rsa cp -r /usr/share/easy-rsa /etc/openvpn/easy-rsa/2.0

Переходим в созданную директорию, где и займёмся генерацией ключей и сертификатов

cd /etc/openvpn/easy-rsa/2.0

Редактируем файл переменных

nano vars

Здесь можно заполнить например так:

# Почти в самом низу файла, заполняем информацию о сертификатах по умолчанию (ваши значения). export KEY_COUNTRY="RU" export KEY_PROVINCE="Amur Region" export KEY_CITY="Blagoveschensk" export KEY_ORG="Organization" export KEY_EMAIL="vash@email.tut" export KEY_OU="MyOrganizationalUnit" # PKCS11 я не использовал, поэтому оставил без изменений. Кто шарит нафига эта штука, допишите статью. export PKCS11_MODULE_PATH=changeme export PKCS11_PIN=1234 #Добавить export KEY_ALTNAMES="VPNsRUS"

копируем конфиг openssl

cp openssl-1.0.0.cnf openssl.cnf

source ./vars

Очищаем от старых сертификатов и ключей папку keys и создаем серийный и индексные файлы для новых ключей

./clean-all

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

./build-ca

Создаем ключ сервера

A challenge password []: Если вы решили ввести challenge password, то необходимо убедиться, что сохранили этот пароль в безопасном месте. Если вам понадобится когда-нибудь переустановить этот сертификат, то потребуется ввести этот пароль снова.

./build-key-server server

В конце соглашаемся с запросом на подпись и добавление сертификата в базу.

Можно сразу создать ключи для клиента, перейдя в соответствующую часть статьи. Я вынес в отдельный раздел, т.к. ключи клиента могут генерироваться не один раз, чтобы было понятнее с чего начать в том случае когда нужно добавить клиента

Создаем ключ Диффи-Хеллмана

./build-dh

Cоздаем ключ для tls-аутификации

openvpn --genkey --secret keys/ta.key

cp -r /etc/openvpn/easy-rsa/2.0/keys/ /etc/openvpn/

Создание файла конфигурации сервера

cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/ cd /etc/openvpn gunzip -d /etc/openvpn/server.conf.gz nano /etc/openvpn/server.conf

port 1194 # Протокол может быть UDP или TCP, я выбрал 1-й вариант. proto udp # Если вы выберите протокол TCP, здесь должно быть устройство tap. Однако, это вариант я не проверял, поэтому ищите информацию отдельно. FIXME dev tun # Указываем где искать ключи ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/server.crt key /etc/openvpn/keys/server.key # This file should be kept secret dh /etc/openvpn/keys/dh2048.pem # Для 12.04 dh1024.pem # Задаем IP и маску виртуальной сети. Произвольно, но если не уверены лучше делайте как показано здесь server 10.8.0.0 255.255.255.0 # Указыем, где хранятся файлы с настройками IP-адресов клиентов (создадим ниже) client-config-dir /etc/openvpn/ccd # Запоминать динамически выданные адреса для VPN-клиентов и при последующих подключениях назначать те же значения. ifconfig-pool-persist /etc/openvpn/ipp.txt # Указываем сети, в которые нужно идти через туннель (сеть-клиента). route 192.168.0.0 255.255.255.0 # Включаем TLS tls-server tls-auth /etc/openvpn/keys/ta.key 0 tls-timeout 120 auth SHA1 cipher AES-256-CBC # Если нужно, чтобы клиенты видели друг друга раскомментируйте ;client-to-client keepalive 10 120 # Сжатие трафика. Для отключения используйте на сервере и клиенте comp-lzo no comp-lzo # Максимум клиентов max-clients 10 user nobody group nogroup # Не перечитывать ключи, не закрывать и переоткрывать TUN\TAP устройство, после получения SIGUSR1 или ping-restart persist-key persist-tun status openvpn-status.log log /var/log/openvpn.log # Детальность логирования verb 3 # Защита от повторов (максимум 20 одинаковых сообщений подряд) mute 20 # Файл отозванных сертификатов. Разремить, когда такие сертификаты появятся. ;crl-verify /etc/openvpn/crl.pem

Создадим директорию для клиентских конфигов

mkdir /etc/openvpn/ccd

Можно запускать наш сервер OpenVPN

service openvpn restart

Смотрим список интерфейсов

ifconfig

Если среди прочих видим

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.8.0.1 P-t-P:10.8.0.2 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

значит VPN-сервер завелся. Если нет, то смотрим лог

tail -f /var/log/openvpn.log

Настройка маршрутизации на стороне сервера

Если сервер имеет «белый» IP то никакой маршрутизации на стороне сервера настраивать не нужно. Если сервер находится в локальной сети за NAT роутера то необходимо настроить маршрутизацию.
Для того, чтобы клиенты могли достучаться до сервера нужно пробросить порты с роутера на сервер. В разных моделях это делается по разному. Суть в том, чтобы стучась на внешний порт, например 12345 1) , клиенты попадали на порт OpenVPN-сервера 1194 (или другой, который мы задали для нашего сервера). Кроме того устройствам в локальной сети нужно сообщить, что для доступа к сети за OpenVPN-сервером нужно обращаться к нему. Но проще задать этот маршрут на роутере, который обслуживает локалку.

Создаем файл в каталоге ccd с тем же именем, что и ключ для клиента, т.е. /etc/openvpn/ccd/client

# Маршрут в сеть клиента. Требуется для доступа к сетевым устройствам в сети клиента. Если не требуется - не прописывайте. iroute 192.168.0.0 255.255.255.0 # Задаем маршрут для клиента, чтобы он видел сеть за OpenVPN-сервером. # Если маршрут требуется для всех подключаемых клиентов, достаточно эту # строку прописать в конфигурационный файл сервера server.conf push "route 192.168.1.0 255.255.255.0"

Включаем ipv4_forwarding

В /etc/sysctl.conf расскомментируем #net.ipv4.ip_forward=1 после чего

OpenVPN: создание полноценного openVPN gateway

OpenVPN — это система, позволяющая создавать шифрованные туннели между компьютерами по технологии VPN (Virtual Private Network, виртуальная частная сеть).

Основные плюсы такой модели:

• Просто: настройка занимает менее часа и не требует специальных знаний.
• Экономно: трафик сжимается lzo.
• Безопасно: весь трафик шифруется, а клиенты разделены между собой.
• Иногда по-другому просто никак. 🙂

Несмотря на эти пункты, нормальной статьи о настройке OpenVPN на Хабрахабре я не нашел. Чтож, попытаюсь исправить это своими силами.

Я специально стараюсь не углубляться в технические подробности, но и расписывать принципы сборки ядра и установки ПО в вашем дистрибутиве не буду — это выходит за пределы статьи.

За основу возьмем OpenVPN-2.0.9 и Gentoo Linux в качестве сервера и Linux либо Windows в качестве клиента.

Определися с желаемым.

Примем за основу то, что наш сервер распологается в удаленном датацентре. Т.е. попадать на него мы будет через интернет.

После установки шифрованного туннеля между клиентом и сервером, сервер будет NAT-ить все наши пакеты в Интернет. Также, сервер будет обслуживать DNS и являться firewall-ом для виртуальной локальной сети.

Внешний IP нашего сервера (того, который будет openVPN): 212.212.212.212
Внутренний IP сервера (видимый из туннеля): 10.10.0.1
Пул внутренних адресов openVPN: 10.10.0.2 — 10.10.0.128
Название нашей сети: vpnet
Имя сервера: vpsrv
Имя клиента: vpclient

Зачем нужен внешний IP, думаю, понятно. Внутренний IP нужен для соединения с сервером после поднятия туннеля. Пул адресов — это адреса, которые сервер выдает подключившимся клиентам.
Название сети — это имена конф. файлов и имя сервера в этих конф. файлах. Имена клиента и сервера = имена файлов ключей.

На сервере установлен Gentoo Linux 2008.0, обновленный до последних версий. Ядро — 2.6.29. Вся настройка будет выполняться по SSH.

Настройка ядра.

Замечу сразу, на этом этапе нужно быть крайне осторожным и внимательным. Если кто забыл.

Ядро должно содержать опции ниже на сервере. На клиенте нужны только TUN и ipv4.

В ядре нам понадобится следующий функционал, привожу выдержку из конфига:

CONFIG_NF_NAT=m
CONFIG_NF_NAT_PPTP=m
CONFIG_NETFILTER=y
CONFIG_TUN=m

Ну и разумеется поддержка ipv4, сетевой карты и прочего железа. Собираем и устанавливаем ядро. Можно воспользоваться genkernel. Перезагружаемся.

Настройка сервера.

Установка ПО.

Если 🙂 сервер вернулся из ребута, перейдем к установке ПО.

emerge —sync
emerge openvpn bind bind-tools iptables

Ждем, иногда долго. После установки переходим в /etc/init.d/ и выполняем:

ln -s openvpn openvpn.vpnet
rc-update add openvpn.vpnet default
rc-update add named default
rc-update iptables default
./iptables save

Создав symlink на самого себя, мы указали openvpn, что нужно использовать конфигурацию vpnet. В будущем запускаем его только так:

Сейчас запускать не нужно, ибо запускать пока нечего. 🙂
Помимо этого мы добавили iptables, named и openvpn в автозагрузку.

Создадим нужные каталоги и файлы:

mkdir /etc/openvpn/vpnet/
mkdir /etc/openvpn/vpnet/keys
touch /var/log/openvpn.log
touch /etc/openvpn/vpnet.conf

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

Перейдем в /usr/share/openvpn/easy-rsa/. Откроем файл vars и впишем настроим параметры:

export EASY_RSA=»/usr/share/openvpn/easy-rsa/» #Путь к easy-rsa.
export KEY_CONFIG=»$EASY_RSA/openssl.cnf» #Конфиг OpenSSL
export KEY_DIR=»/etc/openvpn/vpnet/keys» #Каталог, в котором мы будем держать ключи.
export KEY_SIZE=1024 # Размер ключа
export CA_EXPIRE=3650 # Срок действия CA
export KEY_EXPIRE=3650 # Срок действия ключа
export KEY_COUNTRY=»RU» # Двухбуквенный код страны
export KEY_PROVINCE=»XX» # Province, не актуально
export KEY_CITY=»Town» # Город
export KEY_ORG=»Companyname» # Компания
export KEY_EMAIL=»test@mail.ru» # Email

Естественно, значения (компания, путь к ключам и easy-rsa, email) нужно поменять на подходящие вам.

Имопртируем переменные: source ./vars

Теперь создадим ключи.

./clean-all # Убиваем старые ключи, если они были.
openvpn —genkey —secret ta.key # Ключ TLS-auth
./build-dh #Ключ Диффи-Хеллмана.
./pkitool —initca # Certificate Authority для сервера.
./pkitool —server vpsrv # Сертификат сервера.
./pkitool vpclient # Сертификат клиента.

И перенесем остатки в нужное место:

mv ./ta.key /etc/openvpn/vpnet/keys

Все, ключи готовы.

Настройка сервера.

Переходим в /etc/openvpn/, открываем vpnet.conf и пишем туда:

mode server
tls-server
proto tcp-server
dev tap
port 5555 # Порт
daemon
tls-auth /etc/openvpn/vpnet/keys/ta.key 0
ca /etc/openvpn/vpnet/keys/ca.crt
cert /etc/openvpn/vpnet/keys/vpsrv.crt
key /etc/openvpn/vpnet/keys/vpsrv.key
dh /etc/openvpn/vpnet/keys/dh1024.pem
ifconfig 10.10.0.1 255.255.255.0 # Внутренний IP сервера
ifconfig-pool 10.10.0.2 10.10.0.128 # Пул адресов.
push «redirect-gateway def1» # Перенаправлять default gateway на vpn-сервер. Если не нужно — закомментировать.
push «route-gateway 10.10.0.1»
duplicate-cn
verb 3
cipher DES-EDE3-CBC # Тип шифрования.
persist-key
log-append /var/log/openvpn.log # Лог-файл.
persist-tun
comp-lzo

Все опции, в принципе, понятны. Особо важные я отметил комментариями. Пути и названия, адреса — нужно подправить под себя.

Теперь сервер можно запустить командой /etc/init.d/openvpn.vpnet start
Если возникнут проблемы, подробности можно прочитать в log-файле.

NAT

Чтобы сервер выпускал наши пакеты во внешнюю сеть нам нужно настроить NAT. Это просто.

Готовим и запускаем iptables:

/etc/init.d/iptables save
/etc/init.d/iptables start

Включаем поддержку IP forwarding:

sysctl net.ipv4.ip_forward=1
echo «sysctl net.ipv4.ip_forward = 1» >> /etc/sysctl.conf

Добавляем правило firewall:

iptables -v -t nat -A POSTROUTING -o EXTERNAL_IF -s VPN_NET/24 -j SNAT —to-source SERVER_IP

EXTERNAL_IF, VPN_NET и SERVER_IP заменить на внешний интерфейс, сеть VPN и внешний (!) IP сервера соответственно.

Снова делаем /etc/init.d/iptables save, чтобы правило применялось при загрузке системы.

Все, можно работать.

Настройка клиента.

Устанавливаем ПО, создаем пути:

emerge openvpn
cd /etc/init.d/
ln -s openvpn openvpn.vpnet-client
rc-update add openvpn.vpnet-client default

mkdir /etc/openvpn/vpnet
mkdir /etc/openvpn/vpnet/client_keys
touch /etc/openvpn/vpnet-client.conf

Берем с сервера файлы:

ca.crt
vpclient.crt
vpclient.key
ta.key

и закидываем их в /etc/openvpn/vpnet/client_keys/ на клиенте.

Редактируем /etc/openvpn/vpnet-client.conf:

tls-client
proto tcp-client
remote 212.212.212.212
dev tap
port 5555
cd /etc/openvpn/vpnet
pull
tls-auth /etc/openvpn/vpnet/client_keys/ta.key 1
ca /etc/openvpn/vpnet/client_keys/ca.crt
cert /etc/openvpn/vpnet/client_keys/vpclient.crt
key /etc/openvpn/vpnet/client_keys/vpclient.key
cipher DES-EDE3-CBC
log-append /var/log/openvpn.log
comp-lzo

Опции шифрования и компрессии на клиенте и сервере должны совпадать.

Запускаем клиент. Автоматически установится соединение с сервером, создастся туннель, default gateway — сервер VPN. Если все сделано правильно, то можно ходить в интернет.

Настройка закончена.

Могу ответить на вопросы в комментариях.