бриджевание сетей

firewall

нету таких! все цепочки пустые и accept

полезает только бродкаст-трафик

Правильно! Так и должно быть.

Сам догадаешься почему?

Подскажи уж. Я этим еще не занимался, но вдруг то же потребуется, хоть буду знать, как не наступить на эту же ошибку.

ты в дверных проёмах не застреёшь ещё, умник?

если по делу нечего сказать, топай в толксы.

Только со стороны клиента впн не на шлюзе, а на одной из машин в сети 192.168.1.0

И почему трафик должен пойти не на шлюз, а на «одну из машин в сети 192.168.1.0»?

пардон, а зачем ему вообще идти на шлюз, если сеть одноранговая? я ж написал, что забриджевал тоннель и локалку, а адреса все из одной подсети.

Все правильно, я написал, обдумал и удалить не успел :-)

но вдруг то же потребуется

Не потребуется.

А ответ... Ответ лежит на поверхности. Нужно просто понимать, что соременная аппаратура не способна догадываться. Она работает только с тем, что есть в наличии.

Его извилейшество, может быть, будет так любезно слегка развить свою мысль?

Ответ sdio верный? Я тоже сначала так подумал, но уверенность ТС заставила усомниться.

Proxy ARP

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

почему мои-то не связаны? сбриджевал же, смотри оп.

tcpdump на бридже запусти, посмотри доходят ли пакеты до него (через него), может switch слишком умный у тебя

он показывает, что проходят только широковещательные пакеты. сетевая инфраструктура со стороны впн клиента мне не подконтрольна и исследовать её затруднительно, ибо гегорафически далеко (я на стороне сервера живу)

Я не знаю как работает мост в linux.
Для того чтобы работало, надо, чтобы интерфейс в сторону ЛВС принимал пакеты с Dest MAC отличающимся от адреса интерфейса и переправлял на другую сторону, если этот MAC был выучен на другом интерфейсе. Proxy ARP отличается, но довольно близок по смыслу.

ARP правильно резолвится при пинге с любой стороны?
ARP response — это unicast, т.ч. если в ARP table на пингующей стороне появляется правильный адрес удалённой стороны, значит unicast-ы через туннель ходят.

ARP правильно резолвится при пинге с любой стороны?

именно! в чем и дело-то.. а пинги не идут.

Значит что-то накосячено с мостом.

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

да, brctl showmacs br0 показывает верно. маки выучиваются правильно.

Upd: фаервола нет с обоих сторон.

Уверен на 100%?

Попробуй для теста вот эти значения sysctl установить в 0:

net.bridge.bridge-nf-call-arptables
net.bridge.bridge-nf-call-iptables
net.bridge.bridge-nf-call-ip6tables

А пингуешь мелкими пакетами?

стандартными

да, это железобетонно. фаервола между (клиентом впн и остальной сетью) и (сервером и остальной сетью) нет

фаервола между (клиентом впн и остальной сетью) и (сервером и остальной сетью) нет

А между «сторонами моста» и там и там? Дело в том, что в linux мост работает не как обычный тупой свитч. Все пакеты как минимум проходят через цепочку iptables FORWARD, а также через ebtables.

Ещё линуксовый мост может умно обрабатывать мультикаст - оправлять пакеты только на те порты, с которых пришёл запрос на присоединение к мультикаст-группам (multicast snooping). Но это не имеет отношение к сабжевой проблеме.

ebtables не установлены

$ sudo 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

Слышал что для brtools обязательно писать отдельные правила в iptables. То есть: если в iptables всё разрешено это не означает что мостовой трафик пойдёт. Там где-то нужно явно молотком сказать: чтоб пускало трафик от br. - Так-как br это отдельный уровень абстракции ядра Linux. - Бывает сабж в KVM когда вирт. машины не видят например друг-друга.

есть сеть класса С

Классами никто не пользуется. Юзай префиксы, когда говоришь о сетях.

То есть, ты не распарсил? Окей. /24
По сути-то есть что подсказать?

А ссылочки, случайно, не завалялось на это утверждение? Было бы здорово!

А тут уже что-то подобное советовали тебе. http://www.linuxplayer.org/2011/04/rhel6-disabled-iptables-on-bridge-interfac... , но мне кажется даже на ЛОРе проблегало, и совет был несколько из другой плоскости.

Совет анона я выполнил - не полегчало... ссылку повтыкаю, спасибо! аа... там кав раз про это...

На всякий случай... «стандартными» — это 64 байта?

(Хотя по умолчанию вроде df всё равно не выставлен).

frob, ты был прав. я просто не в ту сторону начал думать.

ivanlex, вот ответ:
echo 1 | sudo tee /proc/sys/net/ipv4/conf/br0/proxy_arp с каждой стоноры туннеля.

Любопытно...
Выходит, что либо линуксовый мост «с приколами», либо (во что хотелось бы верить больше) какой-нибудь ещё ключ такие «приколы» включает.

Если взять сферический мост мощностью в одну микроциску, то всё должно работать и без proxy arp. Такое поведение как у твоего моста могло бы получиться, если бы интерфейсы в сторону ЛВС работали не в промискуитетном режиме.

Вот и я голову ломал... все интерфейсы в promisc mode, а не прёт...

если бы интерфейсы в сторону ЛВС работали не в промискуитетном режиме.

ты опять прав! вобщем, с одной стороны впн-а всё это безобразие крутилось в виртуалке. на guest-e я, конечно, переводил всё в promisc mode, но не на хосте!

Реально, «на третий день индеец-зоркий глаз заметил, что стены нет»

вобщем, настроил в параметрах виртуалки, чтобы хостовый интерфейс тоже переводился в promisc mode.

Спасибо тебе! именно твои советы в итоге привели меня к решению!

на guest-e я, конечно, переводил всё в promisc mode, но не на хосте!

А-га! Вот теперь сходится =)
Значит мост в Linux работает как положено.

именно твои советы

Ну, какие ж это советы... так — догадки-домыслы.

в цисках наоборот надо иногда отключать через no ip proxy-arp оно там по умолчанию включено

На свичах ничего отключать не надо.

для мостов отключать не надо, и не на свитчах, а на интерфейсах L3