OpenVPN: Настройка на собственном сервере. Часть 4 - конфигурация клиента.

Категории: HowTo

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

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

 ~/CA/pki/issued/User.crt  
 ~/CA/pki/private/User.key  
 ~/CA/pki/ca.crt  
 /etc/openvpn/keys/ta.key

Скопируем их в отдельный каталог. Так же в этом каталоге создадим файл connect.ovpn следующего содержания:

client  
dev tun  
proto udp  
remote X.X.X.X 1194  
tls-client  
ca "ca.crt"  
tls-auth "ta.key" 1  
cert "User.crt"  
key "User.key"  
remote-cert-tls server  
comp-lzo  
tun-mtu 1500  
mssfix 1450  
verb 3  
nobind

Где X.X.X.X - это айпишник вашего сервера.

Передаем пять этих файлов пользователю и теперь на клиенте можно подключаться:

$ sudo openvpn connect.ovpn

OpenVPN: Настройка на собственном сервере. Часть 3 — iptables

Категории: HowTo

В предыдущей части мы наконец-то сервер запустили. Но достучаться до него возможности нет поскольку iptables все еще не настроены и блокируют все подряд.

Как сказали на одном из формумов: в сети есть множество руководств по iptables для openvpn, но ни одно из них не работает.

В продолжении еще одно :)

