Как сделать одновременно несколько openvpn подключений

Обновлено: 08.07.2024

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

Данные для примера конфигурации

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

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

Первая сеть для соединения при помощи OpenVPN

Локальная сеть 192.168.100.0 mask 255.255.255.0 .

Вторая сеть для соединения при помощи OpenVPN

Локальная сеть 192.168.200.0 mask 255.255.255.0 .

OpenVPN клиент будет настроен на компьютере с адресом 192.168.200.1 .

Виртуальная сеть OpenVPN

Для сети OpenVPN выделяется подсеть 192.168.50.0 mask 255.255.255.0 .

Установка OpenVPN сервера и клиента

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

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

В статье про настройку клиента и сервера OpenVPN приведен пример конфигурационных файлов сервера и клиента с пояснениями.

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

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

Если есть где поставить свой сервер, и аренда не нужна, главное белый айпишник.
Насчет vm-ware не понял вообще. В принципе опенвпн и под винду есть.

а на своем компе я могу поставить виртуальную машину, постаивть на нее линукс, поднять там опенвпн сервер и коннектиться со всеми филиалами одновременно?

чет я не совсем догоняю. у меня 16 филиалов с серваками и белыми айпи, там стоит опенвпн сервер вроде. я со своего рабочего компа с помощью опенвпн клиента коннеклюсь к этим филиалам - создаю впн и юзаю удаленный сервак через РДП. одна проблема я не могу одновременно создать несолько впн.
под линуксом я могу такое сделать?

У нас настроено со всеми филаилами ВПН одновременно рабоатет. На Керио. Более подробно незнаю, админы там химичат что-то. Но что можно одноверменно работать это точно.

вообщем как я делаю сейчас. у меня 16 папок с ключами и с настройками опенвпн (ип удаленного сервера). перед подключением я кидаю эти файлы в C:\Program Files\OpenVPN\config - запускаю опенвпн и цепляюсь к удаленному серваку. когда надо подключиться к другому филиалу - я разрываю соединение, в папку C:\Program Files\OpenVPN\config кидаю новый комплект файлов и снова цепляюсь уже к новому филиалу. как мне уйти от такой ситуации.

(18) Надо знать точно как распределяется инет в сети. У меня белый айпи получает локальная машина через ППОЕ соединение (собственно коннект к провайдеру). Естественно она пингуется из вне. Интет раздает ЮзерГейт. На прокси настраивется маппинг порта 3389 (по этому порту устанавливатся соединение по RDP). Смысл маппинга, это перенапраление или проброс соединения по настроенному порту на указанную машину в локалке (в нашем случае на сервак). Инструкции по настройке маппинга портов к проксике должны быть в описании или на форуме разработчика прокси. В соединении RDP на машине в инете указываешь адрес айпи с проксей. Прокси видит запрос на подключение и перебрасывает соенинение на сервак, в итоге все просто и без всяких випиэнов. Если же айпи получил модем, то надо опять же узнать, может ли он маппировать порты или настроить его в бридж.

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

Випиэнами ты "объединяешь" локалки через инет. Мапиннг портов альтернативная возможность цепляться на любой твой сервак в инете, естественно с возможностью устанавливать RDP одновременно с нескольками. Я тож в свое время озадачивался твоей проблемкой с VPN сейчас она не актуальна.

(23) понял. это тоже выход. но админ не хочет прямой доступ на сервек в целях безопасности. типа через впн безопаснее для удаленного сервака

Доступ только по порту 3389 пожалуй безопаснее нежели поднятие VPN, фарэрволом есс-но можно пропустить только "свои" айпишники.

Зачем нужен VPN-туннель? Ясное дело — связать две приватные подсети друг с другом через интернет. А если подсетей, допустим не две, а пять? Что делать в этом случае? Как можно, как лучше? Мои размышления на эту тему с конкретным примером реализации. Пример основан на программных средствах, с минимумом вложений.

Важное про OpenVPN

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

