[Kami]

Добрый день, коллеги,

 

взываю о помощи, ибо три дня поисков ответа самостятельно, результата не дали.

Ситуация такая, абонент попросил помочь объединить две территориально разнесенных сети на L2 уровне. Дешево.

В качестве туннеля был выбран OpenVPN с tap. И собран следующий стенд:

 

сеть1

- управляемы свитч DES-3200-28 с несколькими серверами в разных VLAN-ах для иммитации сети 1 абонента.

- на порт 27 подключен Linux сервер ETH2, на порт тагом подается 3 VLAN ID: 911,978,2111

- на порту ETH0 этого роутера - рабочий выход в Интерент.

- на сервере поднят OpenVPN с конфигом:

 

local х.х.х.х
proto udp
dev tap0
tun-mtu 1500
cipher none
ping 10

 

интерфейс tap0 объединен в бридж с Eth2

brctl addbr br0
brctl addif eth2
brctl addif tap0
ip link set tap0 up
ip link set br0 up

 

 

 

сеть2

- роутер TP-Link 1043ND V2 с прошивкой OpenWRT WAN-порт с рабочим выходом в Интернет

- к порту LAN4 роутера подключен свитч DES-3200-10, порт 9. с VLAN-ами 911,978,2111 тагом

- к порт 1 свитча (VLAN 2111 акцессом), подключен ноутбук, с настройками "получить все автоматически".

- на роутере поднят OpenVPN с конфигом:

 

remote х.х.х.х
nobind
proto udp
dev tap
tun-mtu 1500
cipher none
ping 10
daemon

 

интерфейс tap0 объединен в бридж с Eth1 (свитч на 4 LAN-порта)

brctl addbr br0
brctl addif eth1
brctl addif tap0
ip link set tap0 up
ip link set br0 up

 

- свитч роутера сконфигурирован на пропуск тегированного трафика:

 

config switch_vlan
       option device 'switch0'
       option vlan '3'
       option vid '911'
       option ports '0t 1t'

config switch_vlan
       option device 'switch0'
       option vlan '4'
       option vid '978'
       option ports '0t 1t'

config switch_vlan
       option device 'switch0'
       option vlan '5'
       option ports '0t 1t 4'
       option vid '2111'

- все поднялось, на аплинковом порту свитча DES-3200-10 видим МАС-и из сети 1:

 

911   ITB-MGMT          FC-75-16-C1-DD-E0    9    Dynamic
911   ITB-MGMT          FC-75-16-C1-DF-C0    9    Dynamic
978   ITB-VOIP1         00-1B-21-39-12-7F    9    Dynamic
978   ITB-VOIP1         00-D0-01-88-94-0A    9    Dynamic
978   ITB-VOIP1         10-BF-48-77-F2-D4    9    Dynamic
2111  ITB-TEACH         00-13-D4-DD-14-B8    9    Dynamic
2111  ITB-TEACH         00-17-31-7C-5A-AC    9    Dynamic
2111  ITB-TEACH         00-18-F3-A2-51-08    9    Dynamic
2111  ITB-TEACH         00-1A-92-29-01-0B    9    Dynamic
2111  ITB-TEACH         00-1B-11-AF-E5-83    9    Dynamic

 

- и наоборот, на порту 27 DES-3200-28 МАС-и из сети 2:

 

911  ITB-MGMT                         00-1E-58-A9-4A-15 27   Dynamic
2111 ITB-TECH                         B8-88-E3-30-69-92 27   Dynamic

00-1E-58-A9-4A-15 - МАС - свитча 3200-10
B8-88-E3-30-69-92 - МАС - ноутбука

 

- более того, ноутбук получил IP адрес от DHCP сервера, который находится в сети 1:

 

13:41:56.481414 b8:88:e3:30:69:92 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from b8:88:e3:30:69:92, length 300
13:41:56.481661 00:26:18:18:55:51 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 10.7.17.129.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
13:41:56.483954 b8:88:e3:30:69:92 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 350: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from b8:88:e3:30:69:92, length 308
13:41:56.514104 00:26:18:18:55:51 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 10.7.17.129.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
13:42:03.005952 b8:88:e3:30:69:92 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 10.7.17.169.68 > 255.255.255.255.67: BOOTP/DHCP, Request from b8:88:e3:30:69:92, length 300
13:42:03.006138 00:26:18:18:55:51 > b8:88:e3:30:69:92, ethertype IPv4 (0x0800), length 342: 10.7.17.129.67 > 10.7.17.169.68: BOOTP/DHCP, Reply, length 300
13:42:06.015872 b8:88:e3:30:69:92 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 10.7.17.169.68 > 255.255.255.255.67: BOOTP/DHCP, Request from b8:88:e3:30:69:92, length 300
13:42:06.016000 00:26:18:18:55:51 > b8:88:e3:30:69:92, ethertype IPv4 (0x0800), length 342: 10.7.17.129.67 > 10.7.17.169.68: BOOTP/DHCP, Reply, length 300

 

