The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Как принять пакет с чужим dst-MAC ?"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Маршрутизация, NAT / Linux)
Изначальное сообщение [ Отслеживать ]

"Как принять пакет с чужим dst-MAC ?"  +/
Сообщение от Rom1email (??), 13-Окт-20, 14:06 
Всем привет!

На интерфейсе системы 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

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Как принять пакет с чужим dst-MAC ?"  +/
Сообщение от муу (?), 13-Окт-20, 15:09 
если сетевуха воткнута в свитч (коммутатор) то никак, тебе пакет для чужого мака туда не прилетит (за исключением броадкастов итп)


Ответить | Правка | Наверх | Cообщить модератору

2. "Как принять пакет с чужим dst-MAC ?"  +/
Сообщение от DeerFriend (?), 13-Окт-20, 15:44 
При легальном использовании, можно посмотреть в сторону arp proxy.
При нелегальном будут дикие потери пакетов и у тебя и у жертвы.
Ответить | Правка | Наверх | Cообщить модератору

3. "Как принять пакет с чужим dst-MAC ?"  +/
Сообщение от Rom1email (??), 13-Окт-20, 16:08 
> При легальном использовании, можно посмотреть в сторону arp proxy.
> При нелегальном будут дикие потери пакетов и у тебя и у жертвы.

Есть третья система, которая меняет влан у проходящего по ней пакета, этот пакет вылетает по этому влану и прилетает на мою систему, но мак-адрес назначения не как у моей системы, надо его принять и смаршрутизировать дальше.

Ответить | Правка | Наверх | Cообщить модератору

4. "Как принять пакет с чужим dst-MAC ?"  +/
Сообщение от . (?), 13-Окт-20, 16:14 
>> При легальном использовании, можно посмотреть в сторону arp proxy.
>> При нелегальном будут дикие потери пакетов и у тебя и у жертвы.
> Есть третья система, которая меняет влан у проходящего по ней пакета, этот
> пакет вылетает по этому влану и прилетает на мою систему, но
> мак-адрес назначения не как у моей системы, надо его принять и
> смаршрутизировать дальше.

Сетевой bridge? Или вы вы пытаетесь изобрести что-то принципиально новое?
Подробнее опишите зачем такие извращения?

Ответить | Правка | Наверх | Cообщить модератору

6. "Как принять пакет с чужим dst-MAC ?"  +/
Сообщение от Licha Morada (ok), 13-Окт-20, 20:29 

> третья система, которая меняет влан у проходящего по ней пакета

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

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

8. "Как принять пакет с чужим dst-MAC ?"  +/
Сообщение от Rom1email (??), 14-Окт-20, 07:38 
> Звучит как жуткий костыль, сочувствую.
> А повлиять в сторону изменения топологии вашей сети вы можете?

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

Ответить | Правка | Наверх | Cообщить модератору

16. "Как принять пакет с чужим dst-MAC ?"  +/
Сообщение от Licha Morada (ok), 14-Окт-20, 20:09 
>> Звучит как жуткий костыль, сочувствую.
>> А повлиять в сторону изменения топологии вашей сети вы можете?
> Есть некий нагруженный трафиком бридж, который должен "выпнуть" в сторону необходимый трафик,
> не используя при этом "дорогостоящих" (читай классических) сетевых механизмов.

Вот этот нагруженный трафиком god-box выглядит хорошим кандидатом на реинжинерию. А то он вам ещё немало крови попьёт.

Ответить | Правка | Наверх | Cообщить модератору

5. "Как принять пакет с чужим dst-MAC ?"  +/
Сообщение от Licha Morada (ok), 13-Окт-20, 20:26 
>[оверквотинг удален]
> и далее, уже провела с ним роутинг и пр.
> Выполнил это:
> 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 и чтите УК.

Ответить | Правка | Наверх | Cообщить модератору

7. "Как принять пакет с чужим dst-MAC ?"  +/
Сообщение от Rom1email (??), 14-Окт-20, 07:14 
> Во первых, удостоверьтесь (например, сниффером), что пакет с 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 и
> чтите УК.

Никакого спуфинга,все легально.

Ответить | Правка | Наверх | Cообщить модератору

9. "Как принять пакет с чужим dst-MAC ?"  +/
Сообщение от Pahanivo (ok), 14-Окт-20, 11:53 
> Задача нестандартная и не укладывается в привычные рамки.
> Никакого спуфинга,все легально.
> Есть некий нагруженный трафиком бридж, который должен "выпнуть" в сторону необходимый трафик, не используя при этом "дорогостоящих" (читай классических) сетевых механизмов.

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

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

Ответить | Правка | Наверх | Cообщить модератору

11. "Как принять пакет с чужим dst-MAC ?"  –1 +/
Сообщение от Rom1email (??), 14-Окт-20, 12:44 
> Может уже перейти к более вменяемому изложению задачи? А то совершенно непонятно
> зачем хватать отдельные пакеты, да еще идущие только в одну сторону.

Я достаточно четко изложил _суть_ задачи, прочтите начало топика еще раз

Ответить | Правка | Наверх | Cообщить модератору

10. "Как принять пакет с чужим dst-MAC ?"  +/
Сообщение от DeerFriend (?), 14-Окт-20, 12:27 
> Но проблема другая, не хочется действий руками т.к. dstMAC может меняться.

А форвардячее правило в случае смены мак адреса кто будет корректировать?

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

12. "Как принять пакет с чужим dst-MAC ?"  –1 +/
Сообщение от Rom1email (??), 14-Окт-20, 12:45 
> А форвардячее правило в случае смены мак адреса кто будет корректировать?

Форвард по L3 же

Ответить | Правка | Наверх | Cообщить модератору

13. "Как принять пакет с чужим dst-MAC ?"  +1 +/
Сообщение от DeerFriend (?), 14-Окт-20, 13:19 
> 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?

Ответить | Правка | Наверх | Cообщить модератору

14. "Как принять пакет с чужим dst-MAC ?"  +/
Сообщение от Rom1email (??), 14-Окт-20, 18:31 
> Это L3?

ОС его примет и маршрутизировать будет уже по L3

Ответить | Правка | Наверх | Cообщить модератору

15. "Как принять пакет с чужим dst-MAC ?"  +/
Сообщение от Licha Morada (ok), 14-Окт-20, 19:47 
Я, кажется, потерял нить.

Вы хотели принять пакет с чужим dst-MAC, и потом его маршрутизировать на L3.
Но, по вашим словам, пакет уже принимается как родной и маршрутизируется дальше, а проблема в том чтобы автоматизировать обработку смены этого чужого dst-MAC.
В таком случае, имеет смысл собрать в одну кучу меры, которые вы принимаете вручную, и уже их автоматизировать, абстрагируясь от дебрей коммутации и раскурочивания пакетов.

Что касается нестандартности задачи, это само по себе не криминал (а наша увлекательная реальность), но повод декомпонировать её на какие-то более или менее стандартные куски.

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру