Создание vpn сервера linux. Настройка сети и ВПН подключения «вручную» в Linux

Настройка с помощью Network Manager"а

Как бы там ни было, но все таки опиши настройку впн с помощью network-manager"а. Эта настройка вполне подойдет тем, у кого в подключении к сети используется автоматическое получение IP адреса с помощью DHCP.

1. Устанавливаем два необходимых нам пакета:
#apt-get install pptp-linux network-manager-pptp
Так как этих пакетов по умолчанию нет на диске с убунтой, а впн часто приходится настраивать на машине, у которой больше нет другого выхода в интернет, то советую заранее припастись этими пакетами с официального репозитория. Для этого заходим на сайт packages.ubuntu.com/ , там ищем два эти пакета, закачиваем их и в дальнейшем устанавливаем на нужной нам машине.
2. Если в аплете Network Manager не появился пункт «VPN соединения»(VPN Connections) или он не будет открываться, то надо перелогиниться или даже лучше - перезагрузиться.
3. Нажимаем левой клавишей мыши (по правой кнопке вызывается другое меню) по значку Network Manager"а и в выпавшем меню выбираем «VPN соединения» - «Настройка VPN»(Configure VPN). Добавляем новое соединение и выставляем все нужные опции для этого соединения.
4. После этого, ваше соединение должно появиться в меню «VPN соединения», если оно вдруг не появилось - перелогиньтесь или перезагрузитесь (ну что я могу поделать, на столько, все еще, сырой этот network-manager).
5. Все теперь можете подключаться к созданному вами впн соединению (а также и отключаться, выбрав пункт меню в Network Manager"е).

#apt-get install pptp-linux

Как я уже описывал выше в разделе установки с помощью network-manager"а, впн часто приходится настраивать на машине, у которой больше нет другого выхода в интернет, поэтому советую заранее припастись этим пакетом с официального репозитория packages.ubuntu.com/.

2. Редактируем файл options.pptp:
#nano /etc/ppp/options.pptp

lock noauth nobsdcomp nodeflate persist

Не буду описывать каждый из параметров, опишу лишь некоторые:
persist - этот парметр пытается по новой открыть соединение, когда оно закрывается;
nodeflate - не использовать deflate сжатие (хотя говорят с ним работает быстрее, не знаю - не проверял).
Также, если у вас в соединении используется шифрование, то добавляем одну из строк, в зависимости от типа шифрования - require-mschap-v2, require-mppe-40, require-mppe-128, require-mppe.

3. Создаем файл подключения /etc/ppp/peers/vpn (название vpn можете заменить на любое другое, но если замените, не забывайте менять его дальше в этой статье)

#nano /etc/ppp/peers/vpn

Вставляем туда следующие строки:
maxfail 0 lcp-echo-interval 60 lcp-echo-failure 4 defaultroute pty "pptp vpn.ava.net.ua --nolaunchpppd" name sukochev remotename PPTP +chap file /etc/ppp/options.pptp ipparam vpn

Внимание!!! Обязательно замените следующие опции на ваши:
Вместо vpn.ava.net.ua впишите адрес вашего впн сервера (можно использовать IP сервера). Вместо sukochev вставляете ваш логин подключения.
Опишу некоторые параметры:
maxfail 0 - всегда пытаться подключиться при отсутствии связи;
lcp-echo-interval - интервал времени, по прошествии которого, происходит опрос удаленной стороны;
lcp-echo-failure - количество не отвеченных запросов удаленной стороны, после чего система считает, что нас отключили;
defaultroute - устанавливаем маршрут по умолчанию;
+chap - тип аутентификации. Помимо +chap может использоваться тип +pap.
file - читать дополнительные настройки из заданного файла.
Также можно добавить, если нужно, следующие параметры:
deflate 15,15 - использовать deflate сжатие (в файле options.pptp не должно быть параметра nodeflate);
mtu - максимальный размер передаваемого пакета (изменяют этот параметр обычно тогда, когда часто отключается соединение или не открываются некоторые сайты);
mru - максимальный размер получаемого пакета.

4. Редактируем файл /etc/ppp/chap-secrets (если используется тип аутентификации PAP, то /etc/ppp/pap-secrets соответственно)

#nano /etc/ppp/chap-secrets

Вставляем туда строку, типа:

Sukochev PPTP password *

Внимание!!! Замените sukochev на свой логин, а password на ваш пароль для подключения.
5. Если это необходимо, то прописываем в файл /etc/network/interfaces нужные роуты. Например у меня роуты прописаны для того, чтобы при включенном впн-подключении я мог пользоваться местной локальной сетью. Вот пример моих роутов (те что начинаются на up route), у вас они естественно будут отличаться:

Auto eth1 iface eth1 inet dhcp up route add -net 10.1.0.0 netmask 255.255.0.0 gw 10.1.45.1 dev eth1 up route add -net 10.3.0.0 netmask 255.255.0.0 gw 10.1.45.1 dev eth1

Не забываем после изменения файла /etc/network/interfaces перезапустить сетевые подключения:

#/etc/init.d/networking restart

6. Теперь можете включать и выключать впн подключение с помощью следующих команд:
Включение

Выключение

Автоматическое подключение VPN при загрузке системы

Для этого редактируем файл /etc/network/interfaces
#nano /etc/network/interfaces

И вставляем в конец фйла следующие строки:
auto ppp0 iface ppp0 inet ppp provider vpn pre-up ip link set eth1 up up route del default up route add default dev ppp0

Где eth1 - это интерфейс сетевого устройства, через которое подключается впн-соединение, а vpn - название впн-соединения, которое вы создали в папке /etc/ppp/peers/.

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

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

И так, для начала нам нужен сервер. Для VPN сетей с небольшой нагрузкой виртуального сервера (VPS) более чем достаточно. Проблема в том, что порог вхождения на рынок интернет-услуг, мягко говоря не высок. Соответственно качество этих услуг часто оставляет желать лучшего. В любом случае, перед покупкой необходимо уточнит разрешены ли у хост-провайдера VPN сети вообще и включены ли на их VPS NAT и TUN/TAP .

На правах рекламы я рекомендую провайдера . Я пользуюсь их услугами с момента открытия ими второго дата-центра в Нью-Йорке (почти 2 года) и за это время нареканий к их работе у меня не возникло. За почти десять лет я сменила множество провайдеров и мне есть с чем сравнить. То есть это действительно современный сервис «для людей». В случае с DigitalOcean, поддержка VPN включается в один клик клиентом при создании VPS. После регистрации и внесения минимального месячного платежа клиент сам выбирает конфигурацию своего VPS (Droplet, в терминологии DigitalOcean), которая варьируется от 512 MB RAM и 20 GB дискового пространства, до тех мощностей, которые клиенту по карману. Система виртуализации - KVM , накопители - SSD диски. Деньги со счёта клиента списываются ежедневно из расчёта почасовой оплаты. Клиент в любое время может пересоздать, изменить или уничтожить свой Droplet, а так же создать новый. Они гордятся своими 55-ю секундами и по факту, действительно, между нажатием кнопки «создать» и получением письма с IP-адресом и паролем для root-доступа проходит не больше минуты. DigitalOcean так же продают услуги в Амстердаме, что для европейских и восточноевропейских клиентов, возможно, более предпочтительно из-за расстояния и пинга между сервером и аудиторией этого сервера. В любом случае, при создании VPS нужно поставить галку напротив «Private Networking», чтоб включить в конфигурацию NAT и TUN/TAP.

Я настоятельно не рекомендую без острой необходимости использовать 32-х битные дистрибутивы современных операционных систем в виду устаревшей архитектуры и того, что сами разработчики уделяют им гораздо меньшее внимание, по сравнению с 64-х битными. Таким образом в природе существует 32-х битная серверная версия Ubuntu 14.04, но на официальном сайте Ubuntu она не представлена там, где предлагается загрузка образа этой ОС.

И так, после того как с сервером мы определились, то приступаем к установке. В моём случае это VPS с 1024 RAM и 64-х битной Ubuntu 14.04 в качестве ОС.

Aptitude install pptpd

Разрешаем IP-forwarding. Для этого редактируем файл /etc/sysctl.conf и в нём либо расскоментируем, либо добавляем следующую строку, если таковая отсутствует:

Net.ipv4.ip_forward = 1

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

Правим файл /etc/pptpd.conf и приводим его к следующему виду:

Option /etc/ppp/pptpd-options logwtmp localip 10.30.1.1 remoteip 10.30.1.30-40,10.30.1.15

Где localip - IP виртуального сетевого интерфейса ppp0. Не нужно прописывать сюда внешний IP сервера, или IP других сетевых интерфейсов сервера.
Remoteip - диапазон клиентских адресов в количестве десяти (от 10.30.1.30 и до 10.30.1.40), а так же (через запятую) выделенные адреса (если таковые необходимы). В моём случае выделенный адрес один. Вы можете указать здесь любое приемлемое значение.
Например:

Localip 10.10.1.1 remoteip 10.10.1.100-200,10.10.1.25,10.10.1.26

В таком случае динамичные адреса, раздаваемые клиентам присутствуют в количестве ста штук и два адреса зарезервированы.

User1 pptpd password "*" user2 pptpd password "10.30.1.15"

В файле у нас два пользователя user1 и user2, password - пароли пользователей, звёздочка в кавычках говорит о том, что user1 получит свободный IP из указанного в /etc/pptpd.conf диапозона, а за user2 закреплён выделенный адрес. Соблюдение синтаксиса обязательно.

Редактируем файл /etc/ppp/pptpd-options
name pptpd refuse-pap refuse-chap refuse-mschap require-mschap-v2 require-mppe-128 ms-dns 8.8.8.8 ms-dns 8.8.4.4 proxyarp nodefaultroute lock nobsdcomp novj novjccomp nologfd noipx mtu 1400 mru 1400

Где ms-dns - DNS сети. Указаны публичные адреса Google, но можно выставить свои, если таковые имеются. MTU и MRU по умолчанию установлены в значение 1500. Если удалить эти две строки, то будет использоваться значение по умолчанию. В моём случае при значениях по умолчанию наблюдается большая потеря пакетов. То есть к этим строкам подход индивидуальный. Всё зависит от настроек клиентской стороны и от скорости соединения в целом.

Перезагружаем pptp сервер

Service pptpd restart

Проверяем.

Netstat -alpn | grep:1723

Если получаем нечто похожее на то, что на скриншоте, то всё работает как надо.

Создаём правила NAT для iptables

Iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE && iptables-save

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

Iptables --table nat --append POSTROUTING --out-interface ppp0 -j MASQUERADE iptables -I INPUT -s 10.0.0.0/8 -i ppp0 -j ACCEPT iptables --append FORWARD --in-interface eth0 -j ACCEPT

Сохраняем

Iptables-save

Если вы используете стороннюю программу для настроек фаервола, то перед тем как вносить через неё изменения, следует убедиться, что принятые только что правила отображаются в этой программе. Я использую панель управления Webmin и фаервол обычно настраиваю через неё. Соответственно там отображаются лишь те правила, которые были внесены через неё. Если добавить правило и применить, то изменения, принятые через терминал в процессе настройки PPTP сервера перезапишутся. Чтоб этого не произошло, в Webmin, в настройках фаервола нужно вернуть текущую конфигурацию iptables. Убеждаемся, что принятые изменения присутствуют в списке правил и только тогда жмём «сохранить».

На этом всё. Ниже два скриншота с настройками подключения на стороне клиента (Windows и Linux).

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

Поскольку PPTP не является примером безотказности ввиду своих сложных отношений с фаерволом, то можно слегка ускорить Сеть, завернув трафик через прокси сервер. То есть клиенты локальной сети будут выходить из неё в Интернет через прокси сервер. Как установить и настроить Squid я . Ниже конфигурация Squid 3.3 для Ubuntu 14.04, позволяющая клиентам локальной сети выходить в Интернет.

Http_port 8085 icp_port 0 cache_mem 256 MB memory_replacement_policy lru maximum_object_size_in_memory 512 KB cache_swap_low 90 cache_swap_high 95 access_log /var/log/squid3/access.log squid logfile_rotate 12 refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320 dns_nameservers 8.8.8.8 8.8.4.4 positive_dns_ttl 6 hours negative_dns_ttl 1 minutes #auth_param basic program /usr/lib/squid3/basic_ncsa_auth /etc/squid3/passwords #auth_param basic children 5 #auth_param basic realm Please provide your username and password. #auth_param basic credentialsttl 24 hour #acl ncsa_users proxy_auth REQUIRED acl localnet src 10.0.0.0/8 # RFC 1918 possible internal network acl localnet src 172.16.0.0/12 # RFC 1918 possible internal network acl localnet src 192.168.0.0/16 # RFC 1918 possible internal network acl localnet src fc00::/7 # RFC 4193 local private network range acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines acl SSL_ports port 443 # https acl SSL_ports port 22 # ssh acl All_ports port 1-65535 # unregistered ports acl CONNECT method CONNECT http_access allow localnet #http_access allow ncsa_users http_access allow All_ports http_access allow CONNECT SSL_ports http_access deny all coredump_dir /var/spool/squid3 request_header_access Cache-Control deny all

В данной конфигурации Squid будет обслуживать клиентов локальной сети без пароля, из внешних сетей доступ к нему будет закрыт. Если раскомментировать закомментированые строки конфигурации, то клиенты локальной сети по прежнему смогут обращаться к нему без пароля, но так же будет возможен доступ из вне, но уже с паролями, указанными в файле «passwords».

Для клиентов локальной сети адрес прокси должен быть локальным. Смотрите скриншот выше с выводом команды «ifconfig». У меня на сервере два физических сетевых интерфейса: eth0, который смотрит в Интернет и eth1 - интерфейс, смотрящий в локальную сеть. Таким образом в моём случае адрес прокси будет 10.128.9.55. Для клиентов из внешних сетей в качестве адреса должен служить внешний IP сервера.

Таким образом PPTP нет необходимости пробрасывать трафик от клиента во внешнюю сеть через фаервол. Этим будет заниматься Squid.

На этом всё. Наша сеть работает.

Предположим, вы не доверяете VPN-сервисам, либо вас не устраивают высокие тарифы, либо хотите иметь полный контроль над сервером, с возможностью подключать сколько угодно клиентом и использовать любые протоколы. Для вас и предназначен данный раздел! Здесь мы рассмотрим процесс настройки VPN-сервера на Linux, на машине с Debian 7 64bit на борту и OpenVPN, в качестве реализации.

Процесс настройки VPN вручную состоит из нескольких этапов:

Организация сертификационного центра
Настройка VPN-сервера, выдача сертификата
Настройка VPN клиента/ов, выдача сертификататов

Прежде всего стоит сказать, две вещи:

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

Разворачиваем сертификационный центр

Настройка VPN начинается с построения (Public Key Infrastructure) на основе x.509 сертификатов и открытых ключей - это программный комплекс, включающий в себя сам СА со списком отзыва сертификатов и софт для генерации ключей. Выдавать сертификаты можно несколькими способами:

Безопасный метод Создается PKI и сертификационный центр, аналогичный софт ставится на машины клиентов. Чтобы получить сертификат, клиент должен сформировать запрос и закрытый ключ - запрос передается СА - СА подписывает его или отклоняет - подписанный сертификат передается клиенту. Передача происходит вручную, или по защищенным каналам.
Сертификационный центр самостоятельно генерирует закрытый ключ и сертификат, или оные вместе в зашифрованном пакете PKCS12 - пакет передается на машину клиента — клиент может подключаться к VPN.

Мы говорили об этом выше, но повторим - сертификаты и ключи нужны для ограничения круга лиц, имеющих доступ к серверу; передавать закрытые ключи по сети крайне нежелательно (по крайней мере, в незашифрованном виде), открытый ключ распространяется свободно и математически связан с закрытым - он служит для расшифровки данных, зашифрованных закрытым ключом. А сертификаты объединяют в себе функции открытого ключа и подтверждают, что такой-то ключ принадлежит такому-то хосту, действует столько-то, и с этим ключом можно получить доступ к серверу. Проще говоря, x.509 сертификат - это улучшенный открытый ключ из философии ассиметричного шифрования.

Для настройки OpenVPN потребуется пакет openvpn - он лежит в репозиториях большинства Linux-систем.

# apt-get update

# apt-get install openvpn

После установки, по пути “/usr/share/doc/openvpn/examples/” должна появиться директива /easy-rsa/2.0. Если её нет - дополнительно установите пакет easy-rsa:

# apt-get install easy-rsa

И тогда нужная папка появится по пути “/ush/share/easy-rsa”

Настройку СА не стоит производить из под root [в идеале - это вообще должна быть отдельная машина, не подключенная к сети], но так как в нашем случае СА и VPN-сервер - одна и та же машина, то будем работать под root. В противном случае, лучше создать для СА отдельного пользователя без рутовых прав.

# useradd - s /bin/bash -m ca

# passwd ca

Дабы избежать удаления всех конфигов при очередном обновлении, перенесем утилиту easy-rsa в директиву конфигов openvpn:

# sudo cp -R /usr/share/doc/openvpn/examples/easy-rsa/ /etc/openvpn

# sudo cp -R /usr/share/easy-rsa/ /etc/openvpn

И перейдем в директорию easyrsa:

# cd /etc/openvpn/easy-rsa/2.0

В данной директории лежат скрипты для генерации сертификатов и формирования запросов на сертификаты, примеры конфига openssl, и главное - подробный файл README, объясняющий, как это всё работает. Распакуйте его утилитой gzip:

# gzip -d README.gz

И, желательно, изучите.

Файл vars - своеобразный шаблон, на основании которого заполняются поля сертификатов - его мы и отредактируем в первую очередь. Нас интересуют лишь следующие строки:

# Битовая длина алгоритма шифрования, которым шифруется закрытый ключ. Если вы параноик - измените значение на 2048 - это замедлит взлом, но и скорость VPN-соединения слегка упадет.

export KEY_SIZE=1024

# Срок годности в днях по умолчанию, для корневого сертификата сертификационного центра.

export CA_EXPIRE=3650

# Срок годности по умолчанию для всех сертификатов.

export KEY_EXPIRE=3650

# Информация о владельце сертификата. Ни на что, особо, не влияет, если вы разворачиваете сеть VPN для себя.

export KEY_COUNTRY="RU" #Код страны владельца

export KEY_PROVINCE="RU" #Код области владельца

export KEY_CITY="Moscow" #Город

export KEY_ORG="cs-companion" #Организация

export KEY_EMAIL=" Этот адрес электронной почты защищен от спам-ботов. У вас должен быть включен JavaScript для просмотра. " #контактный email

export KEY_EMAIL= Этот адрес электронной почты защищен от спам-ботов. У вас должен быть включен JavaScript для просмотра. #контактный email 2

Сохраним, применим изменения и очистим папку.keys скриптом./clean-all:

source ./vars

source ./clean-all

(Важно: если после изменений файл vars не запускается - сделайте его исполняемым: “chmod +x ./vars”)

Шаблон готов - можно создавать корневой сертификат СА, и на его основе создавать сертификаты остальных пользователей. Для генерации корневого сертификата выполним:

# ./build-ca

Во время генерации вам предложат самостоятельно заполнить поля, хотя можно просто жать Enter - тогда они заполнятся на основании шаблона.

Итак, после генерации в папке./keys появилось два ключа:

ca.crt - открытый
ca.key - закрытый.

Наверняка вам будет интересно, как же выглядит этот сертификат изнутри - как-то так:

Или на человеческом:

Посмотреть содержимое сертификата в виде текста можно средствами openssl, вот такой командой:

# openssl x509 -in [путь/к/сертификату] -noout -text

В сгенерированный нами сертификат входит:

Версия
Уникальный серийный номер
Информация о держателе (организация, имя, контакты).
Сроки начала и конца действия сертификата
Информация о использумых алгоритмах.
Открытый ключ
Цифровая подпись сертификата

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

Немного теории.

Файл ca.key должен лежать только на машине самого сертификационного центра, а вот открытый - напротив, должен передаваться на каждую машину, которая собирается сделать запрос на сертификат и затем получить доступ к VPN-серверу.

Попробуем объяснить, как это работает:

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

свой открытый и закрытый ключ
открытый ключ СА
открытые ключи всех клиентов,

У СА должен быть:

свой закрытый и открытый ключ,
открытый ключ сервера и всех клиентов.

А у всех клиентов, которые будут взаимодействовать с сервером:

свои закрытые и открытые ключи
открытый ключ сервера и СА

Но всё это - в идеале, то есть в случае, если сертификаты выдаются по запросу. Мы же используем протокол PKCS12, значительно упрощающий развертывание OpenVPN сети — пакеты с сертификатами мы будем генерировать самостоятельно, а клиенту нужно только прописать путь к нему в конфигах, и IP-адрес сервера.

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

# ./build-key-server [имя-сертификата-сервера]

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

Помимо ключей, OpenVPN использует дополнительные средства защиты - хэш-суммы и протокол Диффи-Хеллмана. Не будем углублятся в теорию работы второго - просто сгенерируйте одноименный файл командой:

./build-dh

Итак, вернемся в папку./keys, и что мы видим:

dh1024.pem - Файл Диффи-Хеллмана
ca.crt - открытый ключ (сертификат) СА
ca.key - закрытый ключ СА
vpnserver.key - закрытый ключ сервера
vpnserver.crt - сертификат сервера.

Все они, кроме закрытого ключа СА, должны быть перемещены в главную директорию VPN-сервера - /etc/openvpn.

Если вы дошли до этого этапа - значит наш СА работает как часы. Следующим шагом будет настройка самого VPN-сервера и клиентов, а пока подробнее остановимся на том, как генерировать и удалять сертификаты.

Работа с CRL и выдача сертификатов.

Как генерировать сертификаты:

build-key [имя] - сгенерировать пару закрытый/открытый сертификат.

build-key-pass [имя] - аналогично, но сертификат защищен паролем, который спрашивается каждый раз при использовании.

build-key-pkcs12 - сгенерировать сертификаты в виде pkcs12-пакета.

Что же такое этот pkcs12-пакет? Цитируя руководство openssl - “Some would argue that the PKCS#12 standard is one big bug:-)” - и, тем не менее, это наиболее удобный способ распространения сертификатов. Как уже говорилось - это своеобразный пакет, зашифрованный на стороне сервера, и включающий в себя связку сертификатов - открытый СА; закрытый и открытый клиента. Поступая к клиенту, софт OpenVPN посылает с ним запрос на VPN-сервер, а сервер, если такой пакет был сгененерирован подходящим центром сертификации, распознает его и пускает клиента в свою сеть. С p12 пакетами вы получаете дополнительный слой шифрования пакетов и больше нет необходимости пересылать каждый сертификат отдельно.

Сгенерируем такой пакет для нашего клиента:

# ./build-key-pkcs12 lain.iwakura.Vorona

Во время генерации вы должны ввести пароли [пароль закрытого ключа и пароль экспорта], последний из которых будет спрашиваться при каждом подключении, а также заполнить данные сертификата. После этого - можно передавать пакет на машину клиента - отправим пакет lain.iwakura.Vorona.p12 на машину клиента под Arch Linux, через scp.

# scp ./keys/lain.iwakura.Vorona.p12 user@ip:/home/

Позже, при настройке клиента, он нам понадобится.

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

Выполните “./list-crl” - результатом выполнения будет создание списка отзыва сертификатов - CRL. CRL необходим для того, чтобы администратор СА смог в любой момент запретить какому-либо хосту доступ к серверу со своим сертифкатом.

Отозвать сертификат предельно просто - командой:

./revoke-full [имя]

К примеру, сгенерируем pkcs12 сертификат iwakuralain и тут же отзовем:

./revoke-full iwakuralain

Посмотреть список отозванных сертификатов можно командой:

./list-crl

А самой базой данных отозванных сертификатов является файл crl.pem из папки keys. После отзыва очередного сертификата необходимо скопировать его в папку /etc/openvpn VPN-сервера и перезагрузить, для обновления базы данных:

# /etc/init.d/openvpn restart

VPN – Virtual Private Network (виртуальная частная сеть) – простыми словами, это служба, которая обеспечивает связь между удалёнными точками, путём объединения их в одну общую сеть. Протокол связи – PPPoE (point-to-point-over-ethernet), т.е. это туннелированное соединение с определёнными настройками шифрования, что в свою очередь позволяет не только объединить две удалённые сети в один сегмент, но и защитить такое соединение от перехвата пакетов злоумышленниками.

VPN можно использовать не только сетевым администраторам для нужд крупных компаний (объединение двух офисов), но и простым пользователям. Например для сетевых баталий, в случаях, когда игра не имеет официального сервера и не подразумевает неофициальные, а поиграть с товарищами ну очень хочется. Тогда можно объединить 2,3,4 и более компьютеров в единую сеть. Даже если вы отдалены от товарищей и находитесь на другом континенте, пользуетесь услугами другого провайдера и прочее…

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

Итак, приступаем к установке и настройке:

Пункт первый – устанавливаем пакет pptpd. В Linux Debian/Ubuntu и подобных воспользуйтесь утилитой apt-get. Кстати пакет находится обычно в стандартных репозиториях, так что дополнительно ничего подключать не надо.

apt-get install pptpd

Пункт второй – конфигурируем главный файл – pptpd-options. Лежит файлик в папке /etc/ppp и редактируется с правами администратора редактором на ваш вкус. Кстати, на всякий случай, чтобы было понятнее понять что к чему, я потрудился перевести pptpd-options на русский язык. Собственно вот он:

##############################################################################

Перевод pptpd-options на русский язык.

Вы можете использовать pptpd-options с комментариями на русском языке в своей системе.

Вы можете свободно распространять текст перевода pptpd-options со ссылкой на источник.

Конфигурационный файл pptpd-options переведён Squ1sh специально для сайт

###############################################################################

Аутентификация

Имя локальной системы аутентификации

(Должно быть вторым в файле /etc/ppp/chap-secrets) (после имени пользователя)

name pptpd

Опционально – имя домена для аутентификации.

domain mydomain.net

Префикс домена из имени пользователя до аутентификации.

(применяется если вы используете pppd с chapms-strip-domain патчем)

#chapms-strip-domain

Шифрование

На заметку – refuse-выкл. тип шифрования, require – вкл. тип шифрования

refuse-pap

refuse-chap

Включим MPPE 128-bit шифрование. На нём и будет всё завязано.

(Внимание! MPPE использует MSCHAP-V2 во время аутентификации)

require- mppe-128

Сеть и маршруты

Если pppd работает для Microsoft Windows клиентов, включите в

pppd поддержку одного или двух DNS (Domain Name Server – Сервер имён). Для linux клиентов не работает!

адресов для клиентов. Первым указывается адрес первичного DNS сервера вашей #локальной сети; Вторым — вторичный (если таковой есть)

#ms-dns 10.0.0.1

#ms-dns 10.0.0.2

По той же схеме можно указать адреса WINS серверов.

#ms-wins 10.0.0.3

#ms-wins 10.0.0.4

#Proxyarp — это одна из функциональных возможностей протокола ARP, позволяющая #имитировать принадлежность разных IP-сетей к одному Ethernet-сегменту

#(использование одного сетевого префикса для обеих сетей). Короче опция должна #быть включена, ибо без неё никак

proxyarp

Не назначать маршрутом по умолчанию (defaultroute – назначение этого #соединения маршрутом по умолчанию в таблице маршрутизации)

nodefaultroute

Пишем логи

Включаем дебаггинг с записью логов.

Показать все установленные опции.

(Часто по просьбе список рассылки, чтобы поверить опции). Лично я вообще не #понял что это за вещь, и с чем её едят. Я даже сомневаюсь в правильности

#перевода… Ну да ладно, всё равно опция не важна.

Разное

Использовать блокировку портов UCPP, чтобы одновременно несколько # последовательных устройств не обращались к одному порту

Отключить BSD-Compress сжатие.

nobsdcomp

###########################################################################

Как вы могли заметить, я выделил несколько параметров жирным. Это минимальные 7 параметров для приемлемой работы VPN сервера. Т.е. ваш минимальный конфиг pptpd-options может выглядеть так:

name pptpd

require-mschap-v2

require-mppe-128

proxyarp

nodefaultroute

nobsdcomp

Его вполне хватит для того, чтобы играться по сети, или объединить 2 офиса в сеть. Но, если не указать DNS-сервера в файле pptpd-options, то невозможно будет обращаться к компьютеру по Net-Bios имени (только по ip-адресу), что создаст некоторые трудности при не статичных адресах (работающий DHCP-сервер в сети), если вы не знаете адреса, а только имя нужной машины.

________________________________________

Пункт третий – настройка адресов/диапазона адресов в VPN. Пользователь, который будет подключаться к нашей сети должен естественно получить ip-адрес. Вы можете выдавать адреса из диапазона, либо привязать каждого пользователя к определённому адресу (уж как вам нравится). Если привяжете IP к имени пользователя VPN, то можете пропустить настройку pptpd.conf, если будете выдавать адреса из диапазона – читаем внимательно. Итак, файл pptpd.conf. Находится он прямо в корне папки /etc. Из него нам нужно только 2 параметра, их я и перевёл. Листаем файл в самый конец и видим следующее:

IP-адрес сервера в локальной сети

localip 192.168.1.1

Диапазон адресов для клиентов PPTP-сервера

remoteip 192.168.1.50-254

По этому файлу всё.

Пункт четвёртый – заводим пользователей VPN. Список пользователей, паролей и привязанных к ним ip-адресов хранится в файле chap-secrets. Лежит он в /etc/ppp.

Приведу 2 примера добавления пользователей:

#Пример №1 – пользователь получает ip-адрес из указанного нами в /etc/pptpd.conf диапазона адресов

Username pptpd password “*”

#Пример №2 – привязка ip-адреса к аккаунту VPN пользователя.

Username pptpd password “192.168.1.52 ”

Т.е. принцип таков – сначала пишем логин пользователя, потом имя службы (ту, котоую указали в параметре name в начале файла pptpd-options), затем идёт пароль, и в кавычках указываем ip-адрес, или * если выдавать из диапазона. Вот собственно и вся настройка.

Кстати, после того, как отредактируете все нужные файлы – перезапустите службу

/etc/init.d/pptpd restart

Естественно к вашему серверу должен быть доступ извне, т.е. в правилах iptables по необходимости добавить следующее:

Разрешить всем протокол GRE iptables -A INPUT -p gre -j ACCEPT # Разрешить соединение с VPN-сервером; iptables -A INPUT -m tcp -p tcp —dport 1723 -j ACCEPT

ВНИМАНИЕ! Это только половина статьи! О том, как подключаться разными клиентами на разных операционных системах, а так же маршрутизации и приведение примера объединения двух и более офисов в 1 сеть, мы расскажем вам позже.

2015-12-12T18:46:56+00:00 admin Обзоры Статьи pptpd,VPN,Администрирование,Безопасность,Установка

Рассмотрев в предыдущих частях теоретические вопросы перейдем к практической реализации. Сегодня мы рассмотрим создание VPN сервера PPTP на платформе Ubuntu Server. Данный материал рассчитан на читателей, имеющих навыки работы с Linux, поэтому мы не будем отвлекаться на вещи описанные нами в других статьях, таких как настройку сети и т.п. Если вы испытываете затруднения - предварительно изучите другие наши материалы.

Практическое знакомство с VPN мы начнем с PPTP, как наиболее простого в реализации. Однако следует помнить о том, что это слабозащищенный протокол и его не следует использовать для доступа к критически важным данным.

Рассмотрим схему, которую мы создали в нашей тестовой лаборатории для практического знакомства с данной технологией:

У нас имеется локальная сеть 10.0.0.0/24 с сервером терминалов 10.0.0.2 и 10.0.0.1, который будет выполнять функции VPN сервера, для VPN мы зарезервировали сеть 10.0.1.0/24. Внешний интерфейс сервера имеет условный выделенный IP адрес X.X.X.X. Наша цель - предоставить удаленным клиентам доступ к терминальному серверу и общим ресурсам на нем.

Настройка сервера PPTP

Установим пакет pptpd реализующий функционал PPTP VPN:

Sudo apt-get install pptpd

Теперь откроем файл /etc/pptpd.conf и зададим основные настройки VPN сервера. Перейдем в самый конец файла, где укажем адрес сервера в VPN сети:

Localip 10.0.1.1

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

Remoteip 10.0.1.200-250

Адресов нужно выделить не меньше, чем возможных одновременных соединений, лучше с небольшим запасом, так как их увеличение без перезапуска pptpd невозможно. Также находим и раскомментируем строку:

Bcrelay eth1

Это позволит передавать VPN клиентам широковещательные пакеты внутренней сети.

Также можно использовать опции listen и speed , первая позволяет указать IP адрес локального интерфейса для прослушивания входящих PPTP соединений, второй указать скорость VPN соединений в бит/с. Например разрешим серверу принимать PPTP соединения только с внешнего интерфейса:

Listen X.X.X.X

Более тонкие настройки находятся в файле /etc/ppp/pptpd-options . Настройки по умолчанию вполне соответствуют нашим требованиям, однако кратко рассмотрим некоторые из них, чтобы вы имели представление о их назначении.

Секция #Encryption отвечает за шифрование данных и проверку подлинности. Данные опции запрещают использование устаревших и небезопасных протоколов PAP, CHAP и MS-CHAP:

Refuse-pap
refuse-chap
refuse-mschap

Require-mschap-v2
require-mppe-128

Следующая секция #Network and Routing , здесь следует обратить внимание на опцию ms-dns , которая позволяет использовать DNS сервер во внутренней сети. Это может быть полезно при доменной структуре сети или наличия в ней DNS сервера который содержит имена всех ПК сети, что дает возможность обращаться к компьютерам по их именам, а не только по IP. В нашем случае данная опция бесполезна и закомментирована. Подобным образом можно задать и адрес WINS сервера опцией ms-wins .

Здесь же находится опция proxyarp , включающая, как несложно догадаться из названия, поддержку сервером Proxy ARP.

В секции #Miscellaneous содержится опция lock , которая ограничивает клиента одним подключением.

Ivanov * 123 *
petrov * 456 10.0.1.201

Первая запись позволяет подключаться к серверу пользователю ivanov c паролем 123 и присваивает ему произвольный IP адрес, вторая создает пользователя petrov с паролем 456, которому при подключении будет присваиваться постоянный адрес 10.0.1.201.

Перезапускаем pptpd :

Sudo /etc/init.d/pptpd restart

Важное замечание! Если pptpd не хочет перезапускаться, зависая на старте, а в /var/log/syslog добавляя строку long config file line ignored обязательно добавьте в конец файла /etc/pptpd.conf перенос строки.

Наш сервер готов к работе.

Настройка клиентских ПК

В общем случае достаточно настроить VPN соединение с опциями по умолчанию. Однако мы советуем явно указать тип соединения и отключить лишние протоколы шифрования.

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

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

Теперь еще одно важное дополнение. В большинстве случаев доступ к компьютерам локальной сети будет возможен только по IP адресам, т.е. путь \\10.0.0.2 будет работать, а \\SERVER - нет. Это может оказаться неудобным и непривычным для пользователей. Существует несколько способов решения данной проблемы.

Если локальная сеть имеет доменную структуру, достаточно указать DNS сервером для VPN подключения DNS сервер контроллера домена. Воспользуйтесь опцией ms-dns в /etc/ppp/pptpd-options сервера и данные настройки будут получены клиентом автоматически.

Если DNS сервер в локальной сети отсутствует, то можно создать и использовать WINS сервер, информацию о нем также можно автоматически передавать клиентам при помощи опции ms-wins . И наконец, если удаленных клиентов немного, использовать на клиентских ПК файлы hosts (C:\Windows\System32\drivers\etc\hosts), куда следует добавить строки вида.