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

Предположим, вы не доверяете 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, значительно упрощающий развертывание Open VPN сети — пакеты с сертификатами мы будем генерировать самостоятельно, а клиенту нужно только прописать путь к нему в конфигах, и 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

Не является эталоном безопасности и плохо дружит с фаерволами, но является одним из самых простых способов построения изолированной локальной сети и установки защищённого соединения с ней. При том, что протокол 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.

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

Инструкция

Проверьте, существует ли поддержка протокола PPP в ядре вашей операционной системы. Проще всего это сделать, просмотрев значения опций с префиксом CONFIG_PPP в файле текущей конфигурации ядра. Обычно он устанавливается в каталог /boot и имеет имя, начинающееся с config. Узнайте имя данного файла при помощи команды
ls /boot
или
ls /boot | grep conf
Выведите нужные строки командой cat, осуществив фильтрацию при помощи grep. Например:
cat /boot/config-2.6.30-std-def-alt15 | grep PPP
Проанализируйте строки, содержащие опции CONFIG_PPP, CONFIG_PPP_ASYNC, CONFIG_PPP_SYNC_TTY. Если перед ними нет символа #, поддержка соответствующего функционала имеется (при значениях m - в виде внешнего модуля, при значениях y - включена в ядро).

Проверьте, инсталлировано ли в системе клиентское программное обеспечение для установления VPN-соединений. Нужный пакет обычно носит имя, начинающееся с pptp. Используйте apt-cache с опцией search для поиска нужного пакета в доступных репозиториях и rpm с опцией -qa для того, чтобы проверить, установлен ли пакет. При работе в графической среде может иметь смысл воспользоваться такими программами, как synaptic.

Произведите инсталляцию недостающего программного обеспечения. Используйте подходящие менеджеры пакетов (apt-get, rpm в консоли, synaptic в графической среде, и т.д.). Если была осуществлена инсталляция пакета ppp с модулями ядра для поддержки соответствующего протокола, перезагрузите компьютер.

Попробуйте настроить VPN при помощи скриптов конфигурирования, таких как pptp-command или pptpsetup. Часто они входят в состав пакетов с клиентским ПО для установки VPN-соединений. Для получения справки по параметрам командной строки данных утилит используйте их запуск с опцией --help. Например:
pptpsetup --help
Если конфигурирующие скрипты установлены не были, перейдите к следующему шагу для осуществления ручной настройки VPN.

Создайте каталог /etc/ppp, а в нем - файл с именем chap-secrets. Откройте файл в текстовом редакторе. Добавьте в него строку вида:
LOGIN SERVER PASSWORD *
Значения LOGIN и PASSWORD - имя пользователя и пароль. Они должны предоставляться провайдером услуг доступа к VPN. Вместо SERVER укажите произвольное имя соединения или *.

Создайте каталог /etc/ppp/peers. Создайте в нем файл, имеющий имя, совпадающее со значением SERVER из предыдущего шага (или произвольное имя, если было указано значение *). Отредактируйте этот файл, добавив в него информацию вида:
pty "pptp SERVER --nolaunchpppd"
name LOGIN
ipparam SERVER
remotename SERVER
lock
noauth
nodeflate
nobsdcomp
Значения LOGIN и SERVER здесь - те же, что и в шаге 5. На этом настройку VPN в Linux можно считать законченной.

Полезный совет

Подключение к VPN осуществляйте командой
pppd call SERVER
где SERVER - имя соединения, совпадающее с аналогичным значением из шага 6.

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

Вам понадобится

- пароль пользователя root.

Инструкция

Запустите программу конфигурирования системы. Откройте меню запуска приложений графической оболочки, разверните раздел настроек. Найдите пункт «Центр управления системой» или System management center. Кликните по нему. Введите пароль пользователя root, если он будет запрошен. Данное приложение также можно выполнить из консоли или окна запуска программ, введя команду acc.

Перейдите к конфигурированию сетевых интерфейсов. В окне центра управления системой найдите раздел Network. Кликните по кнопке Ethernet interfaces.

