Как настроить vpn между двумя офисами. Настройка VPN-подключения средствами ОС Windows. Объединение офисов предприятия на основе технологий VPN
Организация каналов между удаленными сетями посредством VPN-соединения одна из самых популярных тем на нашем сайте. В тоже время, как показывает читательский отклик, наибольшие затруднения вызывает правильная настройка маршрутизации, хотя мы специально уделяли внимание этому моменту. Проанализировав наиболее часто задаваемые вопросы, мы решили посвятить теме маршрутизации отдельную статью. Есть вопросы? Надеемся, что после прочтения данного материала их станет меньше.
Прежде всего разберемся, что такое маршрутизация . Маршрутизация - это процесс определения маршрута следования информации в сетях связи. Скажем честно, тема эта весьма глубокая и требующая солидного багажа теоретических знаний, поэтому в рамках данной статьи мы сознательно упростим картину и коснемся теории ровно в той мере, которой будет достаточно для осмысления происходящих процессов и получения практических результатов.
Возьмем произвольную рабочую станцию, подключенную к сети, каким образом она определяет куда посылать тот или иной пакет? Для этой цели предназначена таблица маршрутизации , которая содержит перечень правил для всех возможных адресов назначения. На основании этой таблицы хост (или маршрутизатор) принимают решение, на какой интерфейс и адрес назначения отправить пакет, адресованный определенному получателю.
Route print
В итоге мы увидим следующую таблицу:
Все очень просто, нас интересует секция IPv4 таблица маршрута
, первые две колонки содержат адрес назначения и маску сети, затем следует шлюз - узел которому следует перенаправить пакеты для указанного назначения, интерфейс и метрика. Если в колонке Шлюз
указано On-link
, то это означает что адрес назначения находится в одной сети с хостом и доступен без маршрутизации. Метрика
определяет приоритет правил маршрутизации, если адрес назначения имеет в таблице маршрутов несколько правил, то используется тот, что имеет меньшую метрику.
Наша рабочая станция принадлежит к сети 192.168.31.0 и, согласно таблице маршрутов, все запросы к данной сети отправляет на интерфейс 192.168.31.175, что соответствует сетевому адресу это станции. Если адрес назначения находится в одной сети с адресом источником, то доставка информации происходит без использования IP-маршрутизации (сетевой уровень L3 модели OSI), на канальном уровне (L2). В противном случае пакет отправляется узлу, указанному в соответствующему сети назначения правилу таблицы маршрутов.
Если такого правила нет, то пакет отправляется по нулевому маршруту , который содержит адрес основного шлюза сети. В нашем случае это адрес роутера 192.168.31.100. Нулевым этот маршрут называется потому, что адресом назначения для него указывается 0.0.0.0. Этот момент является очень важным для дальнейшего понимания процесса маршрутизации: все пакеты, не принадлежащие данной сети и не имеющие отдельных маршрутов, всегда отправляются основному шлюзу сети.
Что сделает маршрутизатор, получив такой пакет? Прежде всего разберемся, чем отличается маршрутизатор от обычной сетевой станции. Если говорить крайне упрощенно, то маршрутизатором (роутером) является сетевое устройство, которое настроено передавать пакеты между сетевыми интерфейсами. В Windows это достигается включением службы Маршрутизация и удаленный доступ , в Linux заданием опции ip_forward .
Решение о передаче пакетов в этом случае также принимается на основании таблицы маршрутизации. Посмотрим, что содержит данная таблица на самом обычном роутере, например, описанном нами в статье: . В Linux-системах получить таблицу маршрутов можно командой:
Route -n
Как видим, наш роутер содержит маршруты к известным ему сетям 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 и отправит пакет на соответствующий интерфейс, в этом несложно убедиться выполнив команду трассировки, которая покажет весь путь нашего пакета:
Tracert 192.168.3.106
Теперь попробуем выполнить пинг узла 192.168.31.175 с узла 192.168.3.106, т.е. в обратном направлении. У нас ничего не вышло. Почему?
Давайте внимательно посмотрим таблицу маршрутизации. Никаких записей для сети 192.168.31.0 она не содержит, поэтому пакет будет отправлен маршрутизатору 192.168.3.1, как основному шлюзу сети, который данный пакет отбросит, так как никаких данных о сети назначения не имеет. Как быть? Очевидно, что следует отправить пакет тому узлу, который содержит нужную информацию и может передать пакет по назначению, в нашем случае это роутер 192.168.31.100, который в данной сети имеет адрес 192.168.3.108.
Чтобы пакеты для сети 192.168.31.0 отправлялись именно ему, нам нужно создать отдельный маршрут.
192.168.31.0 mask 255.255.255.0 192.168.3.108
В дальнейшем мы будем придерживаться такой записи маршрутов, что она значит? Все просто, пакеты для сети 192.168.31.0 с маской 255.255.255.0 следует отправлять узлу 192.168.3.108. В Windows маршрут можно добавить командой:
Route add 192.168.31.0 mask 255.255.255.0 192.168.3.108
Route add -net 192.168.31.0 netmask 255.255.255.0 gw 192.168.3.108
Попробуем.
Давайте проанализируем результат, в таблице маршрутизации появился маршрут и все пакеты к сети 192.168.31.0 теперь отправляются роутеру этой сети, что видно из ответа команды ping, но до назначения не доходят. В чем дело? Самое время вспомнить, что одной из основных задач роутера является не только маршрутизация, но и функция сетевого экрана, который явно запрещает доступ из внешней сети внутрь. Если мы временно заменим данное правило разрешающим, то все будет работать.
Добавленные вышеуказанными командами маршруты сохраняются до перезагрузки узла, это удобно, даже если вы сильно накуролесили, достаточно просто выполнить перезагрузку, чтобы отменить внесенные изменения. Чтобы добавить постоянный маршрут в Windows выполните команду:
Route add 192.168.31.0 mask 255.255.255.0 192.168.3.108 -p
В Linux в /etc/network/interfaces , после описания интерфейса, следует добавить:
Post-up route add -net 192.168.31.0 netmask 255.255.255.0 gw 192.168.3.108
Кстати, это не единственный способ настроить доступ из сети 192.168.3.0 в сеть 192.168.31.0, вместо того, чтобы добавлять маршрут для каждого узла, можно "научить" правильно отправлять пакеты маршрутизатор.
В этом случае узел источник не имеет записей о сети назначения и отправит пакет шлюзу, в прошлый раз шлюз такой пакет отбросил, но теперь мы добавили в его таблицу маршрутизации нужный маршрут, и он отправит пакет узлу 192.168.3.108, который доставит его по назначению.
Мы настоятельно рекомендуем самим потренироваться на аналогичных примерах, чтобы маршрутизация перестала быть для вас черным ящиком, а маршруты - китайской грамотой. После того как возникнет понимание, можно переходит ко второй части данной статьи.
Теперь рассмотрим реальные примеры по объединению сетей офисов через 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-сервере (клиенте) маршрут:
192.168.44.0 mask 255.255.255.0 10.8.0.2
Недостаток данной схемы - необходимость прописывать маршруты на каждом узле сети, что не всегда удобно. Его можно использовать если устройств в сети немного или требуется выборочный доступ. В остальных случаях задачу маршрутизации будет правильнее переложить на основной маршрутизатор сети.
В этом случае сетевые устройства офиса ничего не знают о сети филиала и отправят пакеты для него по нулевому маршруту, шлюзу сети. Теперь задача шлюза перенаправить этот пакет VPN-серверу (клиенту), это просто сделать, добавив в его таблицу маршрутизации нужный маршрут:
192.168.44.0 mask 255.255.255.0 192.168.31.101
Про задачу VPN-сервера (клиента) мы упоминали выше, он должен доставить пакеты тому узлу VPN-сети, который является частью сети назначения или имеет маршрут к ней.
192.168.44.0 mask 255.255.255.0 10.8.0.2
Для доступа из сети филиала в сеть офиса потребуется добавить соответствующие маршруты на сетевые узлы филиала. Сделать это можно любым удобным способом, не обязательно также, как это сделано в офисе. Простой реальный пример: все компьютеры филиала должны иметь доступ к сети офиса, но не все компьютеры офиса должны иметь доступ в филиал. В таком случае в филиале добавляем маршрут к VPN-серверу (клиенту) на маршрутизаторе, а в офисе добавляем его только на нужные компьютеры.
В целом, если вы представляете, как работает маршрутизация и каким образом принимается решение о перенаправлении пакетов, а также умеете читать таблицу маршрутизации, то настройка правильных маршрутов не должна вызывать затруднений. Надеемся, что после прочтения данной статьи у вас их также не будет.
Теги:
Инструкция
Нажмите на меню «Пуск» и выберите пункт «Панель управления». Найдите раздел «Сеть и интернет». Для организации VPN-соединения необходимо запустить оснастку «Центр управления сетями и общим доступом». Также можно нажать на значок сети в трее и выбрать аналогичную команду. Перейдите к созданию нового подключения или сети, отметив, что необходимо организовать подключение к рабочему столу. Нажмите кнопку «Далее». Появится запрос использования существующего подключения. Поставьте галочку на пункте «Нет, создать новое подключение» и перейдите к следующему этапу настроек.
Выберите команду «Использовать мое подключение к интернету», чтобы настроить VPN-соединение. Отложите появившийся запрос настройки интернета перед продолжением. Появится окно, в котором необходимо указать адрес VPN-сервера согласно договору и придумать название для подключения, которое будет отображаться в центре управления сетями и общим доступом. Отметьте галочкой пункт «Не подключаться сейчас», иначе компьютер сразу же после настройки попытается установить соединение. Отметьте пункт «Использовать смарт-карту», если удаленный VPN-узел проверяет подлинность подключение по смарт-карте. Нажмите «Далее».
Введите логин пользователя, пароль и домен, согласно которым вы получаете доступ к удаленной сети. Нажмите кнопку «Создать» и дождитесь завершения настройки VPN-соединения. Теперь необходимо установить подключение к интернету. Для этого нажмите на значок сети в трее и запустите настройку свойств созданного подключения.
Откройте вкладку «Безопасность». Установите «Тип VPN» - «Автоматически» и «Шифрование данных» - «Необязательное». Отметьте пункт «Разрешить следующие протоколы» и выберите протоколы CHAP и MS-CHAP. Перейдите на вкладку «Сеть» и оставьте галочку только возле пункта «Протокол интернета версии 4». Нажмите кнопку «Ок» и подключите VPN -соединение.
Любая vpn-сеть предусматривает наличие определенного сервера, который будет обеспечивать связь сетевых компьютеров и других устройств. Одновременно с этим она обеспечивает некоторым из них (или всем) доступ к внешней сети, например – интернету.
Вам понадобится
- - сетевой кабель;
- - сетевая карта.
Инструкция
Самый простым примером vpn-сети может послужить создание локальной сети между , каждый из которых будет получать доступ к интернету. Естественно, прямое соединения с сервером провайдера будет только у одного ПК. Выберите этот компьютер.
Установите в него дополнительный сетевой адаптер, который будет соединен со вторым компьютером. Используя сетевой кабель нужной длины, соедините сетевые карты двух компьютеров между собой. К другому сетевому адаптеру основного ПК подключите кабель провайдера.
Настройте подключение к интернету. Это может быть LAN или DSL-соединение. В данном случае это совершенно не важно. Завершив создание и настройку нового подключения, перейдите к его свойствам.
Откройте меню «Доступ» в появившемся окне. Разрешите использовать это соединение с интернетом всем компьютерам, входящим в состав определенной локальной сети. Укажите сеть , образованную вашими двумя компьютерами.
Мультисервисные и беспроводные сети
Объединение офисов предприятия на основе технологий VPN
Корпоративные сети передачи данных предназначены для обеспечения эффективного функционирования информационной инфраструктуры предприятия. КСПД позволяют объединить разрозненные и удаленные территории и офисы компании в единую корпоративную сеть , создать единое информационное пространства и защищенные соединения удаленных офисов на основе технологий VPN (см. рис.1). Защищённая корпоративная виртуальная частная сеть, обеспечивает шифрование данных, передаваемых между офисами компании.ИЦ "Телеком-Сервис" предлагает комплексные решения по построению корпоративных VPN сетей на основе оборудования Cisco Systems, Juniper Networks и Huawei Technologies.Рис.1 Схема организации корпоративной VPN сети
Организация корпоративной VPN сети на основе оборудования Cisco Systems
В настоящее время компания Cisco Systems предлагает высокотехнологичные VPN-решения полностью соответствующие требованиям российского технического регулирования в сфере информационной безопасности.
Компаниями Cisco Systems и С-Терра СиЭсПи разработана новая версия VPN-модуля NME-RVPN (MCM), поддерживающий российские крипто алгоритмы и тесно интегрируемый в интеллектуальную информационную сеть.Интеграция модуля NME-RVPN в исполнении МСМ в маршрутизаторы Cisco ISR серий 2800/3800 и 2900/3900 позволяет потребителям получить единое решение, обеспечивающее защиту передаваемой информации в соответствии с требованиями российских стандартов, развитую маршрутизацию, поддержку механизмов качества обслуживания приоритетного трафика (QoS), а также сервисы IP-телефонии и передачи видео. Подобные качества, дополненные управляемостью и надежностью платформ на базе операционной системыВ качестве альтернативного решения предлагается построение защищенной VPN сети на основе межсетевых экранов Cisco ASA 5500. Линейка межсетевых экранов ASA 5500 позволяет разворачивать VPN сети на основе протокола IPSec с использованием симметричного алгоритма шифрования DES (Data Encryption Standard
). Для шифрования использует ключ с длиной 56 бит, что соответствует требованиям российского технического регулирования в сфере информационной безопасности. Решение является бюджетным по сравнению с вариантом на основе модуля NME-RVPN. Недостатком такого решения является низкая стойкость алгоритма шифрования DES по сравнению с существующими алгоритмами шифрования.
Типовое решение состоит из следующих функциональных компонентов (см. рис.2): Рис.2
Реализацию защищенной VPN сети предлагается выполнять на основе серии сервисных шлюзов Juniper SRX. Серия сервисных шлюзов SRX позволяет разворачивать VPN сети на основе протокола IPSec без ограничений по используемым алгоритмам шифрования. В сервисных шлюзах SRX консолидирован функционал маршрутизации, коммутации и сетевой безопасности. Серия шлюзов SRX имеет высокую производительность в части функционала межсетевого экрана, функции IPS и большую плотность GE портов с поддержкой функции PoE. Т.о. данное решение можно отнести к классу бюджетных решений, позволяющих разворачивать VPN сети без ограничений по применяемым алгоритмам шифрования.
Организация корпоративной VPN сети на основе оборудования Juniper Networks
Реализацию защищенной VPN сети предлагается выполнять на основе шлюзов безопасности USG. Шлюзы безопасности USG позволяет разворачивать VPN сети на основе протокола IPSec без ограничений по используемым алгоритмам шифрования. Универсальные шлюзы безопасности USG представляют собой новое поколение многофункциональных шлюзов безопасности, предназначенных для предприятий среднего бизнеса, филиалов крупных предприятий. Благодаря модульной структуре, USG объединяет различные функции, такие как безопасность, маршрутизация, коммутация и функции беспроводной связи.Также предлагается решение по организации VPN сетей полностью соответствующих требованиям российского технического регулирования в сфере информационной безопасности. Для защиты данных используется программно-аппаратный комплекс (далее - ПАК) «ViPNet Coordinator HW-VPNM», являющийся совместной разработкой компаний ИнфоТеКС и Huawei Symantec. ПАК «ViPNet Coordinator HW-VPNM» является универсальным средством защиты информации в локальных и глобальных сетях связи (включая Интернет) и выполняет функции межсетевого экрана и криптошлюза. Особенностями ПАК являются его исполнение в виде модуля расширения к маршрутизаторам Huawei Symantec USG, а также высокая производительность в задаче шифрования реального IP-трафика – до 180 Мбит/с трафика без ограничения на число одновременно поддерживаемых сессий. Следует отметить, что при этом осуществляется полное шифрование всего IP-трафика по алгоритму ГОСТ 28147-89 с одновременной инкапсуляцией (сокрытием структуры информации) исходных IP-пакетов в UDP-пакеты. Это обеспечивает беспрецедентную стойкость к попыткам анализа и несанкционированного доступа к защищаемой информации. ПАК «ViPNet Coordinator HW» имеет сертификат соответствия ФСБ РФ №СФ/124-1459 от 9 мая 2010 года, удостоверяющего его соответствие требованиям ФСБ России к СКЗИ класса КС3 и возможность использования для криптографической защиты информации (шифрование и имитозащиты IP-трафика) информации, не содержащей сведений, составляющих государственную тайну.
Организация корпоративной VPN сети на основе оборудования Huawei Symantec
Концепция построения виртуальных частных сетей в полном соответствии с современными законодательными требованиями российских регуляторов. Предлагаемое решение соответствует следующим требованиям:
Организация корпоративной VPN сети на основе системы ViPNet компании ИнфоТеКС
Кому нужен VPN?
На март 2017 г. доля вакансий о работе с удаленным доступом, размещенных на hh.ru составляла 1,5% или 13 339 вакансий. За год их число удвоилось . В 2014 г. численность удаленных сотрудников оценивалась в 600 тыс. чел или 1% от экономически-активного населения (15–69 лет). J"son & Partners Consulting прогнозирует , что к 2018 г. около 20% всех занятых россиян будут работать удаленно. Например, до конца 2017 г. Билайн планирует перевести на удаленное сотрудничество от 50% до 70% персонала.
Зачем компании переводят сотрудников на удаленку:
- Сокращение затрат компании на аренду и содержание рабочих мест.
- Отсутствие привязки к одной локации дает возможность собирать команду
проекта, которую никогда нельзя было бы собрать в пределах одного города. Дополнительный плюс – возможность использования более дешевой рабочей силы. - Удовлетворение потребности сотрудников в связи с их семейными обстоятельствами.
Мы для себя открыли потребность в VPN более 10 лет назад. Для нас мотиватором предоставления VPN доступа сотрудникам была возможность оперативного доступа в корпоративную сеть из любой точки мира и в любое время дня и ночи.
Путь выбора идеального 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.
Рутокен 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-сессии, то нам нужно сконфигурировать OpenVPN-клиент для работы с ним. Провайдером PKCS#11 является библиотека собственной разработки для работы с нашими токенами, путь к которой и прописывается в настройках OpenVPN клиента. Подробнее о ней можно почитать .
При запросе на установку VPN-соединения, запрашивается PIN-код ключа, при корректном вводе извлекается сертификат для аутентификации клиента, осуществляется хэндшейк клиента с сервером и устанавливается VPN-соединение. Знающие люди могут возразить, что не все так просто, но целью данного описания не является рассказать все тонкости работы OpenVPN, а только осветить основные моменты нашей реализации.
Немного о наших планах. Основное, над чем сейчас мы работаем - это реализация ГОСТ-шифрования. Уже пройден достаточно большой путь исследований, позволивший нам максимально приблизиться к ее реализации. В ближайшее время сможем удовлетворить интерес потенциальных клиентов в данной функциональности.
Теги:
- vpn
- openvpn
- raspberry pi
- рутокен
- openssl
Частная виртуальная сеть (VPN) хороша тем, что предоставляет пользователю защищенный или доверительный канал с другим ПК без необходимости предоставления выделенного канала связи. Её создают поверх другой сети - Интернет, например.
Windows имеет встроенные инструменты для налаживания VPN-подключения между компьютерами, размещенными на больших расстояниях. Наладим VPN-туннель между двумя ПК, которые управляются средой Windows.
Создадим серверную часть
Подсоединение удаленных клиентов к VPN-сети организовывается через специальный сервер доступа. От входящего подключения он может потребовать прохождения процедур идентификации и аутентификации. Он знает, какие пользователи обладают доступом к виртуальной сети. Также, он располагает данными о разрешенных IP-адресах.
Для налаживания VPN-сервера доступа в центре управления сетями надо открыть апплет изменений параметров адаптеров. Если главное меню апплета не отображается, нажмите кнопочку «Alt». В верхней части апплета должно появиться главное меню, в котором следует найти пункт «Файл», а затем выбрать «Новое входящее подключение». Рассмотрим более подробнее.
В панели управления пройдем «Сеть и Интернет».
На следующем шаге откроем сетевой центр.
Создадим новое входящее соединение.
Появившееся окошко предложит выбрать из существующих пользователей или определить нового, которым будет разрешено подсоединяться к данному ПК.
При добавлении нового «юзера» нужно указать имя и пароль, с которыми ему дозволено будет соединяться с VPN-сервером доступа.
На следующем шаге мастер настройки частной сети спросит, как будут подключаться пользователи.
Надо указать, что делать они это будут поверх Интернет, поэтому отметим флажком требуемую опцию.
Следующий шаг связан с налаживанием сетевых приложений, которые должны принимать входящие подключения. Среди них есть компонент «Интернет-протокол версии 4(TCP/IPv4)». Понадобится открыть его свойства и вручную ввести диапазон IP-адресов, которым дозволен доступ к серверу.
Иначе, предоставьте это дело DHCP-серверу для автоматического определения «айпишников». В нашем случае понадобилось вручную их определять.
После выполнения процесса обработки введенных данных, сервер доступа получит требуемую информацию для предоставления необходимых разрешений авторизующимся пользователям. Одновременно система подскажет имя компьютера, которое понадобится в будущем.
В итоге, мы получим такой результат. Подключенных клиентов еще нет.
Настроим клиента
Современные сети чаще всего выстраиваются по клиент-серверной архитектуре. Она позволяет выделить главный компьютер в сетевом окружении. Клиенты инициируют запросы к серверу и делают первыми попытку подключения к серверу.
Серверную часть этой архитектуры мы уже настроили. Теперь осталось наладить работу клиентской части. В качестве клиента должен выступать другой компьютер.
В сетевом центре другого ПК (клиента) наладим новое подключение.
Нам надо подсоединяться напрямую к рабочему месту.
Опять же обратимся в сетевой центр Windows только теперь другого ПК. Выберем опцию настройки нового подсоединения. Появившийся апплет предложит несколько вариантов на выбор, однако нам понадобится опция подключения к рабочему месту. Мастер спросит, как выполнять подсоединение. Нам же надо остановить свой выбор на настройке подсоединения к Интернету (VPN).
Мастер попросит на следующем шаге указать IP-адрес VPN-сервера доступа и назначить имя местоназначения. IP-адрес сервера доступа можно узнать на первом нашем компьютере, введя в командной строке команду ipconfig. IP-адрес Ethernet-сети и будет искомым адресом.
Затем, система применит все введенные настройки.
Выполним подключение
Временем X для нашего эксперимента является выполнение подсоединения клиента к серверной части нашей сети. В сетевом центре выберем опцию «Подключиться к сети». В появившемся окошке кликнем VPN-Test (мы указали местоназначение именно с данным именем) и кликнем кнопочку подключиться.
Так, мы откроем апплет соединения с VPN-Test. В текстовых полях укажем имя и пароль «юзера» для осуществления авторизации на сервере доступа. Если все пройдет успешно и наш пользователь не только зарегистрируется в сети, но и сможет полностью подсоединиться к серверу доступа, то на противоположной стороне появится обозначение подключившегося «юзера».
Но иногда, может случиться ошибка такого рода. VPN-сервер не отвечает.
Кликнем ярлычок входящих соединений.
На отмеченной вкладке откроем свойства протокола IP.
Установим опцию указывать IP адреса явным образом и пропишем, какие «айпишники» надо обслуживать.
Когда же повторно подключимся, то увидим такую картину. Система нам показывает, что подключен один клиент и этот клиент vpn(SimpleUser).
Краткий итог
Итак, для налаживания VPN-сети между двумя ПК понадобится определиться с тем, какой из них должен стать «главным» и играть роль сервера. Остальные ПК должны подсоединяться к нему через систему авторизации. В Windows есть средства, обеспечивающие создание серверной части для нашей сети. Она настраивается через создание нового входящего соединения, указания пользователя, а также приложений, которые должны принимать соединение. Клиента настраивают через установление соединения к рабочему месту, указывая пользователя и данные сервера, к которому этот пользователь должен подключаться.