* 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.

Немного теории

Перед вами два рисунка:

* разделённые сети

* объединённые сети

Scheme 1, Scheme 2
или здесь: Scheme 1, Scheme 2

Итак, давайте рассмотрим более подробно, что изображено на рисунках.
На первом рисунке изображены 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 (http://openvpn.net/),
хотя можно воспользоваться и другими программными продуктами, умеющими
работать с TAP интерфейсами.

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 ветки необходимо патчить
ядро. Патчи можно найти по адресу http://bridge.sourceforge.net/

В ядро необходимо включить

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])

Утилиты по управлению функциональностью ядра можно взять по адресу
http://ebtables.sourceforge.net/ Пересобираем ядро, перегружаем
машину - всё - вы имеете готовый мост. Осталось его настроить.
Есть одна тонкость - в мост можно включать только интерфейсы, не
имеющие назначенных 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 версию http://openvpn.se/
Скачиваем openvpn для windows, устанавливаем, проделываем все
операции, указаные в разделе "OpenVPN" этого документа. Идём в
"Control panel->Network connections" выделяем интерфейсы, которые
необходимо включить в мост, кликаем правой кнопкой мышки, выбираем
пункт меню "Bridge connections".

Возможно, после этого, если вы используете DHCP - произойдёт новая
выдача адреса.

Авторы OpenVPN предупреждают о нестабильности работы Windows версии,
из-за которой может произойти крах системы с появлением печально
знаменитого "BSOD". Замечание касается версии 1.5 Как обстоят дела с
версией 2.0 автору этого документа неизвестно.