Настройка VPN-сервера (OpenVPN) в CentOS/RHEL 7


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

 

Подключаем репозиторий EPEL

Для того чтобы установить OpenVPN – необходимо подключить EPEL-репозиторий (Extra Packages for Enterprise Linux):

 

Устанавливаем OpenVPN

 

Настраиваем OpenVPN в простейшем варианте

Прежде всего доведём OpenVPN до рабочего состояния, а потом уже накрутим необходимые «навороты». Нам понадобится личный ключ, сертификат и сертификат центра сертификации. Как их создать – можно прочитать в этой статье.

Некоторые OpenVPN-клиенты не умеют работать по UDP, как например OpenVPN-клиент в роутерах MikroTik, в этом случае, вместо строки proto udp нужно написать proto tcp. Авторизацию в этом конфигурационном файле мы включили по системным пользователям. Т.е. для подключения, в настройках клиента нужно будет указать логин и пароль уже существующего пользователя.
 

Настраиваем firewall

Первая строка разрешит подключаться к OpenVPN-серверу по протоколу UDP, вторая по TCP.
 

Пробный запуск OpenVPN-сервера

Теперь, запустим наш OpenVPN-сервер и попробуем к нему подключиться:

 

OpenVPN-клиент на CentOS 7

В клиентском конфиге у меня есть строка: ca /etc/pki/tls/certs/ca-bundle.crt она означает что для проверки серверного SSL-сертификата я использую системные доверенные корневые сертификаты. Если у вас на OpenVPN-сервере используется какой-нибудь самоподписанный сертификат, то на клиентскую сторону необходимо будет скопировать сертификат центра сертификации и указать его в конфигурационном файле клиента, в строке ca.
А строки «user nobody» и «group nobody» мы закомментировали из-за того, что если их оставить, то после завершения VPN-соединения, у клиента OpenVPN не хватит прав на то чтобы «убрать за собой». Он оставит маршруты и DNS-сервера изменёнными.

После успешного соединения, в логе на сервере мы видим следующее:

Имейте в виду, если в конфиг клиента прописать строку auth-nocache при авторизации по логину и паролю, то после реконнекта логин с паролем не будет прочитан из файла, а их нужно будет ввести в консоли.
Клиент с сервером соединились, попробуем с клиентской стороны пропинговать IP-адрес сервера:

Как видим, всё пингуется. Значит настройки и клиента, и сервера у нас корректные. Но лучше такими настройками не пользоваться, т.к. на клиентской стороне, в файле, у нас находятся системные имя пользователя и пароль в открытом виде. Использовать подобное можно непродолжительное время, только во время первоначальной настройки.
 

Настройка маскарадинга на серверной стороне

Для того чтобы клиенты выходили в мир через наш VPN, мы на стороне сервера должны настроить маскарадинг и проброс маршрута по умолчанию на клиента (имейте в виду, желательно пробросить ещё и DNS-сервер). Для этого сделаем следующее:

Имейте в виду, линуксовый клиент с настройками по умолчанию не меняет свои DNS-сервера при подключении к OpenVPN, чтобы это изменить сделайте на клиенте следующее:

Но, так же, имейте в виду, что если вы проталкиваете внешний адрес OpenVPN-сервера в качестве DNS, обращение к нему будет идти с внешнего адреса клиента. А если проталкиваете внутренний IP-адрес OpenVPN-сервера, то может возникнуть такая проблема, что локальный DNS-сервер не слушает 53-й порт на этом адресе. Если адрес появляется в системе после того как локальный DNS-сервер уже запущен – необходимо выполнить команду systemctl reload named-chroot.service для того чтобы DNS-сервер прибиндился к появившимся в системе IP-адресам. Чтобы это автоматизировать, сделаем на сервере следующее:

 

Настраиваем автозапуск OpenVPN

То как мы запускали OpenVPN годится только для тестов. Подготовим OpenVPN к нормальному запуску:

Описатель server означает что используется конфигурационный файл с именем server.conf в папке /etc/openvpn, в случае клиента, нужно выполнить следующую команду:

Вообще можно запускать несколько разных сервисов OpenVPN на одной машине, главное чтобы были разные конфигурационные файлы, и чтобы не использовались одни и теже порты и IP-адреса.
Попробуем запустить OpenVPN-сервер:

Как видим, сервис не запустился. Посмотрим из-за чего:

Ага, интересно. Заглянем ещё в лог SELinux:

Круть. Не хватает прав у OpenVPN на запуск скрипта. Дадим ему эти права и попробуем запустить сервис ещё раз:

Теперь сервис запустился без ошибок.
 
А чуть позже я дополню пост описанием работы OpenVPN с сертификатами.

Comments

  1. Петр Мамонтов
    31.12.2014 - 16:37

    Круто написано. Возник вопрос, можно как-нибудь избавиться от firewall-cmd —zone=trusted —add-interface=tun0?
    Попробовал сделать так для доступа к samba:
    firewall-cmd —permanent —zone=public —add-interface=tun0
    firewall-cmd —permanent —add-service=samba
    firewall-cmd —reload
    Но не сработало. И сопутствующий вопрос, где можно посмотреть лог того что банит firewall-cmd (искал в /var/log, но там не нашел)? Чтобы разобраться детальнее с правилами, а не разрешать все сразу.

    • Может попробовать написать:
      $ firewall-cmd —permanent —zone=public —add-service=samba
      ?

      А лога как такового по умолчанию у firewall-cmd – нет. firewall-cmd – это по сути, просто обёртка над старым iptables’ом. Т.е. нужно сначала создать правило, мол логируем то-то и то-то, а потом уже глядеть что там в логах получилось. Можно попробовать написать что-нибудь типа:
      $ firewall-cmd —add-rich-rule=’rule service name=samba log level=info’
      А потом посмотреть что в логах появляется.

      PS. А masquerade делаете?

  2. Петр Мамонтов
    01.01.2015 - 13:36

    Использую обычный форвардинг между интерфейсами через net.ipv4.ip_forward = 1. Попробовал явно указать зону public, но это ничего не дало, так как она зона по умолчанию и все интерфейсы у меня в ней. rich-rule тоже не дал эффекта, хоть полное логирование включай и снимай еще дампы. Но я решил, пойди чуть другим путем, все таки запихнуть tun0 в trusted и запретить исходящие соединения на интерфейсе, который смотрит в локалку. Насколько понял это нетривиальная задача для FirewallD, так как не встречал ее в статьях о нем. Буду курить подробнее man. И конечно есть еще пара выходов DMZ и ACL на сетевом оборудовании.
    P.S.: С праздниками вас.

  3. Петр Мамонтов
    01.01.2015 - 13:52

    Дополню немного, так как коммент нельзя править, «запретить исходящие соединения на интерфейсе» — хотел этим сказать, что кроме запрета еще и разрешить на нужные адреса и порты серверов. Так как не нравится мне идея полностью открытой локалку, для пользователей извне с их завирусованными машинами и червями.

  4. роман
    04.03.2015 - 04:29

    ну вот что вы за люди? вы думаете что мало опытный ит специалист после гуи или виндовс полезет конфиги через вим править? нет
    он скачает гуи или перейдет на кде или гноме, да да, воткнет иксы на серверный линукс
    максимум что возможно это поправить пару строчек в свойствах самбы на разрешение записи в папке или доработает fstab
    поэтому гуи, гуи и веб интерфес

    • Прочитал и посмеялся. Не нужно всех равнять по себе! Очень много людей понимают что гуй на сервере — это первый шаг к тому что этот сервер станет частью чьего-нибудь ботнета. 🙂

  5. Всем привет. Подскажите плиз почему при выполнении:
    [root@centos ~]# chcon -u system_u /etc/openvpn/server.conf
    Получаю ошибку:
    chcon: не удалось применить частичный контекст к не помеченному файлу «/etc/openvpn/server.conf»

Добавить комментарий