Jump to content
Калькуляторы

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

Обнаружилось, что с роутеров 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

Share this post


Link to post
Share on other sites
57 минут назад, vurd сказал:

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

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

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

 

Share this post


Link to post
Share on other sites

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

Покурите

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

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

 

 

Edited by TriKS

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
3 часа назад, vurd сказал:

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

 

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

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

Share this post


Link to post
Share on other sites
1 час назад, pvl сказал:

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

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

Share this post


Link to post
Share on other sites
3 часа назад, vurd сказал:

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

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

Share this post


Link to post
Share on other sites
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 порту.

Share this post


Link to post
Share on other sites
В 23.05.2020 в 12:53, [anp/hsw] сказал:

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

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

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

Share this post


Link to post
Share on other sites
7 часов назад, Ivan_83 сказал:

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

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

 

Share this post


Link to post
Share on other sites
16 часов назад, [anp/hsw] сказал:

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

Ты не прав.

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

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

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

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

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

Share this post


Link to post
Share on other sites
10 часов назад, Ivan_83 сказал:

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

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

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

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

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

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

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

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

Share this post


Link to post
Share on other sites
16 часов назад, [anp/hsw] сказал:

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

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

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

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

 

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

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

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

 

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this