Искал интересную тему, заслуживающую внимания, чтобы получить инвайт на Хаброхабре и вот нашёл. Такой особенный случай мне пришлось недавно реализовать.
Здесь мы будем говорить о двух сетях, которые нужно объединить, одну из которых я буду называть «моя офисная сеть», а другую «удалённая сеть».
Системный администратор удалённой сети отказывается вносить наименьшие изменения, для подключения и единственное что можно сделать — это поместить своё оборудование в удалённой сети. Выход в интернет из этой сетиv4 производится через шлюз, который натит в мир. Нужно построить тоннель, между двумя офисами, чтобы узлы моей офисной сети могли получать доступ к узлам удалённой сети, при минимальных изменениях c обеих сторон.
Для выполнения задачи объединения двух сетей и построения виртуального тоннеля нужно использовать Virtual Private Network. В ходе поиска подходящего варианта подключения, для себя разделил VPN на два вида: клиент-серверный вариант и равноправный. В следующих моментах заключается принципиальное отличие:
Примечание1: В обоих вариантах должно соблюдается одно из условий (для клиент-серверного варианта, только для сервера):
Примеры VPN протоколов:
Клиент-серверный VPN:
Равноправный VPN:
Таким образом, становится очевиден выбор варианта — Клиент-серверный VPN. Так как менять со стороны клиента ничего не нужно в этом варианте.
И первое что приходит на ум — старый добрый PPTP. Недостатков в плане безопасности у него полно, хотя существуют его более продвинутые, новые, версии. Не смотря на огрехи в плане безопасности, у PPTP есть ещё одна очень не приятная особенность — это протокол GRE, используемый PPTP клиентом для установления соединения с сервером. В случае установки связи по схеме указанной в Примечании1.B оборудование которое производит перенаправление порта (Port Forwarding) должно уметь пропускать соединение по протоколу PPTP (Часто расположен в секции Application Level Gateway) через себя (Функция часто называется pass through PPTP, что с английского так и переводится пропустить PPTP через себя). Это связано с особенностями протокола и тем, что изначально PPTP не был рассчитан на работу через NAT. Если такой функции нет, то в этой схеме VPN канал установлен не будет по той простой причине, что сервер не увидит входящего запроса на соединение.
PPPoE, L2TP и PPTP использует далёкие от совершенства протоколы авторизации pap, chap, mscap1 и mscap2.
К счастью протокол OpenVPN лишен большинства выше перечисленных недостатков, не использует протокол GRE и был специально разработан с учётом особенностей сетей использующих NAT.
Немного об Open VPN: Работает на порту 1194, может использовать как TCP так и UDP протоколы. Протокол уровня приложения, по модели OSI.
Таким образом, выбор из этих протоколов стал тоже очевиден — OpenVPN. Конечно же, он не идеален и не панацея, но для этого случая подойдёт наилучшим образом.
Будем использовать OpenVPN сервер со стороны моей офисной сети (где я могу что-то менять, по большому счёту могу всё менять, просто не хочу) будет сервер, а со стороны удалённой сети будет клиент. Для того, чтобы сильно не менять схему своей офисной сети, в которой фаервол является аппаратным устройством (и у которого нет встроенного OpenVPN сервера), нужно поставить за ним устройство с OpenVPN сервером и пробросить на него порт 1194.
Теперь мы представляем, как будет устанавливаться связь между клиентом и сервером, но как узлы сети моего офиса смогут видеть узлы удалённой сети?
Чтобы не вносить изменения в маршруизаторы удалённой сети будем скрывать сеть моего офиса НАТом. Со стороны моего офиса, на маршрутизаторе, запишем маршрут, к удалённой сети через ВПН тоннель.
Недостатком маскирования, в данном случае, может стать, не возможность получения доступа узлов удалённой сети к узлам моего офиса, что в данном случае, скорее, преимущество.
На схеме красным цветом отображен тоннель установленный клиентом к серверу, чёрным пунктиром отображен маршрут пакета от узла из моего офиса к узлу из удалённого офиса через тоннель.
На прокси-сервере 192.168.0.1-192.168.100.3 были добавлены маршруты:
Здесь мы заворачиваем все пакеты, адресованные сети 192.168.1.0/30 и 10.0.0.0/8 на маршрутизатор 192.168.100.2-192.168.1.1. На этом же маршрутизаторе работает OpenVPN Server. Все пакеты по умолчанию пересылаются в интернет через шлюз 192.168.100.1-Real_1, а для сети 10.0.0.0/8 пересылаются через виртуальный канал, построенный в сети интернет на OpenVPN Client 192.168.1.2-10.1.1.2.
Для нормальной работы OpenVPN Server'а на шлюзе 192.168.100.1-Real_1 проброшен на него порт 1194.
На OpenVPN Client'е прописан адрес из удалённой подсети 10.1.1.2. Шлюз по умолчанию для него 10.1.1.1. Клиент устанавливает связь в интернет через реальный IP адрес Real_1. Для сети 192.168.100.0/24 прописан маршрут через 192.168.1.1-192.168.100.2 для того чтобы пакеты пришедшие из моего офиса благополучно вернулись обратно. Здесь же, на клиенте, установлено правило в файерволе (таблица NAT): пакеты, пришедшие из сети 192.168.100.0/24, маскируются (masquerading) под адрес из этой подсети (10.1.1.2).
Так пакеты из моей сети будут попадать в удалённую сеть и обратно в соответствии с правилами:
Пакеты, посланные узлом 192.168.0.123 из моего офиса в удалённую сеть 10.0.0.0/8 на узел 10.0.0.123 будут замаскированы шлюзом 192.168.0.1-192.168.100.3 под адрес 192.168.100.3 и по правилу направятся в маршрутизатор 192.168.100.2-192.168.1.1, откуда они перенаправятся через адрес 192.168.1.1 на адрес маршрутизатора 192.168.1.2-10.1.1.2, где они снова будут замаскированы под адрес 10.1.1.2, откуда благополучно дойдут до адресата 10.0.0.123. Адрес 10.0.0.123 пошлёт ответ 10.1.1.2-192.168.1.2, который отошлёт ответ с адреса 192.168.1.2 на адрес 192.168.1.1-192.168.100.2, который вернёт пакет с адреса 192.168.100.2 серверу 192.168.100.3-192.168.0.1, который передаст пакет обратно 192.168.0.123 с адреса 192.168.0.1.
Эта подробная процедура прослеживания прохождения пакетов понадобилась для того чтобы удостоверится, что все настройки были сделаны правильно и ничего не было пропущено.
Можно использовать обычный компьютер с установленной системой *nix и пакетом ПО OpenVPN.
А можно использовать специализированное оборудование. Так сложилось, что у меня были два Mikrotik RB450.
Дело в том, что первый раз я пытался тестировать всё на PPTP, но клиент не мог установить связь с сервером, хотя с компьютера под Windows установить связь было возможно.
Только с версии 3.25 или выше можно обновляться до 4.20, так написано на официальном сайте www.mikrotik.com/download.html#2.php.
Поэтому в разделе загрузки выбираем нашу систему, а в разделе Software выбираем Legacy. Здесь я выбрал последний релиз 3.30, который без лишних вопросов ставится поверх 3.22:
Делал по аналогии со статьей www.asp24antenna.com.ua/obnovlenie-s-328-os-na-routeros-40.
Открываем WinBOX заходим в files, перетягиваем туда файл прошивки 3.30, перезагружаемся и ждём двойного пика — всё прошивка уже стоит. Потом заходим в System>License и жмём обновить (роутер должен быть в это время подключён к сети интернет с настроенным DNS). После обновления снова скачиваем только уже новую прошивку и кидаем её в роутер, перезагружаемся — всё у нас самая новая прошивка! Провозился с обновлением обоих микротиков RB450 с версии 3.22 на 3.30 а потом на 4.20, но это не помогло и никак не исправило ситуации с PPTP :(
По руководству этой стати wiki.mikrotik.com/wiki/OpenVPN я создал сертификаты и импортировал их. За подробностями обращайтесь к указанной статье. Опишу только ключевые моменты или те, которые вызывали трудности.
Создал аккаунт на CAcert.org, хотя это вовсе не обязательно, можно выдать самоподписанный сертификат.
На роутере, который будет OpenVPN server'ом, выполняем команды:
Открываем файл certificate-request.pem копируем его содержимое (скопировать на компьютер, к примеру, по FTP или перетяните на рабочий стол из WinBOX'а) и вставляем в форму на сайте CAcert.org (нужна регистрация) Server Certificates>New, полученный ответ копируем в файл certificate-response.pem (нужно залить на OpenVPN server).
Теперь импортируем сертификаты в WinBOX:
После чего у добавляемого сертификата появится пометка KR. Если вместо неё вы видите QR, импортируйте private-key.pem ещё раз (мне помогло).
Теперь приступаем к созданию сервера (не забудьте поменять под свои нужды):
Интересно отметить, что, теоретически, есть возможность установки ВПН соединения, не имея ни одного реального IP адреса. Аналог такого соединения – устанавливаемое голосовыми интернет месагерами типа скайп. Суть такого соединения состоит в том, что есть несколько узлов и один сервер. Каждый узел соединён с сервером, но когда узел1 хочет установить сеанс связи с узлом2, он запрашивает параметры установленного соединения на сервер узла2, у сервера, после чего «вклинится» вместо сервера, до разрыва установленного соединения и установит его напрямую. Это реализуется при помощи протокола SIP (Session Initiation Protocol). Именно по этому сервера Скайп не загружены промежуточным трафиком, генерируемым клиентами. Результат таких изысканий установки соединения ВПН тоннеля используя SIP контроль привёл по ссылке www.ietf.org/mail-archive/web/sipping/current/msg10092.html. К сожалению, широкого распространения эта идея не приобрела, не смотря на то, что существуют наброски VPN-SIP от IETF и также существует описание от ETSI TS 185 010 V2.1.1 (2009-07) (Нужно ввести «TS 185 010» и быть зарегистрированным членом ETSI чтобы прочесть документ).
Пример установки VPN соединения, используя SIP контроль:
Рис.1 Удалённый доступ к домашней сети.
Всё же существуют закрытые, программы с аналогичным функционалом, такие как Hamachi, Teamviewer, которые, вполне возможно, используют именно эту идею.
Только представьте, как преобразился бы мир, если бы он имел распространенный и стандартизированный протокол, по которому можно было бы установить VPN соединение, используя SIP контроль!
Постановка задачи: Получить доступ к узлам удалённой сети.
Здесь мы будем говорить о двух сетях, которые нужно объединить, одну из которых я буду называть «моя офисная сеть», а другую «удалённая сеть».
Системный администратор удалённой сети отказывается вносить наименьшие изменения, для подключения и единственное что можно сделать — это поместить своё оборудование в удалённой сети. Выход в интернет из этой сетиv4 производится через шлюз, который натит в мир. Нужно построить тоннель, между двумя офисами, чтобы узлы моей офисной сети могли получать доступ к узлам удалённой сети, при минимальных изменениях c обеих сторон.
Для выполнения задачи объединения двух сетей и построения виртуального тоннеля нужно использовать Virtual Private Network. В ходе поиска подходящего варианта подключения, для себя разделил VPN на два вида: клиент-серверный вариант и равноправный. В следующих моментах заключается принципиальное отличие:
- В равноправном VPN, использующем глобальную сеть интернет, нужно иметь один реальный IP адрес, для каждого из узлов (минимум 2-ва узла). Здесь соединение может быть инициировано каждой из сторон (именно поэтому я так и обозвал его, равноправный), их может быть больше двух.
- В клиент-серверном варианте, использующем глобальную сеть интернет, нужен только один реальный IP адрес, для сервера. Соединение здесь происходит по требованию клиента, сервер всегда ожидает, клиентов может быть больше одного.
Примечание1: В обоих вариантах должно соблюдается одно из условий (для клиент-серверного варианта, только для сервера):
- A. VPN peer, должен находится непосредственно на шлюзе (должно быть установлено дополнительное ПО, или устройство должно быть способно устанавливать нужный тип VPN соединений).
- B. Если же нет возможности запустить VPN peer непосредственно на шлюзе, нужно его сконфигурировать так, чтобы он смог пропускать порт на другое устройство, настроенное как VPN peer.
Примеры VPN протоколов:
Клиент-серверный VPN:
- PPTP;
- L2TP;
- OpenVPN;
- PPPoE;
- ...
Равноправный VPN:
- IPSec;
- ...
Таким образом, становится очевиден выбор варианта — Клиент-серверный VPN. Так как менять со стороны клиента ничего не нужно в этом варианте.
Какой же из клиент-серверных вариантов выбрать?
И первое что приходит на ум — старый добрый PPTP. Недостатков в плане безопасности у него полно, хотя существуют его более продвинутые, новые, версии. Не смотря на огрехи в плане безопасности, у PPTP есть ещё одна очень не приятная особенность — это протокол GRE, используемый PPTP клиентом для установления соединения с сервером. В случае установки связи по схеме указанной в Примечании1.B оборудование которое производит перенаправление порта (Port Forwarding) должно уметь пропускать соединение по протоколу PPTP (Часто расположен в секции Application Level Gateway) через себя (Функция часто называется pass through PPTP, что с английского так и переводится пропустить PPTP через себя). Это связано с особенностями протокола и тем, что изначально PPTP не был рассчитан на работу через NAT. Если такой функции нет, то в этой схеме VPN канал установлен не будет по той простой причине, что сервер не увидит входящего запроса на соединение.
PPPoE, L2TP и PPTP использует далёкие от совершенства протоколы авторизации pap, chap, mscap1 и mscap2.
К счастью протокол OpenVPN лишен большинства выше перечисленных недостатков, не использует протокол GRE и был специально разработан с учётом особенностей сетей использующих NAT.
Немного об Open VPN: Работает на порту 1194, может использовать как TCP так и UDP протоколы. Протокол уровня приложения, по модели OSI.
Таким образом, выбор из этих протоколов стал тоже очевиден — OpenVPN. Конечно же, он не идеален и не панацея, но для этого случая подойдёт наилучшим образом.
Немного подрезюмируем.
Будем использовать OpenVPN сервер со стороны моей офисной сети (где я могу что-то менять, по большому счёту могу всё менять, просто не хочу) будет сервер, а со стороны удалённой сети будет клиент. Для того, чтобы сильно не менять схему своей офисной сети, в которой фаервол является аппаратным устройством (и у которого нет встроенного OpenVPN сервера), нужно поставить за ним устройство с OpenVPN сервером и пробросить на него порт 1194.
Теперь мы представляем, как будет устанавливаться связь между клиентом и сервером, но как узлы сети моего офиса смогут видеть узлы удалённой сети?
Чтобы не вносить изменения в маршруизаторы удалённой сети будем скрывать сеть моего офиса НАТом. Со стороны моего офиса, на маршрутизаторе, запишем маршрут, к удалённой сети через ВПН тоннель.
Недостатком маскирования, в данном случае, может стать, не возможность получения доступа узлов удалённой сети к узлам моего офиса, что в данном случае, скорее, преимущество.
Созревшая схема.
На схеме красным цветом отображен тоннель установленный клиентом к серверу, чёрным пунктиром отображен маршрут пакета от узла из моего офиса к узлу из удалённого офиса через тоннель.
На прокси-сервере 192.168.0.1-192.168.100.3 были добавлены маршруты:
Route 10.0.0.0/8 192.168.100.2
Route 192.168.1.0/30 192.168.100.2Здесь мы заворачиваем все пакеты, адресованные сети 192.168.1.0/30 и 10.0.0.0/8 на маршрутизатор 192.168.100.2-192.168.1.1. На этом же маршрутизаторе работает OpenVPN Server. Все пакеты по умолчанию пересылаются в интернет через шлюз 192.168.100.1-Real_1, а для сети 10.0.0.0/8 пересылаются через виртуальный канал, построенный в сети интернет на OpenVPN Client 192.168.1.2-10.1.1.2.
Для нормальной работы OpenVPN Server'а на шлюзе 192.168.100.1-Real_1 проброшен на него порт 1194.
На OpenVPN Client'е прописан адрес из удалённой подсети 10.1.1.2. Шлюз по умолчанию для него 10.1.1.1. Клиент устанавливает связь в интернет через реальный IP адрес Real_1. Для сети 192.168.100.0/24 прописан маршрут через 192.168.1.1-192.168.100.2 для того чтобы пакеты пришедшие из моего офиса благополучно вернулись обратно. Здесь же, на клиенте, установлено правило в файерволе (таблица NAT): пакеты, пришедшие из сети 192.168.100.0/24, маскируются (masquerading) под адрес из этой подсети (10.1.1.2).
Теоретическая проверка прохождения пакетов
Так пакеты из моей сети будут попадать в удалённую сеть и обратно в соответствии с правилами:
Пакеты, посланные узлом 192.168.0.123 из моего офиса в удалённую сеть 10.0.0.0/8 на узел 10.0.0.123 будут замаскированы шлюзом 192.168.0.1-192.168.100.3 под адрес 192.168.100.3 и по правилу направятся в маршрутизатор 192.168.100.2-192.168.1.1, откуда они перенаправятся через адрес 192.168.1.1 на адрес маршрутизатора 192.168.1.2-10.1.1.2, где они снова будут замаскированы под адрес 10.1.1.2, откуда благополучно дойдут до адресата 10.0.0.123. Адрес 10.0.0.123 пошлёт ответ 10.1.1.2-192.168.1.2, который отошлёт ответ с адреса 192.168.1.2 на адрес 192.168.1.1-192.168.100.2, который вернёт пакет с адреса 192.168.100.2 серверу 192.168.100.3-192.168.0.1, который передаст пакет обратно 192.168.0.123 с адреса 192.168.0.1.
Эта подробная процедура прослеживания прохождения пакетов понадобилась для того чтобы удостоверится, что все настройки были сделаны правильно и ничего не было пропущено.
Какое оборудование выбрать в качестве OpenVPN сервера и клиента?
Можно использовать обычный компьютер с установленной системой *nix и пакетом ПО OpenVPN.
А можно использовать специализированное оборудование. Так сложилось, что у меня были два Mikrotik RB450.
Настройка RB450 или почему я не тестировал PPTP.
Дело в том, что первый раз я пытался тестировать всё на PPTP, но клиент не мог установить связь с сервером, хотя с компьютера под Windows установить связь было возможно.
Обновление Mikrotik RB450 с версии 3.22 на 4.20:
Только с версии 3.25 или выше можно обновляться до 4.20, так написано на официальном сайте www.mikrotik.com/download.html#2.php.
Поэтому в разделе загрузки выбираем нашу систему, а в разделе Software выбираем Legacy. Здесь я выбрал последний релиз 3.30, который без лишних вопросов ставится поверх 3.22:
Делал по аналогии со статьей www.asp24antenna.com.ua/obnovlenie-s-328-os-na-routeros-40.
Открываем WinBOX заходим в files, перетягиваем туда файл прошивки 3.30, перезагружаемся и ждём двойного пика — всё прошивка уже стоит. Потом заходим в System>License и жмём обновить (роутер должен быть в это время подключён к сети интернет с настроенным DNS). После обновления снова скачиваем только уже новую прошивку и кидаем её в роутер, перезагружаемся — всё у нас самая новая прошивка! Провозился с обновлением обоих микротиков RB450 с версии 3.22 на 3.30 а потом на 4.20, но это не помогло и никак не исправило ситуации с PPTP :(
Решил строить сразу на OpenVPN.
По руководству этой стати wiki.mikrotik.com/wiki/OpenVPN я создал сертификаты и импортировал их. За подробностями обращайтесь к указанной статье. Опишу только ключевые моменты или те, которые вызывали трудности.
Создал аккаунт на CAcert.org, хотя это вовсе не обязательно, можно выдать самоподписанный сертификат.
На роутере, который будет OpenVPN server'ом, выполняем команды:
/certificate create-certificate-request
#Обязательно заполнить следующие поля:
passphrase:
(Your name) common name:
#Мы получим два файла
certificate-request.pem
private-key.pemОткрываем файл certificate-request.pem копируем его содержимое (скопировать на компьютер, к примеру, по FTP или перетяните на рабочий стол из WinBOX'а) и вставляем в форму на сайте CAcert.org (нужна регистрация) Server Certificates>New, полученный ответ копируем в файл certificate-response.pem (нужно залить на OpenVPN server).
Теперь импортируем сертификаты в WinBOX:
System> Certificates> Import
сначала добавим certificate-response.pem
потом private-key.pemПосле чего у добавляемого сертификата появится пометка KR. Если вместо неё вы видите QR, импортируйте private-key.pem ещё раз (мне помогло).
Теперь приступаем к созданию сервера (не забудьте поменять под свои нужды):
/ interface ethernet
set ether1 name="ether1"
#Этого можно и не делать
/ interface bridge
add name="lan" arp=proxy-arp
#Внимание, этот аргумент важен arp=proxy-arp!
/ interface bridge port
add interface=ether1 bridge=lan
/ ip address
add address=192.168.1.1/24 interface=lan
#Это адрес сервера
/ ip pool
add name="ovpn-pool" ranges=192.168.1.2-192.168.1.2
#В пуле будет только один адрес.
/ ppp profile
add name="ovpn-profile" local-address=192.168.1.1 remote-address=ovpn-pool use-encryption=yes only-one=yes change-tcp-mss=default
#Странно, но это создается в / ppp %)
/interface ovpn-server server
set enabled=yes auth=sha1 netmask=24 certificate=cert1 max-mtu=1500 port=1194 cipher=aes256 keepalive-timeout=60 mode=ip require-client-certificate=no default-profile=ovpn-profile
#Настраиваем наш сервер на необходимый уровень безопасности
#Важно выбрать mode=ip !
/ ppp secret
add name="user-1" service=pptp password="123456" profile=ovpn-profile
#Обязательно указывайте имя пользователя и пароль в кавычках!
На роутере, который будет OpenVPN Client'ом выполняем:
/interface ovpn-client
add name="ovpn-out1" connect-to=Real_1 port=1194 mode=ip user="user-1" password="123456" profile=default certificate=none cipher=aes256 add-default-route=no
#Вместо Real_1 поставьте реальный IP вашего OpenVPN сервера.
#Имя пользователя и пароль указываем в кавычках!
#Важно выбрать mode=ip !
/ip firewall nat
chain=srcnat out-interface=ether1 src-address=192.168.100.0/24 action=masquerade
#Маскируем адреса пришедшие с 192.168.100.0/24
#На этом всё :)Лирическое отступление
Интересно отметить, что, теоретически, есть возможность установки ВПН соединения, не имея ни одного реального IP адреса. Аналог такого соединения – устанавливаемое голосовыми интернет месагерами типа скайп. Суть такого соединения состоит в том, что есть несколько узлов и один сервер. Каждый узел соединён с сервером, но когда узел1 хочет установить сеанс связи с узлом2, он запрашивает параметры установленного соединения на сервер узла2, у сервера, после чего «вклинится» вместо сервера, до разрыва установленного соединения и установит его напрямую. Это реализуется при помощи протокола SIP (Session Initiation Protocol). Именно по этому сервера Скайп не загружены промежуточным трафиком, генерируемым клиентами. Результат таких изысканий установки соединения ВПН тоннеля используя SIP контроль привёл по ссылке www.ietf.org/mail-archive/web/sipping/current/msg10092.html. К сожалению, широкого распространения эта идея не приобрела, не смотря на то, что существуют наброски VPN-SIP от IETF и также существует описание от ETSI TS 185 010 V2.1.1 (2009-07) (Нужно ввести «TS 185 010» и быть зарегистрированным членом ETSI чтобы прочесть документ).
Пример установки VPN соединения, используя SIP контроль:
Рис.1 Удалённый доступ к домашней сети.
Всё же существуют закрытые, программы с аналогичным функционалом, такие как Hamachi, Teamviewer, которые, вполне возможно, используют именно эту идею.
Только представьте, как преобразился бы мир, если бы он имел распространенный и стандартизированный протокол, по которому можно было бы установить VPN соединение, используя SIP контроль!
