LINUX.ORG.RU
Форум — Admin  

vlan - переправление трафика между двумя подсетями

 


0

1

Здравствуйте!

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

1. Linux (Debian).
2. Сетевушка (eth0), которая смотрит в локалку (основная сеть).

На сетевушке (eth0) поднят vlan2 (eth0.2). Бродкасты с vlan2 (eth0.2) долетают в основную сесть (eth0) и из основной сети (eth0) долетают в VLAN2 (eth0.2).

Вопрос. Как убрать переправление трафика между этими двумя подсетями? Опционно для vlan пересылку можно отключить (не используя механизмы типа ebtables)?

/proc/sys/net/ipv4/ip_forward = 1 (необходима маршрутизация).
/proc/sys/net/ipv4/conf/eth0/proxy_arp = 0
/proc/sys/net/ipv4/conf/eth0.2/proxy_arp = 0


← Может ли HTTP/HTTPS proxy отличить браузер от не-браузера?
Хочу возможность firmware на своем девайсе →

Ну тут или-или. Или вы отключаете форвардинг и реализуете форвардинг через iptables, или включаете форвардинг и запрещаете ненужные форварды iptables'ом. Вы включили форвардинг, так что ответ очевиден - iptables -A FORWARD -i eth0 -o eth0.2 -j DROP

araks ★★
()
Ответ на: комментарий от av

Надо порт коммутатора, к которому подключена сетевуха, перевести в режим trunk (он же tagged). И указать к какому vlan-у относятся нетегированные кадры (native vlan, он же untagged vlan). Тогда коммутатор будет коммутировать широковещательные кадры только на те порты, которые относятся к vlan-у кадра.

iliyap ★★★★★
()
Ответ на: комментарий от iliyap

Так и сделано.

В итоге получается: dhcp-запрос идет с vpn2, долетает до eth0.2, затем он переправляется linux-ом на eth0, дальше, по нетегированному каналу ему отвечает dhcp-сервер, отправляет пакеты обратно (eth0 -> eth0.2 -> switch port -> client-запроса ).

Данные ответы после того как пришли к linux по нетегированному канала, идут на eth0.2 в тегированном виде (через tcpdump их вижу).

av
() автор топика
Ответ на: комментарий от av

Линукс не маршрутизирует броадкасты, да и никто их не маршрутизирует. У тебя галлюцинации. Твой dhcp сервер слушает на eth0.2 и с него же посылает ответы.

iliyap ★★★★★
()
Ответ на: комментарий от iliyap

1. Слушаем созданный в linux vlan и видим бродкасты клиентов:

tcpdump -e -n -i eth0.226 udp port 67 or port 68

11:22:49.353212 b8:a3:86:70:aa:5f > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 192.168.22.122.68 > 255.255.255.255.67: BOOTP/DHCP, Request from f0:92:1c:eb:13:e8, length 300
11:22:51.519219 b8:a3:86:70:aa:5f > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 192.168.22.96.68 > 255.255.255.255.67: BOOTP/DHCP, Request from f0:92:1c:ee:40:48, length 300

2. Слушаем интерфейс на котором создан vlan (eth0) и видим те же бродкасты, но в тегированном виде :

tcpdump -e -n -i eth0 udp port 67 or port 68|grep 802.1Q
11:44:20.008926 b8:a3:86:70:aa:5f > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 346: vlan 226, p 0, ethertype IPv4, 192.168.22.105.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 34:64:a9:36:cb:d1, length 300

11:44:23.186486 b8:a3:86:70:aa:5f > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 346: vlan 226, p 0, ethertype IPv4, 192.168.22.51.68 > 255.255.255.255.67: BOOTP/DHCP, Request from f0:92:1c:e1:81:e4, length 300

В созданном vlan машин нет, трафик идет из eth0 (нетегированной сети). DHCP не на Linux

Почему и при помощи какого механизма бродкасты основной сети оказывается в тегированном vlan?

av
() автор топика
Ответ на: комментарий от av

Странный ты. У тебя есть хитрая сеть о конфигурации которой ты молчишь, а мы должны догадаться где, кто и как сконфигурирован.

Смотри настройки коммутатора на тему dhcprelay IMHO.

vpn2 какой-то нарисовался. А он по dhcp не умеет получать адреса для клиентов ?

а чей MAC b8:a3:86:70:aa:5f ? Это явно какой-то dhcprelay.