Настройте сетевые интерфейсы. На текущей странице центра управления системой в списке Interfaces выделите нужный пункт. В выпадающем списке Configuration выберите метод конфигурирования: Manually, Use DHCP или Zeroconf. Введите адреса DNS-серверов в поле DNS servers. При выборе ручного способа конфигурирования (Manually), задайте IP-адрес и сетевую маску в полях IP address и Netmask соответственно. Нажмите кнопку Apply для применения изменений. Нажмите кнопку Main для перехода к предыдущей странице.

Казалось бы — про VPN не говори, про него все сказано. В сети выложено огромное количество настроек и HOW-TO на любой вкус. Скрупулезный анализ показал, что основные проблемы новичков возникают на этапах аутентификации клиента и VPN-сервера, а также настройки роутинга. На них мы остановимся подробно. Попутно выяснилось что настройки VPN-соединения можно сильно упростить и тем самым облегчить понимание ключевых параметров.

Именно для облегчения понимания мы рекомендуем всем новичкам настраивать VPN из командной строки и не пользоваться (полу)автоматическими конфигураторами VPN — как показывает практика, от их непрозрачных настроек одни неприятности. Как вы увидите ниже, этих настроек очень небольшое количество, так что незачем вставать на костыли, чтобы бежать стометровку. К тому же командная строка вам сослужит добрую службу, когда пойдет что-то не так. Вы всегда можете запостить свои конфиги и вывод консольных команд, и суровые бородатые дядьки, которые давно на «ты» с линуксом, вам помогут. Потому что вы говорите с ними на одном языке. И наоборот, что-нибудь вроде «в этом окошке я отмечаю галочкой второй снизу пункт» практически гарантирует отсутствие обратной связи.

Настраивать VPN-соединение мы будем по шагам. В конце каждого шага — шаг проверки. Все команды в командной строке вводятся от имени суперпользователя (root). Готовы? Тогда вперед!

Что нам нужно для работы

Для поднятия и настройки VPN-соединения нам потребуются всего две программы — ppp и pptp . Программа ppp с вероятностью 99% уже стоит в вашем дистрибутиве, пакет, содержащий pptp , в разных дистрибутивах называется по-разному, в основном pptp-linux . После установки в системе должны присутствовать два исполняемых файла — /usr/sbin/pppd и /usr/sbin/pptp . Вкратце — pptp создает туннель к VPN-серверу, через который ppp соединяется и работает как обычное модемное соединение.

Естественно, для поднятия соединения нам необходима рабочая локальная сеть и данные провайдера об IP (или имени) VPN-сервера, VPN-логине и VPN-пароле. Также пригодится информация об используемом протоколе аутентификации и о наличии шифрования траффика. Если ее нет — ничего страшного. Подавляющее большинство провайдеров используют протокол аутентификации MS-CHAP v2, а о наличии шифрования нам подскажут логи ошибок pppd . Подсказка: если у вас стоит MS Windows и там поднято VPN-соединение, его параметры можно посмотреть на вкладке соединения «Сведения». Нас интересуют параметры «Проверка подлинности» и «Шифрование».

Все манипуляции мы будем проводить на имеющейся под рукой домашней сети Корбина телеком. Итак, провайдер снабдил нас следующей информацией:
Локальная сеть:

IP: 10.167.17.38
Маска подсети: 255.255.0.0.
Шлюз (gateway): 10.167.0.17
DNS1: 195.14.50.1
DNS2: 195.14.50.21

VPN параметры:

Имя VPN-сервера: vpn.corbina.net
Логин: VPN_LOGIN
Пароль: VPN_PASSWORD

Проверка работоспособности локальной сети

Если сеть уже настроена, мы должны увидеть примерно следующее

# ifconfig eth0

RX packets:2884 errors:0 dropped:0 overruns:0 frame:0
TX packets:25 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:243742 (238.0 Kb) TX bytes:2242 (2.1 Kb)
Interrupt:19

# ip a sh dev eth0
3: eth0: mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:13:D4:68:B2:3E brd ff:ff:ff:ff:ff:ff
inet 10.167.17.38/16 brd 10.167.255.255 scope global eth0
<# route -n
Kernel IP routing table

