https://www.opennet.ru/openforum/vsluhforumID1/97651.html Всем привет!<br><br>На интерфейсе системы eth0 MAC-адрес 00:00:00:00:00:11, на этот интерфейс прилетает пакет на иной MAC-адрес (например 00:00:00:00:00:22). Нужно чтобы система приняла этот пакет и далее, уже провела с ним роутинг и пр.<br><br>Выполнил это:<br>ebtables -t nat -A PREROUTING -d 00:00:00:00:00:22 -i eth0 -j dnat --to-destination 00:00:00:00:00:11<br>Но это не помогло.<br><br>Подскажите что делать.<br><br>net.ipv4.conf.all.rp_filter = 0<br>net.ipv4.conf.default.rp_filter = 0<br>net.ipv4.conf.eth0.rp_filter = 0<br>net.ipv4.conf.lo.rp_filter = 0<br> https://www.opennet.ru/openforum/vsluhforumID1/97651.html#16 Wed, 14 Oct 2020 17:09:25 GMT &gt;&gt; Звучит как жуткий костыль, сочувствую.<br>&gt;&gt; А повлиять в сторону изменения топологии вашей сети вы можете?<br>&gt; Есть некий нагруженный трафиком бридж, который должен "выпнуть" в сторону необходимый трафик, <br>&gt; не используя при этом "дорогостоящих" (читай классических) сетевых механизмов.<br><br>Вот этот нагруженный трафиком god-box выглядит хорошим кандидатом на реинжинерию. А то он вам ещё немало крови попьёт.<br><br> https://www.opennet.ru/openforum/vsluhforumID1/97651.html#15 Wed, 14 Oct 2020 16:47:12 GMT Я, кажется, потерял нить.<br><br>Вы хотели принять пакет с чужим dst-MAC, и потом его маршрутизировать на L3.<br>Но, по вашим словам, пакет уже принимается как родной и маршрутизируется дальше, а проблема в том чтобы автоматизировать обработку смены этого чужого dst-MAC.<br>В таком случае, имеет смысл собрать в одну кучу меры, которые вы принимаете вручную, и уже их автоматизировать, абстрагируясь от дебрей коммутации и раскурочивания пакетов.<br><br>Что касается нестандартности задачи, это само по себе не криминал (а наша увлекательная реальность), но повод декомпонировать её на какие-то более или менее стандартные куски.<br><br> https://www.opennet.ru/openforum/vsluhforumID1/97651.html#14 Wed, 14 Oct 2020 15:31:54 GMT &gt; Это L3?<br><br>ОС его примет и маршрутизировать будет уже по L3<br> https://www.opennet.ru/openforum/vsluhforumID1/97651.html#13 Wed, 14 Oct 2020 10:19:01 GMT &gt; ebtables -t nat -A PREROUTING -d 00:00:00:00:00:22 -i eth0 -j dnat --to-destination 00:00:00:00:00:11<br><br>Это L3?<br> https://www.opennet.ru/openforum/vsluhforumID1/97651.html#12 Wed, 14 Oct 2020 09:45:12 GMT &gt; А форвардячее правило в случае смены мак адреса кто будет корректировать?<br><br>Форвард по L3 же<br> https://www.opennet.ru/openforum/vsluhforumID1/97651.html#11 Wed, 14 Oct 2020 09:44:00 GMT &gt; Может уже перейти к более вменяемому изложению задачи? А то совершенно непонятно <br>&gt; зачем хватать отдельные пакеты, да еще идущие только в одну сторону. <br><br>Я достаточно четко изложил _суть_ задачи, прочтите начало топика еще раз<br> https://www.opennet.ru/openforum/vsluhforumID1/97651.html#10 Wed, 14 Oct 2020 09:27:48 GMT &gt; Но проблема другая, не хочется действий руками т.к. dstMAC может меняться.<br><br>А форвардячее правило в случае смены мак адреса кто будет корректировать?<br> https://www.opennet.ru/openforum/vsluhforumID1/97651.html#9 Wed, 14 Oct 2020 08:53:09 GMT &gt; Задача нестандартная и не укладывается в привычные рамки.<br>&gt; Никакого спуфинга,все легально.<br>&gt; Есть некий нагруженный трафиком бридж, который должен "выпнуть" в сторону необходимый трафик, не используя при этом "дорогостоящих" (читай классических) сетевых механизмов.<br><br>После таких формулировок следует пара выводов - либо афтар темнит в силу нелегальности затеи, либо он банально нифига не понимает что делает.<br><br>Может уже перейти к более вменяемому изложению задачи? А то совершенно непонятно зачем хватать отдельные пакеты, да еще идущие только в одну сторону.<br> https://www.opennet.ru/openforum/vsluhforumID1/97651.html#8 Wed, 14 Oct 2020 04:38:58 GMT &gt; Звучит как жуткий костыль, сочувствую.<br>&gt; А повлиять в сторону изменения топологии вашей сети вы можете?<br><br>Есть некий нагруженный трафиком бридж, который должен "выпнуть" в сторону необходимый трафик, не используя при этом "дорогостоящих" (читай классических) сетевых механизмов.<br>