vel ★★★★★
()
Ответ на: комментарий от av

Модуль ядра 8021q входящие кадры в формате 802.1q крадет с родительского интерфейса, снимает тег, реенкапсулирует в формат Ethernet ii, и кладет на тегированный интерфейс. Исходящие кадры с тегированного интерфейса, наоборот, крадет, реенкапсулирует в формат 802.1q, добавляя тег, и кладет на родительский интерфейс.

iliyap ★★★★★
()
Ответ на: комментарий от vel

2 Мне не понятно, почему не получается изолировать два пространства не пребигая к доп инструментам. Или vlan это не предполагает?

3 vlan0.2 = eth0.226. (на linux один vlan типа 802.1Q).

4. ifconfig |grep b8:a3:86:70:aa:5f
eth0 Link encap:Ethernet HWaddr b8:a3:86:70:aa:5f

av
() автор топика
Ответ на: комментарий от av

2 - У тебя один физический канал, который разделен на виртуальны сети метками пакетов. Сетевая карта примет все, что адресовано ей и BC/MC во всех vlan-ах которые указаны на порту коммутатора.

tcpdump на физическом интерфейсе видит все. А дальше ядро решит что делать с тегированным пакетом - отдать его в native-vlan или передать на обработку vlan-интерфейсу.

Если работаешь с vlan, то настоятельно не рекомендуется использовать физическией интерфейс.

3 - имя интерфейса ничего не говорит. А еще коммутаторы умеют транслировать vlan-ы и vlan-ы можно запихнуть в один мост!

4 - замечательно. Ищи процесс выполняющий форвардинг dhcp-запросов.

ps

«tcpdump -nei eth0 vlan XXX and udp and port 67» или «tcpdump -nei eth0 vlan and udp and port 67» и никаких grep 802.1Q

vel ★★★★★
()
Ответ на: комментарий от av

1. Ты посмотрел tcpdump'ом на виртуальный интерфейс, родителем которого является физический eth0 и получил список кадров, которые в него попали после декапсуляции кадров VLAN 226, полученных физическим интерфесом. Ты видишь трафик VLAN 226;

2. Ты посмотрел tcpdump'ом на физический интерфейс, в который прилетают кадры без тега и с VID 226. Ты видишь всё, что прилетает твоему компьютеру в сетевой интерфейс.

Сам угадаешь, почему во втором случае ты видишь трафик из VLAN 226?

spijet ★★★
()
Ответ на: комментарий от av

Что значит изолировать? Ты считаешь, что если 802.1q кадры видны в захвате с eth0, то они не изолированы? Но они не будут подняты на уровень IP интерфейса eth0. Кадры с тегом 226 будут подняты на уровень IP интерфейса eth0.226. Это не изоляция?

Если не хочешь видеть 802.1q кадры в захвате с eth0, добавь в фильтр захвата условие !vlan.

То, что в захвате видны все кадры, в том числе те, которые не будут подняты на уровень IP ни одного из интерфейсов хоста, а будут дропнуты или сбриджованы модулем bridging, это нормально, это by design. Это позволяет смотреть броадкасты, мультикасты, отзеркалированный коммутатором трафик и т.д.

iliyap ★★★★★
()
Ответ на: комментарий от spijet

А чего тут гадать - бродкасты основной сети (нетегированной) переваливаются в созданный vlan (eth0.226) и их движение в vlan (eth0.226) идет в тегированном виде.
Подтверждается это тем, что опуская vlan (eth0.226), тегированный трафик на интерфейсе eth0 перестает поступать.
Вот только причина меня больше интересует. Хочу что бы не было в vlan (eth0.226) бродкастов основной сети.

av
() автор топика
Ответ на: комментарий от iliyap

Ты считаешь, что если 802.1q кадры видны в захвате с eth0, то они не изолированы?

Нет, я так не считаю. На eth0, для просмотра через tcpdump, доступен весь трафик.

av
() автор топика
Ответ на: комментарий от av

В том захвате, который ты привел, нет нетегированных бродкастов. Поэтому непонятно, с чего ты взял, что нетегированные бродкасты переваливаются в eth0.226.

iliyap ★★★★★
()
Ответ на: комментарий от av

Раз b8:a3:86:70:aa:5f это локальный адрес, значит в твоем захвате локально сгенерированные пакеты. Их сгенерировал dhcp клиент, запущенный на интерфейсе eth0.226. Когда ты опускаешь интерфейс, dhcp клиент завершается, и перестает генерировать пакеты.