Зато просто, бесплатно, хорошо документировано на 2016 год. В моём случае это было всего лишь три-четыре туннеля на центральном VPN сервер е, полтора десятка пользователей, значит полоса пропускания туннелей небольшая, трафика для шифрования немного и ресурсов сервера VPN хватало с запасом.

Но нужно быть в курсе про недостатки OpenVPN перед внедрением. Если бы что-то подобное сотворялось сегодня, а не в 2016 году, пробовал бы WireGuard.

Предисловие

Никах средств и никакого оборудования мне никто выделять не собирался. Да и никто не воспринял мою затею всерьёз. Всех устраивало как удалённое приложение работает через проброс портов на маршрутизаторе главного офиса. Естественно без всякого шифрования и аутентификации при входе в сеть.

Всё что мне было позволено — создать несколько виртуальных машин на имеющихся серверах, да ещё в моём распоряжении был неиспользуемый мини-десктоп HP. Но я попробовал, результат получился на удивление изящный и дешёвый:

Абонентка 500 рублей в месяц за VPS-сервер;
Потом уже, когда система заработала и была обкатана, купили 2 Raspberry Pi 3;
Стабильная работа и Keepalive.

Чуть теории

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

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

Минусы в этом же: среда передачи — общественная сеть. Низкую задержку никто не гарантирует. И нужно шифровать трафик, среда передачи небезопасна.

Также могут возникнуть проблемы "на ровном месте":

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

Не буду скрывать, да это и очевидно — всё, что будет описано в данной записи, 100% материала — придумано всё это не мной, как сказал один мой знакомый — всё украдено до нас. Моя задача смотреть, анализировать, собирать информацию и доводить проект до конечной реализации сперва на бумаге, а потом в продакшене.

Выбор топологии

Итак, несколько подсетей. Для начала нужно проверить, что они не перекрываются. При всей очевидности проверить все-таки надо. Вот скажите сходу перекрываются ли сети?

Далее, вариантов соединения сетей может быть несколько, но все они сводятся к двум основным — полносвязное соединение и звезда.

Полносвязное соединение

Все элементы равнозначны.

Плюсы:

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

Минусы:

При большом количестве сетей избыточная, громоздкая структура;
Добавление новой сети требует настройки еще стольких новых туннелей, сколько подсетей уже имеется (либо DMVPN);
Если одна сеть (филиал организации) переезжает по новому адресу (без переноса IP), то это требует полной перенастройки всех связанных с ней туннелей.

Звезда

Ядро системы настраивается как VPN сервер, остальные элементы как VPN клиенты.

Плюсы:

VPN клиент может находиться за NAT. IP адрес он может получать по DHCP. Это делает такого клиента непривязанным к конкретной сети провайдера. Включаем его на новом месте, он подсоединяется к серверу и работает. Всё что нужно сделать, это кинуть на него маршрут;
Простота добавления нового клиента — минимальная настройка на сервере, а сам клиент настраивается из типового шаблона;
Если клиент реализован на виртуальной машине, то это бесплатно. Вычислительная мощность такого клиента настраивается за минуту в любую сторону;
Неочевидный плюс безопасности: маршрут на клиент, выступающий в роли шлюза в туннель, можно прописать как для всей локальной сети, так и для отдельных узлов;
Второй неочевидный плюс безопасности: анонимность — с клиентов остальные подсети видятся только по своим приватным адресам, а если вдобавок на vpn-сервере выключен лог, то даже получив доступ к нему невозможно собрать информацию кто и откуда подключался;
Третий неочевидный плюс безопасности: если локальная подсеть клиента маленькая, либо же малое число клиентов в сети использует туннель, то в этом случае клиент можно реализовать на микрокомпьютере Raspberry Pi. При необходимости такой микрокомпьютер можно здорово запрятать, а при настройке соединения через Wi-Fi и вовсе его не найдешь;
Четвертый неочевидный плюс безопасности: всю структуру можно выключить, выключив VPN сервер. Если при этом VPN сервер реализован как VPS в интернете, то сделать это можно, находясь где угодно, одним нажатием на смартфоне. Если хостер разумно-жадный, что в данном случае хорошо и не делает бесплатных бекапов, то и полностью удалить VPN сервер без всяких следов можно также легко.

