Как создать vpn канал между офисом и домашним компьютером

Обновлено: 06.07.2024

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

VPN (англ. Virtual Private Network, «виртуальная частная сеть») — обобщённое название технологий, позволяющих обеспечить одно или несколько сетевых соединений (логическую сеть) поверх другой сети (например Интернет).

Наиболее популярные решения с открытым исходным кодом для построения виртуальных частных сетей — «OpenVPN» и «IPSec». В релиз ядра Linux 5.6, который состоялся 30 марта 2020 года, вошла еще одна реализация технологии VPN — «WireGuard». Это молодой набирающий популярность проект.

Основные преимущества «WireGuard»:

Высокая производительность (бенчмарки можно посмотреть тут)
Простая настройка
Современная криптография
Качественный код

В этой инструкции мы настроим VPN-туннель в локальную сеть с помощью «WireGuard» и обеспечим доступ из интернета к узлам LAN с различных устройств.

Адресация в LAN - 192.168.100.0/24, VPN-сети назначим диапазон 10.0.0.0/24.

Для размещения сервера потребуется VPS. При выборе необходимо обратить внимание на технологию виртуализации: предпочтительно KVM, можно XEN, а вот OpenVZ следует избегать. Дело в том, что в WireGuard реализован как модуль ядра, а в OpenVZ ядро очень старое. Я буду использовать самый дешевый виртуальный сервер c операционной системой Ubuntu 20.04 (KVM 512 МБ RAM 20 ГБ SSD 1 CPU - такая конфигурация вполне подойдет).

Залогинимся на сервер с правами пользователя root и выполним следующие команды:

Создадим конфигурационный файл /etc/wireguard/wg0.conf со следующим содержимым:

[Interface] Address = 10.0.0.1/24 PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE ListenPort = 51820 PrivateKey = <SERVER_PRIVATE_KEY>

Параметры PostUp/PostDown содержат правила iptables, которые будут применены при запуске/остановке сервиса. Обратите внимание на название сетевого интерфейса — оно должно соответствовать общедоступному сетевому адаптеру, в моем случае это eth0. Вывести список адаптеров можно командой:

Выберите из списка тот, которому соответствует внешний IP-адрес. <SERVER_PRIVATE_KEY> - заменяем содержимым файла /etc/wireguard/privatekey.

Запустим VPN-сервис и добавим его в автозагрузку:

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

Если ваш роутер поддерживает WireGuard (Zyxel KeeneticOS >=3.3, Mikrotik RouterOS >=7.1beta2, OpenWRT) — можно настроить VPN-клиент прямо на нем. Я буду использовать для этой цели сервер Ubuntu 20.04 (локальный адрес 192.168.100.7).

Первый этап настройки аналогичен конфигурации серверной части. Выполняем с правами root-пользователя:

[Interface] PrivateKey = <PEER_LAN_PRIVATE_KEY> Address = 10.0.0.2/32 PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o wlp2s0 -j MASQUERADE PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o wlp2s0 -j MASQUERADE [Peer] PublicKey = <SERVER_PUBLIC_KEY> Endpoint = <SERVER_IP>:51820 AllowedIPs = 10.0.0.0/24 PersistentKeepalive = 20

<PEER_LAN_PRIVATE_KEY> — заменяем содержимым /etc/wireguard/privatekey, <SERVER_PUBLIC_KEY> — /etc/wireguard/publickey с сервера, <SERVER_IP> — внешний IP-адрес сервера. Правила iptables в PostUp/PostDown необходимы для того, чтобы наш клиент выступал в роли шлюза в LAN. Указываем в правилах тот сетевой интерфейс, на который назначен локальный адрес (192.168.100.7, в моем случае это wlp2s0). Уточните его путем исполнения команды:

В параметре AllowedIPs задаются адреса, маршрутизация к которым будет осуществляться через VPN-интерфейс. В поле PersistentKeepalive — периодичность проверки доступности соединения в секундах. Запускаем службу и добавляем в автозагрузку:

На сервере добавляем в файл /etc/wireguard/wg0.conf блок:

Где <PEER_LAN_PUBLIC_KEY> — /etc/wireguard/publickey клиента. Перезапустим службу и убедимся, что все настроено корректно:

Проверим теперь с клиента:

Сборки WireGuard доступны для основных платформ: Linux, Windows, Mac, Android, FreeBSD, OpenWRT и др. Рассмотрим настройку VPN-клиента на десктопах под управлением Linux и Windows, а так же на Android-смартфоне.

На клиенте выполняем с правами root:

Конфигурационный файл /etc/wireguard/wg0.conf:

<PEER_1_PRIVATE_KEY> — заменяем содержимым /etc/wireguard/peer_1_privatekey, <SERVER_PUBLIC_KEY> — /etc/wireguard/publickey с сервера.

Обратите внимание на строку «AllowedIPs = 0.0.0.0/0» - в данной конфигурации весь трафик будет маршрутизироваться через VPN-адаптер. Это может понадобиться для сокрытия реального IP при работе в интернет или для защиты трафика при подключении к недоверенным сетям (например публичные Wi-Fi точки доступа). В этом случае указываем «DNS = 8.8.8.8» (8.8.8.8 - DNS-сервер Google), чтобы DNS-запросы выполнялись через защищенное VPN-соединение.

Если VPN-туннель необходим только для доступа к LAN 192.168.100.0/24 - убираем строчку «DNS = 8.8.8.8» и в параметре AllowedIPs меняем «0.0.0.0/0» на «10.0.0.0/24, 192.168.100.0/24».

На сервере в конфигурационный файл /etc/wireguard/wg0.conf добавляем блок:

. [Peer] PublicKey = <PEER_1_PUBLIC_KEY> AllowedIPs = 10.0.0.3/32

Где <PEER_1_PUBLIC_KEY> — содержимое файла /etc/wireguard/peer_1_publickey клиента и перезапускаем службу:

Возвращаемся на клиент и проверяем доступность узлов в LAN через VPN-туннель:

Зачем компании переводят сотрудников на удаленку:

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

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

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

VPN в роутерах

Так называемых “китайских решений” на рынке много. Практически любой роутер имеет функциональность встроенного VPN сервера. Обычно это простое вкл/выкл функционала и добавление логинов паролей для пользователей, иногда интеграция с Radius сервером. Почему мы не стали рассматривать подобное решение? Мы прежде всего думаем о своей безопасности и непрерывности работе сервиса. Подобные же железки не могут похвастаться ни надежной защитой (прошивки выходят обычно очень редко, или не выходят в принципе), да и надежность работы оставляет желать лучшего.

VPN Enterprise класса

Если посмотреть на квадрат Гартнера то на VPN рынке уже давно лидирующие позиции занимают компании, которые производят сетевое оборудование. Juniper, Cisco, Check Point: все они имеют комплексные решения решения, в составе которых есть и VPN сервис.

Минусов у подобных решений, пожалуй, два. Первый и главный — высокая стоимость. Второй — скорость закрытия уязвимостей оставляет желать лучшего, а если не платить ежегодные взносы за поддержку, то обновлений безопасности ждать не стоит. Не так давно появился и третий момент — закладки, встроенные в ПО крупных сетевых вендоров.

Microsoft VPN