iliyap ★★★★★
()
Ответ на: комментарий от iliyap

В приведенном мной выводе тегированные бродкасты в пункте 2 (ethertype 802.1Q), а идут эти запросы через vlan, что указано в выводе ( vlan 226).

3. Что бы еще проще было видеть, что бродкасты переваливаются, вот синхронный вывод:

tcpdump -e -n -i eth0 |grep 192.168.27.
17:49:13.721350 00:90:7f:94:b6:a4 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 346: vlan 226, p 0, ethertype IPv4, 192.168.27.254.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300

17:49:13.721397 b8:a3:86:70:aa:5f > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 346: vlan 226, p 0, ethertype IPv4, 192.168.27.254.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300

17:49:13.721431 b8:a3:86:70:aa:5f > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 192.168.27.254.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300

17:49:13.721436 b8:a3:86:70:aa:5f > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 192.168.27.254.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300

В данном выводе, dhcp-cклиент, делает запрос, затем маршрутизатор (192.168.27.254) кидает его в vlan. Запрос в тегированном виде долетает до linux, а linux его далее отправляет в нетегированном виде в основной интерфейс. Соответственно и обратно. В результате клиент (отдельно включенный и находящийся в этом vln-е) получает ip от dhcp-сервера, расположенного в основной сети.

av
() автор топика
Ответ на: комментарий от av

В этом захвате нет ни одного запроса, только ответы. Первый пакет от :b6:a4, остальные три от локального :aa:f5. Непонятно, есть ли связь между этими пакетами.

Если бы на этом хосте был запущен dhcp релей, а интерфейсы eth0 и eth0.226 были бы сбриджованы, то картинка была бы примерно такая.

iliyap ★★★★★
()
Ответ на: комментарий от iliyap

Как только ответы, а строчка №1.??

1. Строчка №1 - 17:49:13.721350 00:90:7f:94:b6:a4. Это DHCP-запрос (бродкаст во всю сеть, поисках dhcp-сервера) от клиента, находящегося в VLAN. Его mac=00:90:7f:94:b6:a4, его ip 192.168.27.254. Запрос тегированный.

2. В 2-3 строчках - реакция linux (b8:a3:86:70:aa:5f) :
2.1 - 17:49:13.721397 - DHCP-запрос в vlan
2.2 - 17:49:13.721397 - DHCP-запрос в lan
2.3 - 17:49:13.721436 DHCP-запрос в vlan

3. Вот реакция linux не та, что мне хотелось бы видеть. Она похожа на arp-proxy в обе сети. А вот почему она такая, мне не понять...

av
() автор топика
Ответ на: комментарий от av

Ну там же написано DHCP/BOOTP Reply. Какой же это запрос. К тому же порт отправителя 67 (bootps), порт получателя 68 (bootpc), значит от сервера клиенту.

iliyap ★★★★★
()
Последнее исправление: iliyap (всего исправлений: 1)
Ответ на: комментарий от iliyap

За DHCP/BOOTP Reply спасибо, но ситуация сильно от этого не изменилась.

В первом случае от клиента с маком 00:90:7f:94:b6:a4 и ip 192.168.27.254 (коммутатор) вылетел в vlan тегированный пакет (67->68). Что очень похоже на ответ dhcp-сервера.
Linux его увидел и переправил в основную сеть. Это очень похоже на arp-proxy или dhcp-relay. Но ни того ни другого на сервер нет.

netstat -lnp|grep 67 - пусто
netstat -lnp|grep 68 - пусто
netstat -lnp|grep dhc - пусто
Да и машину сам ставил, поэтому знаю, что она из себя представляет.

К тому же DHCP - это частный случай - переваливается все бродкасты, в частности самбовские.

13:12:17.722513 b8:a3:86:70:aa:5f > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 96: vlan 226, p 0, ethertype IPv4, 192.168.22.177.137 > 255.255.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST

В этом выводе запрос клиента общей сети транслируется в vlan.

av
() автор топика
Ответ на: комментарий от iliyap

к сожалению нет :(

brctl show
bridge name bridge id STP enabled interfaces

av
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Может ли HTTP/HTTPS proxy отличить браузер от не-браузера?
Admin
Хочу возможность firmware на своем девайсе →