OpenVPN L2 | автор: admin | 12 июля 2022
Категория: Обзоры программ
Приветствую всех! По немногочисленным просьбам, я всё же решил разместить здесь пост на тему создания OpenVPN туннелей на втором уровне OSI, L2 то есть -)
Некоторый анализ информации, из размещённых различными авторами постов и статей, на просторах Интернета, дал понять, что авторы в основном пытаются строить туннели на L3, т.е. третьем уровне OSI. Возможно у них для этого есть причины, а может они просто любят потом всё маршрутизировать (имея при этом некоторый гемморой -)), а может просто не могут для себе уяснить разницу между L2 и L3 -). Тем не менее, использование L2, снимает многочисленные проблемы, с которыми может столкнуться строитель VPN туннелей.
Представим себе ситуацию - IT-специалисту необходимо объединить на одном уровне головной офис с удалёнными отделениями, для получения различных плюшек и сервисов от ядра локальной сети головного офиса, например ввести все машины в единый домен, IP-телефония, видеоконференции, пропуск Интернет-трафика через головной офис, в целях контроля и ограничений и т.д. Но отделения могут находиться как в пределах одного города, так и находиться на значительном расстоянии. При этом, специалист не обладает широкими возможностями в плане выбора оборудования, да и общее количество хостов в сети не будет превышать 350-400. При большем количестве хостов, возникает проблема коллизионного шума, но это уже отдельная тема.
Задача поставлена и надо её решать.
1. Прежде всего, надо определиться с общей адресацией сетей головного офиса и удалённых отделений. На схеме ниже, выбрана адресация 192.168.48.0/22 которая при данной битовой маске, позволяет получить 1024 хоста в сети. Для удобства, отделения распределены на подсети.
2. Необходимо, чтобы IP-адреса выдаваемые провайдером для головного офиса были глобального вида и статические. Для удаленных отделений этого не требуется. Достаточно, чтобы они были глобальные.
3. Для сокращений задержек по пути следования пакетов, желательно с обоих концов туннеля выбирать единого провайдера.
Связку сервер-клиенты будем реализовывать на CentOS 6.5. Скачиваем дистрибутив CentOS 6.5 x86_64 minimal Устанавливаем на машину имеющую на борту две сетевых карты, настраиваем одну из сетевых карт для доступа по SSH (например)
На второй карте IP-адрес не НАЗНАЧАЕМ! Подключаемся, обновляем систему...
#yum update
Устанавливаем wget...
#yum install wget
Подключаем дополнительные репозитории, в зависимости от выбранной разрядности системы.
Устанавливаем, по желанию, некоторые дополнительные программы...
#yum install mc nano tcpdump nmap
Корректируем файл ifcfg-eth0 к следующему виду...
#nano /etc/sysconfig/network-scripts/ifcfg-eth0
ставим опцию ONBOOT=yes, иначе при перезагрузке eth0 автоматически не поднимется.
Устанавливаем имя нашего сервера VPN...
#nano /etc/sysconfig/network
В данном случае...
Можно перезагрузиться -) reboot
====
Если наш сервер нормально загрузился и мы имеем к нему доступ по SSH, тогда можно продолжить.
Устанавливаем openvpn и необходимые утилиты...
#yum install openvpn easy-rsa bridge-utils
---
OpenVPN способен работать в двух режимах:
1. Маршрутизации (создаётся интерфейс tun)
2. Моста (создаётся интерфейс tap)
Мы будем использовать интерфейс tap и для того чтобы соединить его с нашей клиентской подсетью, организуем мост.
Предварительно следует проверить значения;
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
в файле /etc/sysctl.conf, они должны быть равны нулю. Данные параметры разрешают/запрещают передавать данные проходящие через мост в netfilter. Так как, нам этого не надо, то и передавать мы туда ничего не будем -)
---
Команда разработчиков OpenVPN, любезно приготовила для нас скрипты поднятия/опускания моста -) Запускаем mc и шагаем в /usr/share/doc/openvpn-2.3.2/sample/sample-scripts. Там мы видим два файла - bridge-start и bridge-stop. Копируем их в /etc/openvpn c именами openvpn-startup и openvpn-shutdown соответственно. Делаем их исполняемыми...
chmod +x openvpn-startup openvpn-shutdown
при запуске демона openvpn они будут выполняться автоматически. Правим скрипт openvpn-startup...
nano /etc/openvpn/openvpn-startup
Задаём IP-адрес на сетевой карте eth1 192.168.48.7/22 нашего моста в подсети 192.168.48.0/22 главного офиса.
Делаем проверку поднятия моста...
/etc/openvpn/./openvpn-startup
Если всё в порядке, видим что у нас появились интерфейсы tap0 и br0 с IP-адресом 192.168.48.7
Также проверить состояния моста можно командой
Как видно из вывода в мост объединены интерфейсы eth1 и tap0.
===
Поехали дальше -)
Создаем конфигурационный файл, предварительно удалив другие...
#rm -f /etc/openvpn/*.conf
#touch /etc/openvpn/server.conf
У меня их не было, но мало ли -)
Создаем директорию для логов...
#mkdir /var/log/openvpn
Создаём ключи OpenVPN. Шагаем в /usr/share/easy-rsa/2.0
#cd /usr/share/easy-rsa/2.0
Открываем файлик vars и заносим туда свои значения...
Далее инициализируем PKI и очищаем от старых сертификатов и ключей папку keys/server и создаем серийный и индексные файлы для новых ключей.
#. ./vars
Обратите внимание - две точки через пробел
#./clean-all
Командой build-ca создаём сертификат и ключ центра сертификации (CA).
Обратите внимание, что большинство запрошенных параметров установлены в значения по умолчанию, взятые из файла vars. Common name - единственный параметр, который должен быть явно указан. ЭТО ИМЯ МАШИНЫ ДЛЯ КОТОРОЙ ГЕНЕРИРУЕМ СЕРТИФИКАТ - hd-office.
Создаем сертификат X.509 для сервера hd-office. Всё аналогично заполняем, в том числе cтроки в которых указываем пароль.
Создаём ключи для клиентов (metall, enrgo, stal)...
Будьте внимательны при заполнени данных сертификатов, поле Common Name обязательно к заполнению, причем для сервера оно должно быть одно, а для клиента другое. Например в поле Common Name при генерации сертификата X.509 для сервера мы написали hd-office (имя машины сервера), а для клиента соотвественно metall (имя машины клиента отделения металлообработки). Для остальных клиентов, (enrgo, stal) сертификаты создаются аналогично.
Далее генерируем ключ Диффи Хельмана...
#./build-dh
Создаем ключ для tls-аутентификации...
#openvpn --genkey --secret ta.key
Запускаем mc и копируем директорию keys из /usr/share/easy-rsa/2.0 в /etc/openvpn, также в /etc/openvpn/keys копируем файл ta.key.
Так как наш сервер VPN будет работать от имени openvpn, входящего в группу openvpn, расставим соответствующие права.
В директории /etc/openvpn/keys располагаются следующие файлы;
Файлы, которые необходимы серверу:
ca.crt
ta.key
hd-office.crt
hd-office.key
dh2048.pem
Файлы клиента metall:
metall.crt
metall.key
ca.crt
ta.key
-----
Далее правим файл конфигурации сервера...
#nano /etc/openvpn/server.conf
Запускаем сервер openvpn командой
Настраиваем сервер openvpn для автоматического запуска
#chkconfig --level 2345 openvpn on
===
На этом, настройка серверной части закончена. Настройка клиента несколько проще -)
1. Берём машинку и устанавливаем на неё CentOS 6.5
2. Устанавливаем обновления и подключаем дополнительные репозитории
3. Устанавливаем openvpn и bridge-utils
4. Назначаем на интерфейс br0 адрес подсети отделения металлообработки, например 192.168.49.7/22, имя хоста metall
5. Создаём директорию /etc/openvpn/keys, передаём фельдегерьской почтой файлы metall.crt, metall.key, ca.crt, ta.key =)
6. Создаём директорию /var/log/openvpn
7. Создаём файл /etc/openvpn/client.conf
8. Назначаем соответствующие права на файлы и каталоги в директории /etc/openvpn
9. В файл /etc/openvpn/client.conf пишем...
Аналогично серверу, настраивается автозапуск...
#chkconfig --level 2345 openvpn on
=========
Проверяем работу туннеля. С сервера пингуем интерфейс клиента и какой либо хост в отделении металлообработки...
===
Замечательно! Туннель работает -)
На стороне сервера, при нормальной работе, мы видим примерно следующее...
На стороне клиента...
===========
Всё -)
Сайт восстановлен из веб-архива, есть что есть.
Ответы посетителей
Rector
Модератор
Зарегистрирован: 22.10.2012
Сообщений: 809
Надеюсь данный пост поможет кому-либо в работе. Приведенные конфиги - 100% рабочие.
++
Если есть вопросы, задавайте -)
--
Зри в корень!
# 02 мая 2014 10:20:57 0 0
Павел
Модератор
Зарегистрирован: 26.09.2013
Сообщений: 241
Rector, Вопросов быть не может, спасибо!
Ну, если только дальше копать, например, как выставить оптимальный MTU... Но это уже индивидуально подбирается, ИМХО...
Насчет шума в домене коллизий - это да, особенно Windows-машины стараются, когда у них NetBIOS не отключен.
А порезать широковещательный трафик можно и при помощи ebtables, так
# 03 мая 2014 03:05:05 0 0
Rector
Модератор
Зарегистрирован: 22.10.2012
Сообщений: 809
Сообщение от Павел
А порезать широковещательный трафик можно и при помощи ebtables, так
Совершенно верно! При желании или при возникновении проблем с большим количеством ARP.
Прочитано 1750 раз
Приветствую всех! По немногочисленным просьбам, я всё же решил разместить здесь пост на тему создания OpenVPN туннелей на втором уровне OSI, L2 то есть -)
Некоторый анализ информации, из размещённых различными авторами постов и статей, на просторах Интернета, дал понять, что авторы в основном пытаются строить туннели на L3, т.е. третьем уровне OSI. Возможно у них для этого есть причины, а может они просто любят потом всё маршрутизировать (имея при этом некоторый гемморой -)), а может просто не могут для себе уяснить разницу между L2 и L3 -). Тем не менее, использование L2, снимает многочисленные проблемы, с которыми может столкнуться строитель VPN туннелей.
Представим себе ситуацию - IT-специалисту необходимо объединить на одном уровне головной офис с удалёнными отделениями, для получения различных плюшек и сервисов от ядра локальной сети головного офиса, например ввести все машины в единый домен, IP-телефония, видеоконференции, пропуск Интернет-трафика через головной офис, в целях контроля и ограничений и т.д. Но отделения могут находиться как в пределах одного города, так и находиться на значительном расстоянии. При этом, специалист не обладает широкими возможностями в плане выбора оборудования, да и общее количество хостов в сети не будет превышать 350-400. При большем количестве хостов, возникает проблема коллизионного шума, но это уже отдельная тема.
Задача поставлена и надо её решать.
1. Прежде всего, надо определиться с общей адресацией сетей головного офиса и удалённых отделений. На схеме ниже, выбрана адресация 192.168.48.0/22 которая при данной битовой маске, позволяет получить 1024 хоста в сети. Для удобства, отделения распределены на подсети.
2. Необходимо, чтобы IP-адреса выдаваемые провайдером для головного офиса были глобального вида и статические. Для удаленных отделений этого не требуется. Достаточно, чтобы они были глобальные.
3. Для сокращений задержек по пути следования пакетов, желательно с обоих концов туннеля выбирать единого провайдера.
Связку сервер-клиенты будем реализовывать на CentOS 6.5. Скачиваем дистрибутив CentOS 6.5 x86_64 minimal Устанавливаем на машину имеющую на борту две сетевых карты, настраиваем одну из сетевых карт для доступа по SSH (например)
На второй карте IP-адрес не НАЗНАЧАЕМ! Подключаемся, обновляем систему...
#yum update
Устанавливаем wget...
#yum install wget
Подключаем дополнительные репозитории, в зависимости от выбранной разрядности системы.
Устанавливаем, по желанию, некоторые дополнительные программы...
#yum install mc nano tcpdump nmap
Корректируем файл ifcfg-eth0 к следующему виду...
#nano /etc/sysconfig/network-scripts/ifcfg-eth0
ставим опцию ONBOOT=yes, иначе при перезагрузке eth0 автоматически не поднимется.
Устанавливаем имя нашего сервера VPN...
#nano /etc/sysconfig/network
В данном случае...
Можно перезагрузиться -) reboot
====
Если наш сервер нормально загрузился и мы имеем к нему доступ по SSH, тогда можно продолжить.
Устанавливаем openvpn и необходимые утилиты...
#yum install openvpn easy-rsa bridge-utils
---
OpenVPN способен работать в двух режимах:
1. Маршрутизации (создаётся интерфейс tun)
2. Моста (создаётся интерфейс tap)
Мы будем использовать интерфейс tap и для того чтобы соединить его с нашей клиентской подсетью, организуем мост.
Предварительно следует проверить значения;
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
в файле /etc/sysctl.conf, они должны быть равны нулю. Данные параметры разрешают/запрещают передавать данные проходящие через мост в netfilter. Так как, нам этого не надо, то и передавать мы туда ничего не будем -)
---
Команда разработчиков OpenVPN, любезно приготовила для нас скрипты поднятия/опускания моста -) Запускаем mc и шагаем в /usr/share/doc/openvpn-2.3.2/sample/sample-scripts. Там мы видим два файла - bridge-start и bridge-stop. Копируем их в /etc/openvpn c именами openvpn-startup и openvpn-shutdown соответственно. Делаем их исполняемыми...
chmod +x openvpn-startup openvpn-shutdown
при запуске демона openvpn они будут выполняться автоматически. Правим скрипт openvpn-startup...
nano /etc/openvpn/openvpn-startup
Задаём IP-адрес на сетевой карте eth1 192.168.48.7/22 нашего моста в подсети 192.168.48.0/22 главного офиса.
Делаем проверку поднятия моста...
/etc/openvpn/./openvpn-startup
Если всё в порядке, видим что у нас появились интерфейсы tap0 и br0 с IP-адресом 192.168.48.7
Также проверить состояния моста можно командой
Как видно из вывода в мост объединены интерфейсы eth1 и tap0.
===
Поехали дальше -)
Создаем конфигурационный файл, предварительно удалив другие...
#rm -f /etc/openvpn/*.conf
#touch /etc/openvpn/server.conf
У меня их не было, но мало ли -)
Создаем директорию для логов...
#mkdir /var/log/openvpn
Создаём ключи OpenVPN. Шагаем в /usr/share/easy-rsa/2.0
#cd /usr/share/easy-rsa/2.0
Открываем файлик vars и заносим туда свои значения...
Далее инициализируем PKI и очищаем от старых сертификатов и ключей папку keys/server и создаем серийный и индексные файлы для новых ключей.
#. ./vars
Обратите внимание - две точки через пробел
#./clean-all
Командой build-ca создаём сертификат и ключ центра сертификации (CA).
Обратите внимание, что большинство запрошенных параметров установлены в значения по умолчанию, взятые из файла vars. Common name - единственный параметр, который должен быть явно указан. ЭТО ИМЯ МАШИНЫ ДЛЯ КОТОРОЙ ГЕНЕРИРУЕМ СЕРТИФИКАТ - hd-office.
Создаем сертификат X.509 для сервера hd-office. Всё аналогично заполняем, в том числе cтроки в которых указываем пароль.
Создаём ключи для клиентов (metall, enrgo, stal)...
Будьте внимательны при заполнени данных сертификатов, поле Common Name обязательно к заполнению, причем для сервера оно должно быть одно, а для клиента другое. Например в поле Common Name при генерации сертификата X.509 для сервера мы написали hd-office (имя машины сервера), а для клиента соотвественно metall (имя машины клиента отделения металлообработки). Для остальных клиентов, (enrgo, stal) сертификаты создаются аналогично.
Далее генерируем ключ Диффи Хельмана...
#./build-dh
Создаем ключ для tls-аутентификации...
#openvpn --genkey --secret ta.key
Запускаем mc и копируем директорию keys из /usr/share/easy-rsa/2.0 в /etc/openvpn, также в /etc/openvpn/keys копируем файл ta.key.
Так как наш сервер VPN будет работать от имени openvpn, входящего в группу openvpn, расставим соответствующие права.
В директории /etc/openvpn/keys располагаются следующие файлы;
Файлы, которые необходимы серверу:
ca.crt
ta.key
hd-office.crt
hd-office.key
dh2048.pem
Файлы клиента metall:
metall.crt
metall.key
ca.crt
ta.key
-----
Далее правим файл конфигурации сервера...
#nano /etc/openvpn/server.conf
Запускаем сервер openvpn командой
Настраиваем сервер openvpn для автоматического запуска
#chkconfig --level 2345 openvpn on
===
На этом, настройка серверной части закончена. Настройка клиента несколько проще -)
1. Берём машинку и устанавливаем на неё CentOS 6.5
2. Устанавливаем обновления и подключаем дополнительные репозитории
3. Устанавливаем openvpn и bridge-utils
4. Назначаем на интерфейс br0 адрес подсети отделения металлообработки, например 192.168.49.7/22, имя хоста metall
5. Создаём директорию /etc/openvpn/keys, передаём фельдегерьской почтой файлы metall.crt, metall.key, ca.crt, ta.key =)
6. Создаём директорию /var/log/openvpn
7. Создаём файл /etc/openvpn/client.conf
8. Назначаем соответствующие права на файлы и каталоги в директории /etc/openvpn
9. В файл /etc/openvpn/client.conf пишем...
Аналогично серверу, настраивается автозапуск...
#chkconfig --level 2345 openvpn on
=========
Проверяем работу туннеля. С сервера пингуем интерфейс клиента и какой либо хост в отделении металлообработки...
===
Замечательно! Туннель работает -)
На стороне сервера, при нормальной работе, мы видим примерно следующее...
На стороне клиента...
===========
Всё -)
Сайт восстановлен из веб-архива, есть что есть.
Ответы посетителей
Rector
Модератор
Зарегистрирован: 22.10.2012
Сообщений: 809
Надеюсь данный пост поможет кому-либо в работе. Приведенные конфиги - 100% рабочие.
++
Если есть вопросы, задавайте -)
--
Зри в корень!
# 02 мая 2014 10:20:57 0 0
Павел
Модератор
Зарегистрирован: 26.09.2013
Сообщений: 241
Rector, Вопросов быть не может, спасибо!
Ну, если только дальше копать, например, как выставить оптимальный MTU... Но это уже индивидуально подбирается, ИМХО...
Насчет шума в домене коллизий - это да, особенно Windows-машины стараются, когда у них NetBIOS не отключен.
А порезать широковещательный трафик можно и при помощи ebtables, так
# 03 мая 2014 03:05:05 0 0
Rector
Модератор
Зарегистрирован: 22.10.2012
Сообщений: 809
Сообщение от Павел
А порезать широковещательный трафик можно и при помощи ebtables, так
Совершенно верно! При желании или при возникновении проблем с большим количеством ARP.
Прочитано 1750 раз