Странные mac-и на wan интерфейсах tp-link archer c6

[vurd]

Обнаружилось, что с роутеров archer c6, установленных в разных сегментах сети, на wan интерфейсе иногда генерятся фреймы с маками удивительно похожими один на другой. Выглядит это так

 

Сегмент 1

62:65:AA:AA:BC:81

 

Сегмент 2

5A:23:AA:AA:BC:81

 

Сегмент 3

B6:E0:AA:AA:BC:81

B6:E0:AA:AA:BD:01

 

Это так называемый locally administered address, для назначения административно.
x2-xx-xx-xx-xx-xx
x6-xx-xx-xx-xx-xx
xA-xx-xx-xx-xx-xx
xE-xx-xx-xx-xx-xx

В первом октете адреса установлен бит, и он во всех трех случаях возведен в 1-у, т.е. штука явно сделана специально и правилам.

 

Маки появляются одинаковые, со всех роутеров в сегменте, иногда это происходит одновременно, иногда нет. В момент единовременного появления коммутатор детектирует "mac moving", в моём случае это приводит к блокировке порта в сторону абонента. Различие только в первых двух байтах. Т.е. если увезти роутер в другой сегмент, то он примет "его правила". Видимо работает калькуляция хеша в зависимости от адресации в сегменте.

 

Встав снифером в сегменте (не зеркало порта, просто в домене), удалось поймать крайне странного содержания фрейм.

В нем находится реальный пакет, отправленный из внешнего мира в сторону клиента, но! в L2 части пакета видно, что отправителем является сам клиент, а получателем неизвестный и неизученный мак-адрес (благодаря чему его и удалось соснифать), я полагаю, что это мак машины клиента расположенный за роутером. Т.е. я думаю, что пакет был отрефлекчен в аплинк.

 

Что это за НЁХ? Не сталкивался ли кто?

 

P.S. В интернете только один поляк в лице пользователя с archer c7 столкнулся с подобным.

P.P.S. В tplink запрос отправлен.
 

2020-05-22-strange-mac-tplink.pcap

[[anp/hsw]]

57 минут назад, vurd сказал:

неизвестный и неизученный мак-адрес

Он не просто неизвестный и неизученый, а еще и ни за кем не закреплен. OUI lookup на 14:6c:00 ничего не дает.

Скорее всего это бага кода hwnat или чего-то подобного: кроме стека linux, только там может происходить такое преобразование.

 

[TriKS]

Я вам больше скажу. Некоторые девайсы могут по дефолту блочить данные адреса, т.к. они могут лить трафик мимо portprotect. BDCOM ОЛТ например.

Покурите

https://local.com.ua/forum/topic/111928-bdcom-3608-трафик-между-онушками-непредсказуемо-зеркалируется/?tab=comments#comment-1268169

https://local.com.ua/forum/topic/113049-клиент-всегда-неправ/

 

 

Edited May 22, 2020 by TriKS

[vurd]

dst-mac не является вопросом, т.к. он не создает никаких проблем. Ну да, unkown, пофиг ваще.

[straus]

1 час назад, pvl сказал:

Роутеры с mac адресами 08-C6-B3-xx-xx-xx через WAN  порт раздают IP адреса по протоколу DHCP  всем желающим. В arp порт WAN с внешним белым IP виден ещё и как 192.168.1.1

Учитывая, что в домашних роутерах WAN-порт обычно выделяется при помощи vlan во внутреннем свитче - напрашиваются мысли.
 

[TriKS]

3 часа назад, vurd сказал:

dst-mac не является вопросом, т.к. он не создает никаких проблем. Ну да, unkown, пофиг ваще. 

Сори, читнул по диагонали ваш пост.

[[anp/hsw]]

19 часов назад, pvl сказал:

Роутеры с mac адресами 08-C6-B3-xx-xx-xx через WAN  порт раздают IP адреса по протоколу DHCP  всем желающим.

Тоже встречал, но висячий ACL на доступе проблему решает.

19 часов назад, pvl сказал:

В arp порт WAN с внешним белым IP виден ещё и как 192.168.1.1

Так вообще всегда на роутерах было, все поголовно забывают про rp_filter на wan порту.

[Ivan_83]

В 23.05.2020 в 12:53, [anp/hsw] сказал:

Так вообще всегда на роутерах было, все поголовно забывают про rp_filter на wan порту.

rp_filter - дебильная фигня, которая обычно мешается. Как минимум мультикасту, потому что линуксойды никак не добавят его в исключения rp фильтра.

Я бы предположил рукожопство вендора в части аппаратного нат или правил фаера, но и косяка с не конфигурацией портов свич чипа в разные вланы тоже не исключаю.

[[anp/hsw]]

7 часов назад, Ivan_83 сказал:

rp_filter - дебильная фигня, которая обычно мешается. Как минимум мультикасту, потому что линуксойды никак не добавят его в исключения rp фильтра.

Это исключительно проблема криворукости настройщика. Достаточно добавить роут для мультикаста по самой широкой маске в нужный интерфейс, чтобы rp_filter его пропустил. Собственно, это и будет вашим "добавлением исключения".

 

[Ivan_83]

16 часов назад, [anp/hsw] сказал:

Это исключительно проблема криворукости настройщика. Достаточно добавить роут для мультикаста по самой широкой маске в нужный интерфейс, чтобы rp_filter его пропустил.

Ты не прав.

Это проблема кривого RP фильтра.

1. Мультикаст, как и броадкаст - не маршрутизируется и если он тебе прилетел то ты так или иначе валидный получатель.

2. Если ты не знал, то приложение может джойнится к мультикаст группам НА РАЗНЫХ интерфейсах ОДНОВРЕМЕННО, API линукса и фри и может других ОС это позволяет делать.

https://github.com/rozhuk-im/ssdpd

можно указать любые интерфейсы, ему плевать на то какие кто там маршруты для мультикаста нарисовал. msd работает аналогично - джойнится на указанном интерфейсе.

[[anp/hsw]]

10 часов назад, Ivan_83 сказал:

1. Мультикаст, как и броадкаст - не маршрутизируется и если он тебе прилетел то ты так или иначе валидный получатель.

Вот сейчас бред был. Зайди в любую ethernet-сеть крупного оператора, и посмотри, сколько там broadcast и multicast трафика тебе неподредственно не предназначеного. А еще мультикаст маршрутизируется (хотя это и довольно редкий случай, DVMRP уже забыт), для этого есть mrouted.

10 часов назад, Ivan_83 сказал:

2. Если ты не знал, то приложение может джойнится к мультикаст группам НА РАЗНЫХ интерфейсах ОДНОВРЕМЕННО, API линукса и фри и может других ОС это позволяет делать.

Если ты не знал, то маршрут до одной и той же сети может быть более, чем на одном интерфейсе. И это нормально.

10 часов назад, Ivan_83 сказал:

ему плевать на то какие кто там маршруты для мультикаста нарисовал. msd работает аналогично - джойнится на указанном интерфейсе.

Зацепиться на raw socket - много ума не надо. Только правильный ли это путь при наличии всех инструментов в сетевом стеке?

[Ivan_83]

16 часов назад, [anp/hsw] сказал:

Вот сейчас бред был. Зайди в любую ethernet-сеть крупного оператора, и посмотри, сколько там broadcast и multicast трафика тебе неподредственно не предназначеного. А еще мультикаст маршрутизируется (хотя это и довольно редкий случай, DVMRP уже забыт), для этого есть mrouted.

Маршрутизация мультикаста - это для извращенцев-любителей.

Поинт в том, не нужен ли тебе тот трафик который ты получил а в том что широковещательный трафик предназначен всем.

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

 

16 часов назад, [anp/hsw] сказал:

Если ты не знал, то маршрут до одной и той же сети может быть более, чем на одном интерфейсе. И это нормально.

Раз ты любитель маршрутизации, покажи как на разных интерфейсах работать с одним и тем же мультикаст адресом только задроствуя с маршрутизацией :)

 

16 часов назад, [anp/hsw] сказал:

Зацепиться на raw socket - много ума не надо. Только правильный ли это путь при наличии всех инструментов в сетевом стеке?

Это не raw сокет, в том то и дело, это "высокоуровневое" самой ОС, и ОС сама при этом правильно организует работу IGMP.

И с точки зрения ОС приджойнится к одной и той же мультикаст группе на разных интерфейсах - валидная и обычная операция.

Таблица маршрутизации в данном случае аттавизм/костыль.

А RP фильр - поделие кривых ***ов.

[vurd]

Через 4 года разгадал как генерируется этот замечательный src-mac.

 

мак шлюза 5C:54:6D:43:4C:C8
мак петли 4C:C8:AA:AA:BD:01

 

мак шлюза 5C:54:6D:43:4C:C6
мак петли 4C:C6:AA:AA:BD:01

 

Вариации остальных 4 байт следующие

:AA:AA:BD:01
:AA:AA:BE:41
:AA:AA:BE:81
:AA:AA:BC:81

 

[Дегтярев Илья]

А можно снова выложить  2020-05-22-strange-mac-tplink.pcap ?

а то по ссылке в 1 посте не открывается.