forum.opennet.ru - "Как принять пакет с чужим dst-MAC ?" (16)

"Как принять пакет с чужим dst-MAC ?"

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

"Как принять пакет с чужим dst-MAC ?"	+/–
Сообщение от Rom1 (??), 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ообщить модератору

Оглавление

если сетевуха воткнута в свитч коммутатор то никак, тебе пакет для чужого мака, муу (?), 15:09 , 13-Окт-20, (1)
При легальном использовании, можно посмотреть в сторону arp proxy При нелегально, DeerFriend (?), 15:44 , 13-Окт-20, (2)

Есть третья система, которая меняет влан у проходящего по ней пакета, этот пакет, Rom1 (??), 16:08 , 13-Окт-20, (3)

Сетевой bridge Или вы вы пытаетесь изобрести что-то принципиально новое Подробн, . (?), 16:14 , 13-Окт-20, (4)
Звучит как жуткий костыль, сочувствую А повлиять в сторону изменения топологии в, Licha Morada (ok), 20:29 , 13-Окт-20, (6)

Есть некий нагруженный трафиком бридж, который должен выпнуть в сторону необхо, Rom1 (??), 07:38 , 14-Окт-20, (8)

Вот этот нагруженный трафиком god-box выглядит хорошим кандидатом на реинжинерию, Licha Morada (ok), 20:09 , 14-Окт-20, (16)

gt оверквотинг удален Во первых, удостоверьтесь например, сниффером , что пак, Licha Morada (ok), 20:26 , 13-Окт-20, (5)

Всё так, пакет приходит на мою систему с чужим dstMACТак и сделал, поднял алиас,, Rom1 (??), 07:14 , 14-Окт-20, (7)

После таких формулировок следует пара выводов - либо афтар темнит в силу нелегал, Pahanivo (ok), 11:53 , 14-Окт-20, (9)

Я достаточно четко изложил _суть_ задачи, прочтите начало топика еще раз, Rom1 (??), 12:44 , 14-Окт-20, (11) –1

А форвардячее правило в случае смены мак адреса кто будет корректировать , DeerFriend (?), 12:27 , 14-Окт-20, (10)

Форвард по L3 же, Rom1 (??), 12:45 , 14-Окт-20, (12) –1

Это L3 , DeerFriend (?), 13:19 , 14-Окт-20, (13) +1

ОС его примет и маршрутизировать будет уже по L3, Rom1 (??), 18:31 , 14-Окт-20, (14)

Я, кажется, потерял нить Вы хотели принять пакет с чужим dst-MAC, и потом его ма, Licha Morada (ok), 19:47 , 14-Окт-20, (15)

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

1. Сообщение от муу (?), 13-Окт-20, 15:09 +/–

если сетевуха воткнута в свитч (коммутатор) то никак, тебе пакет для чужого мака туда не прилетит (за исключением броадкастов итп)

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

2. Сообщение от DeerFriend (?), 13-Окт-20, 15:44 +/–

При легальном использовании, можно посмотреть в сторону arp proxy.
При нелегальном будут дикие потери пакетов и у тебя и у жертвы.

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

3. Сообщение от Rom1 (??), 13-Окт-20, 16:08 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #4, #6

4. Сообщение от . (?), 13-Окт-20, 16:14 +/–

>> При легальном использовании, можно посмотреть в сторону arp proxy.
>> При нелегальном будут дикие потери пакетов и у тебя и у жертвы.
> Есть третья система, которая меняет влан у проходящего по ней пакета, этот
> пакет вылетает по этому влану и прилетает на мою систему, но
> мак-адрес назначения не как у моей системы, надо его принять и
> смаршрутизировать дальше.
Сетевой bridge? Или вы вы пытаетесь изобрести что-то принципиально новое?
Подробнее опишите зачем такие извращения?

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

5. Сообщение от 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

6. Сообщение от Licha Morada (ok), 13-Окт-20, 20:29 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #8

7. Сообщение от Rom1 (??), 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ообщить модератору
Родитель: #5 Ответы: #9, #10, #15

8. Сообщение от Rom1 (??), 14-Окт-20, 07:38 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #16

9. Сообщение от Pahanivo (ok), 14-Окт-20, 11:53 +/–

> Задача нестандартная и не укладывается в привычные рамки.
> Никакого спуфинга,все легально.
> Есть некий нагруженный трафиком бридж, который должен "выпнуть" в сторону необходимый трафик, не используя при этом "дорогостоящих" (читай классических) сетевых механизмов.
После таких формулировок следует пара выводов - либо афтар темнит в силу нелегальности затеи, либо он банально нифига не понимает что делает.
Может уже перейти к более вменяемому изложению задачи? А то совершенно непонятно зачем хватать отдельные пакеты, да еще идущие только в одну сторону.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #11

10. Сообщение от DeerFriend (?), 14-Окт-20, 12:27 +/–

> Но проблема другая, не хочется действий руками т.к. dstMAC может меняться.
А форвардячее правило в случае смены мак адреса кто будет корректировать?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #12

11. Сообщение от Rom1 (??), 14-Окт-20, 12:44 –1 +/–

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

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

12. Сообщение от Rom1 (??), 14-Окт-20, 12:45 –1 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #13

13. Сообщение от DeerFriend (?), 14-Окт-20, 13:19 +1 +/–

> 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ообщить модератору
Родитель: #12 Ответы: #14

14. Сообщение от Rom1 (??), 14-Окт-20, 18:31 +/–

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

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

15. Сообщение от Licha Morada (ok), 14-Окт-20, 19:47 +/–

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

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