0.0.0.0 10.167.0.17 0.0.0.0 UG 0 0 0 eth0

# ip r
10.167.0.0/16 dev eth0 proto kernel scope link src 10.167.17.38
default via 10.167.0.17 dev eth0 scope link

Если ничего подобного не выводится,поднимаем сеть и указываем в качестве шлюза по умолчанию наш шлюз

Ifconfig eth0 10.167.17.38 netmask 255.255.0.0 up

Ip a a 10.167.17.18/16 dev eth0
ip l s up dev eth0
ip r a default via 10.167.0.17

Прописываем IP DNS-серверов в файл /etc/resolv.conf Он должен выглядень следующим образом:

# cat /etc/resolv.conf
nameserver 195.14.50.1
nameserver 195.14.50.21

Если сеть работоспособна, должны пинговаться шлюз и VPN-сервер. Проверяем

# ping -c5 10.167.0.17
PING 10.167.0.17 (10.167.0.17) 56(84) bytes of data.
64 bytes from 10.167.0.17: icmp_seq=1 ttl=255 time=3.95 ms
64 bytes from 10.167.0.17: icmp_seq=2 ttl=255 time=0.526 ms
64 bytes from 10.167.0.17: icmp_seq=3 ttl=255 time=0.528 ms
64 bytes from 10.167.0.17: icmp_seq=4 ttl=255 time=3.31 ms
64 bytes from 10.167.0.17: icmp_seq=5 ttl=255 time=0.534 ms
# ping -c5 vpn.someserver.net

64 bytes from vpn8-l0.msk.corbina.net (195.14.38.8): icmp_seq=1 ttl=248 time=1.17 ms
64 bytes from vpn8-l0.msk.corbina.net (195.14.38.8): icmp_seq=2 ttl=248 time=1.16 ms
64 bytes from vpn8-l0.msk.corbina.net (195.14.38.8): icmp_seq=3 ttl=248 time=1.19 ms
64 bytes from vpn8-l0.msk.corbina.net (195.14.38.8): icmp_seq=4 ttl=248 time=1.17 ms
64 bytes from vpn8-l0.msk.corbina.net (195.14.38.8): icmp_seq=5 ttl=248 time=1.00 ms

Предварительная настройка роутинга

Примечание: Предварительная настройка роутинга необходима в том случае, когда VPN и/или DNS-сервера находятся в других подсетях. Если это не так (да вы счастливчик!) — смело пропускайте этот шаг.

Для начала узнаем IP нашего VPN-сервера с помощью команды ping .

# ping -c5 vpn.corbina.net
PING vpn.corbina.net (195.14.38.8) 56(84) bytes of data.

Как видно из команды ping, IP VPN сервера 195.14.38.8

Примечание: Чтобы не копаться в частностях, мы допускаем в данном примере, что vpn.corbina.net имеет только один IP. Ситуацию, когда хост vpn.corbina.net имеет не один а несколько IP адресов (на самом деле их 20) мы рассмотрим в шаге «Автоматизация».

Добавляем в нашу таблицу роутинга статические маршруты на VPN и DNS сервера:

Route add -host 195.14.50.1 gw 10.167.0.17
route add -host 195.14.50.21 gw 10.167.0.17
route add -host 195.14.38.8 gw 10.167.0.17

Ip r a 195.14.50.1 via 10.167.0.17
ip r a 195.14.50.21 via 10.167.0.17
ip r a 195.14.38.8 via 10.167.0.17

Удаляем маршрут по умолчанию

Таблица маршрутизации будет выглядеть так:

# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
195.14.50.21 10.167.0.17 255.255.255.255 UGH 0 0 0 eth0
195.14.50.1 10.167.0.17 255.255.255.255 UGH 0 0 0 eth0
195.14.38.8 10.167.0.17 255.255.255.255 UGH 0 0 0 eth0
10.167.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0

# ip r
195.14.50.21 via 10.167.0.17 dev eth0
195.14.50.1 via 10.167.0.17 dev eth0
195.14.38.8 via 10.167.0.17 dev eth0
10.167.0.0/16 dev eth0 proto kernel skope link src 10.167.17.38

