Openvpn linux ���� ������������

Настройка и использование OpenVPN на Ubuntu

Для удобства настройки заходим под суперпользователем:

Подготовка Ubuntu

Обновляем установленные пакеты:

apt-get update && apt-get upgrade

Устанавливаем утилиту для синхронизации времени:

apt-get install chrony

Разрешаем ее автозапуск и стартуем сервис:

systemctl enable chrony —now

Установим правильную временную зону:

timedatectl set-timezone Europe/Moscow

* в данном примере московское время.

Если в нашей системе используется брандмауэр, открываем порт, на котором будет слушать OpenVPN:

iptables -I INPUT -p udp —dport 443 -j ACCEPT

* в данной инструкции предполагается, что мы настроим VPN-сервер на UDP-порту 443, однако, по-умолчанию, OpenVPN работает на порту 1194.

Для сохранения правила используем iptables-persistent:

apt-get install iptables-persistent

Установка, настройка и запуск VPN-сервера

Обязательные шаги для развертывания сервиса — установка программного обеспечения, генерация сертификатов, настройка OpenVPN. Рассмотрим эти процессы по шагам.

Установка OpenVPN

Устанавливаем необходимые пакеты следующей командой:

apt-get install openvpn easy-rsa

Создание сертификатов

Создаем каталог, в котором разместим готовые сертификаты для OpenVPN:

mkdir -p /etc/openvpn/keys

Создаем каталог, в который будем помещать все сгенерированные сертификаты:

Переходим в созданный нами каталог:

Скопируем в него шаблоны скриптов для формирования сертификатов:

cp -r /usr/share/easy-rsa/* .

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

и приведем его к следующему виду:

export KEY_COUNTRY=»RU»
export KEY_PROVINCE=»Sankt-Petersburg»
export KEY_CITY=»Sankt-Petersburg»
export KEY_ORG=»DMOSK COMPANY»
export KEY_EMAIL=»master@dmosk.ru»
export KEY_CN=»DMOSK»
export KEY_OU=»DMOSK»
export KEY_NAME=»name-openvpn-server.dmosk.ru»
export KEY_ALTNAMES=»name-openvpn-server»

* где KEY_CN и KEY_OU: рабочие подразделения (например, можно указать название отдела); KEY_NAME: адрес, по которому будет выполняться подключение (можно указать полное наименование сервера); KEY_ALTNAMES — альтернативный адрес.

Запускаем отредактированный файл на исполнение:

Почистим каталог от старых сертификатов:

Для генерирования сертификатов необходим конфигурационный файл openssl.cnf — по умолчанию, он отсутствует, но есть файл openssl-1.0.0.cnf. Создаем на него симлинк:

ln -s openssl-1.0.0.cnf openssl.cnf

* в каталоге /etc/openvpn/easy-rsa может быть несколько разных версий конфигурационного файла openssl-x.x.x.cnf. Чтобы узнать точное имя файла, вводим команду ls /etc/openvpn/easy-rsa.

Следующие действия будут записеть от версии OpenVPN. Более новая позволяет создавать сертификаты на основе Easy RSA 3, старая работает на базе 2-й версии. Понять, какой вариант наш можно посмотрев на содержимое каталога easy-rsa:

Либо мы увидим в нем утилиту easyrsa (новая версия), либо набор утилит, начинающихся на build.

Рассмотрим процесс формирования сертификата с использованием как RSA3, так и RSA2.

а) Если используется новая версия (утилита easyrsa)

1. Инициализируем PKI:

2. Создаем корневой сертификат:

* после вводим дважды пароль.

На запрос «Common Name» можно просто нажать Enter:

Common Name (eg: your user, host, or server name) [Easy-RSA CA]:

3. Создаем запрос на сертификат для сервера:

./easyrsa gen-req server nopass

* nopass можно упустить, если хотим повысить безопасность с помощью пароля на сертификат.

На запрос «Common Name» можно просто нажать Enter:

Common Name (eg: your user, host, or server name) [server]:

4. Генерируем сам сертификат:

./easyrsa sign-req server server

После ввода команды подтверждаем правильность данных, введя yes:

Type the word ‘yes’ to continue, or any other input to abort.
Confirm request details: yes

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

Enter pass phrase for /etc/openvpn/easy-rsa/pki/private/ca.key:

Готово. Ключ для сервера создан.

5. Формируем ключ Диффи-Хеллмана:

Создаем ta-ключ командой:

openvpn —genkey —secret pki/ta.key

Скопируем созданные ключи в рабочий каталог:

cp pki/ca.crt /etc/openvpn/keys/

cp pki/issued/server.crt /etc/openvpn/keys/

cp pki/private/server.key /etc/openvpn/keys/

cp pki/dh.pem /etc/openvpn/keys/

cp pki/ta.key /etc/openvpn/keys/

б) Если используется старая версия (утилиты build-)

1. Генерируем последовательность центра сертификации:

На все запросы нажимаем Enter.

2. Запускаем build-dh.bat (сертификат с использованием алгоритма Диффи-Хеллмана):

* команда может выполняться долго — это нормально.

3. Генерируем сертификат для сервера:

* где server — имя сертификата; на все запросы нажимаем Enter.

В конце подтверждаем два раза корректность информации вводом y:

Certificate is to be certified until Aug 8 21:12:24 2031 GMT (3650 days)
Sign the certificate? [y/n]: y

1 out of 1 certificate requests certified, commit? [y/n] y
Write out database with 1 new entries
Data Base Updated

Создаем ta-ключ командой:

openvpn —genkey —secret keys/ta.key

Скопируем созданные ключи в рабочий каталог:

cp keys/ca.crt /etc/openvpn/keys/

cp keys/server. /etc/openvpn/keys/

cp keys/dh2048.pem /etc/openvpn/keys/dh.pem

cp keys/ta.key /etc/openvpn/keys/

Настройка OpenVPN-сервера

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

И вставляем в него следующее:

local 192.168.0.15
port 443
proto udp
dev tun
ca keys/ca.crt
cert keys/server.crt
key keys/server.key
dh keys/dh.pem
tls-auth keys/ta.key 0
server 172.16.10.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
max-clients 32
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log-append /var/log/openvpn/openvpn.log
verb 4
mute 20
daemon
mode server
tls-server
comp-lzo

• local — IP-адрес, на котором будет обрабатывать запросы OpenVPN;
• port — сетевой порт (443 позволит избежать проблем при использовании Интернета в общественных местах, но может быть любым из свободных. Порт 1194 является стандартным для OpenVPN).
• proto — используемый транспортный протокол.
• dev — виртуальный сетевой адаптер, который будет создан для работы OpenVPN.
• ca — путь до сертификата корневого центра сертификации.
• cert — путь до открытого сертификата сервера.
• key — путь до закрытого сертификата сервера.
• dh — путь до ключа Диффи — Хеллмана.
• tls-auth — путь до tls-ключа.
• server — задаем IP-адрес сервера в сети VPN.
• ifconfig-pool-persist — путь к файлу для хранения клиентских IP-адресов.
• keepalive X Y — каждые X секунд отправляется ping-запрос на удаленный узел. Если за Y секунд не получено ответа — перезапускать туннель.
• max-clients — максимум одновременных подключений.
• persist-key — не перезагружать ключи при повторной загрузки из-за разрыва соединения.
• persist-tun — не изменять устройства tun/tap при перезапуске сервера.
• status — путь до журнала статусов.
• log-append — путь до файла лога с дополнительным выводом информации.
• verb — уровень логирования событий. От 0 до 9.
• mute — ограничение количества подряд отправляемых в лог событий.
• daemon — работа в режиме демона.
• mode — в каком режиме работает openvpn (сервер или клиент).
• tls-server — указывает, что данный сервер работает с использованием TLS.
• comp-lzo — использовать сжатие.

Создадим каталог для логов:

Разрешаем автоматический старт сервиса vpn и запускаем его:

systemctl enable openvpn@server —now

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

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

На сервере

Создадим каталог, куда поместим сертификаты для обмена:

* сертификаты будут скопированы в каталог /tmp для удобства их переноса на клиентский компьютер.

Переходим в каталог easy-rsa:

Создаем системные переменные, настроенные ранее в файле vars:

Как в случае формирования сертификата для сервера, наши следующие шаги зависят от версии RSA.

а) Для новой версии (easyrsa)

Создаем сертификат для клиента:

./easyrsa build-client-full client1 nopass

Вводим пароль, который указывали при создании корневого сертификата:

Enter pass phrase for /etc/openvpn/easy-rsa/pki/private/ca.key:

Скопируем ключи во временную директорию:

cp pki/issued/client1.crt pki/private/client1.key pki/ca.crt pki/ta.key /tmp/keys/

Разрешим доступ на чтения всем пользователям:

chmod -R a+r /tmp/keys

б) Для старой версии (build)

Создаем сертификат для клиента:

* на все запросы отвечаем Enter.

В конце отвечаем на два вопроса утвердительно:

Certificate is to be certified until Aug 8 21:49:30 2031 GMT (3650 days)
Sign the certificate? [y/n]: y

1 out of 1 certificate requests certified, commit? [y/n] y
Write out database with 1 new entries
Data Base Updated

Скопируем ключи во временную директорию:

cp keys/client1. keys/ca.crt keys/ta.key /tmp/keys/

Разрешим доступ на чтения всем пользователям:

chmod -R a+r /tmp/keys

На клиенте

Клиент OpenVPN может быть установлен на Windows, Linux, Android и Mac OS. Мы рассмотрим пример работы с Windows.

Заходим на официальную страницу загрузки openvpn и скачиваем клиента для Windows:

Запускаем скачанный файл и устанавливаем программу, нажимая «Далее».

Переходим в папку C:\Program Files\OpenVPN\config. И копируем в нее файлы ca.crt, client1.crt, client1.key, ta.key из каталога /tmp/keys на сервере, например, при помощи программы WinSCP.

После переноса файлов, не забываем удалить ключи из временного каталога на сервере:

Теперь возвращаемся к компьютеру с Windows, открываем блокнот от имени администратора и вставляем следующие строки:

client
resolv-retry infinite
nobind
remote 192.168.0.15 443
proto udp
dev tun
comp-lzo
ca ca.crt
cert client1.crt
key client1.key
tls-client
tls-auth ta.key 1
float
keepalive 10 120
persist-key
persist-tun
verb 0

* где 192.168.0.15 443 — IP-адрес OpenVPN-сервера и порт, на котором он принимает запросы.
* подробнее про настройку клиента OpenVPN.

Сохраняем файл с именем config.ovpn в папке C:\Program Files\OpenVPN\config.

Запускаем с рабочего стола программу «OpenVPN GUI» от имени администратора (это важно).

Нажимаем правой кнопкой по появившемуся в трее значку и выбираем «Подключиться»:

Произойдет подключение и значок поменяет цвет с серого/желтого на зеленый.

Доступ к локальной сети

Для настройки доступа к локальной сети, воспользуйтесь инструкцией Настройка доступа к локальной сети клиентам OpenVPN в Linux.

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

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

Источник

Openvpn linux ���� ������������

OpenVPN 3 Linux client

This is the next generation OpenVPN client for Linux. This project is very different from the more classic OpenVPN 2.x versions. First, this is currently only a pure client-only implementation.

The biggest change from the classic OpenVPN 2.x generation is that it does not need to be started by a root or otherwise privileged account any more. By default, all users on the system will have access to start and manage their own VPN tunnels. It will also support configuring DNS out-of-the-box

The same OpenVPN 3 Core library which is used in the OpenVPN Connect clients is also used in this OpenVPN 3 client. This implementation does not support all options OpenVPN 2.x does, but if you have a functional configuration with OpenVPN Connect (typically on Android or iOS devices) it will work with this client. In general OpenVPN 3 supports routed TUN configurations; TAP and bridged setups are unsupported and will not work.

On a more technical level, this client builds on D-Bus and does also ship with a Python 3 module which can also be used to implement your own OpenVPN client front-end. Any language which supports D-Bus bindings can also be used.

See the instructions on https://community.openvpn.net/openvpn/wiki/OpenVPN3Linux how to install pre-built OpenVPN 3 Linux packages on Debian, Ubuntu, Fedora, Red Hat Enterprise Linux, CentOS and Scientific Linux.

Quick start: Using the openvpn2 front-end

The openvpn2 front-end is a command line interface which tries to be similar to the old and classic openvpn-2.x generation. It supports most of the options used by clients and will ignore unsupported options which does not impact the ability to get a connection running.

Starting a VPN session:

If the provided configuration contains the —daemon option, it will provide the session path related to this session and return to the command line again. From this point of, this session needs to be managed via the openvpn3 front-end.

For more information, see the openvpn2(1) and openvpn3-session-manage(1) man-pages.

Using the openvpn3 front-end

The openvpn3 program is the main and preferred command line user interface.

Starting a VPN session: Single-shot approach

This will import the configuration and start a new session directly

Starting a VPN session: Multi-step approach

Import the configuration file:

This will return a configuration path. This path is a unique reference to this specific configuration profile.

(Optional) Display all imported configuration profiles

Start a new VPN session

Listing established sessions

Getting tunnel statistics For already running tunnels, it is possible to extract live statistics of each VPN session individually

Managing VPN sessions For running VPN sessions, you manage them using the openvpn3 session-manage command, again by providing the session path. For example, to restart a connection:

Other actions can be —pause , —resume , and —disconnect .

All the openvpn3 operations are also described via the —help option.

Auto-loading/starting VPN tunnels

The openvpn3-autoload utility is used to pre-load configuration profiles and possibly also start tunnels. This requires a little bit of preparations. When starting it via systemctl start openvpn3-autoload it will look for configuration profiles found inside /etc/openvpn3/autoload which has a corresponding .autoload configuration present in addition. This tells both the Configuration Manager and Session Manager how to process the VPN configuration profile.

For more details, look at the openvpn3-autoload(8) man-page.

Introduction to the OpenVPN 3 Linux architecture

To interact with the various OpenVPN 3 services running in the background, three different utilities are provided.

This is an interface which tries to look and behave a bit more like the classic OpenVPN 2.x versions. It does only allow options which are supported by the OpenVPN 3 Core Library, plus there are a handful options which are ignored as it is possible to establish connections without those options active.

When running openvpn2 with —daemon it will return a D-Bus path to the VPN session. This path can be used by the openvpn3 utility to further manage this session.

This is a brand new command line interface which does not look like OpenVPN 2.x at all. It can be used to start, stop, pause, resume tunnels and retrieve tunnel statistics. It can also be used as import, retrieve and manage configurations stored in the configuration manager, as well as handling access control lists for VPN configuration profiles and running VPN sessions.

This will mostly only work when run as root . This is used to adjust some settings or retrieve information from some of the backend services.

The OpenVPN 3 Linux project is built on D-Bus. This means it is possible to build your own tools instead of using these tools, all which is required is to access the various OpenVPN 3 D-Bus services. In reality all the front-ends mentioned are just specialized D-Bus clients for the OpenVPN 3 D-Bus services. This resolves the challenges with proper privilege separation between users and the various operations running a VPN tunnel requires.

As mentioned, there are various D-Bus services running behind the scenes. There are six services which is good to beware of. All of these services will normally start automatically. And when they are idle for a while with no data to maintain, they will shut-down automatically.

This is the configuration manager. All configuration profiles will be uploaded and managed by this service before a tunnel is started. This service also ensures only users granted access to VPN various profiles has the proper access to them. By default this process is started as the openvpn user.

This manages all VPN tunnels which are about to start or has started. It takes care of communicating with the VPN backend processes and ensures only users with the right access levels can manage the various tunnels. This service is started as the openvpn user.

This is a helper service and is only used by the session manager. The only task this service has is to start a new VPN client backend processes (the VPN tunnel instances). By default this is also started as the openvpn user.

This is to be started by the openvpn3-service-backendstart only. One such process is started per VPN client. Once it has started, it registers itself with the session manager and the session manager provides it with the needed details so it can retrieve the proper configuration profile from the configuration manager. This service will depend on the openvpn3-service-netcfg to manage the tun interface and related configuration. This service is also running as the openvpn users by default.

This provides a service similar to a VPN API on other platforms. It is responsible for creating, managing and destroying of TUN interfaces, configure them as well as handle the DNS configuration provided by the VPN server. This is the most privileged process which only have a few capabilities enabled (such as CAP_NET_ADMIN and possibly CAP_DAC_OVERRIDE or CAP_NET_RAW ). With these capabilities, the service can run as the openvpn user.

Currently DNS configuration is done by manipulating /etc/resolv.conf directly. Support for systemd-resolved has been added, and will require enabling this feature by running the following command as root:

Next time the openvpn3-service-netcfg service restarts, systemd-resolved support will be used instead. Note, this requires at least systemd v243 or newer (or a distribution which has back-ported a newer version). This works now with CentOS 8, Fedora 31 and newer, Red Hat Enterprise Linux 8 or Ubuntu 20.04.

This service will listen for log events happening from all the various OpenVPN 3 D-Bus services. It supports writing these events to the console (stdout), files or redirect to syslog. This is also automatically started when needed, if it isn’t already running.

More information can be found in the openvpn3-linux(7) man page and OpenVPN 3 D-Bus overview.

How to build openvpn3-linux locally

The primary Linux distributions targeted and regularly tested are:

• CentOS 7 and 8
• Debian 9 and 10
• Fedora 31, 32 and Rawhide
• Red Hat Enterprise Linux (RHEL) 7 and 8
• Scientific Linux 7
• Ubuntu 18.04 and 20.04

This list is not an exclusive list, and it will most likely work on all other distributions with recent enough dependencies.

The following dependencies are needed:

A C++ compiler capable of at least -std=c++11 . The ./configure script will try to detect if -std=c++14 is available and switch to that if possible, otherwise it will test for -std=c++11 . If support for neither is found, it will fail. RHEL-7 users may prefer to use -std=c++1y .

GNU autoconf 2.69 or newer

GNU autoconf-archive (2017.03.21 has been tested)

GNU automake 1.11 or newer

OpenSSL 1.0.2 or newer (recommended, not needed if building with mbed TLS)

mbed TLS 2.13 or newer (not needed if building with OpenSSL)

GLib2 2.50 or newer

http://www.gtk.org This dependency is due to the GDBus library, which is the D-Bus implementation being used.

jsoncpp 0.10.5 or newer

libcap-ng 0.7.5 or newer

liblz4 1.7.3 or newer

libuuid 2.23.2 or newer

polkit 0.105 or newer

Only needed when using the systemd-resolved integration. On Ubuntu this package is called policykit-1.

(optional) libnl3 3.2.29 or newer

Only needed when building with DCO support

(optional) protobuf 2.4.0 or newer

Only needed when building with DCO support

(optional) tinyxml2 2.1.0 or newer

This is only needed if you want to include the AWS-VPC integration.

(optional) Python 3.5 or newer

If Python 3.5 or newer is found, the openvpn2, openvpn3-autoload utilities and the openvpn3 Python module will be built and installed.

(optional) Python docutils

http://docutils.sourceforge.net/ This is needed for the rst2man utility, used to generate the man pages.

(optional) Python Jinja2 template engine

https://palletsprojects.com/p/jinja/ Required when enabling the bash-completion support; used to generate the bash-completion script for openvpn2.

For Linux distributions running with SELinux in enforced mode (like Red Hat Enterprise Linux and Fedora), this is required.

In addition, this git repository will pull in these git submodules:

https://github.com/OpenVPN/openvpn3 This is the OpenVPN 3 Core library. This is where the core VPN implementation is done.

https://github.com/chriskohlhoff/asio The OpenVPN 3 Core library depends on some bleeding edge features in ASIO, so we need to do a build against the ASIO git repository.

This openvpn3-linux git repository will pull in the appropriate ASIO library as a git submodule.

First install the package dependencies needed to run the build.

Building with OpenSSL (recommended):

For newer Debian and Ubuntu releases shipping with OpenSSL 1.1 or newer:

For Ubuntu 16.04 LTS, which ships with OpenSSL 1.0:

Building with mbed TLS (alternative):

Additional Debian 9 and Ubuntu 16.04 Python requirements

The openvpn3 Python module requires the IntFlag extension in the `enum module. This was introduced in the Python 3.6 distribution. OpenVPN 3 Linux implements a workaround for this in distributions which can install the aenum« module via «pip3«

Generic build requirements:

Dependencies to build with DCO support:

Building with OpenSSL (recommended):

Building with mbed TLS (alternative):

Generic build requirements:

Dependencies to build with DCO support:

Red Hat Enterprise Linux / CentOS / Scientific Linux

First install the epel-release repository if that is not yet installed.

NOTES: RHEL 8 / CentOS 8 — differences from RHEL 7 / CentOS 7

For Red Hat Enterprise Linux 8 and CentOS 8, use the package lists used in Fedora. In addition the CodeReady (RHEL) / PowerTools (CentOS) repository needs to be enabled when building with Data Channel Offload (DCO) support.

For CentOS 8 run this command:

(Optional) Installing tinyxml2 and tinyxml2-devel If you want to use —enable-addons-aws , you will need the tinyxml2 development packages. If you cannot find these packages in your normal repositories, they are also available in the openvpn3 Fedora Copr repository. These packages are also found in the CodeReady (RHEL) and PowerTools (CentOS) repositories.

Building with OpenSSL (recommended)

Building with mbed TLS (alternative):

Generic build requirements (only RHEL 7):

For RHEL 8/CentOS 8 see the Fedora package lists, including dependencies for DCO support.

Preparations building from git

• Clone this git repository: git clone git://github.com/OpenVPN/openvpn3-linux
• Enter the openvpn3-linux directory: cd openvpn3-linux
• Run: ./bootstrap.sh

Completing these steps will provide you with a ./configure script.

Adding the openvpn user and group accounts

The default configuration for the services assumes a service account openvpn to be present. If it does not exist you should add one, e.g. by:

Building OpenVPN 3 Linux client

If you already have a ./configure script or have retrieved an openvpn3-linux-*.tar.xz tarball generated by make dist , the following steps will build the client.

• Run: ./configure —prefix=/usr —sysconfdir=/etc —localstatedir=/var
• Run: make
• Run: make install

By default, OpenVPN 3 Linux is built using the OpenSSL library. If you want to compile against mbed TLS, add the —with-crypto-library=mbedtls argument to ./configure .

You might need to also reload D-Bus configuration to make D-Bus aware of the newly installed service. On most system this happens automatically but occasionally a manual operation is needed:

The —prefix can be changed, but beware that you will then need to add —datarootdir=/usr/share instead. This is related to the D-Bus auto-start feature. The needed D-Bus service profiles will otherwise be installed in a directory the D-Bus message service does not know of. The same is for the —sysconfdir path. It will install a needed OpenVPN 3 D-Bus policy into /etc/dbus-1/system.d/ .

With everything built and installed, it should be possible to run both the openvpn2 and openvpn3 command line tools — even as an unprivileged user.

Enable AWS-VPC integration

If you want to enable the AWS-VPC integration, add —enable-addons-aws to the ./configure command.

TECH PREVIEW: Kernel based Data Channel Offload (DCO) support

BEWARE — UNDER HEAVY DEVELOPMENT

The Data Channel Offload support moves the processing of the OpenVPN data channel operations from the client process to the kernel, via the ovpn-dco kernel module. This means the encryption and decryption of the tunnelled network traffic is kept entirely in kernel space instead of being send back and forth between the kernel and the OpenVPN client process. This has the potential to improve the overall VPN throughput. This module must be installed before OpenVPN 3 Linux can make use of this feature. This is shipped in the OpenVPN 3 Linux package repositories or can be built from the source code.

The ovpn-dco kernel module currently only support Linux kernel 5.4 and newer. Currently supported distributions with DCO support:

• CentOS 8
• Fedora release 33, 34 and Rawhide
• Red Hat Enterprise Linux 8
• Ubuntu 20.04 and newer

The ovpn-dco kernel module is currently not functional on RHEL/CentOS due to the kernel version is older than 4.18. OpenVPN 3 Linux will build with the —enable-dco feature but requires a functional ovpn-dco kernel module to be fully functional.

To build OpenVPN 3 Linux with this support, add —enable-dco to the ./configure command.

Auto-completion helper for bash/zsh

If you want to also install the bash-completion scripts for the openvpn2 and openvpn3 commands, add —enable-bash-completion to the ./configure command.

The openvpn3-service-netcfg service depends on being able to pass a file descriptor to the tun device it has created on behalf of the openvpn3-service-client service (where each of these processes represents a single VPN session). This is done via D-Bus. But on systems with SELinux, the D-Bus daemon is not allowed to pass file descriptors related to /dev/net/tun .

The openvpn3-linux project ships atwo SELinux policy modules, which will be installed in /usr/share/selinux/packages if the ./configure script can locate the SELinux policy development files. On RHEL/Fedora the development files are located under /usr/share/selinux/devel and provided by the selinux-policy-devel package.

If the selinux-policy-devel package has been detected by ./configure , running make install will install the openvpn3.pp policy package, typically in /usr/share/selinux/packages .

The openvpn3.pp policy package adds a SELinux boolean, dbus_access_tuntap_device , which grants processes, such as dbus-daemon running under the system_dbusd_t security context access to files labelled as tun_tap_device_t ; which matches the label of /dev/net/tun .

To install and activate this SELinux security module, as root run:

On Red Hat Enterprise Linux and Fedora, the openvpn3-service-netcfg will stop running and the OpenVPN 3 Linux client will be non-functional if this has not been done. The source code of the policy package can be found in src/selinux/openvpn3.te .

For users installing the pre-built RPM binaries, this is handled by the RPM scriptlet during package install.

The second policy module, openvpn3_service.pp , will confine both the openvpn3-service-netcfg and openvpn3-service-client processes into their own SELinux process contexts ( openvpn3_netcfg_t and openvpn3_client_t ). See the src/selinux/openvpn3_service.te source for more details.

For the RPM builds, both SELinux policies are provided in the openvpn3-selinux package.

Logging happens via openvpn3-service-logger . If not started manually, it will automatically be started by the backend processes needing it. The default configuration sends log data to syslog. This service can be started manually and must run as the openvpn user. If being started as root , it will automatically switch to the openvpn user. See openvpn3-service-logger —help for more details. Unless —syslog or —log-file is provided, it will log to the console (stdout).

This log service can also be managed (even though fairly few options to tweak) via openvpn3-admin log-service . The most important feature here is probably to modify the log level.

For more information about logging, see the openvpn3-service-logger(8) , man page, D-Bus Logging and net.openvpn.v3.log D-Bus service documentation.

Ensure you have done a build using —enable-debug-options when running ./configure . This ensures the most crucial debug options are available.

Most of the backend services ( openvpn3-service-logger , openvpn3-service-configmgr , openvpn3-service-sessionmgr and openvpn3-service-backendstart ) can be run in a console. All with the exception of openvpn3-service-netcfg should be started as the openvpn user. openvpn3-service-netcfg must be started as root but will as soon as possible drop its privileges to the openvpn user as well, after it has acquired the CAP_NET_ADMIN capability and possibly a few others. See their corresponding —help screen for details. Most of these programs can be forced to provide more log data by setting —log-level . And they can all provide logging to the console.

For more information about debugging, please see docs/debugging.md

To debug what is happening, busctl , gdbus and dbus-send utilities are useful. The service destinations these tools need to move forward are:

• net.openvpn.v3.configuration (Configuration manager)
• net.openvpn.v3.sessions (Session manager)

Both of these services allows introspection.

There exists also a net.openvpn.v3.backends service, but that is restricted to be accessible only by the openvpn user — and even that users access is locked-down by default and introspection is not possible without modifying the D-Bus policy.

Looking at the D-Bus log messages can be also helpful, for example with:

For more information about debugging, please see docs/debugging.md

Code contributions Code contributions are most welcome. Please submit patches for review to the openvpn-devel@lists.sourceforge.net mailing list. All patches must carry a Signed-off-by line and must be reviewed publicly before acceptance. Pull requests are not acceptable unless it is for early reviews and patch discussions. Final patches MUST go to the mailing list.

Testing This code is quite new, but has been used a lot in various setups. Please reach out on FreeNode @ #openvpn for help and discussing issues you encounter, or subscribe to and ask on the openvpn-users@lists.sourceforge.net mailing list.

Packagers We are beginning to targeting packaging in Linux distributions. The Fedora Copr repository is one which is currently available. We are looking for people willing to package this in other Linux distributions as well.

The OpenVPN 3 Linux project is BETA quality. It is fully functional and so far we have few reports about instabilities.

The OpenVPN 3 Core library this project builds on is used by the OpenVPN Connect and Private Tunnel clients in addition to the OpenVPN for Android client (need to explicitly enable the OpenVPN 3 backend), so the pure VPN tunnel implementation should be good to use.

Источник