Сетевые технологии

Кому нужен 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?

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

Можно конечно купить персональную линию между двух городов, но данное решение это будет скорее всего сверхдорогим.
Решение посредством виртуальной приватной сети (VPN - Virtual Private Network) предлагает нам эту выделенную линию организовать посредством сосздания шифрованного туннеля через интернет.Основное преимуществом VPN перед выделенными линиями связи - сохранение денег компании при полной закрытости канала.
С точки зрения потребителя, VPN - технология, с помощью которой можно организовать удаленный защищенный доступ через открытые каналы Интернета к серверам, базам данных, любым ресурсам вашей корпоративной сети. Допустим бухгалтер в городе А может легко распечатать счет-фактуру на принтере секретаря в городе Б к которому приехал клиент. Удаленные сотрудники подключившись по VPN со своих ноутбуков смогут также работать в сети, как-будто они находятся в физической сети своих офисов.

Очень часто, клиенты сталкиваясь с *тормозами* кассовых аппаратов при использовчании Удаленного рабочего стола приходят к необходимости установки VPN. Это позволят избавиться от персылки данных для кассы туда-обратно на сервер посрдством виртуального COM через интернет и позволет усановку тонкого клиента в любой точке, который общается с кассой напрямую, отправляя на сервер только необходимую информацию по закрытому каналу. Да и трансляция интерфйса RDP прямо в сеть Интернет подвергает Вашу компанию очень большим рискам.

Способы подключений

Способы организации в VPN наиболее целесообразно выделить следующие 2 основных способа:

(Клиент - Сеть ) Удаленный доступ отдельно взятых сотрудников к корпоративной сети организации через модем либо общедоступную сеть.
(Сеть - Сеть ) Объединение двух и более офисов в единую защищенную виртуальную сеть посредством интернет

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

На рисунке показаны оба варианта подключения к основному офису А.

Между офисами А и В организован канал обеспечивающий интеграцию офисов в единую сеть. Это обеспечивает прозрачность обоих офисов для лубых устройств конторые находятся в одном из них, что решает многие проблемы. Например организации единой номерной емкости в рамках одной АТС имеющй IP телефоны.

Мобильным клиентам доступны все сервисы офиса А, а при нахожденнии офиса В в единой виртуальной сети и его сервисы.

При этом способ подкдючения мобильных клиентов обычно реализуется протоколом PPTP (Point-to-Point Tunneling Protocol) Протокол туннелирования точка-точка, а второй IPsec или OpenVPN

PPTP

(Point-to-Point Tunneling Protocol bumagin-lohg) – туннельный протокол «точка-точка», детище Microsoft и является расширением PPP (Point-to-Point Protocol), следовательно, использует его механизмы подлинности, сжатия и шифрования. Протокол PPTP является встроенным в клиент удаленного доступа Windows XP. При стандартном выборе данного протокола компанией Microsoft предлагается использовать метод шифрования MPPE (Microsoft Point-to-Point Encryption). Можно передавать данные без шифрования в открытом виде. Инкапсуляция данных по протоколу PPTP происходит путем добавления заголовка GRE (Generic Routing Encapsulation) и заголовка IP к данным обработанных протоколом PPP.

Из-за значительных проблем в безопасности, нет причин для выбора PPTP вместо других протоколов, кроме как из-за несовместимости устройства с другими протоколами VPN. Если ваше устройство поддерживает L2TP/IPsec или OpenVPN, то лучше выбрать какой-то из этих протоколов.

Надо отметить, что почти все устройства, в том числе и мобильные, имеют встроенного в ОС (Windows, iOS, Android) клиента позволяющему мнгновенно настроить подключение.

L2TP

(Layer Two Tunneling Protocol) – более совершенный протокол, родившийся в результате объединения протоколов PPTP (от Microsoft) и L2F (от Cisco), вобравший в себя все лучшее из этих двух протоколов. Предоставляет более защищенное соединение, нежели первый вариант, шифрование происходит средствами протокола IPSec (IP-security). L2TP является также встроенным в клиент удаленного доступа Windows XP, более того при автоматическом определении типа подключения клиент сначала пытается соединиться с сервером именно по этому протоколу, как являющимся более предпочтительным в плане безопасности.

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

OpenVPN

Продвинутое открытое VPN решение, созданное компанией "OpenVPN technologies", которое сейчас дефакто является стандартом в VPN-технологиях. Решение использует SSL/TLS протоколы шифрования. OpenVPN использует OpenSSL библиотеку для обеспечения шифрования. OpenSSL поддерживает большое количество различных криптографических алгоритмов таких как 3DES, AES, RC5, Blowfish. Как в случае IPSec, CheapVPN включает экстримально высокий уровень шифрования - AES алгоритм с ключом длиной 256 бит.
OpenVPN - Единственное решение позволяющие обойти тех провайдеров которые режут или взымают плату за открытие дополнительных протоколов, кроме WEB. Это дает возможность организовать каналы которые впринципе невозможно отследить и у нас есть такие решения

Теперь у Вас есть некоторое представление о том, что такое VPN и как это работает. Если Вы руководитель - задумайтесь, возможно это именно то, что Вы искали

Пример настройки сервера OpenVPN на платформе pfSense

Создаем сервер

Interface: WAN (сетевой интерфейс сервера, подключенный к интернету)
Protocol: UDP
Local Port: 1194
Description: pfSenseOVPN (любое удобное название)
Tunnel Network: 10.0.1.0/24
Redirect Gateway: Включить (Отключите эту опцию, если Вы не хотите, чтобы весь интернет-трафик клиента перенаправлялся через VPN-сервер.)
Local Network: Оставляем пустым (Если Вы хотите, чтобы локальная сеть, находящаяся за сервером pfSense, была доступна для удаленных клиентов VPN, укажите здесь адресное пространство этой сети. Допустим 192.168.1.0/24 )
Concurrent Connections: 2 (Если Вы приобрели дополнительную лицензию OpenVPN Remote Access Server, укажите число, соответствующее количеству приобретенных лицензий)
Inter-Client Communications: Включить (Если Вы не хотите, чтобы VPN-клиенты видели друг друга, отключите эту опцию)
DNS Server 1 (2 и т.д.): указать DNS-серверы хоста pfSense. (узнать их адреса можно в разделе System > General Setup > DNS Servers )

далее создаем клиентов и для упрощения процедур конфигурации программ-клиентов, в pfSense предусмотрен дополнительный инструмент – “OpenVPN Client Export Utility” . Этот инструмент автоматически подготавливает установочные пакеты и файлы для клиентов, что позволяет избежать ручной настройки OpenVPN-клиента.

VPN соединение между офисами покрывают такие требования безопасности бизнеса как:

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

Если у Вас возникли трудности при настройке или Вы еще не определились с технологией VPN - звоните нам!

VPN (Virtual Private Network) - это виртуальная частная сеть или логическая сеть, которая создается поверх незащищённых сетей (сетей оператора связи или сервис-провайдера Интернет). VPN – это технология, которая обеспечивает защиту данных при передаче их по незащищенным сетям. Виртуальная частная сеть позволяет организовать туннель в незащищённых сетях (между двумя точками сети), например в ATM, FR или IP-сетях.

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

Известны основные виды VPN и их комбинации:

Intranet VPN (внутрикорпоративные VPN);
Extranet VPN (межкорпоративные VPN);
Remote Access VPN (VPN с удаленным доступом);
Client/Server VPN (VPN между двумя узлами корпоративной сети).

В настоящее время для построения корпоративных территориально распределенных сетей в разделяемой инфраструктуре сервис-провайдеров и операторов связи применяются следующие технологий:

IP-туннели с использованием технологий GRE или IPSec VPN;
SSL, к которой относятся OpenVPN и SSL VPN (SSL/TLS VPN) для организации безопасных каналов связи;
MPLS в сети оператора (L3 VPN) или VPN в сети BGP/MPLS;
Metro Ethernet VPN в сети оператора (L2 VPN). Наиболее перспективная технология, используемая в Metro Ethernet VPN, - это VPN на базе MPLS (MPLS L2 VPN) или VPLS.

Что касается применения выделенных линий и технологий Frame Relay, ATM для организации корпоративных территориально распределенных сетей, то они уже для этих целей практически не применяются. Сегодня, как правило, КВС строятся на основе оверлейных сетей (клиент-серверных и одноранговых сетей), которые работают в разделяемой инфраструктуре операторов, и являются «надстройками» над классическими сетевыми протоколами.

Для организации территориально распределенных корпоративных сетей провайдеры предоставляют заказчикам следующие основные модели VPN в среде Интернет:

модель IP VPN (GRE, IPSec VPN, OpenVPN) через WAN сеть, в которой настройка VPN обеспечивается заказчиком;
модель L 3 VPN или MPLS L3 VPN через WAN сеть, в которой настройка VPN обеспечивается сервис-провайдером или оператором связи;
модель L2 VPN через MAN сеть, в которой настройка VPN обеспечивается провайдером или оператором связи:
- point-to-point (AToM, 802.1Q, L2TPv3);
- multipoint (VPLS и H-VPLS).

Технологии VPN можно классифицировать и по способам их реализации с помощью протоколов: аутентификации, туннелирования и шифрования IP-пакетов. Например, VPN (IPSec, OpenVPN, PPTP) основаны на шифровании данных заказчиков, VPN (L2TP и MPLS) базируются на разделении потоков данных между заказчиками VPN, а SSL VPN основана на криптографии и аутентификации трафика. Но, как правило, VPN используют смешанные варианты, когда совместно используются технологии: аутентификации, туннелирования и шифрования. В основном организация VPN-сетей осуществляется на основе протоколов канального и сетевого уровней модели OSI.

Необходимо отметить, что для мобильных удаленных пользователей была разработана технология SSL VPN (Secure Socket Layer - уровень защищенных сокетов), которая основана на ином принципе передачи частных данных (данных пользователей) через Интернет. Для организации SSL VPN используется протокол прикладного уровня HTTPS. Для HTTPS используется порт 443, по которому устанавливается соединение с использованием TLS (Transport Layer Security - безопасность транспортного уровня).

TLS и SSL (TLS и SSL- протоколы 6 уровня модели OSI) - это криптографические протоколы, которые обеспечивают надежную защиту данных прикладного уровня, так как используют асимметричную криптографию, симметричное шифрование и коды аутентичности сообщений. Но поскольку в стеке TCP/IP определены 4 уровня, т.е. отсутствуют сеансовый и представительский уровни, то эти протоколы работают над транспортным уровнем в стеке TCP/IP, обеспечивая безопасность передачи данных между узлами сети Интернет.

Модель IP VPN, в которой настройка VPN обеспечивается заказчиком

Модель IP VPN может быть реализована на базе стандарта IPSec или других протоколов VPN (PPTP, L2TP, OpenVPN). В этой модели взаимодействие между маршрутизаторами заказчика устанавливается через WAN сеть сервис-провайдера. В этом случае провайдер не участвует в настройке VPN, а только предоставляет свои незащищённые сети для передачи трафика заказчика. Сети провайдеров предназначены только для инкапсулированного или наложенного (прозрачного) соединения VPN между офисами заказчика.

Настройка VPN осуществляется телекоммуникационными средствами заказчика, т.е. заказчик сам управляет маршрутизацией трафика. VPN соединение – это соединение поверх незащищённой сети типа точка-точка: «VPN шлюз - VPN шлюз» для объединения удаленных локальных сетей офисов, «VPN пользователь - VPN шлюз» для подключения удаленных сотрудников к центральному офису.

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

OpenVPN обеспечивает безопасные соединения на основе 2-го и 3-го уровней OSI. Если OpenVPN сконфигурировать для работы в режиме моста - он обеспечивает безопасные соединения на основе 2 уровня OSI, если в режиме маршрутизации - на основе 3-го уровня. OpenVPN в отличие от SSL VPN не поддерживает доступ к VPN-сети через web-браузер. Для OpenVPN требуется дополнительное приложение (VPN-клиент).

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

Рис. 1. Модель сети IP VPN (Intranet VPN + Remote Access VPN)

Модель MPLS L3 VPN или L3 VPN, в которой настройка VPN обеспечивается сервис-провайдером или оператором связи (поставщиком услуг)

Рассмотрим процесс организации VPN-сети для трех удаленных локальных сетей офисов заказчика услуг (например, корпорации SC-3), размещенных в различных городах, с помощью магистральной сети MPLS VPN поставщика услуг, построенной на базе технологии MPLS L3 VPN. Кроме того, к сети корпорации SC-3 подключен ПК удаленного рабочего места и ноутбук мобильного пользователя. В модели MPLS L3 VPN оборудование провайдера участвует в маршрутизации клиентского трафика через сеть WAN.

В этом случае доставка клиентского трафика от локальных сетей офисов заказчика услуг к магистральной сети MPLS VPN поставщика услуг осуществляется с помощью технологии IP. Для организации VPN-сети в каждый офис компании устанавливается периферийный или пограничный CE-маршрутизатор (Customer Edge router), который соединяется физическим каналом с одним из пограничных РЕ-маршрутизаторов (Provider Edge router) сети MPLS провайдера (оператора). При этом на физическом канале, соединяющем CE и PE маршрутизаторы, может работать один из протоколов канального уровня (PPP, Ethernet, FDDI, FR, ATM и т.д.).

Сеть поставщика услуг (сервис-провайдера или оператора связи) состоит из периферийных РЕ-маршрутизаторов и опорной сети (ядра сети) с коммутирующими по меткам магистральными маршрутизаторами P (Provider router). Таким образом, MPLS L3 VPN состоит из офисных локальных IP-сетей заказчика и магистральной сети MPLS провайдера (домена MPLS), которая объединяет распределенные локальные сети офисов заказчика в единую сеть.

Удаленные локальные сети офисов заказчика обмениваются IP-пакетами через сеть провайдера MPLS, в которой образуются туннели MPLS для передачи клиентского трафика по опорной сети поставщика. Скриншот модели сети MPLS L3 VPN (Intranet VPN + Remote Access VPN) представлен на рис. 2. С целью упрощения схемы сети приняты следующие начальные условия: все ЛВС офисов относятся к одной VPN, а опорная (магистральная) сеть является доменом MPLS (MPLS domain), находящаяся под единым управлением национального сервис-провайдера (оператора связи).

Необходимо отметить, что MPLS L3 VPN может быть организована с помощью нескольких доменов MPLS разных сервис-провайдеров. На рисунке 2 представлена полносвязная топология VPN.

Рис. 2. Модель сети MPLS L3 VPN (Intranet VPN + Remote Access VPN)

Функционирование PE-маршрутизаторов

Периферийные маршрутизаторы CE и PE (заказчика и провайдера) обмениваются друг с другом маршрутной информацией одним из внутренних протоколов маршрутизации IGP (RIP, OSPF или IS-IS). В результате обмена маршрутной информацией каждый РЕ-маршрутизатор создает свою отдельную (внешнюю) таблицу маршрутизации VRF (VPN Routing and Forwarding) для локальной сети офиса заказчика, подключенной к нему через CE-маршрутизатор. Таким образом, маршрутная информация, полученная от CE, фиксируется в VRF-таблице PE.

Таблица VRF называется виртуальной таблицей маршрутизации и продвижения. Только РЕ-маршрутизаторы знают о том, что в сети MPLS организована VPN для заказчика. Из модели сети MPLS L3 VPN следует, что между CE-маршрутизаторами заказчика не осуществляется обмен маршрутной информацией, поэтому заказчик не участвует в маршрутизации трафика через магистраль MPLS, настройку VPN (РЕ-маршрутизаторов и Р-маршрутизаторов) осуществляет провайдер (оператор).

К РЕ-маршрутизатору могут быть подключены несколько VPN-сетей разных заказчиков (рис.3). В этом случае на каждый интерфейс (int1, int2 и т.д.) PE-маршрутизатора, к которому подключена локальная сеть офиса заказчика, устанавливается отдельный протокол маршрутизации. Для каждого интерфейса РЕ-маршрутизатора один из протоколов IGP создает таблицу маршрутизации VRF, а каждая таблица маршрутизации VRF соответствует VPN-маршрутам для каждого заказчика.

Например, для заказчика SC-3 и его сети LAN0 (главного офиса), подключенной через CE0 к PE0, на PE0 будет сформирована таблица VRF1 SC-3, для LAN1 заказчика SC-3 на PE1 будет создана VRF2 SC-3, для LAN2 на PE2 - VRF3 SC-3 и т.д., а принадлежат они одной VPN SC3. Таблица VRF1 SC-3 является общей для маршрутной информации CE0 и CE4. Необходимо отметить, что таблицы VRF пополняются информацией об адресах локальных сетей всех других офисов данного заказчика с помощью протокола MP-BGP (multiprotocol BGP). Протокол MP-BGP используется для обмена маршрутами непосредственно между РЕ-маршрутизаторами и может переносить в маршрутной информации адреса VPN-IPv4.

Адреса VPN-IPv4 состоят из исходных адресов IPv4 и префикса RD (Route Distinguisher) или различителя маршрутов, который идентифицирует конкретную VPN. В итоге на маршрутизаторах РЕ будут созданы VRF-таблицы с идентичными маршрутами для одной сети VPN. Только те РЕ-маршрутизаторы, которые участвуют в организации одной и той же VPN-сети заказчика, обмениваются между собой маршрутной информацией по протоколу MP-BGP. Префикс RD конфигурируется для каждой VRF-таблицы.

Маршрутная информация, которой обмениваются РЕ-маршрутизаторы по протоколу MP-BGP через глобальный или внутренний интерфейс:

Адрес сети назначения (VPN-IPv4);
Адрес следующего маршрутизатора для протокола (next hop);
Метка Lvpn – определяется номером интерфейса (int) РЕ-маршрутизатора, к которому подключена одна из ЛВС офиса заказчика;
Атрибут сообщения RT (route-target) – это атрибут VPN, который идентифицирует все ЛВС офисов, принадлежащие одной корпоративной сети заказчика или одной VPN.

Рис. 3. РЕ-маршрутизатор

Кроме того, каждый РЕ-маршрутизатор обменивается маршрутной информацией с магистральными P-маршрутизаторами одним из внутренних протоколов маршрутизации (OSPF или IS-IS) и создает также отдельную (внутреннюю) глобальную таблицу маршрутизации (ГТМ) для магистральной сети MPLS. Внешняя (VRF) таблица и внутренняя (ГТМ) глобальная таблицы маршрутизации в РЕ-маршрутизаторах изолированы друг от друга. P-маршрутизаторы обмениваются маршрутной информацией между собой и PЕ-маршрутизаторами с помощью традиционных протоколов внутренней IP-маршрутизации (IGP), например OSPF или IS-IS, и создают свои таблицы маршрутизации.

На основе таблиц маршрутизации с помощью протоколов распределения меток LDP или протоколов RSVP на основе технологии Traffic Engineering строятся таблицы коммутации меток на всех маршрутизаторах P (на PE создаются FTN), образующих определенный маршрут LSP (Label Switched Paths). В результате формируются маршруты с коммутацией по меткам LSP, по которым IP-пакеты продвигаются на основе значений меток заголовка MPLS и локальных таблиц коммутации, а не IP-адресов и таблиц маршрутизации.

Заголовок MPLS добавляется к каждому IP-пакету, поступающему на входной PE-маршрутизатор, и удаляется выходным PE-маршрутизатором, когда пакеты покидают сеть MPLS. В заголовке MPLS используется не метка, а стек из двух меток, т.е. входной PE назначает пакету две метки. Одна из них внешняя L, другая внутренняя Lvpn. Внешняя метка или метка верхнего уровня стека используется непосредственно для коммутации пакета по LSP от входного до выходного PE.

Необходимо отметить, что PE направляет входной трафик в определенный виртуальный путь LSP на основании FEC (Forwarding Equivalence Class – класса эквивалентности продвижения). FEC – это группа пакетов к условиям, транспортировки которых предъявляются одни и те же требования. Пакеты, принадлежащие одному FEC, перемещаются по одному LSP. Классификация FEC может осуществляться различными способами, например: по IP-адресу сети (префиксу сети) назначения, типу трафика, требованиям инжиниринга и т.д.

Если использовать классификацию по IP-адресу сети назначения, то для каждого префикса сети назначения создается отдельный класс. В этом случае протокол LDP полностью автоматизирует процесс создание классов и назначение им значений меток (табл. 1). Каждому входящему пакету, который направляется маршрутизатором PE на определенный IP-адрес сети офиса, назначается определенная метка на основании таблицы FTN.

Таблица 1. FTN (FEC To Next hop) на маршрутизаторе PE1

Из таблицы 1 следует, что значение внешней метки назначает входной маршрутизатор PE1 на основании IP-адреса локальной сети офиса. Внутренняя метка или метка нижнего уровня стека в процессе коммутации пакета по LSP от входного до выходного PE не участвует, а она определяет VRF или интерфейс на выходном PE, к которому присоединена ЛВС офиса заказчика.

Обмен информацией о маршрутах VPN по протоколу MP-BGP

Маршрутная информация (информация о маршрутах VPN), которую передает маршрутизатор PE1 маршрутизатору PE2 по протоколу BGP (красные линии):

Адрес VPN-IPv4: 46.115.25.1:106:192.168.1.0;
Next Hop = 46.115.25.1;
Lvpn=3;
RT= SC-3.

Различитель маршрутов RD=46.115.25.1:106 добавляется к IPv4-адресу сети LAN1 регионального офиса 1. Где 46.115.25.1 – это IP-адрес глобального интерфейса маршрутизатора PE1, через который PE1 взаимодействует с P-маршрутизаторами. Для данного маршрута VPN SC-3 администратор сети провайдера в маршрутизаторе PE1 или PE1 назначает метку (номер), например 106.

Когда маршрутизатор PE2 получает от PE1 адрес сети назначения VPN-IPv4, он отбрасывает разграничитель маршрутов RD, помещает адрес 192.168.1.0 в таблицу VRF3 SC-3 и отмечает, что запись была сделана протоколом BGP. Кроме того, он объявляет этот маршрут, подключенному к нему маршрутизатору заказчика CE2 для данной VPN SC-3.

Таблица VRF3 SC-3 также пополняется протоколом MP-BGP – об адресах сетей других ЛВС офисов данной VPN SC-3. Маршрутизатор PE1 направляет по протоколу MP-BGP маршрутную информация также другим маршрутизаторам: PE0 и PE3. В итоге, все маршруты в таблицах VRF маршрутизаторов (PE0, PE1, PE2 и PE3) содержат адреса всех сетей ЛВС офисов данного заказчика в формате IPv4.

Рис. 4. Таблицы VRF маршрутизаторов (PE0, PE1, PE2 и PE3)

Маршрутная информация, которую передает маршрутизатор PE2 маршрутизатору PE1 по протоколу MP-BGP (красные линии):

Адрес VPN-IPv4: 46.115.25.2:116:192.168.2.0;
Next Hop = 46.115.25.2;
Lvpn=5;
RT=SC-3.

Передача данных между ПК в корпоративной сети организованной на базе технологии MPLS L3 VPN

Рассмотрим, как происходит обмен данными между ПК 2 (IP: 192.168.1.2) сети LAN1 и ПК 1 (IP: 192.168.3.1) сети LAN. Для доступа к файлам, размещенным в директориях или логических дисках ПК 1 (LAN) с общим доступом, необходимо на ПК 2 (LAN1) в строке "Найти программы и файлы" (для ОС Win 7) ввести \\192.168.3.1 и нажать клавишу Enter. В результате на экране ПК 2 будут отображены директории с общим доступом ("расшаренные" директории или папки), которые размещены на ПК 1. Как это происходит?

При нажатии клавишу Enter в ПК 2 (LAN1) на сетевом уровне сформировался пакет с IP-адресом назначения 192.168.3.1. В первую очередь пакет поступает на маршрутизатор CE1 (рис. 5), который направляет его в соответствии с таблицей маршрутизацией на интерфейс int3 маршрутизатора PE1, так как он является следующим маршрутизатором для доступа к сети 192.168.3.0/24, в которой находятся ПК 1 (LAN ГО) с IP-адресом 192.168.3.1. С интерфейсом int3 связана таблица маршрутизации VRF2 SC-3, поэтому дальнейшее продвижение пакета осуществляется на основе ее параметров.

Как следует из таблицы VRF2 SC-3, следующим маршрутизатором для продвижения пакета к сети 192.168.3/24 является PE0 и эта запись была выполнена протоколом BGP. Кроме того, в таблице указано значение метки Lvpn=2, которая определяет интерфейс выходного маршрутизатора PE0. Отсюда следует, что дальнейшее продвижение пакета к сети 192.168.3/24 определяется параметрами глобальной таблицы маршрутизации ГТМ PE1.

Рис. 5. Передача данных между ПК2 (192.168.1.2) и ПК1 (192.168.3.1) сетей LAN1 и LAN главного офиса КС SC-3

В глобальной таблице (ГТМ PE1) адресу следующего маршрутизатора (NH - Next Hop) PE0 соответствует начальное значение внешней метки L=105, которая определяет путь LSP до PE0. Продвижение пакета по LSP происходит на основании L-метки верхнего уровня стека (L=105). Когда пакет проходит через маршрутизатор P3, а затем через маршрутизатор P1, метка L анализируется и заменяется новыми значениями. После достижения пакетом конечной точки LSP, маршрутизатор PE0 удаляет внешнюю метку L из стека MPLS.

Затем маршрутизатор PE0 извлекает из стека метку нижнего уровня стека Lvpn=2, которая определяет интерфейс int2, к которому присоединен маршрутизатор CE0 локальной сети главного офиса заказчика (LAN ГО). Далее из таблицы (VRF1 SC-3), содержащей все маршруты VPN SC3, маршрутизатор PE0 извлекает запись о значении метки Lvpn=2 и о связанном с ней маршруте к сети 192.168.3/24, который указывает на CE0 в качестве следующего маршрутизатора. Из таблицы следует, что запись о маршруте была помещена в таблицу VRF1 SC-3 протоколом IGP, поэтому путь движения пакета от PE0 до CE0 осуществляется по IP-протоколу.

Дальнейшее движение пакета от CE0 к ПК 1 с IP-адресом 192.168.3.1 осуществляется по MAC-адресу, так как CE0 и ПК 1 (192.168.3.1) находятся в одной ЛВС. После получения пакета-запроса от ПК 2 операционная система компьютера ПК 1 отправит копии своих директорий с общим доступом для ПК 2. Операционная система ПК 2, получив копии директорий с общим доступом от ПК 1, отображает их на экране монитора. Таким образом, через общественные сети MPLS провайдера по виртуальным каналам LSP осуществляется обмен данными между двумя ПК, принадлежащим разным ЛВС офисов одного заказчика.

Что касается подключения удаленного мобильного пользователя к ресурсам территориально распределенной корпоративной сети, то его можно реализовать с помощью одной из технологий Remote Access VPN (Remote Access IPSec VPN и SSL VPN). Необходимо отметить, что технология SSL VPN поддерживает два типа доступа: полный сетевой доступ и clientless. Технология clientless SSL VPN обеспечивает удаленный доступ к сети через стандартный веб-браузер, но в этом случае доступны только сетевые приложения с web-интерфейсом. Технология SSL VPN с полным сетевым доступом, после установки на ПК дополнительного приложения (VPN-клиента) обеспечивает доступ ко всем ресурсам территориально распределенной корпоративной сети.

Как правило, подключение удалённого пользователя к MPLS L3 VPN производится посредством сервера удаленного доступа (RAS), который подключается к одному из PE-маршрутизаторов MPLS сети. В нашем случае мобильный пользователь через сеть доступа (Интернет) подключен с помощью Remote Access IPSec VPN к RAS, который соединен с маршрутизатором PE0. Таким образом, мобильный пользователь через IPSec VPN подключается к своей корпоративной сети (корпорации SC-3), организованной на основе MPLS L3 VPN.

Модель MPLS L2 VPN, в которой настройка VPN обеспечивается провайдером или оператором связи (поставщиком услуг)

Организовать единое информационное пространство в трех офисах (например, корпорации SC-3), расположенных в пределах одного города можно на базе широкополосной Metro Ethernet сети оператора связи (L2 VPN). Одной из услуг сетей Metro Ethernet является организация корпоративных сетей через магистральные сети MAN (сети оператора связи в масштабах города). Для организации Metro Ethernet VPN (L2 VPN) используются различные технологии, например AToM (в основном EoMPLS), 802.1Q, L2TPv3 и так далее, но наиболее перспективной является технология MPLS L2 VPN или VPLS. В этом случае доставка клиентского трафика от локальных сетей офисов заказчика услуг к опорной сети MPLS VPN поставщика услуг осуществляется с помощью технологии второго уровня (Ethernet, Frame Relay или ATM).

Операторы связи предоставляют два типа услуг Ethernet сетей для организации виртуальных частных сетей на втором уровне модели OSI, которые формируются на базе технологии MPLS - это VPWS (Virtual Private Wire Services) и VPLS (Virtual Private LAN Services). Эти VPN строятся на базе псевдоканалов (pseudowire), которые связывают пограничные PE-маршрутизаторы сети провайдера (MPLS domain). Туннели LSP или логические каналы создаются при помощи меток, внутри которых прокладываются псевдоканалы (эмулированные VC) и по этим псевдоканалам передаются пакеты MPLS. VPWS основана на Ethernet over MPLS (EoMPLS). Но в VPLS в отличие от сетей point-to-point (P2P) VPWS организация псевдоканалов осуществляется с помощью многоточечных соединений (P2M).

В VPLS существует два способа установления псевдоканалов между любыми двумя PE, которые входят в состав данной VPLS (с помощью протокола BGP и протокола рассылки меток LDP). Расширенный протокол BGP (MP-BGP) обеспечивает автоматическое определения PE, которые взаимодействуют при построении территориально распределенной ЛВС на основе сервиса VPLS, и сигнализацию меток (vc-labels) виртуальных каналов. Для сигнализации vc-labels можно использовать и расширенный протокол LDP. В этом случае выявление всех PE-маршрутизаторов, которые входят в состав данной VPLS, осуществляется в режиме ручной настройки.