Проверка: мы должны успешно пинговать DNS и VPN сервера.

# ping -c5 195.14.50.1
PING 195.14.50.1 (195.14.50.1) 56(84) bytes of data.
64 bytes from 195.14.50.1: icmp_seq=1 ttl=56 time=4.45 ms
64 bytes from 195.14.50.1: icmp_seq=2 ttl=56 time=1.30 ms
64 bytes from 195.14.50.1: icmp_seq=3 ttl=56 time=1.22 ms
# ping -c5 195.14.50.21
PING 195.14.50.21 (195.14.50.21) 56(84) bytes of data.
64 bytes from 195.14.50.21: icmp_seq=1 ttl=56 time=0.982 ms
64 bytes from 195.14.50.21: icmp_seq=2 ttl=56 time=0.954 ms
64 bytes from 195.14.50.21: icmp_seq=3 ttl=56 time=1.02 ms
# ping -c5 195.14.38.8
PING 195.14.38.8 (195.14.38.8) 56(84) bytes of data.
64 bytes from 195.14.38.8: icmp_seq=1 ttl=248 time=1.34 ms
64 bytes from 195.14.38.8: icmp_seq=2 ttl=248 time=2.60 ms
64 bytes from 195.14.38.8: icmp_seq=3 ttl=248 time=1.09 ms

Настройка параметров VPN-соединения. Тестовый запуск

Все параметры нашего VPN соединения мы запишем в файле /etc/ppp/peers/corbina . Создадим его и наполним следующим содержанием:

Pty "pptp 195.14.38.8 --nolaunchpppd"
user VPN_LOGIN
password "VPN_PASSWORD"
nodeflate
nobsdcomp
noauth

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

Убеждаемя, что в файлах /etc/ppp/options , ~/.ppprc , /etc/ppp/options.ppp0 нет незакомментированных параметров, которыми бы система могла затереть наши настройки. Если есть — комментируем

Поднимаем VPN соединение

Pppd call corbina debug nodetach

Появятся логи соединения. Если все прошло успешно, они будут выглядеть примерно так:

# pppd call corbina debug nodetach
using channel 2
Using interface ppp0
Connect: ppp0 <--> /dev/pts/0
sent
rcvd
sent
sent
rcvd
sent
rcvd
sent
rcvd
rcvd

CHAP authentication succeeded
sent
rcvd
sent
rcvd
sent
rcvd
sent
rcvd
Cannot determine ethernet address for proxy ARP
local IP address 89.178.77.182
remote IP address 195.14.38.8
Script /etc/ppp/ip-up started (pid 4072)
Script /etc/ppp/ip-up finished (pid 4072), status = 0x0

На соседнем терминале убедимся, что VPN-соединение установлено. Должен появиться сетевой интерфейс ppp0 :

# ifconfig
eth0 Link encap:Ethernet HWaddr 00:13:D4:68:B2:3E
inet addr:10.167.17.38 Bcast:10.167.255.255 Mask:255.255.0.0
inet6 addr: fe80::213:d4ff:fe68:b23e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:24990 errors:0 dropped:0 overruns:0 frame:0
TX packets:97 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2327027 (2.2 Mb) TX bytes:8516 (8.3 Kb)
Interrupt:19

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:13496 errors:0 dropped:0 overruns:0 frame:0
TX packets:13496 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1387313 (1.3 Mb) TX bytes:1387313 (1.3 Mb)

ppp0 Link encap:Point-to-Point Protocol
inet addr:89.178.77.182 P-t-P:195.14.38.8 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:40 (40.0 b) TX bytes:46 (46.0 b)

Если VPN сервер использует шифрование, соединение закончится ошибкой [ЗДЕСЬ ДОЛЖНЫ БЫТЬ ЛОГИ ОШИБКИ]. В этом случае добавим в файл /etc/ppp/peers/corbina строчку

и загрузим соответствующий модуль ядра командой

Запускаем снова. Все должно заработать.

Обратите внимание на параметр MTU интерфейса ppp0 . По умолчанию он равен 1500. Если ваш провайдер использует другую величину MTU (допустим, 1492) — в тот же файл конфигурации etc/ppp/peers/corbina добавляем строчку

