Проброс VLAN-ов через интернет

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

Так как в роли внешних маршрутизоторов в обоих офисах выступали машины на базе CentOS 6, для транзита внутреннего трафика было решено использовать OpenVPN. От первоначальной идеи отдельного туннеля на каждый VLAN быстро отказались в связи с низкой масштабируемостью решения.

На помощь пришёл проект Open vSwitch — программный коммутатор с поддержкой VLAN (IEEE 802.1q).


Схема виртуальной сети.

Настройка туннеля OpenVPN


По настройке OpenVPN в сети и на Хабре достаточно много информации, поэтому сразу приведу конфигурацию с некоторыми комментариями.

Конфигурация OpenVPN cервера
local W.X.Y.Z
dev tap

ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh1024.pem

tls-server
tls-auth /etc/openvpn/keys/ta.key 0

keepalive 10 60
ping-timer-rem
persist-tun
persist-key
daemon

user nobody
group nobody

up /etc/openvpn/bridge.sh
Конфигурация OpenVPN клиента
client
dev tap
remote W.X.Y.Z

nobind

ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/client.crt
key /etc/openvpn/keys/client.key
tls-auth /etc/openvpn/keys/ta.key 1

keepalive 10 60
ping-timer-rem
persist-tun
persist-key
daemon
resolv-retry infinite

user nobody
group nobody

up /etc/openvpn/bridge.sh
Скрипт bridge.sh
#!/bin/bash

/usr/bin/ovs-vsctl del-port ovs0 $1
/usr/bin/ovs-vsctl add-port ovs0 $1 trunks=1996,1997,1998,1999
/sbin/ip link set $1 up

Используется устройство tap для возможности передавать ethernet-кадры.

Скрипт bridge.sh используется для внесения сетевого tap-устройства в виртуальный свитч (ovs). При рестарте OpenVPN-демона необходимо вывести и повторно внести tap-устройство в свитч, без данного костыля трафик от виртуального свитча на него не поступает. Данную проблему пока-что не удалось решить красиво.
Как не сложно догадаться, параметр tunks описывает возможность виртуального порта передавать тегируемый трафик указанных вланов.

Настройка open vSwitch


В большинстве современных дистрибутивов open vSwitch уже присутствует целиком. В CentOS 6 присутствует только модуль ядра. Пакет с демоном виртуального свитча придётся искать в сторонних репозиториях, либо собирать самому. Информации по сборке пакета в сети достаточно, этот процесс не должен вызвать каких-либо затруднений. После установки и запуска демона необходимо создать виртуальное устройство свитча. Для этого создаётся конфигурационный файл интерфейса ifcfg-ovs0:

DEVICE=ovs0
ONBOOT=yes
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
HOTPLUG=no

что соответствует команде
ovs-vsctl add-br ovs0


Настройка интерфейсов


Настройка портов виртуального свитча практически ничем не отличаются от настроек обычных системных сетевых интерфейсов. Для внесения интерфейса в свитч создаётся конфигурационный файл интерфейса ifcfg-eth0.197:

PHYSDEVICE=eth0
DEVICE=eth0.197
ONBOOT=yes
DEVICETYPE=ovs
TYPE=OVSPort
OVS_BRIDGE=ovs0
OVS_OPTIONS="tag=197"
BOOTPROTO=none
HOTPLUG=no

Что соответствует команде:

ovs-vsctl add-port ovs0 eth0.197

Замечу, что при добавлении интерфейса в виртуальный свитч — ip-адрес этого интерфейса перестаёт быть доступным. При необходимости на севере использования ip-адреса на данном интерфейсе VLAN-а нужно перенести его на виртуальный внутренний порт свитча. Конфигурационный файл ifcfg-vi197 в данном случае будет выглядеть так:

DEVICE=vi197
ONBOOT=no
DEVICETYPE=ovs
TYPE=OVSIntPort
BOOTPROTO=static
IPADDR=10.0.120.253
NETMASK=255.255.255.0
OVS_BRIDGE=ovs0
OVS_OPTIONS="tag=197"
HOTPLUG=no
ARPCHECK=no

Что соответствует команде:

ovs-vsctl add-port ovs0 vi197 tag=197 -- set Interface vi197 type=internal

По аналогии создаются остальные интерфейсы VLAN-ов.

Просмотреть текущее состояние портов виртуального свитча можно командой:

ovs-vsctl show

В моём случае конфигурация получилась такая:
Скрытый текст
    Bridge "ovs0"
        Port "eth0.198"
            tag: 198
            Interface "eth0.198"
        Port "eth0.197"
            tag: 197
            Interface "eth0.197"
        Port "vi198"
            tag: 198
            Interface "vi198"
                type: internal
        Port "eth0.199"
            tag: 199
            Interface "eth0.199"
        Port "ovs0"
            Interface "ovs0"
                type: internal
        Port "tap0"
            trunks: [1996, 1997, 1998, 1999]
            Interface "tap0"
    ovs_version: "2.3.0"


Заключение


В итоге получаем прохождение тегированного трафика по шифрованному каналу через интернет.

Решение получилось легко масштабируемым, в него легко добавлять как новые VLAN-ы, так и новые удаленные сети.

P.S.: Вместо OpenVPN можно использовать встроенный в open vSwitch GRE-тунель. С ним пока не было времени разобраться и я не уверен на счёт возможности шифрования трафика при его использовании.
Share post

Comments 61

    +1
    Не совсем понял с какой целью вы openvSwitch используете, объясните пожайлуста в чем преимущество перед: просто объединить мостом tap и физический интерфейс роутера? (насколько понимаю на шлюз прилетает транк, этот же транк отправляем через vpn тоннель). Или это для возможности гибкой настройки, какие валаны через vpn кидаем?
      +1
      чтобы не делать отдельный тоннель для каждого vlan
        0
        а транк через openvpn l2 тоннель/linux bridge не проходит(тегированный трафик)?( судя по тому, что настроено выше у вас так и есть — транк идет через l2 тоннель openpvn)
          0
          Один vlan — один мосттоннель, это самое простое что приходит в голову. В частности из-за возможности гибкой настройки списка vlan'ов
            0
            Можно внутри 1 vlan пробросить несколько других vlan. Обычно используется, когда надо пробросить какие то занятые выше vlan.
            QinQ
          0
          поясните, почему в варианте с мостами надо будет делать под каждый влан свой тоннель?
            –1
            можно не делать и свалить все в кучу, но я предпочел бы выпускать тегированный трафик строго по списку
              –1
              Для этого лучше использовать маркировку трафика QOS.
          0
          На маршрутизатор приходят больше вланов, через openvpn пробрасываются только некоторые.
            0
            Делали такое лет 6 назад, на стандартном linux bridge, лишние VLAN фильтровали ebtables.
          +8
          Решение получилось легко масштабируемым

          Решение получилось абсолютно немасштабируемым (ибо растягивание L2 между площадками doesn't scale) и крайне неудобным в сопровождении.

          Почему не выделили три отдельные сети под второй офис и не настроили маршрутизацию? Каков будет путь трафика из VLAN197 второго офиса в VLAN198 второго офиса? Как поживает MTU (на L2 не существует фрагментации и не существует PMTUD, а интернет обычно не пропускает более чем 1500 байт на пакет)?
            –2
            Трафик между этими вланами не маршрутизируется, по каждому влану идёт доступ к ресурсам напрямую. К тому-же все ресурсы сосредоточены в центральном офисе.
            По MTU вопрс не изучался, но каких-либо проблем замечено не было.
              0
              С MTU проблемы не будет. OpenVPN об этом позаботится.
              0
              А как решается вопрос с MTU и фрагментацией пакетов?
                0
                Если коротко, то по умолчанию OpenVPN меняет MSS у TCP-пакетов так, чтобы оно проходило без фрагментации на линках с MTU >= 1490. UDP-пакеты не трогаются и фрагментируются на уровне IP.
                Вообще, в OpenVPN возможностей для фрагментации много, на целую статью, пожалуй.
                0
                Вопрос с MTU, по-видимому, решается средствами туннеля, энкапсулированому трафику об этом знать не обязательно (пока тот же openvpn в состоянии фрагментировать и реассемблировать свои пакеты с учетом MTU транзита)
                Маршрутизация, видимо, не вариант из-за каких-то специфичных приложений которым позарез нужно находится в одном широковещательном домене
                Но, позвольте, почему не L2TPv3?
                  +3
                  Потому что OpenVPN удобнее и проще в настройке, например.
                    +1
                    подтверждаю предыдущего оратора, OpenVPN реально проще и удобнее для этого

                    ну и вообще остальные vpnы у него сосут по совокупности качеств
                      0
                      Ну как решение из последних мне описание очень приглянулось у SoftEther VPN, но сам я его так и не попробовал.
                        0
                        Он довольно хорош, но, к большому сожалению, его тяжело настроить так, как нужно, по крайней мере, мне. Не поддерживает аутентификацию по сертификатам нигде, кроме своего протокола, тяжело настраивать через консоль, невнятные конфигурационные файлы, некоторым основным функциям уделено мало внимания, а некоторым второстепенным много. В целом, это хорошее решение, но какое-то не unix-way-ное.
                        А еще, его использовали террористы в аниме Zankyou no Terror.
                        image
                        0
                        Еще бы ему возможность p-2-p соединений, цены бы ему не было.
                          +1
                          э… вы ман читали? Первая версия openvpn только peer-to-peer и была, это только во второй клиент-серверная появилась (но p2p никуда не делась)
                            +1
                            Спасибо. Был неправ.

                            Но хочется большего — full-mesh, например.
                              0
                              Да, full-mesh решений не хватает(
                                0
                                Tinc — вот вроде. Но реализовать отказоустойчивость с помощью двух провайдеров пока не получилось.
                                  +1
                                  full-mesh — это cisco dmvpn. В принципе, есть его опенсорсная реализация в виде opennhrp (умеет до phase2, третью не умеет), но настройка — это геморрой, впрочем, не сильно больший, чем настройка его непосредственно на цисках
                                  0
                                  что значит отказоустойчивость с помощью двух провайдеров?

                                  Tinc очень хороший и простой vpn, и mesh там реализован то же хорошо.
                                    0
                                    Под отказоустойчивостью имел ввиду использование запасного канала связи. Но я написал пока — думаю все получится.
                          –1
                          нет, что правда ip tun add gre123 mode gre… && ifconfig gre123 прямо таки сложнее и неудобней openvpn который надо ставить, обслуживать для него инфраструктуру ключей и плясать вокруг скриптовой обвязки?
                          он, конечно, местами хорош, но тезис о том что все остальные сосут мягко говоря категоричен
                            0
                            во-первых, критика: если уж ip tun add, то давайте последовательно, ip link set, ip addr add и так далее

                            во-вторых, если бы это было сложно обслуживать инфраструктуру — можно было бы согласиться. Но easy-rsa решает. Это тривиально. А уж что касается скриптовой обвязки, то у openvpn по сравнению с gre-тоннелями вообще всё шоколадно

                            у gre есть своя ниша. Но это не готовое решение, в том виде, что вы привели его никто не использует, потому, что помимо gre потребуется ipsec и тут геморроя с шифрованием на порядок больше, чем openvpn. Полезно оно как компонент сложных серьёзных решений, типа dmvpn — там и раскрываются возможности gre (многоточковость, например)
                              0
                              как по мне, easy-rsa это некий костыль для небольшого числа сертификатов.
                              Меня вот интересует, есть ли нормальные проекты в linux для управление огромным кол-вом сертификатов?
                                0
                                Я недавно изучал этот вопрос. Пришел к выводу, что конкретно для VPN ничего удобней Easy-RSA v3 нет. Если интересно, я сделал версию, которая корректно работает и с IPsec
                                github.com/ValdikSS/easy-rsa-ipsec
                                  0
                                  А вообще, еcть вот такие продвинутые решения:
                                  pki.fedoraproject.org/wiki/PKI_Main_Page
                                  www.ejbca.org/

                                  И несколько менее продвинутые, но, тем не менее, удобные:
                                  sourceforge.net/projects/xca/
                                  gnomint.sourceforge.net/
                                    0
                                    Спс за ответ. Понятно, что ничего нормального и готовогг нет.
                                    Fedora скорее всего привязан к дисту.
                                    ejbca — адская смесь, хотя надо пробовать может там все и хорошо.

                                    пслд два выглядят то, что надо. С Gnomit была засада (уже не помню с чем).
                                    В Gnome еще был проект Seahorse, завязан с ключами, но это конечно то же не то, что хотелось бы.
                              0
                              tinc vpn как по мне лучше и удобнее openvpn.
                            +2
                            Прелестно
                            Vlanы были придуманы для разграничения broadcast domain, а тут мы их через vpn со всеми вытекающими. Надеюсь тунель на tcp?

                            Читать. Или аналоги.
                            www.ciscopress.com/articles/article.asp?p=24101
                              +2
                              Best Practice — уменьшение размера L2-домена и максимально использовать L3. По меньшей мере следует придерживаться модели local-VLAN, т.е. vlan не должен выходить за пределы одного аксесс-свича и пары дистрибьюшн свичей, а тем более идти по WAN. Более того, сейчас стали выпускать L3 access-свичи, которые позволяют сузить L2-домен до границ access-коммутатора. Вы сделали что-то совершенно противоположное без веских на это оснований. Для разделения трафика по типу, можно использовать политики QOS, т.е. маркировку трафика DCSP. Ваше решение очень плохо масштабируется по очень простой причине — если у Вас будет несколько площадок, с резервированием, как Вы будете решать проблемы с L2- петлями? Запустите STP поверх IP?
                                0
                                >Запустите STP поверх IP?
                                С сарказмом — А это отличная идея!
                                0
                                А я бы на Cisco в VPN-туннель psewdowire запихал, раз задача такая.
                                  –1
                                  Я думаю лучше всего было бы использовать MPLS, но народ очень активно эту технологию игнорирует и продолжает использовать адские велосипеды.
                                    0
                                    Вы имеете в виду технологию MPLS-VPN? Во-первых, данная технология не отменяет необходимости шифровать трафик в некоторых ситуациях, т.е. всё теже туннели поверх mpls. Во-вторых, технология не дешёвая. Ну и пожалуй самое важное, MPLS-VPN привязывает Вас к одному или к нескольким провайдерам, между которыми существует mpls-пиринг, что не всегда приемлемо. Если вы имеете множество площадок с очень разнообразной географией и соответственно большое количество разных ISP Вы, скорее всего, не сможете связать их все с помощью mpls-VPN/
                                      –2
                                      Шифровать лучше в любом случаи.
                                      Не дешевая? Хм, что в не дорого? Мы используем ее на mikrotik оборудование.
                                      В общем на хабре уже была статья, повторятся не буду habrahabr.ru/post/169103/

                                      ISP тут роли не играет. Делайте хоть 60 точек и соединяйте.

                                      Просто то, что выше когда начнет разрастаться, будет не очень хорошо.
                                      Я просто в уме прикинуть сколько надо будет сделать телодвижений на те же 60 точек.
                                        0
                                        Минуточку. Задача — есть два удалённых сайта, нужно их объединить. Один узел в Лондоне, второй в Шанхае. Расскажите, как в этом случае их объединить с помощью mpls не привлекая провайдера?
                                          –1
                                          Что значит объединить два сайта? И зачем вам для двух сайтов mpls?
                                            0
                                            А какая разница, два или больше? И вообще, вы расскажите, какое отношение MPLS имеет к описанной задаче.
                                          +1
                                          MPLS (если мы не про L3VPN каналы) тут вообще никаким боком, он не конкурирует с шифрованными туннелями, а дополняет их. Но это лишняя сущность, без которой по возможности стоит обойтись.
                                    +1
                                    Может быть автор все таки в 2-3 словах расскажет для чего было творить такие чудеса с тунелями вместо нормальной человеческой маршрутизации?
                                      0
                                      В данном случае трафик чисто внутренний, который не желательно выпускать в мир. Да и сами сервера с ресурсами не имеют доступа в мир.
                                        +1
                                        прекрасно, но ведь можно все это смаршрутизировать через ipsec тунель (или еще какой-нибудь удобый вам) и не плясать вокруг вланов, не? Получилось бы куда более масштабируемо, да и схема традиционная как никак
                                          –1
                                          С ipsec опыта работы не имел, а с openvpn и open vSwitch сталкивался ранее, поэтому на них всё и организовал.
                                            +2
                                            ну можно было бы смаршрутизировать и через openvpn — тут принципиальной разницы нет. любой удобный протокол динамической маршрутизации решил бы вопрос в считаные минуты (ну или статикой, тогда чуть подольше)
                                            не совсем понятно желание именно тащить вланы, — обычно от этого бегут как от огня, а вы по своей инициативе ;) — вот я ж и уточняю, может были какие-то принципиальные моменты блокирующие решение на основе маршрутизации?
                                              0
                                              Существует странное китайское оборудование, которому непременно нужно l2 (хотя по идее задача такая, что не должно быть нужно). Был у нас случай — специально к нам обратились, чтобы поверх IP VPN, предоставленный провайдером, сделать L2 VPN, который нужен железкам.

                                              Мы тогда сделали на L2TP. Это было ошибкой, я чуть позже повторил это же самое на OpenVPN — он оказался просто фантастикой по сравнению с L2TP, как в плане масштабируемости, так и в плане надёжности.
                                      0
                                      Хочу узнать, что я упускаю, но в любом дистрибутиве можно поднимать туннели встроенными средствами iproute и iptables (если не ошибаюсь) с помощью двух строчек в конфигах.
                                      Зачем такие сложности городить?
                                        0
                                        iproute2 достаточно
                                          +1
                                          тоннели да, но шифрование вы с их помощью не сделаете. Да и «встроенные средства» шифрования в виде ipsec в любом дистрибутиве — те ещё сложности, которые как раз не надо городить, а надо просто брать openvpn и не извращаться
                                            0
                                            ну да. и бог с ним что не мультивендорно, пускай себе юзерспейс (со всеми накладными расходами), надо просто брать и не извращаться
                                            что делать когда в филиале на место тазика приедет например кошка, и/или когда филиалов станет много и часть трафика будет невыгодно пропускать через центральный офис — это пускай другие думают, наверное…
                                          0
                                          Сначала делим трафик:
                                          При этом внутри корпоративной сети использовалось несколько виртуальных сетей (VLAN) — для телефонии, доступа к базе данных, управления оборудованием и т.п.


                                          Потом его же пытаемся пробросить куда-то по негарантированным каналам.

                                          Позвольте поинтересоваться: а по вашему тоннелю широковещательный трафик тоже ходит?
                                            0
                                            подозреваю, ради этого все и затевалось
                                            (есть конечно вариант что это решение — первое что пришло в голову, а первая идея не всегда лучшая)
                                              0
                                              не написано же
                                              >Используется устройство tap для возможности передавать ethernet-кадры.
                                                0
                                                Ходит по таким туннелям широковещательный трафик. Сталкивался я с такими туннелями на предыдущем месте работы. Реализация была такой ввиду коротких сроков и нежелания начальства тратить деньги на организацию физического линка. Иначе было сложно на имеющемся оборудовании выдавать белые адреса клиентам. Сначала кинул вланы через туннель, а потом боролся с паразитным трафиком…

                                              Only users with full accounts can post comments. Log in, please.