Всем привет!На интерфейсе системы eth0 MAC-адрес 00:00:00:00:00:11, на этот интерфейс прилетает пакет на иной MAC-адрес (например 00:00:00:00:00:22). Нужно чтобы система приняла этот пакет и далее, уже провела с ним роутинг и пр.
Выполнил это:
ebtables -t nat -A PREROUTING -d 00:00:00:00:00:22 -i eth0 -j dnat --to-destination 00:00:00:00:00:11
Но это не помогло.Подскажите что делать.
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.eth0.rp_filter = 0
net.ipv4.conf.lo.rp_filter = 0
если сетевуха воткнута в свитч (коммутатор) то никак, тебе пакет для чужого мака туда не прилетит (за исключением броадкастов итп)
При легальном использовании, можно посмотреть в сторону arp proxy.
При нелегальном будут дикие потери пакетов и у тебя и у жертвы.
> При легальном использовании, можно посмотреть в сторону arp proxy.
> При нелегальном будут дикие потери пакетов и у тебя и у жертвы.Есть третья система, которая меняет влан у проходящего по ней пакета, этот пакет вылетает по этому влану и прилетает на мою систему, но мак-адрес назначения не как у моей системы, надо его принять и смаршрутизировать дальше.
>> При легальном использовании, можно посмотреть в сторону arp proxy.
>> При нелегальном будут дикие потери пакетов и у тебя и у жертвы.
> Есть третья система, которая меняет влан у проходящего по ней пакета, этот
> пакет вылетает по этому влану и прилетает на мою систему, но
> мак-адрес назначения не как у моей системы, надо его принять и
> смаршрутизировать дальше.Сетевой bridge? Или вы вы пытаетесь изобрести что-то принципиально новое?
Подробнее опишите зачем такие извращения?
> третья система, которая меняет влан у проходящего по ней пакетаЗвучит как жуткий костыль, сочувствую.
А повлиять в сторону изменения топологии вашей сети вы можете?
> Звучит как жуткий костыль, сочувствую.
> А повлиять в сторону изменения топологии вашей сети вы можете?Есть некий нагруженный трафиком бридж, который должен "выпнуть" в сторону необходимый трафик, не используя при этом "дорогостоящих" (читай классических) сетевых механизмов.
>> Звучит как жуткий костыль, сочувствую.
>> А повлиять в сторону изменения топологии вашей сети вы можете?
> Есть некий нагруженный трафиком бридж, который должен "выпнуть" в сторону необходимый трафик,
> не используя при этом "дорогостоящих" (читай классических) сетевых механизмов.Вот этот нагруженный трафиком god-box выглядит хорошим кандидатом на реинжинерию. А то он вам ещё немало крови попьёт.
>[оверквотинг удален]
> и далее, уже провела с ним роутинг и пр.
> Выполнил это:
> ebtables -t nat -A PREROUTING -d 00:00:00:00:00:22 -i eth0 -j dnat --to-destination
> 00:00:00:00:00:11
> Но это не помогло.
> Подскажите что делать.
> net.ipv4.conf.all.rp_filter = 0
> net.ipv4.conf.default.rp_filter = 0
> net.ipv4.conf.eth0.rp_filter = 0
> net.ipv4.conf.lo.rp_filter = 0Во первых, удостоверьтесь (например, сниффером), что пакет с dst-mac 00:00:00:00:00:22 к вам приходит, т.к. если он не приходит, то всё остальное будет бесполезно. Это зависит от вашего коммутатора.
К вам точно уже приходят пакеты для чужого MAC, или проблема в том чтобы заставить конммутатор вам их слать?Во вторых, вам надо завести у себя требуемый MAC. Самое лучшее было бы отдать под это дело физический порт полностью и просто назначить ему соответствующий MAC.
https://en.wikibooks.org/wiki/Changing_Your_MAC_Address/LinuxЕсли порт приходится делить с обычным трафиком, то так тоже можно
https://unix.stackexchange.com/questions/21841/make-some-vir...В любом случае, надо ЗАПРЕТИТЬ СВЕТИТЬ ЧУЖОЙ MAC В СЕТИ, иначе оно будет мутить ARP таблицы соседей.
https://serverfault.com/questions/486594/arp-who-has-request...В принципе должно работать как-то так, но это не точно. ИМХО, вы творите что-то странное, рекомендую переформулиовать задачу на более высоком уровне абстракции.
Если вы проводите spoofing атаку, то вы выбрали сложноватую стратегию и всего того что я описал будет недостаточно. Гуглите arp cache poisoning и чтите УК.
> Во первых, удостоверьтесь (например, сниффером), что пакет с dst-mac 00:00:00:00:00:22
> к вам приходит, т.к. если он не приходит, то всё остальное
> будет бесполезно. Это зависит от вашего коммутатора.
> К вам точно уже приходят пакеты для чужого MAC, или проблема в
> том чтобы заставить конммутатор вам их слать?Всё так, пакет приходит на мою систему с чужим dstMAC
> Во вторых, вам надо завести у себя требуемый MAC. Самое лучшее было
> бы отдать под это дело физический порт полностью и просто назначить
> ему соответствующий MAC.
> https://en.wikibooks.org/wiki/Changing_Your_MAC_Address/Linux
> Если порт приходится делить с обычным трафиком, то так тоже можно
> https://unix.stackexchange.com/questions/21841/make-some-vir...Так и сделал, поднял алиас, настроил MAC, пакет принимается как родной, маршрутизируется дальше.
Но проблема другая, не хочется действий руками т.к. dstMAC может меняться.
> В любом случае, надо ЗАПРЕТИТЬ СВЕТИТЬ ЧУЖОЙ MAC В СЕТИ, иначе оно
> будет мутить ARP таблицы соседей.
> https://serverfault.com/questions/486594/arp-who-has-request...
> В принципе должно работать как-то так, но это не точно. ИМХО, вы
> творите что-то странное, рекомендую переформулиовать задачу на более высоком уровне абстракции.Задача нестандартная и не укладывается в привычные рамки.
> Если вы проводите spoofing атаку, то вы выбрали сложноватую стратегию и всего
> того что я описал будет недостаточно. Гуглите arp cache poisoning и
> чтите УК.Никакого спуфинга,все легально.
> Задача нестандартная и не укладывается в привычные рамки.
> Никакого спуфинга,все легально.
> Есть некий нагруженный трафиком бридж, который должен "выпнуть" в сторону необходимый трафик, не используя при этом "дорогостоящих" (читай классических) сетевых механизмов.После таких формулировок следует пара выводов - либо афтар темнит в силу нелегальности затеи, либо он банально нифига не понимает что делает.
Может уже перейти к более вменяемому изложению задачи? А то совершенно непонятно зачем хватать отдельные пакеты, да еще идущие только в одну сторону.
> Может уже перейти к более вменяемому изложению задачи? А то совершенно непонятно
> зачем хватать отдельные пакеты, да еще идущие только в одну сторону.Я достаточно четко изложил _суть_ задачи, прочтите начало топика еще раз
> Но проблема другая, не хочется действий руками т.к. dstMAC может меняться.А форвардячее правило в случае смены мак адреса кто будет корректировать?
> А форвардячее правило в случае смены мак адреса кто будет корректировать?Форвард по L3 же
> ebtables -t nat -A PREROUTING -d 00:00:00:00:00:22 -i eth0 -j dnat --to-destination 00:00:00:00:00:11Это L3?
> Это L3?ОС его примет и маршрутизировать будет уже по L3
Я, кажется, потерял нить.Вы хотели принять пакет с чужим dst-MAC, и потом его маршрутизировать на L3.
Но, по вашим словам, пакет уже принимается как родной и маршрутизируется дальше, а проблема в том чтобы автоматизировать обработку смены этого чужого dst-MAC.
В таком случае, имеет смысл собрать в одну кучу меры, которые вы принимаете вручную, и уже их автоматизировать, абстрагируясь от дебрей коммутации и раскурочивания пакетов.Что касается нестандартности задачи, это само по себе не криминал (а наша увлекательная реальность), но повод декомпонировать её на какие-то более или менее стандартные куски.