Установка и конфигурирование сервера OpenVPN на CentOS
Если OVPN Настроен через tcp, то explicit-exit-notify 1 должно быть закомментировано
Установка и конфигурирование сервера OpenVPN на CentOS
Нередко начинающие инженеры сталкиваются с необходимостью развернуть VPN сервер, чтобы поднять уровень защиты сети, чтобы организовать выделенный канал связи, либо же резервный. Причины развёртки данного вида серверов можно описывать долго, но перейдём к сути. Данная статья поможет разобраться в том, как развернуть сервер VPN, а также как его сконфигурировать.
VPN – это виртуальная частная сеть, которая позволяет производить безопасный обмен сообщениями через интернет без выделения линии провайдером. В рамках IP-телефонии применяется, например для регистрации телефонов как клиентов VPN сервера, что позволяет зашифровать весь трафик, а так же защитить канал от прослушивания, как следствие — закрыть вопрос безопасности, остаточные варианты зависят только от Вашей фантазии и инженерного навыка.
Установка OpenVPN
Итак, приступим. Следует сообщить, что развёртка сервера производилась на CentOS 6.9. Для начала необходимо попасть в консоль по telnet или ssh, войти под root, затем набрать в консоли следующую команду:
# yum install –y openvpn
В процессе выполнения должны быть установлены все недостающие модули, yum сделает это за Вас, а благодаря ключу “-y” нам не нужно будет нажимать “y” каждый раз, когда будет необходимо будет доустановить недостающий пакет для работы OpenVPN.
Если Вы не можете установить серверную часть приложения через менеджер пакетов yum, то нужно подключить репозиторий. Для этого в консоли необходимо выполнить следующее:
# wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm — скачиваем необходимый пакет.
# rpm -Uvh epel-release-6*.rpm – устанавливаем.
# yum repolist | grep epel – проверяем установку.
Если всё прошло хорошо, то результат будет следующим:
Отлично, далее нам необходимо создать файл конфигурации.
В конце статьи находятся файлы конфигурации сервера, файл с переменными для генерации сертификатов.
Создавать мы его будем следующим образом: скопируем его из директории с примерами конфигов для OpenVPN сервера в действующую папку. Для этого выполним в консоли:
# cp /usr/share/doc/openvpn-2.4.6/sample/sample-config-files/server.conf /etc/openvpn/
Перед тем, как скопировать строку копирования файла в директорию OpenVPN, необходимо убедиться в валидности версии в пути к файлу, т.к. приложение постоянно обновляется, и если Вы просто скопируете строку, приведённую мною, команда может не сработать. Поэтому копировать рекомендуется до “cp /usr/share/doc/openvpn-“, а далее пользоваться клавишей TAB, благодаря которой будет дописана оставшаяся часть названия папки с примерами конфигурации. После чего можете скопировать и вставить недостающую часть команды.
Далее нам необходимо открыть и отредактировать конфигурационный файл сервера, который мы только что переместили.
Чтобы открыть конфигурационный файл сервера, воспользуемся nano:
# nano /etc/openvpn/server.conf
После выполнения увидим следующее:
Итак, давайте разбираться в конфигурационном файле. Сразу буду акцентировать внимание на необходимом.
# Which local IP address should OpenVPN
# listen on? (optional)
;local a.b.c.d
Какой локальный адрес будет слушать сервер OpenVPN?
Раскомментируем строчку local, вместо a.b.c.d пишем локальный IP, на котором будет работать наш сервер:
# Which local IP address should OpenVPN
# listen on? (optional)
local 192.168.32.95
чтобы наверняка определить, на каком адресе должен работать сервер, введите команду в консоли # ifconfig. По умолчанию весь трафик в CentOS идёт через интерфейс eth0, следовательно, ip, назначенный eth0, и нужно указывать в директиве local.
Переходим к следующему блоку настроек:
# Which TCP/UDP port should OpenVPN listen on?
# If you want to run multiple OpenVPN instances
# on the same machine, use a different port
# number for each one. You will need to
# open up this port on your firewall.
port 1194
Какой порт TCP/UDP должен прослушивать OpenVPN? Если Вы хотите запустить несколько процессов OpenVPN на одной машине, используйте для каждого свой порт. Вы должны будете открыть все предполагаемые к использованию порты в файерволе. Т.к. на нашей машине будет развёрнут один процесс OpenVPN серверного приложения, то и порт мы оставим по умолчанию – 1194.
Идём далее:
# TCP or UDP server?
;proto tcp
proto udp
На каком протоколе будет работать сервер?
Рекомендуется к выбору протокол TCP, т.к. он используется чаще всего, а так же сервис VPN чаще всего работает именно на нём. Например, сетевое оборудование от MirkroTik работает исключительно на протоколе TCP. Следовательно, если Вы сконфигурируете сервер на протокол UDP, то на MikroTik это попросту не будет работать.
Выбираем протокол TCP.
# TCP or UDP server?
proto tcp
;proto udp
Переходим к следующему блоку настроек:
# «dev tun» will create a routed IP tunnel,
# «dev tap» will create an ethernet tunnel.
# Use «dev tap0» if you are ethernet bridging
# and have precreated a tap0 virtual interface
# and bridged it with your ethernet interface.
# If you want to control access policies
# over the VPN, you must create firewall
# rules for the the TUN/TAP interface.
# On non-Windows systems, you can give
# an explicit unit number, such as tun0.
# On Windows, use «dev-node» for this.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
;dev tap
dev tun
«dev tun» используется при создании маршрутизируемых IP туннелей.
«dev tap» используется для создания подключений типа сетевой мост/Bridge. Если Вы хотите контролировать доступ по VPN, необходимо сконфигурировать файервол для интерфейса TUN / TAP. В операционных системах, отличных от семейства Windows, Вы можете присвоить юниту уникальный номер, например, tun0/tun1/tun2 (если tun будет в единственном экземпляре, то присваивать ему уникальный id не имеет необходимости), Для этого на Windows машинах используйте «dev-node». Для большинства систем отключайте или отдельно конфигурируйте файервол.
Существенным различием между TUN и TAP является уровень OSI, на котором они функционируют, что в корне меняет политику применения того или иного интерфейса.
TAP (Layer 2) – название TAP происходит от to TAP into. Суть TAP заключается в том, что он максимально схож с физическим сетевым интерфейсом, имеет MAC адрес, что позволяет принимать и отправлять ARP запросы, также может быть включен в Bridge как полноценный сетевой интерфейс, т.к. он имеет полную поддержку Ethernet. Работает на канальном уровне — OSI Layer 2.
TUN (Layer 3) – Название TUN от TUNnel. Не имеет поддержки Ethernet, потому имеет возможность приёма и отправки только IP пакетов. Следовательно, он не имеет MAC адреса, также его нельзя добавить в Bridge. В этом и заключается особенность интерфейса типа tun – он легковесный, как следствие – быстрый за счёт отсутствия дополнительной инкапсуляции, что идеально подходит для создания VPN сетей.
Таким образом, нам идеально подойдёт интерфейс типа TUN, он уже выбран по умолчанию, поэтому идём дальше. Соответственно, все последующие настройки будут проводиться с учётом особенностей данного интерфейса. Единственное, что стоит добавить – это индекс интерфейса. Я добавлю нулевой индекс.
# «dev tun» will create a routed IP tunnel,
# «dev tap» will create an ethernet tunnel.
# Use «dev tap0» if you are ethernet bridging
# and have precreated a tap0 virtual interface
# and bridged it with your ethernet interface.
# If you want to control access policies
# over the VPN, you must create firewall
# rules for the the TUN/TAP interface.
# On non-Windows systems, you can give
# an explicit unit number, such as tun0.
# On Windows, use «dev-node» for this.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
;dev tap
dev tun0
Следующим этапом будет настройка путей к корневому сертификату сервера, серверному ключу и сертификату центра сертификации:
# SSL/TLS root certificate (ca), certificate
# (cert), and private key (key). Each client
# and the server must have their own cert and
# key file. The server and all clients will
# use the same ca file.
#
# See the «easy-rsa» directory for a series
# of scripts for generating RSA certificates
# and private keys. Remember to use
# a unique Common Name for the server
# and each of the client certificates.
#
# Any X509 key management system can be used.
# OpenVPN can also use a PKCS #12 formatted key file
# (see «pkcs12» directive in man page).
ca ca.crt
cert server.crt
key server.key # This file should be kept secret
Прописываем пути к ca.crt – сертификат центра сертификации, server.crt – главный сертификат сервера, server.key – ключ сервера.
# SSL/TLS root certificate (ca), certificate
# (cert), and private key (key). Each client
# and the server must have their own cert and
# key file. The server and all clients will
# use the same ca file.
#
# See the «easy-rsa» directory for a series
# of scripts for generating RSA certificates
# and private keys. Remember to use
# a unique Common Name for the server
# and each of the client certificates.
#
# Any X509 key management system can be used.
# OpenVPN can also use a PKCS #12 formatted key file
# (see «pkcs12» directive in man page).
ca keys/ca.crt
cert keys/issued/vpn-server.crt
key keys/private/vpn-server.key # This file should be kept secret
Пути стоит прописывать исходя из того, где Вы будете располагать свои ключи. Они могут быть любыми. Если будете делать всё в рамках статьи, то можно оставить пути такими, т.к. после редакции конфиг файла сервера, будет описание создания рабочих директорий.
Информер: OpenVPN считает путь от директории openvpn/, таким образом, если Вы храните все сертификаты в стандартной директории, то следует оставить просто имена файлов без указания путей к ним.
Следующим этапом:
# Diffie hellman parameters.
# Generate your own with:
# openssl dhparam -out dh2048.pem 2048
dh dh2048.pem
Настроим путь к ключу Диффи-Хеллмана:
# Diffie hellman parameters.
# Generate your own with:
# openssl dhparam -out dh2048.pem 2048
dh keys/dh.pem
Протокол Диффи-Хеллмана – это криптографический протокол, который позволяет сторонам получить общий секретный ключ. При этом используется незащищенный от прослушивания, но защищённый от подмены канал связи. Т.е. если кто-нибудь будет пытаться слить данные канала где-то посередине пути, то компрометатор не сможет расшифровать данные, а если произойдёт слив в какой-либо из сторон канала связи, то компрометатор сможет получить ключ Диффи-Хеллмана и скомпрометировать наш траффик. Потому имеет смысл использовать ключ в полной связке: сервер работает на tcp, включена поддержка tls, сгенерирован ключ Диффи-Хеллмана. Генерация ключа будет ближе к концу статьи, когда будем генерировать серверные сертификаты.
Переходим к следующей диррективе:
# Configure server mode and supply a VPN subnet
# for OpenVPN to draw client addresses from.
# The server will take 10.8.0.1 for itself,
# the rest will be made available to clients.
# Each client will be able to reach the server
# on 10.8.0.1. Comment this line out if you are
# ethernet bridging. See the man page for more info.
server 10.8.0.0 255.255.255.0
Установите режим сервера и укажите подсеть VPN, которая будет использоваться как пул адресов для VPN-клиентов. Сервер возьмет себе адрес 10.8.0.1, остаточный пул будет использоваться для выдачи клиентам сервера. На каждом клиенте будет указан адрес сервера 10.8.0.1. Закомментируйте эту строку, если Вы используете Ethernet Bridge.
Данная директива является аналогом DHCP-сервера, так же заменяет директиву ifconfig и может работать только с TLS-клиентами в режиме TUN, использование сертификатов – необходимая мера.
ifconfig в данном случае – это директива, которая указывает статические параметры сети и маски сети для сервера и только для него. Часто заменяется директивой server.Острой нужды в том, чтобы менять адрес сервера в данном примере нет, поэтому я оставлю всё, как есть. В иных ситуациях рекомендуется менять стандартный адрес для повышения безопасности сети.
Далее настроим следующее:
# Maintain a record of client <-> virtual IP address
# associations in this file. If OpenVPN goes down or
# is restarted, reconnecting clients can be assigned
# the same virtual IP address from the pool that was
# previously assigned.
ifconfig-pool-persist ipp.txt
Данная директива отвечает за хранение соответствий клиента и его виртуального IP адреса. Полезно, если сервер OpenVPN остановлен или перезапущен, тогда переподключившиеся клиенты смогут получить прежний IP адрес. Проще говоря, эта директива является, в каком-то смысле, аналогом ARP-таблицы. По умолчанию она раскомментирована, так и оставим.
Переходим к следующей директиве:
# EXAMPLE: Suppose you want to give
# Thelonious a fixed VPN IP address of 10.9.0.1.
# First uncomment out these lines:
;client-config-dir ccd
;route 10.9.0.0 255.255.255.252
# Then add this line to ccd/Thelonious:
# ifconfig—push 10.9.0.1 10.9.0.2
Первая директива отвечает за путь к директории с файлами конфигурации для клиентов. К указанию не обязательна, поэтому я её сотру. Важной является вторая директива, которая задаёт параметры статической маршрутизации для хоста. Третья директива нам так же не нужна в виду того, что она отвечает за выдачу статических ip клиентам, что нам не требуется в данном случае, потому что выше мы настраивали директиву server.
# EXAMPLE: Suppose you want to give
# Thelonious a fixed VPN IP address of 10.9.0.1.
# First uncomment out these lines:
route 10.8.0.0 255.255.255.0
Назначаем статический маршрут.
Следующая немаловажная директива:
# Push routes to the client to allow it
# to reach other private subnets behind
# the server. Remember that these
# private subnets will also need
# to know to route the OpenVPN client
# address pool (10.8.0.0/255.255.255.0)
# back to the OpenVPN server.
;push «route 192.168.10.0 255.255.255.0″
;push «route 192.168.20.0 255.255.255.0″
Данная директива отвечает за передачу клиенту необходимых маршрутов. Из других подсетей до клиента так же должны быть маршруты, что немаловажно.
# Push routes to the client to allow it
# to reach other private subnets behind
# the server. Remember that these
# private subnets will also need
# to know to route the OpenVPN client
# address pool (10.8.0.0/255.255.255.0)
# back to the OpenVPN server.
push «route 10.8.0.0 255.255.255.0″
Итак, следующий немаловажный блок:
# If enabled, this directive will configure
# all clients to redirect their default
# network gateway through the VPN, causing
# all IP traffic such as web browsing and
# and DNS lookups to go through the VPN
# (The OpenVPN server machine may need to NAT
# or bridge the TUN/TAP interface to the internet
# in order for this to work properly).
;push «redirect-gateway def1 bypass-dhcp»
Если включено, то данная директива заменит всем клиентам дефолтный шлюз на VPN, таким образом, весь IP трафик (Web/DNS), будет направляться через VPN. На машине, где развёрнут VPN сервер, должен быть настроен NAT.
В случае, когда мы имеем дело с сервером телефонии, нецелесообразным будет пускать весь трафик через VPN, нас интересует только SIP, поэтому оставляем данную строчку закомментированной, либо удаляем вовсе. В данном случае её наличие не требуется, поэтому удалим её. Раскомментируйте при необходимости.
Идём дальше.
# Certain Windows-specific network settings
# can be pushed to clients, such as DNS
# or WINS server addresses. CAVEAT:
# http://openvpn.net/faq.html#dhcpcaveats
# The addresses below refer to the public
# DNS servers provided by opendns.com.
;push «dhcp-option DNS 208.67.222.222»
;push «dhcp-option DNS 208.67.220.220»
Настройте сетевые параметры, которые будут переданы на клиентские устройства, например, адреса DNS серверов, или WINS-серверов.
Клиентам могут быть переданы параметры:
route — передача статического маршрута
route—gateway – передача шлюза VPN хосту
route—delay – задержка n-секунд перед установлением маршрутов
redirect—gateway – указать в качестве дефолтного шлюза наш сервер
inactive – по истечении n-секунд неактивности TUN/TAP интерфейс отключается.
ping – отсылать icmp пакеты на другой конец туннеля после указанного времени n-секунд
ping—exit — отключать OpenVPN при условии, что за n-секунд не было получено ни одного пакета
ping—restart – перезапускать туннель при условии, что за n-секунд не было получено ни одного пакета
persist—key – не перечитывать файлы ключей при рестарте тоннеля
persist—tun – не изменять интерфейсы TUN/TAP при рестарте OpenVPN
comp—lzo – сжатие трафика
dhcp—option – передать опции dhcp сервераПоследняя опция применима только для Window-клиентов.
Итак, рассмотрим передачу базовых опций по dhcp VPN сервером.
Для базовой конфигурации вполне пойдёт указание двух серверов доменных имён – DNS, раскомментируем строчки, и скорректируем значения:
# Certain Windows-specific network settings
# can be pushed to clients, such as DNS
# or WINS server addresses. CAVEAT:
# http://openvpn.net/faq.html#dhcpcaveats
# The addresses below refer to the public
# DNS servers provided by opendns.com.
push «dhcp-option DNS 10.8.0.1»
push «dhcp-option DNS 8.8.8.8»
Наиболее приоритетным DNS сервером необходимо указать 10.8.0.1, а затем “восьмёрки” гугла – 8.8.8.8
Идём дальше:
# Uncomment this directive to allow different
# clients to be able to «see» each other.
# By default, clients will only see the server.
# To force clients to only see the server, you
# will also need to appropriately firewall the
# server’s TUN/TAP interface.
;client-to-client
Раскомментируйте директиву, если хотите, чтобы клиенты Вашего сервера могли видеть друг друга внутри сети. По умолчанию закомментировано, так и оставим, т.к. в нашем случае это не является мерой необходимой.
Следующий этап:
# The keepalive directive causes ping-like
# messages to be sent back and forth over
# the link so that each side knows when
# the other side has gone down.
# Ping every 10 seconds, assume that remote
# peer is down if no ping received during
# a 120 second time period.
keepalive 10 120
Данная директива отвечает за отправку ping-подобных сообщений в сторону сервера и клиента для проверки доступности хоста. Если одна из сторон перестанет отвечать, то считать, что хост недоступен. В начальной конфигурации директива говорит о том, что пингуем стороны каждые 10 секунд, если одна из сторон недоступна в течение 120 секунд, считать, что хост недоступен. Нам это подходит, так и оставим. Если Вам необходимы иные значения, измените их.
Следующая директива:
# For extra security beyond that provided
# by SSL/TLS, create an «HMAC firewall»
# to help block DoS attacks and UDP port flooding.
#
# Generate with:
# openvpn —genkey —secret ta.key
#
# The server and each client must have
# a copy of this key.
# The second parameter should be ‘0’
# on the server and ‘1’ on the clients.
tls-auth ta.key 0 # This file is secret
Для повышения безопасности при использовании SSL/TLS, необходимо создать «HMAC firewall» для защиты от DoS атак и флуда порта UDP. Сгенеровать можно при помощи: openvpn —genkey —secret ta.key. Сервер и клиенты должны иметь копию данного ключа. Второй параметр необходимо выставить в 0 для сервера и 1 для клиентов.
Если сервер стоит за MikroTik и работает по tcp, то активная аутентификация по tls не заработает ввиду того, что MirkoTik не поддерживает tls по OpenVPN, так же в данной связке не работает сжатие. Если генерировать ключ tls, то он обязательно должен быть на клиенте и сервере. Данный параметр не нужен в моём случае, т.к. мой сервер находится за MikroTik и работает по TCP.
Данная директива отвечает за безопасность. Суть протокола TLS в предоставлении трёх услуг всем приложениям, а именно: 1) шифрование на пути от одной машины к другой 2) аутентификация, 3) целостность данных (обнаруживает подмену информации). На сервере должен быть установлен параметр 0, а на клиенте 1. TLS в данном случае нам не нужен, поэтому данную строчку можно удалить.
TLS в данном случае нам не нужен, поэтому данную строчку можно удалить.
Настроим алгоритм шифрования трафика:
# Select a cryptographic cipher.
# This config item must be copied to
# the client config file as well.
# Note that v2.4 client/server will automatically
# negotiate AES-256-GCM in TLS mode.
# See also the ncp-cipher option in the manpage
cipher AES-256-CBC
Данная директива отвечает за криптошифрование. Если Вы используете шифрующие алгоритмы, указывайте режим CBC (Cipher Block Chaining). Используется для того, чтобы шифр каждого блока был уникальным.
Если используете, то указывайте это в конфиге клиента в том числе.
Следующий этап:
# For compression compatible with older clients use comp-lzo
# If you enable it here, you must also
# enable it in the client config file.
;comp-lzo
Директива сжатия трафика. Если на сервере включено сжатие, то необходимо включать его и на клиенте. Оставим закомментированным, т.к. в рамках нашей сети не требуется сжатие трафика. Если у Вас обратная ситуация, активируйте директиву.
Следующая директива:
# The maximum number of concurrently connected
# clients we want to allow.
;max—clients 100
Раскомментируйте и укажите максимальное количество клиентов сервера, если Вам требуется определённый лимит.
# The maximum number of concurrently connected
# clients we want to allow.
max—clients 32
На моём сервере не будет размещаться много клиентов, потому установлю 32 клиента.
Идём далее:
# It’s a good idea to reduce the OpenVPN
# daemon’s privileges after initialization.
#
# You can uncomment this out on
# non-Windows systems.
;user nobody
;group nobody
Запускать процесс OpenVPN от лица непривилегированного пользователя – хорошая идея. Раскомментируйте эти строки, если НЕ используете машину под управлением Windows. Эта мера необязательна, но желательна на Linux машинах, для того, чтобы при компрометации сервера, невозможно было навредить, используя права root пользователя.
Следующий шаг немаловажен:
# The persist options will try to avoid
# accessing certain resources on restart
# that may no longer be accessible because
# of the privilege downgrade.
persist-key
persist—tun
Данная директива отвечает за перечитывание файлов ключей сервера, а так же изменения tun/tap интерфейсов. Если не закомментировано, то перечитывания файлов не будет. По умолчанию так и выставлено, так и оставим.
Следующим пунктом настроим файл состояния сервера:
# Output a short status file showing
# current connections, truncated
# and rewritten every minute.
status openvpn—status.log
Выберите файл, в который будут производиться записи о текущих подключениях и ошибках VPN сервера.
# Output a short status file showing
# current connections, truncated
# and rewritten every minute.
status /var/log/openvpn/openvpn-status.log
Указываем директорию, “/var/log/”, которая хранит все логи.
Далее настроим сам файл логгирования:
# By default, log messages will go to the syslog (or
# on Windows, if running as a service, they will go to
# the «Program FilesOpenVPNlog» directory).
# Use log or log-append to override this default.
# «log» will truncate the log file on OpenVPN startup,
# while «log-append» will append to it. Use one
# or the other (but not both).
;log openvpn.log
;log-append openvpn.log
По умолчанию, логгирование ведётся в syslog. Log и Log-append служат для записи в другой файл, но со своими особенностями. Если Вы выбираете log, то логи каждый раз будут перезаписываться в указанном файле. Если Вы выберете log-append, то лог будет вестись в указанный файл без перезаписи.
# By default, log messages will go to the syslog (or
# on Windows, if running as a service, they will go to
# the «Program FilesOpenVPNlog» directory).
# Use log or log-append to override this default.
# «log» will truncate the log file on OpenVPN startup,
# while «log-append» will append to it. Use one
# or the other (but not both).
;log openvpn.log
log-append /var/log/openvpn/openvpn.log
Будем использовать log-append. Так же добавим дефолтный путь на /var/log/.
Так же немаловажно установить уровень логгирования. Это нужно для того, чтобы при возникновении неисправностей, мы могли пользоваться максимально детальной, но при этом полезной информацией.
# Set the appropriate level of log
# file verbosity.
#
# 0 is silent, except for fatal errors
# 4 is reasonable for general usage
# 5 and 6 can help to debug connection problems
# 9 is extremely verbose
verb 3
Установите уровень логгирования для файла лога. 0 – записывать только критические ошибки. 4 – получать общие сведения. 5 и 6 – отладочный уровень проблем соединения. 9 – максимально возможный уровень информативности лога, т.е. отображать всё.
# Set the appropriate level of log
# file verbosity.
#
# 0 is silent, except for fatal errors
# 4 is reasonable for general usage
# 5 and 6 can help to debug connection problems
# 9 is extremely verbose
verb 6
По умолчанию значение равно трём. Это нам не подходит, потому что лог будет недостаточно информативным. Рекомендуемое, если не пороговое, значение – 5 или 6. Я установлю 6.
Так же следующая немаловажная директива относительно логгирования:
# Silence repeating messages. At most 20
# sequential messages of the same message
# category will be output to the log.
;mute 20
Данная директива отвечает за то, чтобы в лог записывалось фиксированное количество сообщений одного типа. Это полезно, когда имеется много клиентов или нужно что-то дебажить, чтобы не засорять файл флудом из однотипных сообщений.
# Silence repeating messages. At most 20
# sequential messages of the same message
# category will be output to the log.
mute 20
Раскомментируем директиву и оставим стандартное число сообщений, равное двадцати. Если требуется иное значение, измените параметр под свои нужды.
Последняя директива:
# Notify the client that when the server restarts so it
# can automatically reconnect.
;explicit-exit-notify 1
Эта директива отвечает за отправку уведомления клиенту о том, что сервер перезапущен, и клиент может автоматически переподключиться. Вполне однозначно.
Данная директива не взаимодействует с протоколом tcp. Следовательно, если директива Вам необходима, смените рабочий протокол сервера.
Т.к. наш сервер сконфигурирован под работу с протоколом tcp, то мы оставим директиву закомментированной.
Подготовка к генерации ключей – установка утилиты easy-rsa
Конфигурационный файл сервера готов. Сохраняем и выходим.
Прежде чем перейти дальше, необходимо установить easy-rsa:
#yum install –y easy-rsa
<pic6>
easy-rsa – это утилита, которая использует openssl для выполнения действий с ключами и сертификатами.
Далее приступим к созданию главного сертификата сервера OpenVPN.
Подготовка к генерации ключей – создание файла с переменными “vars”
Создаём в папке Easy-RSA файл vars, хранящий переменные, содержащие содержимое создаваемых сертификатов, которые будут задействованы, во время генерации сертификатов:
# nano /usr/share/easy-rsa/3.0.3/vars
<pic7>
Это нужно для того, чтобы отбросить необходимость отвечать на вопросы, которые сервер задаёт при генерации сертификатов.
Т.к. мы создаём файл с нуля, он будет пустым. На моём скриншоте конфиг уже прописан, ниже прикреплю директивы для этого файла:
export KEY_SIZE=»1024″ – длина ключа
export CA_EXPIRE=»3650″ – время действия главного ключа в днях
export KEY_EXPIRE=»3650″ – время действия сертификата в днях
export KEY_COUNTRY=»RU» – код страны
export KEY_PROVINCE=»Bryansk Region» – указание региона
export KEY_CITY=»Bryansk» – указание города
export KEY_ORG=»VOXLINK COMPANY» – название компании
export KEY_EMAIL=team@voxlink.ru – указываем почту
export KEY_CN=»VOXLINK« – общее имя сертификата
export KEY_OU=»VOXLINK_BRYANSK« – название отдела или подразделения организации
export KEY_NAME=»VoxlinkVPN» – имя ключа
По итогу получится следующее:
<pic8>
После этого выполняем в консоли скрипт следующей командой:
# source ./vars
source – служит для того, чтобы команды скрипта выполнялись в контексте текущего экземпляра интерпретатора, а не запускать второй экземпляр для обработки этих команд.
<pic9>
Передаём source набор параметров, загружаем переменные.
Генерация серверных ключей и сертификатов
Инициализируем PKI:
# ./easyrsa init-pki
PKI – это инфраструктура открытых ключей, расшифровывается как Public Key Infrastructure. Ключ представлен публичной и приватной частями. Подразумевается, что каждая машина в структуре имеет личный ключ, которым она однозначно идентифицируется. PKI нужна для того, чтобы минимизировать последствия кражи. Реализовано это так: есть один, а в идеале, 2 центра сертификации, которые отдают публичную часть своих ключей клиентам, которым выдают подписанные сертификаты.
<pic10>
Создаём корневой сертификат:
# ./easyrsa build-ca
<pic11>
Вводим пароль от главного сертификата сервера.
Затем ещё раз:
<pic12>
После повторного ввода пароля будет запрошен Common Name – имя сервера, ничего не вводим, нажимаем Enter.
<pic13>
Главный сертификат сгенерирован.
Далее изготовим ключ Диффи-Хеллмана.
Для генерации ключа, введём следующую команду:
# ./easyrsa gen—dh
После того, как Вы нажмёте Enter, начнётся процесс генерации ключа:
<pic14>
Процесс генерации может занять около 1-2х минут. Это нормально.
По окончании генерации увидим следующее:
<pic15>
Следующим шагом будет создание запроса на сертификат для сервера:
# ./easyrsa gen-req vpn-server nopass
После ввода команды увидим запрос на Common Name:
<pic16>
Нажимаем Enter, не вводя ничего.
Если всё успешно, увидим следующий вывод:
<pic17>
Сгенерируем сам сертификат командой:
# ./easyrsa sign-req server vpn-server
Увидим:
<pic18>
Необходимо подтвердить запрос, введя ‘yes’:
<pic19>
Введём парольную фразу, которую назначали при генерации главного сертификата сервера:
<pic20>
Успешный вывод будет выглядеть так:
<pic21>
Сертификаты сервера сгенерированы, остаётся лишь создать рабочую папку с ключами в директории openvpn. Для этого делаем:
# mkdir –p /etc/openvpn/keys
<pic22>
После создания папки, нужно переместить в неё все сгенерированные ключи и сертификаты, для этого выполняем в консоли следующую команду:
# cp -r /usr/share/easy-rsa/3.0.3/pki/* /etc/openvpn/keys/
После этого создадим файлы статус-лога и основного лога сервера:
# touch /var/log/openvpn/openvpn.log – создаём основной лог файл.
# touch /var/log/openvpn/openvpn—status.log – создаём статус-лог файл.
<pic23>
После этого делаем запуск сервера:
# service openvpn start
<pic24>
Если Вы видите вывод, как на моём скриншоте, значит, у сервер сконфигурирован успешно.
Если же Вы увидите надпись ‘FAILED’, значит, перепроверьте корректность занесения параметров в конфигурационный файл, а в особенности пути к ключам и сертификатам.
Для финальной проверки, используйте:
# ifconfig
<pic25>
Если Вы видите, что поднялся интерфейс tun0, значит, на этом этапе всё хорошо.
Траблшутинг
Для дебага используйте файл openvpn.log. Если Вы не настроили логгирование, то анализируйте файлы syslog и messages, они распологаются в /var/log/. Для того, чтобы удобно продебажить весь процесс, откройте второй сеанс ssh на сервере, введите в консоль следующую команду:
# tailf /var/log/openvpn/openvpn.log
# tailf – вывод информации из файла в реальном времени в терминал.
А затем вводите в первом сеансе:
# service openvpn start
И анализируйте вывод лог файла.
Если же логи не пишутся, то перепроверяйте пути в файле server.conf и права на файл лога.
Для быстрой и нативной проверки прав используйте программу Midnight Commander.
# mc – вызов программы.
Перемещайтесь в директории с файлами лога, затем нажимайте File -> Chmod.
<pic26>
Далее корректируйте права на файлы следующим образом:
<pic27>
Здесь приведён пул самых частых ошибок и способов их решения. Все необъявленные ошибки стоит траблшутить самостоятельно.
Для просмотра содержимого файлов на Windows-машинах, используйте Notepad ++. Файл server.conf можно урезать, удалив описание директив (они обозначаются знаком #), оставив лишь сами директивы, в том числе и закомментированные, если Вы уверены в своих силах и знаете, за что отвечает каждый параметр.
Минимальная настройка iptables и функции автозапуска
Последним пунктом идёт настройка iptables на станции и автозагрузки. Т.к. нам нужно, чтобы клиенты могли подключаться к нашему серверу, то создадим правило:
iptables -A INPUT -p tcp —dport 1194 -j ACCEPT
Чтобы сохранить изменения, внесённые в конфигурацию iptables, введите в терминале:
# service iptables save
если Ваш сервер находится за роутером, то необходимо разрешить порт 1194 по протоколу tcp в файерволе, а так же сделать проброс указанного порта на локальный адрес вашей машины.
Для того, чтобы OpenVPN стартовала совместно с операционной системой, используйте:
# chkconfig openvpn on
ПРИЛОЖЕНИЕ
Сервер полностью сконфигурирован и готов к работе, приятного пользования. В качестве приятного дополнения, прикреплю здесь файл vars, файл server.conf и server_short.conf
<attach vars & server.conf & server_short.conf>
Если Вы желаете узнать, как генерировать сертификаты для OpenVPN сервера, ознакомьтесь со статьёй на нашем сайте — Генерация сертификатов для OpenVPN клиента .