OpenVPN Bridge

Материал из Xgu.ru

Перейти к: навигация, поиск
Автор: Игорь Чубин
Короткий URL: openvpn/bridge


На этой странице описывается каким образом можно организовать перенос трафика тегированного с помощью тега 802.1Q поверх уровня IP. Решение этой задачи позволяет сохранить принадлежность трафика VLAN'у даже при переходе через границу сети на канальном уровне, что, в свою очередь, позволяет создавать сети с единым планом VLAN'ов независимо от того сколько сетей канального уровня входит в её состав.


Содержание

[править] Введение

Сейчас практически любая компьютерная сеть сегментируется при помощи VLAN'ов. Это делается по многочисленным причинам, в том числе с целью повышения безопасности сети, её эффективности и управляемости.

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

Обычно, это верно в случае, если устройства соединены между собой на канальном уровне. Если же устройства соединены между собой только на уровне IP (напрямую или через VPN, не важно), тегированный трафик VLAN не передаётся, и информация о принадлежности пакетов тому или иному VLAN'у теряется.

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

Такой подход не всегда удобен. Создание независимого множества VLAN'ов для каждой сети приводит к ненужному умножению управляемых сущностей, снижению гибкости и усложнению системы в целом. Например, если в сети используется аутентификация при доступе к сети 802.1X и пользователь попадает в тот или иной VLAN на основе своей учётной записи (подробнее: 802.1X и RADIUS), вы должны думать не только о том, какой пользователь входит в сеть, но ещё и о том, через какой коммутатор он подключается, и в какой из множества сетей этот коммутатор стоит.

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

Ситуация существенным образом упрощается, если как-то добиться того, что VLAN'ы прозрачно передаются поверх IP. То есть, например, VLAN 2 в одной сети и VLAN2 в другой сети -- это один и тот же VLAN, трафик между компьютерами этого VLAN'а, включая широковещательный, передаётся как и должен, без всяких ограничений, независимо от того, сколько IP-хопов он при этом преодолевает (они должны быть невидимы для сети).

[править] Задача

Существует две сети, соединённые на IP-уровне между собой. Необходимо сделать так чтобы между этими сетями мог прозрачно передаваться трафик, тегированный с помощью тега 802.1Q так как если бы это была большая коммутируемая сеть. 


               VLANS
              2    4    6    8
              |    |    |    |
              |    |    |    |
              |    |    |    |
              |    |    |    |
         +-----------------------+
         | 802.1Q enabled switch |
         |                       |
         +-----------------------+
                              |
                              |802.1Q tagged link
                              |
                              |
                              |
                     IP       |
+----------------+         +-----------------+
| Linux / FreeBSD|---------| Linux / FreeBSD |
+----------------+         +-----------------+
              |
              |802.1Q tagged link
              |
              |
          +-----------------------+
          | 802.1Q enabled switch |
          |                       |
          +-----------------------+
                |    |    |    |
                |    |    |    |
                |    |    |    |
                |    |    |    |
                2    4    6    8
                  VLANS


[править] Решение

Указанную задачу можно решить с помощью различных средств построения туннелей, в частности vtun и OpenVPN. Ниже описывается решение задачи с помощью OpenVPN.

Рассмотрим топологию:

Openvpnbridge.png


Здесь есть несколько машин, соединённых в цепочку с помощью коммутаторов.

  • debian1 — машина, находящаяся в одной локальной сети
  • debian5 — машина, находящаяся в другой локальной сети
  • debian2 — шлюз в Интернет с одной стороны
  • debian4 — шлюз в Интернет с другой стороны.
  • debian3 — условный Интернет; соединяет между собой шлюзы debian2 и debian4

В качестве операционной системы используется Debian GNU/Linux. Рассматриваемая последовательность действий будет работать и и в других дистрибутивах Linux. В FreeBSD принципиальных отличий нет, но некоторые команды отличаются (настройка мостов и VLAN'ов).

Необходимо сделать так чтобы машина debian1 видела машину debian5 так как будто они находятся с ней в одной коммутируемой сети. Если трафик, передающийся в этой сети тегирован, теги должны сохранятся. Другими словами, если вместо машины debian1 будет коммутатор с настроенными на нём VLAN'ами, который будет смотреть на debian2 тегированным портом (и точно такая же ситуация будет с противоположной стороны), то компьютеры находящиеся в одном VLAN'е будут прекрасно видеть друг друга, независимо от того, в какой части сети они находятся.

[править] Программное обеспечение

Для выполнения процедуры потребуется установить программное обеспечение.

На debian2 и debian4:

  • openvpn
  • bridge-utils
  • iproute2 (не обязательно; но тогда нужно использовать команду ifconfig вместо команды ip)

На debian1 и debian5:

  • vlan
  • tcpdump

[править] Настройка OpenVPN

Настройки OpenVPN:

На debian2 (сервер): 

debian2%# cat /etc/openvpn/server.conf 
dev tap0
secret static.key

На debian4 (клиент): 

remote 192.168.2.2
dev tap
secret static.key

(здесь предполагается, что 192.168.2.2 — IP-адрес машины debian2 в условном Интернете)

Как и следовало ожидать, для поднятия туннеля и его использования в режиме моста, IP-адреса не нужны.


После того как туннель поднят 

debian2 %# /etc/init.d/openvpn start
debian4 %# /etc/init.d/openvpn start

на обеих машинах появляются tap-интерфейсы, однако они находятся в погашеном состоянии (ifconfig -a).

[править] Настройка виртуальных мостов

Необходимо создать мосты на обеих машинах (debian2 и debian4), и включить все необходимые интерфейсы.

На debian2: 

   debian2 %# brctl addbr br0
   debian2 %# brctl addif br0 tap0
   debian2 %# brctl addif br0 eth1
   debian2 %# ip link set tap0 up
   debian2 %# ip link set br0 up

На debian4: 

   debian4 %# brctl addbr br0
   debian4 %# brctl addif br0 tap0
   debian4 %# brctl addif br0 eth2
   debian4 %# ip link set tap0 up
   debian4 %# ip link set br0 up

[править] Проверка

Теперь машины debian1 и debian5 видят друг друга, так как если бы они находились в одной сети. 

debian1%# ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 00:16:3e:01:00:c2
          inet addr:192.168.4.1  Bcast:192.168.4.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:335 errors:0 dropped:0 overruns:0 frame:0
          TX packets:346 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:24490 (23.9 KiB)  TX bytes:24736 (24.1 KiB)

debian5%# ifconfig eth1 
eth1      Link encap:Ethernet  HWaddr 00:16:3e:01:04:c2
          inet addr:192.168.4.5  Bcast:192.168.4.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:144 errors:0 dropped:0 overruns:0 frame:0
          TX packets:132 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:13492 (13.1 KiB)  TX bytes:12556 (12.2 KiB)

С машины debian1 можно пингануть машину debian5 и проследить маршрут: 

debian1%# ping 192.168.4.5
PING 192.168.4.5 (192.168.4.5) 56(84) bytes of data.
64 bytes from 192.168.4.5: icmp_seq=1 ttl=64 time=5.56 ms

--- 192.168.4.5 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 5.566/5.566/5.566/0.000 ms

debian1%# traceroute 192.168.4.5
traceroute to 192.168.4.5 (192.168.4.5), 30 hops max, 40 byte packets
 1   (192.168.4.5)  108.408 ms  108.389 ms  108.382 ms

Трассировка показала, что debian5 находится с debian1 в одной коммутируемой сети.


Мы также можем передавать тегированный трафик.

На машине debian1: 

debian1%# vconfig add eth1 100
debian1%# ifconfig eth1.100 192.168.100.1

На машине debian5: 

debian5%# vconfig add eth1 100
debian5%# ifconfig eth1.100 192.168.100.5

Проверяем: 

debian1:~# ifconfig eth1.100
eth1.100  Link encap:Ethernet  HWaddr 00:16:3e:01:00:c2  
          inet addr:192.168.100.1  Bcast:192.168.100.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:34 errors:0 dropped:0 overruns:0 frame:0
          TX packets:34 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:2712 (2.6 KiB)  TX bytes:3188 (3.1 KiB)

debian1%# ping 192.168.100.5
PING 192.168.100.5 (192.168.100.5) 56(84) bytes of data.
64 bytes from 192.168.100.5: icmp_seq=1 ttl=64 time=1.34 ms
--- 192.168.100.5 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.346/1.346/1.346/0.000 ms

debian1%# traceroute 192.168.100.5
traceroute to 192.168.100.5 (192.168.100.5), 30 hops max, 40 byte packets
 1   (192.168.100.5)  1.960 ms  1.938 ms  1.930 ms


В это время на debian5: 

debian5# tcpdump -i eth1 -n
device eth1 entered promiscuous mode
audit(1203642136.881:2): dev=eth1 prom=256 old_prom=0 auid=4294967295
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
01:02:29.644256 vlan 100, p 0, IP 192.168.100.1 > 192.168.100.5: ICMP echo request, id 19801, seq 1, length 64
01:02:29.644373 vlan 100, p 0, IP 192.168.100.5 > 192.168.100.1: ICMP echo reply, id 19801, seq 1, length 64
...

[править] Дополнительная информация

[править] Материалы по OpenVPN на xgu.ru

Источник — «http://xgu.ru/wiki/OpenVPN_Bridge»