kuzma73 Опубликовано 7 ноября, 2019 · Жалоба На микротике два бриджа. К каждому подключена локальная сеть. На бридже 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. Вроде бы задача не сложная, но решить не получается. Буду благодарен за помощь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sheft Опубликовано 7 ноября, 2019 · Жалоба 4 часа назад, kuzma73 сказал: маршрутизировать широковещательный пакет мне одному кажется что это из области как научить всех водителей ездить на красный сигнал светофора? Маски и роутеры как раз и используются чтобы минимизировать и ограничить хождение широковещалок В качестве вредного совета - объединить бриджи в один и натить не по бриджу, а по сурсу Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pingz Опубликовано 8 ноября, 2019 · Жалоба @kuzma73 Лучше напиши, что вы хотите реализовать? 99.9% что вашу задачу можно решить по другому. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kuzma73 Опубликовано 8 ноября, 2019 · Жалоба Ок. В сети 2 сервера (видеонаблюдение + камеры). В сети 1 клиенты. При добавлении нового клиента он ищет сервера посылая один широковещательный пакет, на который каждый из серверов отвечает уже нормальным юникастом. Если добавлять сервера на клиенты по одному руками, то всё норм. Перенести клиентов в сеть 2 невозможно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 8 ноября, 2019 · Жалоба Разобрать бриджи и включать proxy-arp прямо на портах ethernet. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VolanD666 Опубликовано 8 ноября, 2019 · Жалоба А по доменному имени клиенты точно не могут искать? В смысле может есть специальное доменное имя по которому они пытаются разрезолвить адрес сервера? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kuzma73 Опубликовано 8 ноября, 2019 (изменено) · Жалоба 1 час назад, jffulcrum сказал: 1 час назад, jffulcrum сказал: Разобрать бриджи и включать proxy-arp прямо на портах ethernet. Так попробую, спасибо. 27 минут назад, VolanD666 сказал: А по доменному имени клиенты точно не могут искать? В смысле может есть специальное доменное имя по которому они пытаются разрезолвить адрес сервера? Не, широковещательный пакет не проходит. Я в шарке глядел. Изменено 8 ноября, 2019 пользователем kuzma73 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VolanD666 Опубликовано 8 ноября, 2019 · Жалоба Я в смысле про то, что клиент может сначала запрашивать какое-нить специальное доменное имя типа: "SUPER-PUPER-SERVER.local.ccc" и когда ему резолв не приходит, он начинает искать широковещательными пакетами. Нет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kuzma73 Опубликовано 8 ноября, 2019 · Жалоба 1 минуту назад, VolanD666 сказал: Я в смысле про то, что клиент может сначала запрашивать какое-нить специальное доменное имя типа: "SUPER-PUPER-SERVER.local.ccc" и когда ему резолв не приходит, он начинает искать широковещательными пакетами. Нет? Не, сразу пакет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kuzma73 Опубликовано 8 ноября, 2019 · Жалоба В догонку, так сказать. Мне не столько надо сделать чтобы эта конфигурация работала - она и так работает. Сервера руками добавлены. Новые клиенты появляются не часто. Мне интересно как можно (если можно) маршрутизировать пакет. Я пробовал dst nat в прероутинге, манглы + маршруты и т.д. Не получается. Если в прероутинге делаешь дстнат на ip адрес микротика, то пакет попадает в цепочку input. Если на адрес сети 2 - то его не видно ни в output ни в forward. Хотелось бы разобраться чего происходит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SUrov_IBM Опубликовано 8 ноября, 2019 · Жалоба Kuzma73, доброго времени суток. В привычном понимании маршрутизаторов (что мы называем маршрутизаторами класса SOHO), маршрутизация широковещательных пакетов между подсетями (ограниченными маской сети) – не возможна. Возможно только преобразование широковещательного запроса (например DHCP) в IP кадр отправляемый конкретному IP адресу (IP helper перенаправляет запрос DHCP серверу, затем возвращает обратно). Дополнительно: Например, технология IGMP snooping применяемая для IPTV является многоадресной, но не широковещательной. Большинство современных IP видеокамер, видео регистраторов и софт-видео регистраторов к сожалению сделаны по принципу поиска друг друга в сети с "одним коммутатором", используя широковещательный запрос L2 сети, но полноценных SOHO маршрутизаторов способных преобразовать данный широковещательный запрос на подобии IP helper практически не существует. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kuzma73 Опубликовано 8 ноября, 2019 (изменено) · Жалоба Возможно, мне хочется странного, но я хотел бы разобраться. Итак на микротик из сети №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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
McSea Опубликовано 11 ноября, 2019 · Жалоба 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 сервер. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kuzma73 Опубликовано 11 ноября, 2019 · Жалоба 3 часа назад, McSea сказал: Откуда у вас цепочка прероутинга в NAT-е взялась ? Там есть только цепочки dstnat и srcnat. Dst-nat из 255.255.255.255 в конкретный адрес работает, я так DHCP запросы от VPN клиентов перебрасываю на MS DHCP сервер. А цепочка dstnat в NAT-е где находится? Пробрасываете именно dstnat-ом, или при помощи DHCP Relay ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
McSea Опубликовано 11 ноября, 2019 · Жалоба @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 не менялся Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kshishtoff Опубликовано 16 декабря, 2019 (изменено) · Жалоба В 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
McSea Опубликовано 16 декабря, 2019 · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kshishtoff Опубликовано 17 декабря, 2019 (изменено) · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fractal Опубликовано 17 декабря, 2019 · Жалоба 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 на микротах Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kshishtoff Опубликовано 17 декабря, 2019 · Жалоба 1 час назад, fractal сказал: записывайте pcap на микротах Посниффал трафик, ничего толкового (кстати, вдруг кто не знал, можно его напрямую в wireshark отправлять), запросы даже не уходят с роутера. Но внезапно пришло другое решение: сунуть по экземпляру сервера в каждую подсеть, а в нём уже можно руками прописать дальнейший путь в главную сеть. Спасибо всем за советы! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...