[kuzma73]

На микротике два бриджа. К каждому подключена локальная сеть. На бридже 1 192.168.1.0/24. На бридже 2 172.16.0.0/16. Для пакетов исходящих с бриджа 2 работает srcnat. Правила файрвола ничему не мешают. 
Задача - маршрутизировать широковещательный пакет (dst ip 255.255.255.255 и dst MAC FF:FF:FF:FF:FF:FF ) из сети 1 в сеть 2.

Вроде бы задача не сложная, но решить не получается. Буду благодарен за помощь. 

[sheft]

4 часа назад, kuzma73 сказал:

маршрутизировать широковещательный пакет

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

В качестве вредного совета - объединить бриджи в один и натить не по бриджу, а по сурсу

[pingz]

@kuzma73 Лучше напиши, что вы хотите реализовать? 99.9% что вашу задачу можно решить по другому. 

[kuzma73]

Ок. В сети 2 сервера (видеонаблюдение + камеры). В сети 1 клиенты. При добавлении нового клиента он ищет сервера посылая один широковещательный пакет, на который каждый из серверов отвечает уже нормальным юникастом. Если добавлять сервера на клиенты по одному руками, то всё норм. Перенести клиентов в сеть 2 невозможно. 

[jffulcrum]

Разобрать бриджи и включать proxy-arp прямо на портах ethernet.

[VolanD666]

А по доменному имени клиенты точно не могут искать? В смысле может есть специальное доменное имя по которому они пытаются разрезолвить адрес сервера?

[kuzma73]

1 час назад, jffulcrum сказал:

1 час назад, jffulcrum сказал:

Разобрать бриджи и включать proxy-arp прямо на портах ethernet.

Так попробую, спасибо.

 

 

27 минут назад, VolanD666 сказал:

А по доменному имени клиенты точно не могут искать? В смысле может есть специальное доменное имя по которому они пытаются разрезолвить адрес сервера?

Не, широковещательный пакет не проходит. Я в шарке глядел.

Изменено 8 ноября, 2019 пользователем kuzma73

[VolanD666]

Я в смысле про то, что клиент может сначала запрашивать какое-нить специальное доменное имя типа: "SUPER-PUPER-SERVER.local.ccc" и когда ему резолв не приходит, он начинает искать широковещательными пакетами. Нет?

[kuzma73]

1 минуту назад, VolanD666 сказал:

Я в смысле про то, что клиент может сначала запрашивать какое-нить специальное доменное имя типа: "SUPER-PUPER-SERVER.local.ccc" и когда ему резолв не приходит, он начинает искать широковещательными пакетами. Нет?

Не, сразу пакет.

[kuzma73]

В догонку, так сказать. Мне не столько надо сделать чтобы эта конфигурация работала - она и так работает.  Сервера руками добавлены. Новые клиенты появляются не часто. Мне интересно как можно (если можно) маршрутизировать пакет. Я пробовал dst nat в прероутинге, манглы + маршруты  и т.д. Не получается. Если в прероутинге делаешь дстнат на ip адрес микротика, то пакет попадает в цепочку input. Если на адрес сети 2 - то его не видно ни в output ни в forward. Хотелось бы разобраться чего происходит.

[SUrov_IBM]

Kuzma73, доброго времени суток.

 

В привычном понимании маршрутизаторов (что мы называем маршрутизаторами класса SOHO), маршрутизация широковещательных пакетов между подсетями (ограниченными маской сети) – не возможна.

 

Возможно только преобразование широковещательного запроса (например DHCP) в IP кадр отправляемый конкретному IP адресу (IP helper перенаправляет запрос DHCP серверу, затем возвращает обратно).

 

Дополнительно: Например, технология IGMP snooping применяемая для IPTV является многоадресной, но не широковещательной.

Большинство современных IP видеокамер, видео регистраторов и софт-видео регистраторов к сожалению сделаны по принципу поиска друг друга в сети с "одним коммутатором", используя широковещательный запрос L2 сети, но полноценных SOHO маршрутизаторов способных преобразовать данный широковещательный запрос на подобии IP helper практически не существует.

[kuzma73]

Возможно, мне хочется странного, но я хотел бы разобраться. Итак на микротик из сети №1 приходит пакет c ip адресом получателя 255.255.255.255 и MAC адресом получателя FF:FF:FF:FF:FF:FF. Я отлавливаю его в цепочке прероутинга и дст натом меняю ему адрес получателя на занятый адрес из сети #2 (например 172.16.155.155 - такой сервер есть). И после этого пакет не появляется ни в одной из цепочек. Что с ним происходит и почему? 