16. Сообщение от Licha Morada (ok), 14-Окт-20, 20:09 +/–

>> Звучит как жуткий костыль, сочувствую.
>> А повлиять в сторону изменения топологии вашей сети вы можете?
> Есть некий нагруженный трафиком бридж, который должен "выпнуть" в сторону необходимый трафик,
> не используя при этом "дорогостоящих" (читай классических) сетевых механизмов.
Вот этот нагруженный трафиком god-box выглядит хорошим кандидатом на реинжинерию. А то он вам ещё немало крови попьёт.

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

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

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

3. Сообщение от Rom1 (??), 13-Окт-20, 16:08	+/–
> При легальном использовании, можно посмотреть в сторону arp proxy. > При нелегальном будут дикие потери пакетов и у тебя и у жертвы. Есть третья система, которая меняет влан у проходящего по ней пакета, этот пакет вылетает по этому влану и прилетает на мою систему, но мак-адрес назначения не как у моей системы, надо его принять и смаршрутизировать дальше.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #2 Ответы: #4, #6

4. Сообщение от . (?), 13-Окт-20, 16:14	+/–
>> При легальном использовании, можно посмотреть в сторону arp proxy. >> При нелегальном будут дикие потери пакетов и у тебя и у жертвы. > Есть третья система, которая меняет влан у проходящего по ней пакета, этот > пакет вылетает по этому влану и прилетает на мою систему, но > мак-адрес назначения не как у моей системы, надо его принять и > смаршрутизировать дальше. Сетевой bridge? Или вы вы пытаетесь изобрести что-то принципиально новое? Подробнее опишите зачем такие извращения?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #3

5. Сообщение от 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

6. Сообщение от Licha Morada (ok), 13-Окт-20, 20:29	+/–
> третья система, которая меняет влан у проходящего по ней пакета Звучит как жуткий костыль, сочувствую. А повлиять в сторону изменения топологии вашей сети вы можете?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #3 Ответы: #8

7. Сообщение от Rom1 (??), 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ообщить модератору
Родитель: #5 Ответы: #9, #10, #15

8. Сообщение от Rom1 (??), 14-Окт-20, 07:38	+/–
> Звучит как жуткий костыль, сочувствую. > А повлиять в сторону изменения топологии вашей сети вы можете? Есть некий нагруженный трафиком бридж, который должен "выпнуть" в сторону необходимый трафик, не используя при этом "дорогостоящих" (читай классических) сетевых механизмов.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6 Ответы: #16

9. Сообщение от Pahanivo (ok), 14-Окт-20, 11:53	+/–
> Задача нестандартная и не укладывается в привычные рамки. > Никакого спуфинга,все легально. > Есть некий нагруженный трафиком бридж, который должен "выпнуть" в сторону необходимый трафик, не используя при этом "дорогостоящих" (читай классических) сетевых механизмов. После таких формулировок следует пара выводов - либо афтар темнит в силу нелегальности затеи, либо он банально нифига не понимает что делает. Может уже перейти к более вменяемому изложению задачи? А то совершенно непонятно зачем хватать отдельные пакеты, да еще идущие только в одну сторону.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #7 Ответы: #11

10. Сообщение от DeerFriend (?), 14-Окт-20, 12:27	+/–
> Но проблема другая, не хочется действий руками т.к. dstMAC может меняться. А форвардячее правило в случае смены мак адреса кто будет корректировать?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #7 Ответы: #12

11. Сообщение от Rom1 (??), 14-Окт-20, 12:44	–1 +/–
> Может уже перейти к более вменяемому изложению задачи? А то совершенно непонятно > зачем хватать отдельные пакеты, да еще идущие только в одну сторону. Я достаточно четко изложил _суть_ задачи, прочтите начало топика еще раз
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #9

12. Сообщение от Rom1 (??), 14-Окт-20, 12:45	–1 +/–
> А форвардячее правило в случае смены мак адреса кто будет корректировать? Форвард по L3 же
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10 Ответы: #13

13. Сообщение от DeerFriend (?), 14-Окт-20, 13:19	+1 +/–
> 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ообщить модератору
Родитель: #12 Ответы: #14

14. Сообщение от Rom1 (??), 14-Окт-20, 18:31	+/–
> Это L3? ОС его примет и маршрутизировать будет уже по L3
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #13

15. Сообщение от Licha Morada (ok), 14-Окт-20, 19:47	+/–
Я, кажется, потерял нить. Вы хотели принять пакет с чужим dst-MAC, и потом его маршрутизировать на L3. Но, по вашим словам, пакет уже принимается как родной и маршрутизируется дальше, а проблема в том чтобы автоматизировать обработку смены этого чужого dst-MAC. В таком случае, имеет смысл собрать в одну кучу меры, которые вы принимаете вручную, и уже их автоматизировать, абстрагируясь от дебрей коммутации и раскурочивания пакетов. Что касается нестандартности задачи, это само по себе не криминал (а наша увлекательная реальность), но повод декомпонировать её на какие-то более или менее стандартные куски.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #7

16. Сообщение от Licha Morada (ok), 14-Окт-20, 20:09	+/–
>> Звучит как жуткий костыль, сочувствую. >> А повлиять в сторону изменения топологии вашей сети вы можете? > Есть некий нагруженный трафиком бридж, который должен "выпнуть" в сторону необходимый трафик, > не используя при этом "дорогостоящих" (читай классических) сетевых механизмов. Вот этот нагруженный трафиком god-box выглядит хорошим кандидатом на реинжинерию. А то он вам ещё немало крови попьёт.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #8