Однажды руководство нашей организации поставило задачу включить офис в другом городе в основную корпоративную сеть. При этом внутри корпоративной сети использовалось несколько виртуальных сетей (VLAN) — для телефонии, доступа к базе данных, управления оборудованием и т.п. По некоторым причинам не удалось арендовать прямой канал для проброса этих VLAN-ов.
Так как в роли внешних маршрутизоторов в обоих офисах выступали машины на базе CentOS 6, для транзита внутреннего трафика было решено использовать OpenVPN. От первоначальной идеи отдельного туннеля на каждый VLAN быстро отказались в связи с низкой масштабируемостью решения.
На помощь пришёл проект Open vSwitch — программный коммутатор с поддержкой VLAN (IEEE 802.1q).
Схема виртуальной сети.
По настройке OpenVPN в сети и на Хабре достаточно много информации, поэтому сразу приведу конфигурацию с некоторыми комментариями.
Используется устройство tap для возможности передавать ethernet-кадры.
Скрипт bridge.sh используется для внесения сетевого tap-устройства в виртуальный свитч (ovs). При рестарте OpenVPN-демона необходимо вывести и повторно внести tap-устройство в свитч, без данного костыля трафик от виртуального свитча на него не поступает. Данную проблему пока-что не удалось решить красиво.
Как не сложно догадаться, параметр tunks описывает возможность виртуального порта передавать тегируемый трафик указанных вланов.
В большинстве современных дистрибутивов open vSwitch уже присутствует целиком. В CentOS 6 присутствует только модуль ядра. Пакет с демоном виртуального свитча придётся искать в сторонних репозиториях, либо собирать самому. Информации по сборке пакета в сети достаточно, этот процесс не должен вызвать каких-либо затруднений. После установки и запуска демона необходимо создать виртуальное устройство свитча. Для этого создаётся конфигурационный файл интерфейса ifcfg-ovs0:
что соответствует команде
Настройка портов виртуального свитча практически ничем не отличаются от настроек обычных системных сетевых интерфейсов. Для внесения интерфейса в свитч создаётся конфигурационный файл интерфейса ifcfg-eth0.197:
Что соответствует команде:
Замечу, что при добавлении интерфейса в виртуальный свитч — ip-адрес этого интерфейса перестаёт быть доступным. При необходимости на севере использования ip-адреса на данном интерфейсе VLAN-а нужно перенести его на виртуальный внутренний порт свитча. Конфигурационный файл ifcfg-vi197 в данном случае будет выглядеть так:
Что соответствует команде:
По аналогии создаются остальные интерфейсы VLAN-ов.
Просмотреть текущее состояние портов виртуального свитча можно командой:
В моём случае конфигурация получилась такая:
В итоге получаем прохождение тегированного трафика по шифрованному каналу через интернет.
Решение получилось легко масштабируемым, в него легко добавлять как новые VLAN-ы, так и новые удаленные сети.
P.S.: Вместо OpenVPN можно использовать встроенный в open vSwitch GRE-тунель. С ним пока не было времени разобраться и я не уверен на счёт возможности шифрования трафика при его использовании.
Так как в роли внешних маршрутизоторов в обоих офисах выступали машины на базе 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
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
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
/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-тунель. С ним пока не было времени разобраться и я не уверен на счёт возможности шифрования трафика при его использовании.
