Практика: настраиваем VPN, работающий через Amazon EC2

Меня попросили поделиться инструкцией о том, как настраивается VPN с использованием виртуального сервера из амазоновского EC2 (часть AWS – Amazon Web Services). Инструкцию размещаю на dxdt.ru, ведь в современном Интернете VPN – полезный инструмент. Подобные инструкции есть в Сети, но я попробовал ещё раз пройти всё детально по шагам, собрать все этапы вместе, включая настройку DNS. Более того, в рамках данной инструкции мы ещё разберёмся с созданием собственного “удостоверяющего центра” для выпуска SSL-сертификатов и создания инфраструктуры для аутентификации узлов. И DNS, и особенности управления сертификатами (отзыв сертификатов; проверка имён, например, при помощи директивы VPN tls-remote) – среди тех ключевых моментов, о которых постоянно забывают, настраивая “личный” VPN.

О том, для чего в технократическом хозяйстве пригодится VPN – я писал раньше, и не один раз. Если вдруг кто забыл, то под VPN подразумеваются зашифрованные каналы связи, организованные поверх открытого Интернета и ведущие от клиента к серверу VPN, при этом множество клиентов может быть объединено в виртуальную сеть. Главная особенность: трафик, идущий по VPN, практически недоступен для анализа и перехвата.

Описание длинное, с картинками, поэтому прячу под “Читать полностью”.

Цели

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

Обзор технологии

Фундаментом нам послужит пакет OpenVPN. Пакет, в его современной версии, ориентирован на использование иерархии криптографических сертификатов (читай – SSL/TLS; далее – SSL). С помощью пары сертификатов при создании защищённого канала проводится взаимная аутентификация: сервер аутентифицируется клиентом, а клиент – сервером. Обратите внимание, что такой подход качественно отличается от типичного сценария использования HTTPS, где проводится аутентификация только сервера, но не клиента. Другими словами: подключиться к серверу VPN сможет только клиент, авторизационная информация которого удостоверена корневым сертификатом, используемым в системе; это исключает возможность скрытного перехвата соединения технически продвинутыми методами.

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

Интересной особенностью использования амазоновского сервиса является то, что там, для новых аккаунтов, предлагается один год бесплатного использования сервера минимальной конфигурации, который как раз и может послужить узлом VPN. За трафик, впрочем, придётся платить. Ну и вообще – смотрите, пожалуйста, внимательно и самостоятельно на цены и прайс-листы: автор, по понятным причинам, ничего касательно платности/бесплатности гарантировать не может.

Приборы и материалы

Потребуются: сервер в Amazon EC2 (понятно, что можно использовать любой другой сервер, со схожей конфигурацией, но данная инструкция написана для EC2), компьютер – рабочее место.

В основном, используются ОС Linux. Я понимаю, что без рассмотрения Windows в данном случае никак не обойтись, поэтому, там, где применимо, (например, описание настройки клиента VPN) описана и эта операционная система. На сервере используется Amazon Linux. Хорошим бонусом при освоении данной инструкции станут навыки работы с консолью, базовое представление об архитектуре этих самых линуксов и сетевых протоколов TCP/IP.

Сервер

Опустим этап регистрации аккаунта Amazon AWS – это элементарно (для регистрации нужны работающий телефонный номер и банковская карта).

Если вы используете другой сервер, не амазоновский, то переходите сразу к разделу, описывающему настройку ПО. Кстати, учитывайте, что многие провайдеры, предоставляющие выделенные серверы в аренду, прямо запрещают использовать их в качестве точек выхода VPN – читайте правила.

После того, как аккаунт создан и активирован, открывайте панель управления AWS при помощи браузера: нужно запустить сервер. Возможных настроек очень много, но это не проблема, для наших целей годятся настройки по умолчанию. Собственно, поэтому я не останавливаюсь подробно на разборе каждой опции. Кроме того, часть значений параметров я скрыл на скриншотах (источником скриншотов служил мой аккаунт).

Начало процесса создания сервера выглядит примерно так:

Обратите внимание на региональные настройки слева – здесь можно выбрать различные дата-центры. Для целей этого руководства хорошо подходит шт. Виргиния. При помощи клика на кнопку Launch Instance запускаем пошаговый “мастер” создания экземпляра виртуальной машины (Instance). Используем Classic Wizard:

Следующий шаг: выбор операционной системы и платформы.

Выбираем тип ОС – Amazon Linux, 64 бита. Следующий шаг, “размер” виртуальной машины:

Для нашего VPN хватает минимального – Micro (кстати, именно этот тип виртуальных машин входит в бесплатный пакет). Сейчас виртуальные машины AWS используют в качестве дисковой подсистемы образы EBS (Elastic Block Storage) с гарантированным хранением, то есть данные на диске переживут останов виртуальной машины.

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

Для удобства использования, к виртуальным машинам можно привязывать разные дополнительные описания. Назначим нашему экземпляру имя (Name), чтобы потом не перепутать, если что:

Для доступа к серверу будет использоваться SSH. Стандартное решение. При этом, в нашем случае, авторизация “по паролю” в SSH изначально отключена (и не вздумайте её включать!). Используется современный способ авторизации, по паре ключей (секретный/открытый). Эту пару нужно создать, если только вы не использовали амазоновский сервис раньше – и ключи уже не заданы:

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

Все современные SSH-клиенты умеют работать с авторизационными ключами. Это правильная практика. Возможно, у вас уже есть свой “приватный ключ”, который вы используете на других серверах, тогда соответствующий открытый ключ можно будет добавить на сервер позже (ключи, обычно, на сервере размещаются в файле ~/.ssh/authorized_keys). На всякий случай, напомню детали: сгенерировать пару ключей для SSH можно утилитой ssh-keygen; штатно, закрытый ключ сохраняется в файл ~/.ssh/id_rsa, открытый – ~/.ssh/id_rsa.pub; использовать ssh с другими файлами ключей помогает опция -i. (Я обещал не забывать про Windows: что касается SSH, то для этой ОС есть пакет PuTTY, он учит Windows кое-каким из тех штук, которые юниксы умеют делать от рождения.)

Возвращаемся к запуску сервера. Осталось настроить брандмауэр (Firewall) AWS. Это несложно, нужно указать название группы настроек и выбрать правила. Фильтруется только входящий трафик.

Для нашего сервера нужно открыть доступ к порту 22 (TCP) для SSH и к 1194 (UDP, TCP) для OpenVPN. Если вы заранее знаете, из каких сетей или каких IP-адресов будете обращаться к серверу, можно указать только их. Для доступа из любой точки Интернета – используйте стандартное обозначение 0.0.0.0/0. Если есть возможность, то хотя бы доступ для SSH нужно зафильтровать по IP-источника, иначе сервер будут донимать автоматические сканеры паролей. Собственно, из-за них и требуется аторизация строго по ключам.

1194 – стандартный порт OpenVPN. Типичное решение подразумевает использование UDP, в некоторых случаях это быстрее. Я рекомендую пользоваться TCP, как более надёжным вариантом. Именно для TCP будет настроен наш сервер. OpenVPN умеет работать на любом порту. В ряде случаев, для преодоления всяких нехороших брандмауеров и фильтров, более удобным оказывается порт 443 (https) или 80 (http). Если задумаете поменять порты в будущем, то не забудьте разрешить соответствующие соединения в брандмауере AWS (я ещё раз напомню об этом ниже по тексту, если что).

Обязательно кликните Add Rule для добавления правил и сохраните настройки.

Сервер практически сконфигурирован. Осталось взглянуть на итоговые сведения:

Если всё верно, то кликаем Launch.

Экземпляр виртуальной машины появляется в разделе Instances панели управления. Если у вас нет других виртуальных машин, то раздел будет состоять из одной строчки.