Разрешаем коннекты к серверу (в прошлый раз мы настроили дефолтный впн через udp. Поэтому здесь мы открываем только подключение udp.

iptables -I INPUT -i eth0 -m state --state NEW -p udp --dport 1194 -j ACCEPT

Обратите внимание, что нужно использовать модификатор -I, который добавит это правило первым к цепочке. Если же использовать -A как рекомендуют некоторые, то правило будет добавлено к цепочке последним. А как мы знаем - последним правилом в цепочке стоит reject. И это значит, что добавляй после него или не добавляй правила - ничего не заработает.

Кстати из-за подобной ошибки (способа добавления правила в цепочку можно порой у некоторых видеть такую ошибку:

TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)  
TLS Error: TLS handshake failed

Это как раз значит, что сервер не смог ответить на “рукопожатие”. Т.е. порт заблокирован или где-то на пути к серверу не работает форвардинг пакетов.

Теперь разрешим интерфейсу tun коммуникацию с другими интерфейсами в системе.

iptables -I FORWARD -i tun+ -j ACCEPT  
iptables -I FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT  
iptables -I FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT

Включим nat (как вы помните из предыдущей части - сервер настроен в режиме роутера, а не моста - поэтому nat обязателен).

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

В цепочке POSTROUTE чаще всего нет reject. Поэтому смело используем -A.

И последний шаг - разрешить исходящий трафик на tun-инмерфейсе.

iptables -A OUTPUT -o tun+ -j ACCEPT

Теперь самый важный шаг: проверить, что все заработало

$ sudo nmap -sU -p1194 X.X.X.X

Starting Nmap 7.00 ( https://nmap.org ) at 2016-01-24 21:33 MSK  
Nmap scan report for X.X.X.X  
Host is up (0.089s latency).  
PORT STATE SERVICE  
1194/udp open|filtered openvpn

Nmap done: 1 IP address (1 host up) scanned in 1.08 seconds

Если у вас похожий вывод - сохраняем правила iptables и генерируем клиентский конфиг в следующей части.

$ sudo /usr/libexec/iptables.init save

Ниже конфиг /etc/sysconfig/iptables, который я приведу для сравнения (если у вас что-то не заработало).

*nat  
:PREROUTING ACCEPT [80:8210]  
:INPUT ACCEPT [0:0]  
:OUTPUT ACCEPT [24:11832]  
:POSTROUTING ACCEPT [24:11832]  
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE  
COMMIT  
*filter  
:INPUT ACCEPT [0:0]  
:FORWARD ACCEPT [0:0]  
:OUTPUT ACCEPT [66:10292]  
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT  
-A INPUT -p icmp -j ACCEPT  
-A INPUT -i lo -j ACCEPT  
-A INPUT -i eth0 -p udp -m state --state NEW -m udp --dport 1194 -j ACCEPT  
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT  
-A INPUT -i tun+ -j ACCEPT  
-A INPUT -j REJECT --reject-with icmp-host-prohibited  
-A FORWARD -i tun+ -j ACCEPT  
-A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT  
-A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT  
-A FORWARD -j REJECT --reject-with icmp-host-prohibited  
-A OUTPUT -o tun+ -j ACCEPT  
COMMIT

OpenVPN: Настройка на собственном сервере. Часть 2 — конфигурация сервера.

Категории: HowTo

Ключи сгенерировали. Теперь можно запускать сервер.

Обращаю внимание, что дальше речь пойдет о дефолтной настройке openvpn в режиме роутера. Это тот режим, когда вам нет необходимости интегрировать подключенных клиентов в локальную сеть.

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

Поддробнее про разные режимы работы можно почитать в официальной документации: https://community.openvpn.net/openvpn/wiki/BridgingAndRouting.

Копируем конфиг сервера

$ sudo cp /usr/share/doc/openvpn-*/sample/sample-config-files/server.conf /etc/openvpn

Теперь нужно отредактировать этот конфиг поправив следующие параметры

# пути к сертификатам ставим свои  
ca /etc/openvpn/keys/ca.crt  
cert /etc/openvpn/keys/vpn-server.crt  
key /etc/openvpn/keys/vpn-server.key # This file should be kept secret  
dh /etc/openvpn/keys/dh.pem

# заставляем клиент направлять весь трафик через сервер (чтобы избежать всяких утечек днс-запросов)  
push "redirect-gateway def1 bypass-dhcp"

# пропишем собственные dns  
push "dhcp-option DNS 8.8.8.8"  
push "dhcp-option DNS 8.8.4.4"

# защита от флуда  
tls-auth /etc/openvpn/keys/ta.key 0 # This file is secret

# сразу после запуска у сервера будут отобраны рутовые права (безопасности больше)  
user nobody  
group nobody

Если есть желание - можно поправить порт.

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

$ sudo systemctl -f enable openvpn@server.service  
$ sudo systemctl start openvpn@server.service

OpenVPN: Настройка на собственном сервере. Часть 1 — сертификаты.

Категории: HowTo

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

Для этого нужно три компонента:

  • Корневой сертификат (назовем его для простоты CA), которым будут подписываться ключи клиента и сервере. Крайне желательно чтобы он был на отдельной машине.
  • Сертификат сервера, который будет подписан корневым доверительным сертификатом.
  • Сертификат для каждого из клиентов, который тай жэ будет подписан CA

Корневой сертификат и сертификат сервера

Создаем корневой центр собственной сертификации (лучше делать это не на той машине, где запуен openvpn и там должен быть установлен пакет easy-rsa)

$ cp -R /usr/share/easy-rsa/3.0.0/ ~/CA  
$ cp /usr/share/doc/easy-rsa/vars.example ~/CA/vars  
$ cd ~/CA

Нужно отредактировать vars и поправить те параметры, которые будут вам интересны. Это имя домена, имя сервера и прочее - все подробно прокомментировано в файле.

Инициализировать PKI (Public Key Infrastructure — Инфраструктура открытых ключей):

$ ./easyrsa init-pki

Создать корневой сертификат. Common Name сервера вводить на ваше успотрение. (лучше придумать что-то вроде vpn-server). Сложный пароль ключа обязателе. Не менее 128 бит.

$ ./easyrsa build-ca

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

$ ./easyrsa gen-dh

Создать запрос на сертификат для сервера OVPN. Обращаю внимание, что сертификат будет незапаролен (параметр nopass), иначе при каждом старте OpenVPN будет запрашивать этот пароль.

$ ./easyrsa gen-req vpn-server nopass

Создать и подписать сертификат

$ ./easyrsa sign-req server vpn-server

Скопировать полученные ключи в рабочий каталог openvpn

$ sudo mkdir -p /etc/openvpn/keys  
$ sudo mkdir cp ~/CA/pki/ca.crt /etc/openvpn/keys  
$ sudo mkdir cp ~/CA/pki/issued/vpn-server.crt /etc/openvpn/keys  
$ sudo mkdir cp ~/CA/pki/private/vpn-server.key /etc/openvpn/keys  
$ sudo mkdir cp ~/CA/pki/dh.pem /etc/openvpn/keys

Создать «HMAC firewall» для защиты от DoS аттак и флуда UDP порта.

$ cd /etc/openvpn/keys/  
$ sudo openvpn --genkey --secret ta.key

Генерация пользовательских ключей

Создание запроса запароленного ключа для клиента (потребуется вводить при каждом подключении) с именем User

$ cd ~/CA  
$ ./easyrsa gen-req User

User - это имя пользователя для которого вы генерируете ключ.

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

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

$ ./easyrsa gen-req User nopass

Теперь ключ надо подписать

$ ./easyrsa sign-req client User

Дефолтно ключ выдается на 10 лет. Можно ограничить время. И ключи придется только перевыпускать по завершению работы.

$./easyrsa sign-req client User -days 90

Клиенту потребуется следующий набор файлов

 ~/CA/pki/issued/User.crt  
 ~/CA/pki/private/User.key  
 ~/CA/pki/ca.crt  
 /etc/openvpn/keys/ta.key

Отзывы сертификатов

Герируем файл отозванных ключей

$ cd ~/CA  
$ ./easyrsa gen-crl

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

$ sudo cp ~/CA/pki/crl.pem /etc/openvpn/keys

В /etc/openvpn/server.conf добавить строку

crl-verify /etc/openvpn/keys/crl.pem

Отзыв сертификата пользователя User

$ ./easyrsa revoke User

Каждый раз при отзыве сертификата необходимо обновлять crl.pem, чтобы внести в него изменения

$ ./easyrsa gen-crl

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

failed to update database  
Easy-RSA error:  
signing failed (openssl output above may have more detail)

Для исключения возможности mitm атаки, ошибка которого так выглядит в логах клиента как показано ниже служит параметр remote-cert-tls server в конфиге клиента.

WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.

Ссылки:

OpenVPN: Настройка на собственном сервере. Часть 0 - подготовка системы.

Категории: HowTo

В этих туториалах я опишу как поднять собственный openvpn на vds/vps.

В качестве базовой системы рассматривается Fedora/RedHat/CentOS. Для других систем шаги будут несколько отличаться.

Для начала нам нужно подготовить сервер: поставить необходимые пакеты.

Управлять доступом мы будем через iptables, а не firewalld. Так же если ваш сервер не использует ipv6, то ip6tables вам не нужен.

Важно: ни в коем случае не отключайтесь от сервера до оконччания настройки iptables. Иначе доступ к серверу будет потерян.

$ sudo dnf install iptables-services openvpn easy-rsa  
$ sudo systemctl mask firewalld  
$ sudo systemctl enable iptables  
$ sudo systemctl enable ip6tables  
$ sudo systemctl restart iptables  
$ sudo systemctl restart ip6tables

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

Вообще правила iptables изначально поставляются с возможностью доступа по ssh.

Для проверки можно заглянуть в /etc/sysconfig/iptables (и /etc/sysconfig/ip6tables для ipv6). Там будет строчка вроде

-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

Если она там есть, то проверьте с другого терминала, что доступ к ssh возможен.

Так же, если сервис висит на нестандартном порту, то стоит изменить номер порта в этих файлах.

Если же доступа к ssh нет, то нужно добавить его вручную

$ sudo iptables -I INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

и сохранить правила.

$ sudo /usr/libexec/iptables/iptables.init save

Дальше перезагружаем таблицы еще раз

$ sudo systemctl restart iptables  
$ sudo systemctl restart ip6tables

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