Что такое vpn канал. Как организовать VPN канал между офисами с помощью OpenVPN

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

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

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

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

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

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

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

Принцип работы VPN

Виртуальная частная сеть базируется на трех китах: туннелирование, шифрование и аутентификация.

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

Такое положение дел таит в себе две проблемы. Первая заключается в том, что передаваемая через туннель информация может быть перехвачена злоумышленниками. Если она конфиденциальна (номера банковских карточек, финансовые отчеты, сведения личного характера), то вполне реальна угроза ее компрометации, что уже само по себе неприятно. Хуже того, злоумышленники имеют возможность модифицировать передаваемые через туннель данные так, что получатель не сможет проверить их достоверность. Последствия могут быть самыми плачевными. Учитывая сказанное, мы приходим к выводу, что туннель в чистом виде пригоден разве что для некоторых типов сетевых компьютерных игр и не может претендовать на более серь-езное применение.

К счастью, обе проблемы решаются современными средствами криптографической защиты информации. Чтобы воспрепятствовать внесению несанкционированных изменений в пакет с данными на пути его следования по туннелю, используется метод электронной цифровой подписи (ЭЦП). Суть метода состоит в том, что каждый передаваемый пакет снабжается дополнительным блоком информации, который вырабатывается в соответствии с асимметричным криптографическим алгоритмом и уникален для содержимого пакета и секретного ключа ЭЦП отправителя. Этот блок информации является ЭЦП пакета и позволяет выполнить аутентификацию данных получателем, которому известен открытый ключ ЭЦП отправителя. Защита передаваемых через туннель данных от несанкционированного просмотра достигается путем использования сильных алгоритмов шифрования.

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

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

Чтобы обеспечить совместимость различных реализаций VPN, были приняты стандарты, наиболее распространенными среди которых являются протоколы PPTP и L2TP (см. врезку «Протоколы PPTP и L2TP с IPSEC»). Оба эти стандарта обеспечивают схожий уровень функциональности, однако поскольку L2TP использует протокол UDP для организации туннеля, он может работать через сети ATM (Asynchroneus Transfer Mode), Frame Relay и X.25. Кроме того, L2TP предлагает более высокую защищенность соединения за счет использования протокола обеспечения безопасности IPSec.

Средства для реализации VPN

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

Крупная фирма в случае необходимости обеспечить безопасное соединение нескольких офисов (по схеме route-to-route) и дать возможность удаленной работы (remote access) с ресурсами локальной сети своим сотрудникам скорее всего предпочтет оборудование Cisco как наиболее мощный и гибкий вариант. Если фирма только развивается и ей требуется подключить к главному офису одно региональное представительство, можно ограничиться маршрутизаторами-брандмауэрами производства ZyXEL или D-Link. Это решение существенно дешевле, а главное, не предъявляет таких высоких требований к профессиональному уровню системных администраторов, как настройка маршрутизаторов Cisco. Обе компании предоставляют подробную документацию, описывающую как возможности своих продуктов, так и процедуру их настройки с вариантами использования. Нужно отметить, что аппаратные устройства, как правило, являются комплексными решениями и предлагают целый набор смежных технологий, которые облегчают интеграцию вычислительных устройств через VPN-соединение и увеличивают уровень безопасности.

Обращаясь к программным реализациям VPN, нужно вспомнить о том, что операционные системы Microsoft имеют встроенную поддержку VPN-соединений по протоколам PPTP или L2TP. Если построение VPN-сервера на базе серверной операционной системы этого производителя может вызывать споры и дискуссии, то наличие интегрированного VPN-клиента безусловно является удобством и позволяет организовывать удаленные рабочие места сотрудников с минимальными затратами. Если же в фирме используется другая операционная система или по каким-то причинам интегрированные средства признаны неудовлетворительными, стоит обратить внимание на свободную кросс-платформенную реализацию VPN-сервера OpenVPN, которая доступна по ссылке:
http://openvpn.net/ .

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

Протоколы PPTP и L2TP с IPSec

Сетевая технология PPTP (Point-to-Point Tunneling Protocol) - развитие протокола удаленного доступа PPP (Point-to-Point Protocol). PPTP, относящаяся к стеку протоколов TCP/IP, была создана для организации работы многопротокольных сетей через Интернет. Для функционирования PPTP необходимо установить два TCP-соединения: для управления VPN-соединением и для передачи данных. Конфиденциальность передаваемой информации обеспечивается шифрованием по схеме RC4 с ключом до 128 бит.

Улучшенная версия протокола PPTP - индустриальный стандарт L2TP (Layer Two Tunneling Protocol), представляющий собой комбинацию технологий PPTP и L2F (Layer Two Forwarding). Транспортная среда для протокола L2TP - UDP. Шифрование данных обеспечивает комплекс средств, предлагаемых протоколом безопасности IPSec. Доступны следующие методы шифрования: DES (Data Encryption Standard) с 56-бит ключом и 3DES (Triple DES) с тремя 56-бит ключами.
Кроме того, IPSec предоставляет механизм согласования ключей IKE (Internet Key Exchange), аутентификацию Kerberos и другие технологии информационной безопасности.

В основе работы обоих рассмотренных протоколов туннелирования лежит инкапсуляция пакетов протокола сетевого уровня, используемого в локальной сети, в PPP-пакеты. На рисунках представлен вид структуры информации, передаваемой по туннелю. Полезные данные, заключенные в пакеты протоколов сетевого уровня (IP, IPX или NetBEUI), снабжены PPP-заголовками, содержащими информацию о протоколе. Они необходимы для того, чтобы полученные данные направлялись соответствующему драйверу. Протокол PPTP шифрует пришедшую информацию и снабжает ее заголовком, требующимся для доставки получателю - шлюзу VPN. В отличие от него, L2TP добавляет заголовки L2TP и UDP. После этого модуль обеспечения безопасности IPSec выполняет шифрование данных. Затем они, сопровожденные IPSec-заголовком, дополняются адресной информацией, необходимой для доставки.

Аппаратные устройства VPN

Поскольку стоимость аппаратных решений для организации VPN приемлема даже для малых фирм или индивидуальных предпринимателей, а в эксплуатации они гораздо удобнее и надежнее, нежели программные средства на базе ПК, имеет смысл обратить внимание на некоторые из них. Создать точку доступа для нескольких VPN-соединений можно на основе VPN-маршрутизатора DI-804HV/DI-808HV (позволяет организовать до 40 соединений) производства D-Link или брандмауэра ZyWALL (от 1 до 100 соединений в зависимости от модификации) компании ZyXEL. Конфигурирование обоих устройств может быть выполнено через удобный веб-интерфейс, продукты ZyXEL, кроме того, позволяют получить доступ к ZyNOS (сетевой операционной системе ZyXEL) в режиме командной строки по протоколу Telnet, что дает возможность более тонкой настройки и отладки соединений. Интересным и недорогим решением для объединения локальных сетей является использование ADSL модема-маршрутизатора-брандмауэра ZyXEL Prestige P661H. Это устройство позволяет организовать два VPN-соединения, но помимо того может служить мостом между тремя IP-подсетями, разделяющими общую среду Ethernet (с возможностью фильтрации трафика между ними), направлять IP-трафик в соответствии с таблицей статических маршрутов, реализует фирменную технологию Any-IP, которая позволяет задействовать его в качестве шлюза по умолчанию компьютерам, сконфигурированным в расчете на работу в другой подсети.

При настройке описанных устройств нужно внимательно прописывать параметры VPN-соединений, так как в случае даже небольшой ошибки туннели не установятся. Например, предопределенные ключи (Preshared Key) должны быть одинаковыми на обоих окончаниях туннеля, для одного и того же VPN-соединения не могут различаться механизмы согласования ключей (Manual или IKE) и криптографические алгоритмы шифрования и аутентификации. Если что-то отказывается работать, необходимо обратиться к сопроводительной документации, понять принцип, в соответствии с которым должен функционировать проблемный участок, и определить круг возможных причин не-работоспособности.

Выбирая параметры туннеля, следует внимательно ознакомиться с возможными вариантами его реализации, с тем чтобы быть уверенным в получении должной функциональности. Так, например, протокол AH (Authentication Header) организации SA (Security Association) обеспечивает только аутентификацию передаваемых данных без их шифрования. Для получения полной защиты следует выбирать протокол ESP (Encapsulating Security Payload).

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

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

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

Network N_B1 содержит:

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

Network N_B2 содержит:

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

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

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