10 лет назад мы были компанией, ориентированной прежде всего на Windows. Microsoft предлагает бесплатное решение для тех, у кого вся инфраструктура построена на их базе. В простых случаях настройка не вызывает сложностей даже у начинающего системного администратора. В нашем случае мы хотели выжать из VPN все с точки зрения безопасности, соответственно, использование паролей было исключено. Мы естественно хотели использовать сертификаты вместо паролей и для хранения ключевой пары использовать свой продукт Рутокен ЭЦП. Для реализации проекта нам нужно было: контроллер домена, радиус сервер и правильно поднятая и настроенная инфраструктура PKI. Подробно на настройке я останавливаться не буду, в интернете есть достаточно много информации по данным вопросам, а правильная настройка PKI вообще может потянуть на десяток статей. Первым протоколом, который мы использовали у себя, был протокол PPTP. Долгое время данный вариант VPN нас устраивал, но в конечном итоге нам пришлось отказаться от него по двум причинам: PPTP работал далеко не везде и мы начинали пользоваться не только Windows, но и другими операционными системами. Поэтому мы стали искать альтернативы. Замечу, что поддержка PPTP не так давно была прекращена apple. Для начала мы решили посмотреть, что еще из протоколов может предложить на Microsoft. SSTP/L2TP. SSTP нас устраивал всем, за исключением того, что он работал только на Windows. L2TP данным недостатком не обладал, но его настройка и поддержание его в работе показались нам достаточно затратными и мы решили попробовать альтернативы. Хотелось более простого решения, как для пользователей, так и для администраторов.

OpenVPN

Мы в компании “Актив” искренне любим open source. Выбирая замену Microsoft VPN мы не могли обойти стороной решение OpenVPN. Основным плюсом для нас было то, что решение "из коробки" работает на всех платформах. Поднять сервер в простом случае достаточно просто. Сейчас, используя docker и, к примеру готовый образ, это можно сделать за несколько минут. Но нам хотелось большего. Нам хотелось добавить в проект интеграцию с Microsoft CA, для того, чтобы использовать выданные ранее сертификаты. Нам хотелось добавить поддержку используемых нами токенов. Как настраивать связку OpenVPN и токены описано к примеру вот в этой статье. Сложнее было настроить интеграцию Microsoft CA и OpenVPN, но в целом тоже вполне реализуемо. Получившимся решением мы пользовались около трех лет, но все это время продолжали искать более удобные варианты. Главной возможностью, которую мы получили, перейдя на OpenVPN, был доступ из любой ОС. Но остались еще две претензии: сотрудникам компании нужно пройти 7 кругов ада Microsoft CA для выписывания сертификата, а администраторам по-прежнему приходилось поддерживать достаточно сложную инфраструктуру VPN.

У нас есть знание, как использовать токены в любых операционных системах, у нас есть понимание, как правильно готовить инфраструктуру PKI, мы умеем настраивать разные версии OpenVPN и мы имеем технологии, которые позволяют управлять всем этим удобным для пользователя образом из окна браузера. Так возникла идея нового продукта.

Настройка Рутокен VPN

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

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

Третьим шагом необходимо настроить сам VPN сервис. Указать внешний IP, на который будет происходить подключение. Выбрать тип шифрования и адресацию сети.

Четвертым шагом настройки мы создаем локальных пользователей, или добавляем их из AD

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

Личный кабинет сотрудника

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

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

После установки плагина/расширения нам остается лишь сгенерировать сертификат себе на Рутокен ЭЦП.

И установить клиент под нужную операционную систему:

Как все это работает?

Немного об аппаратной части. Изначально мы долго думали, какую “базу” использовать для нашего решения, так как нужно было соблюдать баланс между стоимостью, удобством, производительностью. После исследований, что предлагается на рынке, мы остановились на двух вариантах реализации и дальнейшего распространения решения:

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

Raspberry Pi – уже достаточно известный микрокомпьютер, который обладает вполне неплохой производительностью при не самой высокой стоимости и который можно начать использовать как VPN-сервер уже через 10 минут после того, как его в прямом смысле вынули из коробки.

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

Но изначально, нам все же нужно осуществить настройку сервисов, которые требуются для корректной работы продукта. Настройка сервисов осуществляется на текущий момент специалистами нашей компании в полуавтоматическом режиме. Это значит, что автоматизирован процесс деплоя программного обеспечения и первичных настроек, но инициализация данного процесса пока остается привилегией человека. Во время первичной настройки устанавливаются системные пакеты, python, django, OpenVPN, supervisor, OpenSSL и пр.

А что же дальше? Далее необходимо настроить всю инфраструктуру, которая собственно и отвечает в целом за безопасность. А именно: CA (центр сертификации), PKI (инфраструктура открытых ключей), выписать необходимые ключи и сертификаты.

Создание PKI и CA, а также формирование файла конфигурации OpenVPN-сервера, генерация ключей и выписывание сертификатов осуществляется уже после передачи продукта клиенту. Но это не значит, что для этого необходимо иметь какие-то специфические знания и прямой доступ к операционной системе. Все реализовано в бизнес-логике бэкенда системы администрирования, доступ к которой предоставляется через Web-интерфейс. От клиента требуется только ввести минимальный набор атрибутов (описано выше), после чего стартует процесс инициализации PKI и создания СА. Описывать конкретные вызовы системных команд смысла особого нет, так как уже давно все описано и разжевано до нас. Главное, что мы сделали — это автоматизировали данный процесс, избавив пользователя от необходимости обладать специфическими знаниями в администрировании.

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

Самый долгий процесс при настройке инфраструктуры – это генерация файла Diffie-Hellman. Мы долго экспериментировали с параметрами и пришли к балансу “качество-производительность”. Хотя были мысли вообще избавиться от данного шага, нагенерировать таких файлов заранее, используя наши серверные мощности и просто “раздавать” их во время первичной инициализации. Тем более, что данные, содержащиеся в этом файле не являются приватными. Но пока мы оставили эти мысли для дальнейших “изысканий”.

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

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

При инициализации процесса выписывания сертификата, осуществляется запрос на токен для генерации ключевой пары а также запрос на выписку сертификата в CA. Приватный ключ записывается на токен, а запрос на выписку сертификата отправляется в СА, который в свою очередь осуществляет его выписывание и возвращает в ответе. После чего сертификат так же записывается на токен.

Почти все готово для установления VPN-соединения. Не хватает клиента, который “знает”, как работать с сервером и нашими токенами.

Наш клиент реализован на Electron. Кто не в курсе, что это за зверь, то если совсем кратко – возможность реализовать десктопное приложение, используя js, css и html. Не вдаваясь в подробности, клиент является неким “враппером” над OpenVPN-клиентом, позволяющим осуществлять его вызовы с нужными параметрами. Почему именно так? На самом деле нам было так удобней, хотя выбранное решение и накладывает определенные ограничения.

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

Немного о наших планах. Основное, над чем сейчас мы работаем — это реализация ГОСТ-шифрования. Уже пройден достаточно большой путь исследований, позволивший нам максимально приблизиться к ее реализации. В ближайшее время сможем удовлетворить интерес потенциальных клиентов в данной функциональности.

Организация VPN каналов между офисами. Маршрутизация

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

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

Чтобы не быть голословными рассмотрим таблицу маршрутов самой обыкновенной рабочей станции. В Windows системах это можно сделать командой:

В итоге мы увидим следующую таблицу:

Наша рабочая станция принадлежит к сети 192.168.31.0 и, согласно таблице маршрутов, все запросы к данной сети отправляет на интерфейс 192.168.31.175, что соответствует сетевому адресу это станции. Если адрес назначения находится в одной сети с адресом источником, то доставка информации происходит без использования IP-маршрутизации (сетевой уровень L3 модели OSI), на канальном уровне (L2). В противном случае пакет отправляется узлу, указанному в соответствующему сети назначения правилу таблицы маршрутов.

Если такого правила нет, то пакет отправляется по нулевому маршруту, который содержит адрес основного шлюза сети. В нашем случае это адрес роутера 192.168.31.100. Нулевым этот маршрут называется потому, что адресом назначения для него указывается 0.0.0.0. Этот момент является очень важным для дальнейшего понимания процесса маршрутизации: все пакеты, не принадлежащие данной сети и не имеющие отдельных маршрутов, всегда отправляются основному шлюзу сети.

Что сделает маршрутизатор, получив такой пакет? Прежде всего разберемся, чем отличается маршрутизатор от обычной сетевой станции. Если говорить крайне упрощенно, то маршрутизатором (роутером) является сетевое устройство, которое настроено передавать пакеты между сетевыми интерфейсами. В Windows это достигается включением службы Маршрутизация и удаленный доступ, в Linux заданием опции ip_forward.

Решение о передаче пакетов в этом случае также принимается на основании таблицы маршрутизации. Посмотрим, что содержит данная таблица на самом обычном роутере, например, описанном нами в статье: Ubuntu Server. Настраиваем роутер NAT + DHCP + Squid3. В Linux-системах получить таблицу маршрутов можно командой:

Как видим, наш роутер содержит маршруты к известным ему сетям 192.168.31.0 и 192.168.3.0, а также нулевой маршрут к вышестоящему шлюзу 192.168.3.1.

Адрес 0.0.0.0 в колонке шлюза (Gateway) обозначает, что адрес назначения доступен без маршрутизации. Таким образом все пакеты с адресами назначения в сетях 192.168.31.0 и 192.168.3.0 будут отправлены на соответствующий интерфейс, а все остальные пакеты будут переданы дальше по нулевому маршруту.

Следующий важный момент - адреса приватных (частных) сетей, они же "серые", к ним относятся три диапазона:

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

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

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

Самое время проверить, как это все работает. Попробуем с нашего узла 192.168.31.175 пропинговать узел 192.168.3.106, который находится в сети за роутером. Как видим, это нам удалось, хотя таблица маршрутов узла не содержит никаких сведений о сети 192.168.3.0.

Как это стало возможным? Так как узел-источник ничего не знает о сети назначения, то он отправит пакет на адрес шлюза. Шлюз проверит свою таблицу маршрутов, обнаружит там запись для сети 192.168.3.0 и отправит пакет на соответствующий интерфейс, в этом несложно убедиться выполнив команду трассировки, которая покажет весь путь нашего пакета:

Теперь попробуем выполнить пинг узла 192.168.31.175 с узла 192.168.3.106, т.е. в обратном направлении. У нас ничего не вышло. Почему?

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

В дальнейшем мы будем придерживаться такой записи маршрутов, что она значит? Все просто, пакеты для сети 192.168.31.0 с маской 255.255.255.0 следует отправлять узлу 192.168.3.108. В Windows маршрут можно добавить командой:

Давайте проанализируем результат, в таблице маршрутизации появился маршрут и все пакеты к сети 192.168.31.0 теперь отправляются роутеру этой сети, что видно из ответа команды ping, но до назначения не доходят. В чем дело? Самое время вспомнить, что одной из основных задач роутера является не только маршрутизация, но и функция сетевого экрана, который явно запрещает доступ из внешней сети внутрь. Если мы временно заменим данное правило разрешающим, то все будет работать.

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

В Linux в /etc/network/interfaces, после описания интерфейса, следует добавить:

Кстати, это не единственный способ настроить доступ из сети 192.168.3.0 в сеть 192.168.31.0, вместо того, чтобы добавлять маршрут для каждого узла, можно "научить" правильно отправлять пакеты маршрутизатор.

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

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

Самый простой случай, когда VPN-сервер (клиент) и маршрутизатор сети располагаются на одном хосте. Рассмотрим схему ниже:

Так как теорию, надеемся, вы усвоили и закрепили на практике, проанализируем маршрут пакетов из сети офиса 192.168.31.0 в сеть филиала 192.168.44.0, такой пакет будет отправлен на шлюз по умолчанию, который является также VPN-сервером. Однако данный узел ничего не знает о сети назначения и должен будет откинуть данный пакет. В тоже время мы уже можем обратиться к маршрутизатору филиала по его адресу в VPN-сети 10.8.0.2, так как данная сеть доступна с маршрутизатора офиса.

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

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

Возьмем схему посложнее, когда маршрутизатор и VPN-сервер (клиент) являются разными узлами сети. Здесь возможны два варианта, передать нужный пакет непосредственно VPN-серверу (клиенту) или заставить это делать шлюз.

Сначала рассмотрим первый вариант.

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

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

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

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

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

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

строим 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С, установленной в другой организации.

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