Можно также использовать системы управления, которые автоматизируют поиск и настройку PE устройств для организации VPLS сервисов. Для передачи кадров использует стек меток, верхняя метка предназначена для туннелей LSP, которая используется для достижения выходного PE. Нижняя метка - это метка VC Label, которая используется для демультиплексирования виртуальных каналов (pseudowires), передаваемых внутри одного туннеля. В одном туннеле может быть проложено множество псевдоканалов для разных экземпляров VPLS.

Для каждого экземпляра VPLS на PE создаются отдельные виртуальные коммутаторы VSI. Коммутаторы VSI изучают MAC-адреса и строят таблицы продвижения MPLS-пакетов. На основании данных таблицы продвижения коммутаторы VSI, получив кадры, инкапсулированные в пакеты MPLS, направляют их в псевдоканалы ведущие к пограничным PE, к которым подключены пограничные коммутаторы CE сегментов ЛВС офисов заказчика.

На базе VPWS (point-to-point) можно объединить две подсети офисов корпорации в одиную сеть, с единой сквозной IP-адресацией. VPLS – это технология, которая обеспечивает многоточечные соединения поверх пакетной сетевой инфраструктуры IP/MPLS. VPLS позволяет объединить несколько территориально распределенных локальных сетей офисов корпорации в единую локальную сеть. В этом случае магистральная сеть MPLS сервис-провайдера представляет собой виртуальный Ethernet-коммутатор (L2-коммутатор), который пересылает Ethernet-фреймы между сегментами ЛВС отдельных офисов заказчика. Схема территориально распределенной (в пределах города) локальной сети корпорации представлена на рис. 6.

Рис. 6. Схема территориально распределенной (в пределах города) локальной сети корпорации

Суть концепции VPLS заключается в прозрачной передаче Ethernet-фреймов ПК локальных сетей офисов (сегментов сетей офисов заказчика) заказчика по магистральной сети MPLS провайдера. Пограничными устройствами на стороне заказчика VPLS 1 служат коммутаторы CE0, CE1, CE2, которые соединены с устройствами PE0, PE1, PE2. PE-маршрутизаторы взаимодействуют друг с другом, с целью выявления всех PE, подключенных к VPLS 1. Устройства PE и P строят таблицы маршрутизации, на основе которых создаются каналы LSP и псевдоканалы.

В качестве протоколов сигнализации могут использоваться как BGP, так и LDP. Виртуальные коммутаторы VSI 1 устройств PE0, PE1, PE2 строят таблицы продвижения MPLS-пакетов. Например, VSI 1 устройства PE0 формирует таблицу коммутации, представленную на рис. 6. При поступлении Ethernet-фрейма c одного из ПК сети LAN главного офиса на вход устройства PE0 он инкапсулирует Ethernet-фрейм в MPLS пакет и, используя таблицу коммутации, направляет его в туннель, по которому пакет поступает на выходное устройство PE1.

Для продвижения пакета через MPLS сеть (через псевдоканалы в туннелях LSP) используется стек меток, который состоит из метки туннеля LSP и метки псевдоканала VC Label, например, 15. На выходном устройстве PE1 пакеты MPLS преобразуются в Ethernet-фреймы и направляются на коммутатор С1, к которому подключен ПК назначения с MAC-адресом 90:5C:E7:C8:56:93. В документах RFC 4761 и RFC 4762 подробно изложены методы сигнализации на базе протоколов BGP и LDP для локальных сетей организованных с помощью услуг VPLS.

Список источников информации:

1. Компьютерные сети. Принципы, технологии, протоколы: Учебник для вузов. 4-е изд. / В.Г. Олифер, Н.А. Олифер –СПб. Питер, 2010. – 944 с.

2. Олвейн, Вивек. Структура и реализация современной технологии MPLS.: Пер. с англ. – М. : Издательский дом «Вильямс», 2004. – 480 с.

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

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

Путь выбора идеального VPN решения

VPN в роутерах

VPN Enterprise класса

Microsoft VPN

OpenVPN

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

Рутокен VPN

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

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

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

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

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

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

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

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

Теги: Добавить метки

Организация каналов между удаленными сетями посредством 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-серверу (клиенту) на маршрутизаторе, а в офисе добавляем его только на нужные компьютеры.

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

Теги:

Please enable JavaScript to view the