Окончательная настройка роутинга

Итак, мы подняли VPN соединение, но в интернет выйти не можем — машина пока не знает, где искать интернет-хосты. Для этого мы должны добавить маршрут по умолчанию через интерфейс ppp0 в нашу таблицу маршрутизации (помните — старый маршрут по умолчанию мы удалили). В качестве шлюза по умолчанию теперь выступает remote IP address, который нам любезно предоставил VPN сервер — 195.14.38.8 (да-да, в нашем случае он совпадает с IP VPN сервера!). Этот remote IP address присутствует как в логах pppd (remote IP address 195.14.38.8), так и в параметрах интерфейса ppp0 , которые выводятся на экран командой ifconfig (P-t-P:195.14.38.8). Вводим:

Route add default gw 195.14.38.8

Route add default dev ppp0

что в данном контексте — одно и то же Теперь попробуем пропинговать какой-нибудь интернет-хост

# ping -c5 www.ya.ru
PING ya.ru (213.180.204.8) 56(84) bytes of data.
64 bytes from ya.ru (213.180.204.8): icmp_seq=1 ttl=61 time=2.11 ms
64 bytes from ya.ru (213.180.204.8): icmp_seq=2 ttl=61 time=2.23 ms
64 bytes from ya.ru (213.180.204.8): icmp_seq=3 ttl=61 time=2.39 ms

Работает!

Автоматизация

Теперь, когда соединение оттестировано, можно подумать и об автоматизации. Когда pppd устанавливает соединение, он автоматически выполняет скрипт /etc/ppp/ip-up , когда соединение рвется — выполняется скрипт /etc/ppp/ip-down . Значит, в эти файлы и надо забить весь роутинг, который в предыдущих пунктах мы вводили руками.

Мы не случайно сначала рассмотрели идеальный вариант, когда VPN сервер провайдера представлен в единственном числе и имеет один IP. В этом случае именем хоста (vpn.corbina.net ) можно пренебречь и использовать в настройках только его IP, что мы и сделали. Однако если провайдер большой, под именем VPN сервера скрывается несколько серверов с разными IP, что позволяет провайдеру динамически регулировать нагрузку на них. Для того, чтобы выяснить, какие IP имеет хост vpn.corbina.net , воспользуемся командой host из пакета dnsutils

# host vpn.corbina.net
vpn.corbina.net has address 195.14.38.19
vpn.corbina.net has address 195.14.38.20
vpn.corbina.net has address 195.14.38.1
vpn.corbina.net has address 195.14.38.2
vpn.corbina.net has address 195.14.38.3
vpn.corbina.net has address 195.14.38.4
vpn.corbina.net has address 195.14.38.5
vpn.corbina.net has address 195.14.38.6
vpn.corbina.net has address 195.14.38.7
vpn.corbina.net has address 195.14.38.8
vpn.corbina.net has address 195.14.38.9
vpn.corbina.net has address 195.14.38.10
vpn.corbina.net has address 195.14.38.11
vpn.corbina.net has address 195.14.38.12
vpn.corbina.net has address 195.14.38.13
vpn.corbina.net has address 195.14.38.14
vpn.corbina.net has address 195.14.38.15
vpn.corbina.net has address 195.14.38.16
vpn.corbina.net has address 195.14.38.17
vpn.corbina.net has address 195.14.38.18

Роутинг на всю эту прорву серверов нам нужно один раз внести в файл /etc/ppp/ip-up и привести файл к следующему виду:

#!/bin/sh
#
# This script is run by pppd when there"s a successful ppp connection.
#
route add -host 195.14.38.1 gw 10.167.0.17
route add -host 195.14.38.2 gw 10.167.0.17
route add -host 195.14.38.3 gw 10.167.0.17
....
route add -host 195.14.38.19 gw 10.167.0.17
route add -host 195.14.38.20 gw 10.167.0.17
route del default

а в скрипт /etc/ppp/ip-down мы запишем всего одну строчку, которая вернет нам шлюз по умолчанию после обрыва соединения:

#!/bin/sh
#
# This script is run by pppd after the connection has ended.
#
route add default gw 10.167.0.17

Вы, наверное, уже заметили, что мы не вписали в файл /etc/ppp/ip-up строчку route add default dev ppp0 . Это не нужно — после успешного коннекта pppd сам впишет шлюз по умолчанию, если мы дадим ему команду defaultroute . В результате наш файл настроек /etc/ppp/peers/corbina будет выглядеть следующим образом:

Pty "pptp vpn.corbina.net --nolaunchpppd"
user VPN_LOGIN
password "VPN_PASSWORD"
nodeflate
nobsdcomp
noauth
defaultroute

Pon corbina
poff corbina

Если есть необходимость запускать соединение от простого пользователя, установите программу sudo и в файл /etc/sudoers впишите:

Sergo myhost = NOPASSWD: /usr/bin/pon, /usr/bin/poff

Соответственно, замените sergo и myhost на имя вашего пользователя и его машины. Он сможет запускать и прерывать соединение командами

Sudo pon corbina
sudo poff corbina

На этом настройка подключения завершена.
Источник

Иногда нужно получить удаленный доступ к сети предприятия, создать тоннель между серверами или предоставить доступ к Интернету хорошему соседу которого отключили от Сети за задолженность А, может быть, - просто иметь возможность получить доступ к своей сети из любого уголка мира, где есть Интернет.

Для этих целей можно использовать виртуальные частные сети (Virtual Private Network - VPN). В нашем случае, это будет самый распространенный протокол в странах СНГ, а именно - PPTP (Point-to-Point Tunneling Protocol). Многие кабельные провайдеры интернета используют именно его для предоставления услуг доступа ко .

Поднять свой сервер на Linux Ubuntu Server LTS не так уж трудно. Для этого нам понадобится доступ к Интернету и реальный IP (если нужно будет подключаться из Интернета).

Заходим на сервер, используя учетную запись root и устанавливаем необходимые пакеты командой apt-get install pptpd Нам предложат также установить пакет bcrelay, он позволяет дублировать широковещательные пакеты, принятые на входящем интерфейсе на виртуальные (PPP тоннели клиентов).

Нажимаем enter и наш сервер установлен. Приступим к конфигурации. Откроем файл nano /etс/pptpd.conf и в самом низу увидим следующие строки

#localip 192.168.0.1
#remoteip 192.168.0.234-238,192.168.0.245
# or
#localip 192.168.0.234-238,192.168.0.245
#remoteip 192.168.1.234-238,192.168.1.245