Вновь созданная виртуальная машина доступна только по внутреннему адресу. Для нормального использования VPN – требуется внешний, “маршрутизируемый” IP-адрес. Его необходимо зарезервировать в разделе Elastic IPs (Network & Security – в панели слева). Выделяете адрес и привязываете его к виртуальной машине. Два шага. Для этого служат кнопки вверху, машина должна быть запущена и работать. Обратите внимание, что за неиспользуемые IP-адреса взимается почасовая плата! Используемые – бесплатны. Хитрость состоит в том, что как только вы остановите виртуальную машину, IP-адрес от неё “отклеится”, станет неиспользуемым, то есть – платным. В таком случае, понятно, можно адрес освободить.

Есть разные способы, позволяющие использовать динамический DNS для доступа к VPN-серверу, а не арендовать IP-адрес. На мой взгляд, это баловство. Правильное решение – фиксированный IP. Я, к тому же, держу вполне статическую запись, указывающую на VPN-сервер, в своей доменной зоне, подписанной DNSSEC. Это не обязательно, но удобно.

Выделенный для сервера IP нужно записать – он потребуется для доступа.

Теперь у нас есть работающий сервер. Можно брать в руки консоль.

ПО на сервере

Прежде всего отмечу, что вместо настройки собственного сервера, есть, конечно, возможность выбрать тот или иной созданный другими пользователями образ (AMI в амазоновской терминологии) с уже сконфигурированным VPN. Это не наш метод, так как прежде придётся разбираться, что там в этом дистрибутиве лишнего и как всё устроено.

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

Все настройки выполняются из консоли сервера, по SSH. (Amazon Linux – это Red Hat.)

Прежде всего – обновления:

$ sudo yum update

Устанавливаем редактор nano – он используется в данной инструкции, естественно, можно заменить на любой другой, подходящий:

$ sudo yum install nano

Устанавливаем требуемые пакеты:

$ sudo yum install openvpn

– это сам openvpn;

$ sudo yum install bind

– BIND будет служить рекурсивным резолвером, выделенным для нашего VPN.

Сконфигурируем BIND, это быстро:

$ sudo nano /etc/named.conf

Нам потребуется добавить несколько директив в раздел options, директивы эти касаются обслуживаемых адресов и параметров резолвера.

allow-query { localhost; 192.168.2/24; };

– добавляем подсеть (виртуальную) VPN в список обслуживаемых резолвером – 192.168.2/24. Строго говоря, просто localhost работать не будет, несмотря на то, что и VPN-сервер, и BIND размещены на одной и той же виртуальной машине. VPN мы позже сконфигурируем так, что подключающиеся узлы будут получать адреса из указанного сегмента.

Другие опции:

max-cache-size 50m;
max-cache-ttl 28800;
max-ncache-ttl 3600;

Это обычная настройка рекурсивного резолвера – максимальный размер кэша, максимальные значения TTL. Итоговый файл named.conf должен выглядеть примерно так (DNSSEC здесь не используется):


###
options {
listen-on port 53 { localhost; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { localhost; 192.168.2/24; };
recursion yes;

max-cache-size 50m;
max-cache-ttl 28800;
max-ncache-ttl 3600;

};

logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};

zone "." IN {
type hint;
file "named.ca";
};
include "/etc/named.rfc1912.zones";
###

Сервер полностью выделен под VPN, здесь нет дополнительных пользователей, кроме стандартного набора, и нет лишних приложений.

Сертификаты и микропрактикум по OpenSSL

Для работы OpenVPN потребуются сертификаты: сертификат удостоверяющего центра (УЦ, CA), сертификат узла доступа, по одному сертификату для каждого клиента. В принципе, дистрибутив OpenVPN содержит пакет скриптов, позволяющих сгенерировать все нужные сертификаты и ключи при помощи OpenSSL. Использование скриптов описано в документации.

Но нет ничего сложного в том, чтобы, хотя бы для тренировки и понимания процесса, проделать все операции с OpenSSL самостоятельно. В качестве побочного результата – получим возможность генерировать собственные сертификаты для веб-сайтов, для адресов электронной почты, да для чего угодно.

В этот раз станем суперпользователем:

$ sudo su

Создаём базовую директорию, в которой будет работать наш удостоверяющий центр (УЦ). (Нужно, впрочем, понимать, что настоящие, большие удостоверяющие центры не должны быть устроены таким образом; хотя, в реальности на это остаётся только надеяться. А для наших целей – использование инструментария OpenSSL по описанному сценарию вполне подходит.)