- но, и это самое обидное, трафик между ноутбуком в сети 2 и любым хостом в VLAN-е 2111, не идет. Даже с сервером, которые выдал ему IP адрес.

- наблюдение за трафиком на любом участке (роутер TP-Link), сервер OpenVPN, сервер DHCP, ноутбук - показывает наличие свободнопроходящего в обе стороны ARP-трафика:

 

TP-Link:

 

tcpdump -i eth1 -n -nn -e | grep '69:92'
13:48:24.778563 b8:88:e3:30:69:92 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 2111, p 0, ethertype ARP, Request who-has 10.7.17.129 tell 10.7.17.169, length 46
13:48:25.776921 b8:88:e3:30:69:92 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 2111, p 0, ethertype ARP, Request who-has 10.7.17.129 tell 10.7.17.169, length 46
13:49:29.789821 b8:88:e3:30:69:92 > 54:04:a6:93:cb:d7, ethertype 802.1Q (0x8100), length 64: vlan 2111, p 0, ethertype ARP, Reply 10.7.17.169 is-at b8:88:e3:30:69:92, length 46

tcpdump -i tap0 -n -nn -e | grep '69:92'
13:50:54.786717 b8:88:e3:30:69:92 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 2111, p 0, ethertype ARP, Request who-has 10.7.17.129 tell 10.7.17.169, length 46
13:50:54.958522 b8:88:e3:30:69:92 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 96: vlan 2111, p 0, ethertype IPv4, 10.7.17.169.137 > 10.7.17.191.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST

 

 

DHCP-Server:

tcpdump -i eth3 -n -nn -e | grep '69:92'
13:52:57.775613 b8:88:e3:30:69:92 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.7.17.129 tell 10.7.17.169, length 46
13:52:57.775618 00:26:18:18:55:51 > b8:88:e3:30:69:92, ethertype ARP (0x0806), length 42: Reply 10.7.17.129 is-at 00:26:18:18:55:51, length 28
13:53:00.115821 b8:88:e3:30:69:92 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.7.17.129 tell 10.7.17.169, length 46
13:53:00.115828 00:26:18:18:55:51 > b8:88:e3:30:69:92, ethertype ARP (0x0806), length 42: Reply 10.7.17.129 is-at 00:26:18:18:55:51, length 28

 

Т.е. ситуация слега бредовая - бродкастовые пакеты летают в обе стороны, а юникастовые - кем-то убиваются.

 

Файрволлы с обеих сторон туннеля опущены:

 

# iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Форвардинг пакетов включен:

sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

 

Куда еще копать ?

Спасибо.

[MMM]

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

Также имеет смысл покрутить ethtool на предмет отключения offload.

[Kami]

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

Также имеет смысл покрутить ethtool на предмет отключения offload.

 

Предлагаете сделать так (предварительно удалив старый br0):

 

- на линуксовом серевер

vconfig add eth2 2111

brctl addbr br2111

brctl addif br2111 tap0

brctl addif br2111 eth2.2111

 

 

- на TP-Link-е:

vconfig add eth1 2111

brctl addbr br2111

brctl addif br2111 tap0

brctl addif br2111 eth1.2111

 

Или в tap0 тоже создавать отдельный саб-интерфейс ?

 

vconfig add eth2 2111

vconfig add tap0 2111

brctl addbr br2111

brctl addif br2111 tap0.2111

brctl addif br2111 eth2.2111

[Kami]

В общем, проблема решена. Все получилось, все работает, причем, в первоначальной конфигурации.

 

Проблема оказалась в том, что VPN-сервер для теста был собран на виртуальной машине (VMware-ESXi v5.1.0). После того, как точно такая же

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

свитча платформы, который тегировал 802.1q пакеты.

 

Всем спасибо

и мои извинения за лишнее беспокойство. :)

Изменено 23 мая, 2014 пользователем Kami