Я рассуждал так: После дст ната в прероутинге, принимая решение о маршрутизации, микротик увидит что пакет адресован компу из сети №2 и отправит его в цепочку форвард. Но что-то, как говорится, пошло не так. Я исходил из того что пакет в микротике движется как нарисовано на прилагаемой картинке (взятой отсюда https://habr.com/ru/post/443788/ ) Т.е. в точке 1 пакет отбрасываеся? Почему?

Изменено 8 ноября, 2019 пользователем kuzma73

[McSea]

On 11/9/2019 at 12:30 AM, kuzma73 said:

Возможно, мне хочется странного, но я хотел бы разобраться. Итак на микротик из сети №1 приходит пакет c ip адресом получателя 255.255.255.255 и MAC адресом получателя FF:FF:FF:FF:FF:FF. Я отлавливаю его в цепочке прероутинга и дст натом меняю ему адрес получателя на занятый адрес из сети #2 (например 172.16.155.155 - такой сервер есть). И после этого пакет не появляется ни в одной из цепочек.

Откуда у вас цепочка прероутинга в NAT-е взялась ? Там есть только цепочки dstnat и srcnat.

Dst-nat из 255.255.255.255 в конкретный адрес работает, я так DHCP запросы от VPN клиентов перебрасываю на MS DHCP сервер.

 

[kuzma73]

3 часа назад, McSea сказал:

Откуда у вас цепочка прероутинга в NAT-е взялась ? Там есть только цепочки dstnat и srcnat.

Dst-nat из 255.255.255.255 в конкретный адрес работает, я так DHCP запросы от VPN клиентов перебрасываю на MS DHCP сервер.

 

А цепочка dstnat в NAT-е где находится?

Пробрасываете именно dstnat-ом, или при помощи DHCP Relay ?

[McSea]

@kuzma73 

/ip firewall nat
add action=dst-nat chain=dstnat comment="DHCP INFORM" dst-address=255.255.255.255 dst-port=67 log=yes log-prefix=DHCP protocol=udp src-address=YY.YY.YY.YY src-port=68 to-addresses=XX.XX.XX.XX

Вот такое правило, и к нему еще в Raw надо правило с no track, чтобы обратно адрес сервера на 255.255.255.255 не менялся

[kshishtoff]

В 11.11.2019 в 13:49, McSea сказал:

@kuzma73 

/ip firewall nat
add action=dst-nat chain=dstnat comment="DHCP INFORM" dst-address=255.255.255.255 dst-port=67 log=yes log-prefix=DHCP protocol=udp src-address=YY.YY.YY.YY src-port=68 to-addresses=XX.XX.XX.XX

Вот такое правило, и к нему еще в Raw надо правило с no track, чтобы обратно адрес сервера на 255.255.255.255 не менялся

А не расскажете поподробней, что именно нужно прописать в Raw?

Изменено 16 декабря, 2019 пользователем kshishtoff

[McSea]

11 hours ago, kshishtoff said:

что именно нужно прописать в Raw?

/ip firewall raw
add action=notrack chain=prerouting dst-address=YY.YY.YY.YY dst-port=68 protocol=udp src-address=XX.XX.XX.XX src-port=67

 

[kshishtoff]

8 часов назад, McSea сказал:

/ip firewall raw
add action=notrack chain=prerouting dst-address=YY.YY.YY.YY dst-port=68 protocol=udp src-address=XX.XX.XX.XX src-port=67

 

Спасибо, но не помогло, увы. 

На всякий случай опишу ситуацию: есть главная сеть предприятия 10.10.11.0/24 и пара (пока пара, потом может быть больше) подсетей филиалов, 10.10.12.0/24 и 10.10.13.0/24. В основной сети есть сервер, на котором некая самописная служба слушает udp-запросы на 9009 порт, и есть некая самописная программа (от которой отказаться/заменить/ещё что-то нет никакой возможности), которая запускается, рассылает бродкаст на 255.255.255.255:9009, получает ответ от сервера, и дальше работает, как задумано её создателем, принимает/отправляет данные. И если в основной сети всё работает без проблем, то из подсетей никак не заставить достучаться до сервера. Попробовал ваш способ, в сторону сервера счётчик тикает, т.е. пакеты туда хотя бы уходят, а обратно никак не получается. Может есть ещё какие-то варианты?

Wireshark на сервере работать не хочет, не  посмотреть, что там происходит с запросами.

UPD: Wireshark таки заработал, до сервера тоже ничего не доходит, оказывается. В нат добавлял такое:

/ip firewall nat
add action=dst-nat chain=dstnat comment="SDP" dst-address=255.255.255.255 dst-port=9009 log=yes log-prefix=SDP protocol=udp src-address=10.10.12.25 src-port=9009 to-addresses=10.10.11.4

 

Изменено 17 декабря, 2019 пользователем kshishtoff

[fractal]

2 часа назад, kshishtoff сказал:

Спасибо, но не помогло, увы. 

На всякий случай опишу ситуацию: есть главная сеть предприятия 10.10.11.0/24 и пара (пока пара, потом может быть больше) подсетей филиалов, 10.10.12.0/24 и 10.10.13.0/24. В основной сети есть сервер, на котором некая самописная служба слушает udp-запросы на 9009 порт, и есть некая самописная программа (от которой отказаться/заменить/ещё что-то нет никакой возможности), которая запускается, рассылает бродкаст на 255.255.255.255:9009, получает ответ от сервера, и дальше работает, как задумано её создателем, принимает/отправляет данные. И если в основной сети всё работает без проблем, то из подсетей никак не заставить достучаться до сервера. Попробовал ваш способ, в сторону сервера счётчик тикает, т.е. пакеты туда хотя бы уходят, а обратно никак не получается. Может есть ещё какие-то варианты?

Wireshark на сервере работать не хочет, не  посмотреть, что там происходит с запросами.

UPD: Wireshark таки заработал, до сервера тоже ничего не доходит, оказывается. В нат добавлял такое:

/ip firewall nat
add action=dst-nat chain=dstnat comment="SDP" dst-address=255.255.255.255 dst-port=9009 log=yes log-prefix=SDP protocol=udp src-address=10.10.12.25 src-port=9009 to-addresses=10.10.11.4

 

 

записывайте pcap на микротах

[kshishtoff]

1 час назад, fractal сказал:

записывайте pcap на микротах

Посниффал трафик, ничего толкового (кстати, вдруг кто не знал, можно его напрямую в wireshark отправлять), запросы даже не уходят с роутера. Но внезапно пришло другое решение: сунуть по экземпляру сервера в каждую подсеть, а в нём уже можно руками прописать дальнейший путь в главную сеть. Спасибо всем за советы!