Минусы:

Единая точка отказа, если VPN сервер недоступен по каким-либо причинам, то вся сеть лежит;
Для каждого клиента нужны либо виртуальная машина, либо машина физическая;
Размещенный в интернете VPN сервер требует ежемесячной оплаты;
VPN сервер должен обладать необходимой вычислительной мощностью чтобы покрывать обсчет трафика от клиентов. Теоретически при достаточно большом количестве клиентов и больших подсетях за клиентами этой мощности может не хватить. На практике такого никогда не случится.

Реализация

Сначала хотел сделать что-то, взяв готовые решения типа IpCop, но потом понял, что из этого ничего не получится. Заставить тестового Ubuntu-клиента приконнектиться к серверу не удалось. Несмотря на стандарт, реализация OpenVPN видимо везде разная, например OpenVPN-сервер на роутере Mikrotik RB2011U почему-то использует TCP.. Это видно из строки proto tcp-client.

Роутер Mikrotik в режиме клиента непонятно что использует, но к готовой реализации проекта он также не подключился. Может что-то не разобрал, не спорю, тем не менее в конце-концов, ещё задолго до заказа VPS, пришел к выводу, что придется всё настраивать с нуля на одной ОС для всех машин туннеля.

По многим причинам выбрал вариант с выделенным VPS в интернете. Для начала нужно определиться где, в каком дата-центре разместить VPN сервер. Для этого нужно попросить в поддержке интересующего дата-центра тестовый IP, попинговать его и сделать трассировку из всех предполагаемых к соединению сетей, посмотреть число хопов. Полезная программа WinMTR:

Это занимает определенное время и вот наконец дата-центр выбран, VPS оплачен и готов к настройке.

Настройка VPN-сервера

Используем Ubuntu 16.04 LTS как дружелюбную, хорошо отлаженную систему. Установить систему на VPS можно из предварительно настроенных образов хостера, либо же отписать в поддержку и попросить загрузить для установки свой дистрибутив - А у вас нет такого же, но с перламутровыми пуговицами? Не стал заморачиваться и взял то, что дают. Установил, установка занимает пару минут: root включен, SSH доступ для root'а включен, swap раздела нет. Последнее не очень хорошо, поэтому первое:

Меняем hostname, когда сидишь через SSH сразу на нескольких машинах, то можно легко запутаться и набумбасить лишнего там, где не надо, потом будет обидно, а если отвалится связь с машиной, то очень обидно, поэтому:

Своих клиентов обозвал по порядку V1, V2, V3 и так далее.

Убираем автообновление, вредная штука (на Ubuntu):

Меняем root пароль:

Также полезно пользоваться командой history для просмотра истории команд.

Настройка OpenVPN и сертификатов

Копируем дефолтный конфиг OpenVPN для правки:

Конфиг

Все понятно, наиболее важные параметры:

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

Файрвол

Файрвол по умолчанию выключен. Настраиваем:

Генерация сертификатов сервера

Данное действо происходит довольно долго и зависит от мощности сервера.

Переходим непосредственно к генерации ключей сервера:

Будут сгенерированы сертификат удостоверяющего центра и сертификат и ключ сервера - ca.crt, server.crt, server.key, все их нужно скопировать в папку /etc/openvpn:

Проверим, что все на месте:

Запускаем сервис и проверяем его статус:

Если само не возвращается в привилегированный режим, то жмем Ctrl-C.

Генерация сертификатов клиентов

Совет - генерируйте сразу на пару клиентских сертификатов больше, чем нужно, с запасом.

Для заливки/скачивания с машины файлов есть очень удобная программа WinSCP.

Копируем ключи с сервера с помощью WinSCP на свою локальную машину. Для каждого клиента X должен быть наборчик - ca.crt, clientX.crt, clientX.key.

Параметры сервера для каждого клиента

В конфиге сервера есть строчки:

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

Редактируем каждый файл параметров:

Первая строчка говорит, что шлюз туннеля на клиенте1 получит адрес 10.8.0.6, вторая обратный маршрут — маршрут с VPN сервера в подсеть клиента1. После настройки всех файлов параметров:

Немного о подсетях для туннеля

Каждый туннель это соединение point-to-point, в котором используется подсеть на 4 адреса. Такая подсесть имеет маску /30, то есть 255.255.255.252, а количество адресов вычисляется по формуле 2^n , где n = 32 - количество бит маски, поэтому адресов для маски /30:

Но первый адрес — это адрес всей подсети, последний - широковещательный адрес этой подсети, поэтому для назначения узлам доступно только два адреса: второй и третий по счёту. Формула тут уже 2^n-2 и для наших подсетей это равно двум. Считать очень легко, группами по четыре ( 0,1,2,3 - 4,5,6,7 - 8,9,10,11 - 12,13,14,15 - 16,17,18,19 - . - 252,253,254,255 ):

Легко можно посчитать, что максимум клиентов при такой конфигурации 256/4 - 1 = 63, то есть больше, чем когда-либо понадобится (минус 1, потому что одна подсеть уже использована для сервера).

На этом, чтобы не усложнять, с сервером пока всё.

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

Для клиентов официальный дистрибутив Ubuntu-Server x64 со страницы проекта, в качестве носителя — виртуальная машина, получение настроек сети — по умолчанию (от DHCP). Виртуальная машина идеально подходит для экспериментов, создаем контрольную точку и по необходимости откатываемся на неё столько раз, сколько надо. Создание нового клиента также идеально на виртуальной машине — предварительно настроенная болванка машины выкладывается куда-нибудь на Яндекс Диск и люди с той стороны её забирают, включают на своем Hyper-V и всё работает.

После установки включаем root'а:

Включаем вход root по ssh:

Переключаемся на root и убиваем текущего пользователя, созданного при установке:

Далее кратенько, так как почти все уже делалось на сервере:

Файрвол не включаем, клиент за NAT, нет необходимости.

Конфиг

Ключи

Копируем ключи, проверяем что все на месте, стартуем OpenVPN, проверяем статус туннеля:

Если все нормально, то будет так:

На этом с основной настройкой всё.

Скрип авто-поднятия туннеля на клиентах

Дело в том, что если туннель на работающем клиенте по каким-то причинам упадёт, то сам он не поднимется до перезапуска сервиса или до перезагрузки клиента, поэтому лепим скрипт, делаем его исполняемым и ставим его в Cron:

Если туннель не найден среди активных интерфейсов, то время пишется в файл openvpn.bug.

Проверка идет каждые 3 минуты, этого достаточно, так как перезапуск службы и подъём туннеля происходит мгновенно.

Синхронизация времени

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

Установить временную зону:

Проверить время можно так:

Сервер

Чтобы с NTP-сервером могли синхронизироваться машины из локальной сети:

Служба синхронизации времени использует порт 123 для соединения с сервером, поэтому необходимо разрешить доступ:

Окончательный вид фаервола сервера:

Клиенты

Узнаем насколько время на клиенте отстает от сервера:

Основные маршруты

Чтобы все машины подсети клиента, речь идёт о Windows машинах, могли ходить в туннель и видеть подсети за туннелем накидываем маршруты для этих подсетей на местный офисный роутер.

Если же это нужно только для отдельных машин, то прописываем маршруты на каждой из них, такой пример для 1 маршрута и соответственно для 1 удалённой подсети на хосте с Windows:

Как добавить постоянный маршрут на Ubuntu-машину рассказано в отдельной записи.

Дополнительные маршруты

А что если на одном или нескольких клиентах есть больше чем одна подсеть? К примеру у меня в центральном офисе за напрямую подключенной к клиенту сетью 192.168.0.0/20, есть еще 10.50.0.0/20. Эта сеть находится за роутером и маршрута в эту сеть на клиенте центрального офиса нет, он ничего про неё не знает. Нужно прописать 4 маршрута - 3 прямых и 1 обратный. То есть сеть 10.50.0.0/20 прописывается:

На клиенте центрального офиса V3;
В файле sever.conf на vpn-сервере:

В файле параметров клиента на vpn-сервере:

И в подсети другого клиента, где сеть 10.50.0.0/24 должна быть доступна (на роутере или на хостах).

Клиент - физическая машина

Админов можно классифицировать по разным признакам, один из признаков — админы, как и коты, бывают ленивые и очень ленивые. Умные дядьки с хорошими зарплатами из центрального офиса сказали, что поднять Hyper-V сервер — это невозможная задача и времени надо как минимум до середины ноября, поэтому готовую виртуальную машину пришлось заливать на физическую и передавать уже в таком виде. Процесс описан в отдельной записи. Ещё надо не забыть включить в BIOS машины опцию Power On After Power Fail, чтобы она самостоятельно включалась после сбоя питания.

Клиент - Raspberry Pi 3

Начиная с третьей версии Малинка поддерживает Ubuntu. Два дистрибутива, что я нашел — не заработали. Дистрибутив с официальной страницы после обновления стал вываливаться в дамп. Второй дистрибутив с "raspberry2" в названии вообще не стартовал.

Поставил Raspbian. Это моё первое знакомство с данной ОС. Логин/пароль по умолчанию pi/raspberry. Практически все команды работают, Debian он и есть.. - установить VIM и команды задавать как vim . Не нашел как отключить автоматическое обновление (а включено ли оно вообще?).

Всё остальное также как и для других клиентов — включить root, убить пользователя pi и так далее. Рассмотрение настройки Малинки не входит в задачи этой статьи. Очень-очень кратко:

Добавление нового клиента

Через некоторое время потребуется добавить нового клиента. Генерим новые сертификаты на сервере:

Другой хороший вариант — сгенерировать сразу клиентских сертификатов с запасом, штук десять.

Прописываем новую сеть в конфигурацию сервера server.conf, создаем файл параметров клиента в папке ccd. Берем болванку виртуальной машины и заливаем сертификаты, а старые удаляем. В начале этого процесса лучше изолировать машину от выхода в интернет, иначе она полезет к серверу и нарушит работу машины, с которой была снята эта болванка.

Подключение к клиентам

После прописывания основных маршрутов все клиенты доступны по SSH через туннель по своим адресам в туннеле - 10.8.0.X.

Заключение

Чего-то много опять получилось, реально статья — 5300+ слов. Наверное половину слов дают конфиги 🙂 А на написание и правку так вообще целый день ушел, больше даже, но написание подобных статей хорошо систематизирует знания. OpenVPN сеть работает и чем дольше пользуюсь, тем больше мне нравится. Приятно, что открытое ПО стало уже таким зрелым и вкусным.

Единственный момент, который был упущен из виду MTU на сервере и на клиентах. Хотя при настройках по умолчанию всё работало нормально. Кто хочет поразбираться с данным моментом, можно почитать на OpenVPN Wiki, поиск по ключу "mssfix".

строим VPN канал

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

Задача: Настроить VPN канал между двумя филиалами вашей компании. Сеть в первом филиале называется N_B1) и сеть во втором филиале N_B2. Установка OpenVPN в обоих офисах будет на ОС Windows 7. Приступим к выполнению поставленной задачи.

Network N_B1 содержит:

Компьютер или сервер, где устанавливается сервер OpenVPN, имеет 2 сетевых интерфейса, один как вы можете понять для wan ip адреса, а второй для внутренней сети..
Также на ней установлен proxy сервер который раздает инет в локальную сеть, тем самым являясь для всех машин в локальной сети основным шлюзом (192.168.2.100)
192.168.2.100 смотрит в локальную сеть
192.168.2.3 данный интерфейс смотрит в интернет через маршрутизатор, который имеет статический IP скажем 123.123.123.123. На нем сделан форвардинг или как его еще называют проброс порта 1190 (для примера порт 1190 проброшен на сетевом интерфейсе с ip адресом 192.168.2.3)
Пользователь в сети имеет 192.168.2.100

Network N_B2 содержит:

Компьютер или сервер, где устанавливается клиент OpenVPN, так же имеет 2 сетевых интерфейса.
Также на ней установлен proxy сервер который раздает интернет в локальную сеть, тем самым являясь для всех машин в локальной сети основным шлюзом(172.17.10.10)
172.17.10.10 смотрит в локальную сеть
192.168.2.3 смотрит в мир через маршрутизатор.
Пользователь в сети: 172.17.10.50

Задача: Человек из офиса с сетью N_B1 (192.168.2.100) должен видеть общие ресурсы на компьютере человека из сети N_B2 (172.17.10.50) и в обратном направлении.

Другими словами каждый каждого должен видеть и иметь возможность заходить в гости, вдруг кто фотки новые расшарит посмотреть своему коллеге из другого branche.

Приступаем к настройке

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

Запускаем установку OpenVPN, на 3-м шаге ставим птички OpenSSL Utilites и OpenVPN RSA Certificate Management Scripts.

Установка OpenVPN 2.3.8

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

Выбор места установки

Во время установки в ОС будет добавлен virtual network adapter TAP-Win32 Adapter V9, и дополнительный драйвер для него. Данному сетевому интерфейсу OpenVPN как раз и будет выдавать IP адрес и маску виртуальной сети OpenVPN. У нас назначен адрес 10.10.10.1 с маской 255.255.255.0 на сервере N_B1 и 10.10.10.2 с такой же маской на клиенте N_B2.

Как организовать канал между офисами при помощи OpenVPN с дополнительной парольной защитой-05

Переименуем его в "VPN"

Как организовать канал между офисами при помощи OpenVPN с дополнительной парольной защитой-06

В директории "C:\OpenVPN" следует сразу же создать дополнительно папку ssl (здесь мы будем хранить ключи аутентификации) папку ccd (здесь будут находится конфигурация настроек сервера для клиента).

В папке easy-rsa создаем файл vars.bat, данный пакетный файл будет задавать переменные для сеанса генерации сертификатов, в той части что касается организации и расположения заполняем своими данными.

Запускаем командную строку от имени администратора.

Как организовать канал между офисами при помощи OpenVPN с дополнительной парольной защитой-07

Переходим по пути C:\OpenVPN\easy-rsa, набрав для перехода в командной строке команду

Запускаем vars.bat:

Как организовать канал между офисами при помощи OpenVPN с дополнительной парольной защитой-08

Далее запускаем clean-all.bat:

Как организовать канал между офисами при помощи OpenVPN с дополнительной парольной защитой-09

Теперь запускаем build-ca.bat. Так как вся информация о сервере у нас уже заполнена, все оставляем без изменений:

Как организовать канал между офисами при помощи OpenVPN с дополнительной парольной защитой-10

после этого у нас в папке ssl появится два файла ca.crt и ca.key.

Запускаем build-dh.bat:

Как организовать канал между офисами при помощи OpenVPN с дополнительной парольной защитой-11

в результате у нас в папке ssl появится файл dh1024.pem.

Создаем серверный ключ, для этого вводим команду:

где "ServerVPN" это название нащего VPN сервера, как в моем случае,

Указываем параметр "commonname" - пишем имя нашего VPN сервера. Все остальные параметры оставляем по умолчанию, на все вопросы отвечаем yes

Как организовать канал между офисами при помощи OpenVPN с дополнительной парольной защитой-12

в результате у нас в папке ssl появятся файлы ServerVPN.crt, ServerVPN.csr, ServerVPN.key.

Приступаем к формированию клиентских ключей.

где "UserVPN_1" имя нашего клиента.

Важно! Указываем параметр "commonname" - пишем имя нашего VPN клиента(UserVPN_1). Все остальные параметры оставляем по умолчанию, на все вопросы отвечаем yes

Как организовать канал между офисами при помощи OpenVPN с дополнительной парольной защитой-13

В результате у нас в папке ssl появятся файлы UserVPN_1.crt, UserVPN_1.csr, UserVPN_1.key.

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