Это настройки IP адресов клиентов. Раскомментируем первые две строки (удалим символ #) и немного подправим их.

Строка localip 192.168.0.1 значит, что у нашего VPN сервера будет IP 192.168.0.1 можно указать наш IP в одной из непосредственно подключенных сетей. Например, у меня в домашней сети у сервера IP адрес - 172.30.2.1 Чтобы не нагружать сервер еще и ненужной я использовал его же.

Вторая строка - remoteip 192.168.0.234-238,192.168.0.245 указывает диапазон IP адресов, которые будут присваиваться клиентам. Как видно из этих строк, сетевой адрес может быть любым (во второй группе строк). Для удобства мы выберем его из того же диапазона что и IP нашего сервера.

Я использую дома такую логику выдачи IP: 1й - роутер, 2-19 - компьютеры, 20-49 - статический VPN (при подключении выдается один и тот же адрес), 50-100 - VPN клиенты, 101-199 - Wi-Fi клиенты, 200-254 - для различных устройств (например IP роутера, телевизора и т.п). Укажем такой диапазон remoteip 172.30.2.50-100 и сохраним конфигурацию.

Перейдем в каталог cd /etс/ppp/ здесь хранятся все файлы настройки pptpd (сервер) и pppd (клиент).

Переименуем файл pptpd-options командой mv pptpd-options pptpd-options.bak и создадим его по новой nano pptpd-options Это сделано для того, чтобы легче было вставить несколько строк в новый файл, чем искать параметры среди десятков строк с комментариями. Вставим в этот новый файл такое содержимое:

name pptpd
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
#require-mppe-128
ms-dns 172.30.2.1
nodefaultroute
lock
nobsdcomp
auth
logfile /var/log/pptpd.log

Что все это значит? Давайте по порядку:

Использовать имя pptpd для поиска логинов в chap-secrets
При указании этой опции pptpd не согласится аутентифицироваться по протоколу refuse-pap, refuse-chap, refuse-mschap
Требовать у партнёра аутентификации с помощью MS-CHAPv2
Требовать использования MPPE со 128-битным шифрованием require-mppe-128 т.е. шифровать весь трафик. Это увеличивает нагрузку на сервер и не все "слабые" устройства его поддерживают (Wi-Fi роутеры и т.п.).
Предложить использовать DNS сервер с IP 172.30.2.1
nodefaultroute - не устанавливать шлюз по умолчанию от сервера к клиенту, в противном случае, весь трафик в Интернет будет послан через подключившегося клиента, также Интернет отключится из-за потери маршрута к провайдеру.
Lock - блокировать сессии, т.е. с одного логина может быть только одно подключение
nobsdcomp - не сжимать трафик. При включении увеличивает нагрузку на наш сервер
auth - требовать авторизации (логин и пароль)
logfile /var/log/pptpd.log - писать логи работы в этот файл.

Сохраняем и закрываем этот конфигурационный файл.

Теперь нужно добавить пользователей, которые будут подключаться к нашему серверу. Откроем файл nano chap-secrets (он используется для хранения учетных записей PPP).

Для корректной работы нужно соблюдать такой формат: колонки должны быть разделены хотя бы одним пробелом или табом (Tab), не допускается использование пробелов в именах (иначе пробел рассматривается как следующая колонка), логин должен начинаться на букву. Например:

Первая колонка - это логин пользователя, вторая - имя сервиса. В нашем случае это pptpd. Далее - пароль пользователя, последняя - IP адрес, который будет выдан. Причем, если стоит * то IP адрес будет выдан из заданного ранее диапазона автоматически. Также в качестве IP можно указать адрес, который может быть за пределами диапазона.

Перед тем, как использовать сервер, нужно его перезапустить. Для этого выполним /etс/init.d/pptpd restart если в конфигурации нет ошибок, сервер будет запущен.

rоot@CoolServ:/etс/ppp# /etс/init.d/pptpd restart
Restarting PPTP:
Stopping PPTP: pptpd.
Starting PPTP Daemon: pptpd.

Если вы используете ) в него нужно добавить такие строки:

# VPN - PPTPD
iptables -A INPUT -p tcp -m tcp --dport 1723 -j ACCEPT
iptables -A INPUT -p gre -m state --state RELATED,ESTABLISHED -j ACCEPT

Для предоставления доступа к Интернету VPN клиентам через наш сервер нужно дописать такое правило в IPTables:

iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

Где eth1 - интерфейс в сторону Интернета.

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

Частые ошибки при подключении

Чтобы создать клиентское подключение PPTP из Windows XP выполняем следующие пункты: нажимаем "Пуск" - "Панель управления" - "Сеть и подключения к интернету" - "Сетевые подключения".

Жмем на "Создание нового подключения" - это запустит "Мастер новых подключений".

Теперь вписываем название подключения. Здесь можно написать что угодно, это будет просто названием подключения, для примера мы напишем "PPTP" (по типу соединения).

Может появиться следующий вопрос «Использовать настроенные подключения к Интернету?» (Если у Вас уже настроено подключение PPPoE), в нем нажимаем "Не набирать номер".

Если такое сообщение не появилось, читаем далее.

Теперь у Вас попросят ввести адрес сервера, указываем IP вашего сервера или его имя.

В окне, показанном на фото выше, выбираем "Свойства". Появится окошко в котором выбираем вкладку "Безопасность". Находим в нем пункт "Требуется шифрование данных" и убираем галочку. в противном случае мы не сможем подключиться, будут появляться ошибки 741 или 742 - «требуемый тип шифрования не поддерживается сервером».

После этого нажимаем кнопку «ОК», возвращаемся в предыдущее окно, вводим логин, пароль и подключаемся к нашему удаленному серверу по защищенному VPN каналу!