Итак, базовая директория:

# mkdir -m 755 /etc/VPNCA

Внутри неё – структура директорий, необходимых для работы OpenSSL в режиме УЦ (CA):

# mkdir -m 0755 \
/etc/VPNCA/CA \
/etc/VPNCA/CA/private \
/etc/VPNCA/CA/certs \
/etc/VPNCA/CA/newcerts \
/etc/VPNCA/CA/crl

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

# cp /etc/pki/tls/openssl.cnf /etc/VPNCA/CA/openssl.vpn.cnf

Установим права доступа безопасным образом (впрочем, на отдельном виртуальном сервере это может показаться избыточным):

# chmod 0600 /etc/VPNCA/CA/openssl.vpn.cnf

В файле конфигурации достаточно исправить пути к директориям в разделе default_ca, вот этот фрагмент, строки, на которые нужно обратить внимание – выделены:


####################################################################
[ ca ]
default_ca = CA_default # The default ca section

####################################################################
[ CA_default ]

dir = . # !!! - базовая директория.

certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # !!! - путь к директории отзывов.
database = $dir/index.txt # database index file.

#unique_subject = no # Set to 'no' to allow creation of
# several ctificates with same subject.

new_certs_dir = $dir/newcerts # default place for new certs.

certificate = $dir/certs/vpnca.crt # !!! - файл сертификата УЦ.

serial = $dir/serial # The current serial number
crlnumber = $dir/crlnumber # !!! - файл с номером для списка отзывов сертификатов.

crl = $dir/crl.pem # !!! - файл с действующим списком отзывов.

private_key = $dir/private/vpnca.key # !!! - файл секретного ключа УЦ.
RANDFILE = $dir/private/.rand # private random number file

###

Нужно задать начальный серийный номер для сертификатов и для списка отзывов:

# echo ‘1001’ > /etc/VPNCA/CA/serial
# echo ’01’ > /etc/VPNCA/CA/crlnumber

После этого можно переходить к генерации сертификата удостоверяющего центра. Это самоподписанный сертификат, что является нормальным положением дел для корневого сертификата. Возвращаемся (если ушли) в базовую директорию:

# cd /etc/VPNCA/CA/

Генерируем сертификат и секретный ключ:

# openssl req -config openssl.vpn.cnf -new -x509 -extensions v3_ca -keyout private/vpnca.key -out certs/vpnca.crt -days 731

OpenSSL потребует ввести некоторое количество параметров, относящихся к создаваемому корневому сертификату. Самое важное: секретный ключ будет сохранён в зашифрованном виде, для этого OpenSSL запросит пароль, который не нужно терять – он потребуется всякий раз, когда вы задумаете подписать или отозвать очередной сертификат.

Обратите внимание, использование -x509 обозначает, что генерируется самоподписанный сертификат удостоверяющего центра (в терминологии OpenSSL – CA), а -days – задаёт период валидности: 731 день, примерно два года.

В результате мы получили пару важных файлов: vpnca.key – секретный ключ удостовряющего центра, именно с его помощью подписываются сертификаты, это самый важный элемент, поэтому установим для него соответствующие уровни доступа:

# chmod 0400 /etc/VPNCA/CA/private/vpnca.key

Второй файл – vpnca.crt – является публичным и представляет собой корневой сертификат нашей системы. Он потребуется для работы OpenVPN, как на сервере, так и на всех клиентах.

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

# cd /etc/VPNCA/CA

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

# openssl req -config openssl.vpn.cnf -new -nodes -keyout private/vpn-node.key -out vpn-node.csr -days 365

Здесь указана опция -nodes, то есть, секретный ключ сохраняется в открытом виде и пароль запрашиваться не будет. Срок действия сертификата – 365 дней. Имя vpn-node указываем и в качестве параметра CN (Common Name) сертификата, это важно и связано с корректной работой клиентов. Выпускам сертификат, используя только что сгенерированный запрос:

# openssl ca -config openssl.vpn.cnf -policy policy_anything -out certs/vpn-node.crt -infiles vpn-node.csr

Ключ -policy – задаёт политику, применяемую к данным сертификатов. Policy_anything – самая свободная политика, допускающая запросы, содержащие, например, отличные от корневого сертификата значения в полях Country Name, Locality Name и др. Политики задаются в файле с конфигурацией OpenSSL, в нашем случае – openssl.vpn.cnf.

В результате выполнения команд мы получили пару файлов, требуемых для идентификации сервера VPN: vpn-node.crt – сертификат, который требуется распространить на всех клиентов; vpn-node.key – секретный ключ сервера, этот файл сохраняется только на сервере (за исключением, разве что, резервной копии). Разумной практикой является использование ограничений на доступ для файлов секретных ключей:

# chmod 0400 /etc/VPNCA/CA/private/vpn-node.key

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

Ещё раз напомню, что мы установили имя сервера vpn-node, которое является частью сертификата. Именно по этому имени, в нашей конфигурации, клиенты будут узнавать о том, что узел является сервером (а не другим авторизованным клиентом нашей сети, проводящим перехват сессии). Это важный момент! Не менее важно использовать правильную политику именования серверов и клиентов. В нашем случае имена клиентов начинаются с префикса “client-“.

Выпускаем сертификаты для каждого из узлов (не обязательно сразу все выпускать). Например, для узла под названием client-pqr, имя указываем в поле Common Name (CN):

# openssl req -config openssl.vpn.cnf -new -nodes -keyout private/client-pqr.key -out client-pqr.csr -days 365
# openssl ca -config openssl.vpn.cnf -policy policy_anything -out certs/client-pqr.crt -infiles client-pqr.csr

Можно взглянуть на то, что получается:

# less ./certs/client-pqr.crt

Файлы .csr – после выпуска сертификата не требуются, их можно удалить.

Настройка OpenVPN

Теперь всё готово для того, чтобы поднять инфраструктуру OpenVPN. Управляющие файлы размещаются в директории /etc/openvpn. Для начала создаём внутри неё директорию pki, где разместим все необходимые для аутентификации данные.

# mkdir /etc/openvpn/pki

Копируем ключи и сертификаты, нужные для работы сервера:

# cp /etc/VPNCA/CA/certs/vpn-node.crt /etc/openvpn/pki/vpn-node.crt
# cp /etc/VPNCA/CA/private/vpn-node.key /etc/openvpn/pki/vpn-node.key

– сертификат и секретный ключ сервера.

# cp /etc/VPNCA/CA/certs/vpnca.crt /etc/openvpn/pki/vpnca.crt

– корневой сертификат или сертификат удостоверяющего центра.

Создаём файл конфигурации /etc/openvpn/openvpn.conf – привожу типовой файл, который работает у меня, с небольшими комментариями:

###

# Порт, тип соединения tcp-server, туннелирование - tun.
port 1194
proto tcp-server
dev tun

# Криптографические файлы для аутентификации.
ca pki/vpnca.crt
cert pki/vpn-node.crt
key pki/vpn-node.key

# Список отзывов сертификатов
crl-verify /etc/VPNCA/CA/crl.pem

# данные для генерации ключа шифрования с использованием протокола Диффи-Хелмана (см. ниже).
dh pki/dh2048.pem

# адресация в виртуальной сети, соответствует настройкам BIND
server 192.168.2.0 255.255.255.0

# опции маршрутизации и DHCP - установка DNS
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 192.168.2.1"

# параметры соединения
keepalive 10 120
comp-lzo
max-clients 10
persist-key
persist-tun

# пользователь/группа для рабочего потока OpenVPN
user nobody
group nobody

# логирование
status openvpn-status.log
log-append openvpn.log
verb 3

###

Осталось сгенерировать исходные данные для файла dh2048.pem и разобраться с отзывом сертификатов. Генерация dh2048.pem:

$ openssl dhparam -out pki/dh2048.pem 2048

Параметр 2048 – обозначает число битов, как несложно догадаться.

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

OpenSSL позволяет создавать списки отзыва при помощи ключа -gencrl. Для начала можно создать пустой список (без него OpenVPN в указанной конфигурации работать не станет):

# cd /etc/VPNCA/CA
# openssl ca -config openssl.vpn.cnf -gencrl -out crl.pem

Отзыв сертификата (вовсе необязательно выполнять при начальной настройке, привожу как пример):

# openssl ca -config openssl.vpn.cnf -revoke certs/client-abc.crt

Вообще, возможно запустить OpenVPN без поддержки списка отзывов, в таком случае удалите директиву crl-verify. Однако, если потребуется заблокировать сертификат (например, потеряли авторизованное устройство), то директиву нужно вернуть и сгенерировать список crl.pem.

Маршруты и NAT

Пакеты, приходящие от узлов-клиентов, подключенных через VPN к серверу, должны ходить наружу, а ответы, поступившие из Интернета, попадать обратно к клиентам – иначе мы получим локальную сеть, не более того. То есть, нужен NAT на сервере. Он настраивается штатными средствами, несколькими командами.

Редактируем файл /etc/sysctl.conf, изменив значение параметра net.ipv4.ip_forward = 1 (было – 0). Перезапускаем сетевые сервисы:

# service network restart

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

# echo ‘1’ > /proc/sys/net/ipv4/ip_forward

Он точно так же разрешает IP-форвардинг, но не переживёт рестарт системы.

Некий NAT настраивается при помощи iptables. Прежде всего, нужно, опять же, скорректировать настройки в файле /etc/sysconfig/iptables-config, включив параметры IPTABLES_SAVE_ON_STOP=”yes” и IPTABLES_SAVE_ON_RESTART=”yes”. Делается это, например, так:

# nano /etc/sysconfig/iptables-config

Создаём файл iptables:

# touch /etc/sysconfig/iptables

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

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

Готово.

Убеждаемся, что все нужные сервисы запустятся после перезагрузки, если такая потребуется:

# chkconfig named on
# chkconfig iptables on
# chkconfig openvpn on

Перезапускаем/запускаем сервисы:

# service iptables restart
# service named start
# service openvpn start

Всё. Сервер готов.

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

Если сравнивать с серверной вознёй, то настройка клиентов – элементарна. На клиенте должны быть три файла из инфраструктуры сертификатов, которую мы завели: 1) файл корневого сертификата, он содержит открытый ключ удостоверяющего центра, который позволяет проверять подлинность сертификата (сертификатов), предъявляемых сервером; 2) собственный сертификат данного узла – выпускается на сервере, потому что там мы держим УЦ; позволяет аутентифицировать узел-клиент перед сервером при наличии на узле подходящего секретного ключа; 3) файл, содержащий этот секретный ключ – в нашем примере ключ генерировался на сервере, откуда может быть скопирован на клиент при соблюдении разумных мер предосторожности. Вообще, ключ можно генерировать на клиенте, той же самой командой openssl, которая использовалась выше, на сервер в таком случае передаётся только файл .csr, на основе которого выпускается сертификат.

Помимо копирования файлов, для линуксов/юниксов – достаточно установить штатными средствами OpenVPN и прописать конфигурацию в файл, в примерно том же формате, что и на сервере. Например:

###

remote 10.10.7.11 1194
client
tls-remote vpn-node
proto tcp-client
dev tun

ca pki/vpnca.crt
cert pki/client-abc.crt
key pki/client-abc.key

comp-lzo
user nobody
group nobody
persist-key
persist-tun

status openvpn-status.log
log-append openvpn.log

verb 3

###

Здесь 10.10.7.11 – поменяйте на IP-адрес вашего сервера. Всё заработает.

Обратите внимание на директиву tls-remote, задающую имя сервера, указанное в сертификате (vpn-node, в нашем случае). Если не использовать эту директиву, то другие узлы, имеющие валидный сертификат, выданный нашим УЦ VPN, в принципе, могут прикидываться сервером и перехватывать трафик. Конечно, для небольшой закрытой системы VPN эта атака чисто теоретическая, но тем не менее. Самое занятное, что у tls-remote довольно неожиданная “семантика”: эта директива позволяет использовать “префиксы”, поэтому если имя сервера, указанное в сертификате – “vpn-node”, то “vpn-no” также пройдёт авторизацию. (В нашей схеме все клиентские узлы получают имена, начинающиеся со слова client, так что с vpn-node не перепутаются.)

Для запуска на линуксах: service openvpn start или аналогичный метод, в зависимости от дистрибутива.

Обратите внимание и на DNS! К сожалению, далеко не во всех случаях DNS-сервер правильно устанавливается автоматически, по DHCP. Если всё настроено по этой инструкции, то на клиенте должен использоваться сервер с адресом 192.168.2.1. Если автоматом не получилось, укажите адрес вручную, либо в настройках новомодных Network Managers, либо в /etc/resolv.conf. Понятно, что заработает DNS только после того, как установилось соединение VPN (интерфейс tun).

Для Windows существует клиент с графическим интерфейсом. Не могу сказать, работает ли он под Windows 7/Vista: я не использую Windows, поэтому протестировал этот клиент только под XP – и тут всё хорошо, кроме того, что часть DNS-трафика ходит через незащищённый интерфейс. Впрочем, это полечилось при помощи прописывания для незащищённого соединения адреса VPN-овского DNS-сервера вручную (клиент OpenVPN поднимает свой виртуальный интерфейс и создаёт собственное “Сетевое соединение”). Вот конфигурационный файл:

###

remote 10.10.7.11 1194
client
tls-remote vpn-node
dev tun
proto tcp-client
persist-key
persist-tun

ca c:\\vpn\\pki\\vpnca.crt
cert c:\\vpn\\pki\\client-pqr.crt
key c:\\vpn\\pki\\client-pqr.key
comp-lzo
verb 4
mute 20
register-dns

###

Дополнительные сетевые порты

Как я упоминал выше, не через все сети проходит трафик на порт 1194. Для того, чтобы OpenVPN работал на других портах, нужно, во-первых, открыть их в брандмауэре AWS:

– во-вторых, соответственно поправить настройки на клиентах и на сервере.

Проверка и тестирование

Для проверки работы VPN есть такие простые инструменты:

$ ifconfig

– видим поднявшийся интерфейс tun (если всё сработало верно);

$ ping 192.168.2.1

– должен отвечать наш “виртуальный маршрутизатор”;

Браузер показывает сайты, как если бы мы работали из США (доказательство для Windows, кстати):

Для проверки верной настройки DNS – воспользуйтесь очень полезным тестером энтропии от DNS-OARC (адрес вашего DNS-резолвера отображается вверху страницы).

Дополнения, комментарии, пояснения про Windows, если кто знает подробности, описания для Mac-ов (не успел добавить) – крайне приветствуются в комментариях.

Вот.

(Иллюстрация к тексту отношения не имеет.)

Адрес записки: https://dxdt.ru/2012/08/06/5063/

Похожие записки:



Далее - мнения и дискуссии

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

Комментарии читателей блога: 12

  • 1. 6th August 2012, 13:34 // Читатель jno написал:

    “В мемориз!” (C)

  • 2. 6th August 2012, 13:37 // Читатель jno написал:

    До кучи (тесты): http://dnssec.vs.uni-due.de/

  • 3. 25th September 2012, 14:29 // Читатель jno написал:

    Кстати, Дума думает надумать закон, запрещающий обход средств фильтрации трафика.
    Т.е. VPN’ов, в частности…

  • 4. 26th September 2012, 10:01 // Александр Венедюхин:

    Какая-нибудь лицензия будет.

  • 5. 26th September 2012, 12:56 // Читатель jno написал:

    Т.е. как в СССР – обязательная регистрация печатно-множительной техники?
    Впрочем, лицензия ничего не даст.
    Скорее, будут сертифицированные поставщики (вроде приснопамятного питерского “Атланта”) ублюдочного самопала, обязательного к использованию…

  • 6. 1st July 2013, 13:13 // Читатель username написал:

    Статья очень подробная,но возникли трудности при создании ключей.Кто может дать консультацию по поднятию сервера и создания ключей?

  • 7. 1st July 2013, 16:40 // Александр Венедюхин:

    О каких именно ключах речь? Если это ключи SSH, то они создаются автоматически амазоновским сервисом (можно использовать свои, генерируются при помощи ssh-keygen). На сервере, ключи, обычно, находятся в файле .ssh/authorized_keys.

  • 8. 1st July 2013, 17:23 // Читатель jno написал:

    в ~/.ssh/authorized_keys лежат ПУБЛИЧНЫЕ ключи – не перепутайте!
    которые обычно после ssh-keygen образуются с суффиксом .pub

  • 9. 1st July 2013, 18:06 // Александр Венедюхин:

    Да, это важно: секретный ключ остаётся на клиенте, публичную часть просто копируете в authorized_keys на сервере. В случае, если клиент – под Windows, то форматы файлов могут отличаться, но проблем там нет.

  • 10. 1st July 2013, 19:45 // Читатель username написал:

    Спасибо что отозвались,конкретно ключ vpn-node.key.С ssh проблем нет.Еще появились вопросы:
    – на момент написание статьи, еще работал фри дунднс, на данный момент сейчас только платно, несовсем понял как привязывать днс, если к примеру воспользоваться сервисом no-ip;
    – в актуальной версии опенвпн 2.3.1 easy -rsa, это отдельный проект, поэтому приходится заливать их по отдельности, может в этом какой-то конфликт;
    – при service ipenvpn start FAIL,какая-то проблема с пробросом портов, потому что в логах ругается на ip:port.
    Александр возможно ли с Вами как то по этому поводу проконсультироваться, и как, возможно я упускаю какаой-то момент на этапе настройки самого впн, ибо все делаю по инструкции, а результата нет.

  • 11. 2nd July 2013, 15:17 // Александр Венедюхин:

    > конкретно ключ vpn-node.key.

    А что пишет openssl? Вы генерируете ключ с его помощью (как в статье)?

    > как привязывать днс

    Для DNS потребуется домен и серверы имён. Услуга называется “DNS-хостинг”, бывает она платной и бесплатной. Бесплатно есть, например, у “Яндекса”. Платно – nic.ru. Из иностранных компаний – Go Daddy и др.

    > в актуальной версии опенвпн 2.3.1 easy -rsa

    Easy-rsa можно не использовать, в статье описана настройка без него. Ну, то есть, либо easy-rsa, либо как в статье.

    > какая-то проблема с пробросом портов

    А какая именно? У OpenVPN есть лог – что он туда пишет?

  • 12. 2nd July 2013, 23:00 // Читатель username написал:

    Александ благодарю Вас что откликнулись, возможно вы помножите мне с проблемой.Подготовил ряд следующих вопросов:
    1.Есть ли преимущество без использования easy rsa ?
    2.выбираю инстант амазона Classic Wizard- Amazon Linux AMI 2013.03.1-T1 micro 613mib-2/2 checks passed
    3.привязываю Elastic IPs-Allocate New Address-EC2-Yes-Associate Address-выбираю свой инст-Yes
    4.Запускаю putty -Auth(указываю сгенерированный ключ), далее Translation-UTF8, далее session (указываю ип,который был в Elastic ips), все, логин ec2-user.Я на сервере.
    5.Все делал по статье порты прописал на амозоне, далее иду по ней же, все отлично, до следующего момента
    6.Дохожу до
    openssl ca -config openssl.vpn.cnf -policy policy_anything -out certs/vpn-node.crt -infiles vpn-node.csr
    получаю
    Enter pass phrase for ./private/vpnca.key:
    и вот ошибка

    140702121150304:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:596:
    140702121150304:error:23077074:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 cipherfinal error:p12_decr.c:104:
    140702121150304:error:2306A075:PKCS12 routines:PKCS12_item_decrypt_d2i:pkcs12 pbe crypt error:p12_decr.c:130:
    140702121150304:error:0907B00D:PEM routines:PEM_READ_BIO_PRIVATEKEY:ASN1 lib:pem_pkey.c:132:

    Пока только это.