Генерация ключа tls-auth (ta.key) для аутентификации пакетов, для этого переходим в корневую папку OpenVPN:

и выполняем команду:

в результате в папке ssl плучим файл ta.key.

Приступаем к созданию конфига сервера. В папке config создаем файл OpenVPN.ovpn:

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

Создаем конфиг клиента.

Устанавливаем на клиенте OpenVPN, предаём ему ca.crt, UserVPN_1.crt, UserVPN_1.key, ta.key.

Настраиваем файрволы и антивирусы на клиенте и на сервере для беспрепятственного прохождения пакетов. Описывать не буду все зависит от установленных антивирусов и файрволов.

После всего этого запускаем наш сервер и клиент.

Как организовать канал между офисами при помощи OpenVPN с дополнительной парольной защитой-14

Если все правильно сделали наш сервер получит IP 10.10.10.1 и подключится к нему клиент и получит IP 10.10.10.2 . И так подключение у нас состоялось теперь сервер и клиент пингуют друг друга по IP нашей VPN сети, то есть 10.10.10.1 и 10.10.10.2.

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

Как организовать канал между офисами при помощи OpenVPN с дополнительной парольной защитой-15

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

Как организовать канал между офисами при помощи OpenVPN с дополнительной парольной защитой-16

После этого мы сможем пинговать внутренние IP сервера и клиента (172.17.10.10 клиент и 192.168.2.100 сервер).

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

Как организовать канал между офисами при помощи OpenVPN с дополнительной парольной защитой-17

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

Есть второй способ как сделать видимыми внутренние IP сетей наших сервера и клиента.

Для этого заходим в реестр, открываем ветку реестра:

Находим параметр и меняем значение: IPEnableRouter типа REG_DWORD значение 1.

Как организовать канал между офисами при помощи OpenVPN с дополнительной парольной защитой-18

Не забываем перезагрузить машину, чтобы настройки вступили в силу!

Это нужно проделать и на сервере, и на клиенте.

Итак мы пингуем наши сети по внутренним IP, а так как у нас и сервер и клиент для своих сетей являются шлюзами, то и машины из сети 1 могут видеть машины из сети 2 и наоборот. то есть Пользователь N_B1 (192.168.2.100) может видеть расшаренные папки Пользователя N_B2 (172.17.10.50) и наоборот.

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

Пример для N_B1:

Пример для N_B2:

в моем случае этого не понадобилось.

Для автоматического запуска сервера и клиента нам нужно включить службу OpenVPN Service

Как организовать канал между офисами при помощи OpenVPN с дополнительной парольной защитой-19

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

Дополнительная защита

Как известно в OpenVPN есть возможность аутентификации по сертификатам, как описано выше, а так же по логину и паролю, но можно еще и объединить их вместе. Насколько мне известно только в Linux есть возможность штатными средствами настроить аутентификацию по логину и паролю, но в Windows это тоже можно решить. Для этого в папке config создаем файл auth.vbs и пишем в него следующее

Так же в папке config содаем файл Users.pw туда пишете логин и пароль нашего клиента

Если несколько клиентов то:

Дальше нужно в конфиге клиента прописать строку auth-user-pass, теперь когда клиент будет подключаться к серверу у него будет выплывать окно авторизации где нужно ввести логин и пароль, который вы назначили ему в Users.pw,их нужно будет сообщить клиенту.

Как организовать канал между офисами при помощи OpenVPN с дополнительной парольной защитой-20

У меня настроено что имя пользователь(логин) соответствует имени клиента в сертификате, то естьUserVPN_1. но можно задать и другое имя отличное от имени в сертификате, для этого нужно смотреть настройки в auth.vbs.

а в конфиге клиента меняем строку auth-user-pass на auth-user-pass C:\\OpenVPN\\ssl\\pass.txt.

Теперь я включаю машину где установлен OpenVPN -Server, запускается служба и сервер VPN автоматически поднимается. Клиент запускает машину и у него также проходит автоматическое подключение к моему серверу. Теперь можно заходить в общие папки или по RDP работать, например, в 1С, установленной в другой организации.

Читайте также: