2006 г.
Организация единой сети при помощи виртуальных ethernet адаптеров (TAP) и программных мостов
Роман Ерин, "Slackware Linux в Томске"
Это нужно внимательно прочитать
К написанию статьи автора подтолкнуло естественное желание помочь другим людям. Автор не несёт ответственности за возможный вред, нанесённый использованием или невозможностью использования информации из этого документа. Вы используете эту информацию "КАК ЕСТЬ" без всяких гарантий. Не присылайте, пожалуйста, мне гневных писем с жалобами на то что у вас не работает - у меня это работает и, по всей видимости, должно работать у вас - если не работает - что ж, мне очень жаль... Не просите меня объяснить вам что-либо из того, что написано в этом документе - всё, что я хотел и мог рассказать изложено ниже.
Терминология
- layer 2 - уровень 2 модели OSI (канальный) - на этом уровне работает ethernet
- layer 2 тунель исходя из предыдущего пункта - виртуальный ethernet адаптер - поэтому оба термина используются в документе и совершенно равнозначны
- VPN - виртуальная сеть в своём изначальном смысле - не только pptp
- маршрутизатор - устройство 3-его уровня OSI - использует логическую адресацию
- коммутатор(мост) - устройство 2-ого уровня OSI - использует физическую адресацию (по MAC)
- Spanning Tree Protocol (STP) - протокол, позволяющий коммутаторам автоматически определять древовидную конфигурацию связей в сети без образования петель
Проблема
Время от времени встаёт необходимость объединить географически удалёные объекты в единую сеть с единым адресным пространством. Для большей конкретности будем рассматривать некую компанию с офисами расположенными в разных концах города или вообще в разных городах. Конечно, если все офисы подключены к одному провайдеру и провайдер готов предоставить VLAN - задача вырождается в совершенно тривиальную.
Предположим, что провайдер по некоторым одному ему понятным причинам, отказывается сделать отдельный VLAN или офисы подключены к разным операторам (в этом случае выделение VLAN-а становится чем-то из области ненаучной фантастики).
Решение
Для работы единой сети необходимо создать единое layer2 пространство, т.е. обеспечить ip пакетам прозрачное прохождение маршрутизаторов и передачу arp запросов. В принципе, поскольку создаётся единое layer2 пространство, можно таким же образом осуществить объединение сетей Netware на базе ipx.
Немного теории
Перед вами два рисунка:
- разделённые сети
- объединённые сети
Итак, давайте рассмотрим более подробно, что изображено на рисунках.
На первом рисунке изображены 3 локалки: A,B,C и их пограничные маршрутизаторы. Черные линии между маршрутизаторами показывают связи между маршрутизаторами. Как происходит маршрутизация в реальности - совершенно безразлично.
При такой схеме построения сети невозможно распространение широковещательных пакетов, в результате чего отказываются работать некоторые сетевые приложения (чаще всего игры). Кроме того, если в сетях работают протоколы, отличные от ip - их также невозможно использовать при обмене данными между сетями. Обычно эту проблему решают при помощи VPN типа точка-точка, однако такое построение VPN не предоставляет тех возможностей, какие доступны при прямом ethernet подключении.
Предлагаемый способ построения VPN на основе виртуальных ethernet интерфейсов (TAP) и программных ethernet мостов позволяет решить все указаные проблемы, фактически объединив локалки A,B и C в одну большую сеть. При этом маршрутизаторы будут выполнять функции программных коммутаторов. Сказаное выше иллюстрирует рисунок 2.
На рисунке 2 голубыми линиями изображены связи между маршрутизаторами Поверх этих связей проброшены layer2 тунели (виртуальные ethernet адаптеры). Оранжевыми линиями обозначены включенные программные мосты поверх layer 2 тунелей. Красным обозначена избыточная связь, которая при использовании STP может быть использована для увеличения надежности образуемой сети.
Особенно хотелось бы подчеркнуть, что при такой организации VPN можно работать с любыми сетевыми протоколами, не только ip.
Реализация
Для реализации решения можно использовать любую из нижеперечисленных ОС:
- Linux
- FreeBSD
- Windows (экспериментельно не проверялось, но должно работать)
Итак, если куски вашей сети имеют общую точку-маршрутизатор, решение задачи заключается в создании моста между двумя физическими интерфейсами маршрутизатора. Такой вариант может вам пригодиться, если вы ходите разделить локалку на части, фильтровать трафик между ними и в то же время сохранить общее layer2 пространство.
OpenVPN
Скачиваем, собираем и устанавливаем OpenVPN обычным для вашего дистрибутива образом. На обоих концах тунеля создаём файлы конфигурации вида
remote w.x.y.z
nobind
proto udp
dev tap
tun-mtu 1500
cipher none
ping 10
remote адреса нужно проставить соответственно внешние адреса маршрутизаторов, между которыми поднимается мост. Если вы хотите защитить данные, передаваемые через публичные сети, вы можете использовать шифрование - OpenVPN предоставляет такую возможность. Более подробную информацию вы можете получить в документации на OpenVPN.
Linux
Речь пойдёт о семействе 2.6 ядер, для 2.4 ветки необходимо патчить ядро. Патчи можно найти по этому адресу.
В ядро необходимо включить
CONFIG_BRIDGE_NETFILTER=y
Если вы хотите фильтровать трафик, проходящий через мост - вы также должны включить
CONFIG_BRIDGE_NF_EBTABLES=[y|m]
ebtables имеет достаточно много возможностей, которые вы можете включить в соответствующем разделе конфигурации netfilter.
ebtables заслуживает более детального описания. Ждите следующей статьи.
Device Drivers => Networking support => Networking support (NET [=y]) => Networking options => Network packet filtering (replaces ipchains) (NETFILTER) => Bridge: Netfilter Configuration
Для поддержки TAP надо включить соответствующий пункт, расположенный в:
Device Drivers => Networking support => Network device support (NETDEVICES [=y])
Утилиты по управлению функциональностью ядра можно взять по адресу. Пересобираем ядро, перегружаем машину - всё - вы имеете готовый мост. Осталось его настроить.
Есть одна тонкость - в мост можно включать только интерфейсы, не имеющие назначенных ip адресов.
#!/bin/sh
modprobe tun
LOCAL_IF="eth0"
REMOTE_IF="tap0"
BRIDGE_IF="br0"
BRIDGE_IP="w.x.y.z"
BRIDGE_MASK="a.b.c.d"
BRIDGE_BROADCAST="e.f.g.h"
CONFIG="/path/to/config"
# Запускаем OpenVPN в режиме демона
openvpn --config $CONFIG --daemon
# Выключаем мост (если он включен)
ifconfig $BRIDGE_IF down
# Удаляем мост (убираем мусор за предыдущим запуском скрипта)
brctl delbr $BRIDGE_IF
# Добавляем новый мост
brctl addbr $BRIDGE_IF
# Включаем в мост интерфейсы
brctl addif $BRIDGE_IF $LOCAL_IF
brctl addif $BRIDGE_IF $REMOTE_IF
# Убираем адреса с интерфейсов, входящих в мост и поднимаем их
ifconfig $LOCAL_IF 0.0.0.0 promisc up
ifconfig $REMOTE_IF 0.0.0.0 promisc up
# Назначаем мосту адрес, если это необходимо - например вместо адреса на интерфейсе локалки.
ifconfig $BRIDGE_IF $BRIDGE_IP netmask $BRIDGE_MASK broadcast $BRIDGE_BROADCAST
# Включаем мост
ifconfig $BRIDGE_IF up
Готово.
FreeBSD
В ядро необходимо включить
device BRIDGE
Пересобираем ядро или можно загрузить модуль
kldload bridge
FreeBSD использует другой способ организации моста - управление параметрами через sysctl. Отдельного интерфейса не создаётся.
# Здесь через запятую указываются интерфейсы, входящие в мост (версия FreeBSD 5.2 или старше)
net.link.ether.bridge_cfg:
# Включить/выключить фильтрация трафика с помощью ipfw
net.link.ether.bridge_ipfw: 0
# Включить/выключить фильтрация трафика с помощью ipf
net.link.ether.bridge_ipf: 0
# Здесь через запятую указываются интерфейсы, входящие в мост (версия FreeBSD младше 5.2)
net.link.ether.bridge.config:
# Включить/выключить мост
net.link.ether.bridge.enable: 0
Windows
Windows как всегда предоставляет мышевозильный интерфейс:) Mathias Sundman разработал для Windows GUI версию. Скачиваем openvpn для windows, устанавливаем, проделываем все операции, указаные в разделе "OpenVPN" этого документа. Идём в "Control panel->Network connections" выделяем интерфейсы, которые необходимо включить в мост, кликаем правой кнопкой мышки, выбираем пункт меню "Bridge connections".
Возможно, после этого, если вы используете DHCP - произойдёт новая выдача адреса.
Авторы OpenVPN предупреждают о нестабильности работы Windows версии, из-за которой может произойти крах системы с появлением печально знаменитого "BSOD". Замечание касается версии 1.5 Как обстоят дела с версией 2.0 автору этого документа неизвестно.
Заключение
Во время написания этого документа стало совершенно ясно, что затронутая тема достаточно обширна и требует для понимания множество смежных знаний. Автор надеется, что полученная вами информация будет вам полезна и, несмотря на некоторую скомканость изложения, понятна. Пожалуйста, направляйте ваши комментарии и поправки по адресу, указаному в заголовке документа.