LINUX.ORG.RU
решено ФорумAdmin

[РЕШЕНО]Gentoo настройка бриджа между 2мя интерфесами

 , , , ,


0

1

На ESXi 5.0 u1 сервере крутится виртуалка gentoo ядро 3.6.11 с поключенными к ней 2мя сетевыми интерфейсами eth0 eth1 которые через 2 разных виртуальных свича подключены к разным сетевым картам сервера.

Задача - сделать из виртальной машины фильтр от паразитного трафика для небольшой части локальной сети ( она подключена через медленные радиорелейки). Впринципе задача сводится к настройке бриджа межуд 2мя интерфейсами и потом стоит копать всторону ebtables. В сети куча манулов на эту тему. Вроде бы делаю все правильно. Пока в виде тестового клиента подключаю не хвост от части сети, а просто рабочую станцию и.... ничего не происходит, рабочая станция не получает адрес по dhcp. Прописал сетевые настройки руками, всеравно толку нет - пинги не идут. ebtables пока не настраивал чтоб не мешали раньше времени. Ядро компилил с учетом всяких вкусностей типа поддержки форвардинга и всяких там --tables. Форвардинг в ядре включен (cat /proc/sys/net/ip4/conf/br0/forwarding выдает 1). Чтобы все поднималось само в /etc/sysctl.conf добавил net.ipv4.ip_forward = 1

мой /etc/conf.d/net

config_eth0=("null")
config_eth1=("null")

bridge_br0="eth0 eth1"
brctl_br0=( "stp off setfd 0 sethello 1" )
config_br0=("x.y.7.5 netmask 255.255.255.0 brd x.y.7.255" )
routes_br0=( "default gw x.y.7.1" )
dns_servers_br0="x.y.7.7"
rc_need_br0="net.eth0 net.eth1"

ну и


ifconfig
br0       Link encap:Ethernet  HWaddr ff:0c:ff:9d:ff:ff  
          inet addr: x.y.7.5  Bcast: x.y.7.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:13057 errors:0 dropped:554 overruns:0 frame:0
          TX packets:1037 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:858813 (838.6 KiB)  TX bytes:319636 (312.1 KiB)

eth0      Link encap:Ethernet  HWaddr ff:0c:ff:9d:ff:ff  
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:16009 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1165 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1508609 (1.4 MiB)  TX bytes:370284 (361.6 KiB)

eth1      Link encap:Ethernet  HWaddr ff:0c:ff:9d:ff:f1  
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:115 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11642 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:21604 (21.0 KiB)  TX bytes:890228 (869.3 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

brctl show
bridge name	bridge id		STP enabled	interfaces
br0		8000.000c299dffed	no		eth0
							eth1
route
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         x.y.7.1         0.0.0.0         UG    1      0        0 br0
x.y.7.0         *               255.255.255.0   U     0      0        0 br0
loopback        localhost       255.0.0.0       UG    0      0        0 lo

вроде бы спотыкаться негде, мост должен уже работать, или я что-то еще упустил?



Последнее исправление: Tango (всего исправлений: 3)
Ответ на: комментарий от vasily_pupkin

щас фактически все идет через шнурок который физически подключен к eth0. tcpdump показывает что eth0 br0 принимают кучу пакетов, на eth1 почти все arp трафик

Tango
() автор топика

собери мост руками для начала. если всё выйдет, то надо искать один параметр, который я не помню... тоже борол. поборол.

суть, вобщем, была в том, что сетевухи слишком долго там до чего-то договаривались, и в инит скрипте мост не работал, а руками - на ура.

или этот sethello 1 как раз и есть то, о чем я говорю? %)

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

нашел еще вот такой вот комент гдет ов дебрях гугла

It's possible that the underlying network devices on the host do not have promiscuous mode enabled. In VMWare, for example, if the underlying virtual network adapter isn't +promisc then the guest bridge will fail miserably — even though it thinks its able to enter promiscuous mode, it can't.

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

FU*$ YE"%! все завелось надо было только вот сюда написать передохнуть пол часа и еще чучуть погуглить. Оказалось в настройках виртуального свича в моем ESXi promiscuous mode был в статусе reject. Итог чтобы убрать 2 галочки ушло полтора дня =)

Tango
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.