MAC addr устройсва

никак
/thread

Переключить китайский зюзероутер в режим ната и присвоить его внешнему интерфейсу мак нужного устройства.

Выше уже ответили - никак. Объясню - для «видимости» MAC-адресов тебе необходим общий MAC-уровень всей сети (один общий L2 сегмент). Этого можно добиться использованием bridge на втором «внутреннем» роутере, чтоб все его порты и беспроводная сеть была одним бриджём, тогда все фреймы L2 будут свободно гулять в нужном направлении и первый роутер будет видеть все хосты. Естественно, в таком варианте, необходимо иметь только один DHCP-сервер и будет общая L3 подсеть (айпишники из одной подсети). Можно заморочиться и в пределах одного L2 разделить на несколько L3 с фильтрами, но гемора значительно больше. Ну и естественно, на официальных прошивках такого нет, по-крайней мере, WAN порт никогда не объединяют в бридж со всеми остальными интерфейсами, так что решать придётся при помощи openwrt или других неофициальных прошивок.

ЗЫ. Самый простой способ, воткнуть шнурок от первого роутера в LAN порт второго и на втором отключить DHCP-сервер (должен остаться только DHCP-сервер на первом роутере). Соответственно WAN порт второго роутера остаётся висеть в воздухе неиспользованным. Это если нет возможности перепрошить второй роутер и не принципиально использование WAN.

спасибо))

Ну и естественно, на официальных прошивках такого нет, по-крайней мере, WAN порт никогда не объединяют в бридж со всеми остальными интерфейсами

Это вы маху дали. Именно так Vlan-ы, скажем для IPTv и делаются - WAN отдаёт vlan бриджем в определенный порт.

Кстати говоря почему «никак»? Если все находится в одной сети, скажем 192.168.135.0/24 то получив пакет от устройства роутер (2) видит что роутер (3) в одной сети с ним, и поставит в пакет MAC отправителя. Так почему iptables не должен работать?

Давайте не будем в тонкости вдаваться. Читать полноценную лекцию о разном внутреннем устройстве разных роутеров ни времени ни средств не хватит.

А так, всё зависит от внутреннео устройства SOC и организации роутера. На некоторых WAN/LAN разделение исключительно 802.1q средствами реализовано (коммутатор 6-портовый, один порт в сторону процессора, 5 портов наружу, а дальше любой порт конфигурируй как хочешь), на некоторых с процессорной стороны 2 ethernet порта, на которые уже можно вешать разные коммутаторы, какие захочешь (привет, mikrotik).

Но всё завязано на официальную прошивку конкретного вендора. А они всё делают по стандартной схеме разделения WAN/LAN и в большинстве случаев бытовых приборов до изменения этой конфигурации без перепрошивки/хаков не добраться.

ЗЫ. Насчёт IPTV, тоже зависит от конфигурации SOC, т.к. в случае с 6-портовым коммутатором этот самый коммутатор и занимается перенаправлением потоков, процессор только регистры дёргает для этого. А в случае с SOC с двумя ethernet портами нужен отдельный демон в OS системы для перенаправления между портами хост-системы. Именно поэтому на некоторых роутерах с дохлым CPU так плохо работает IPTV. Ну я не рассматриваю вариант «китайской» прошивки или «китайского производства», в которой для первого случая используют демон, когда есть возможность всё разрулить аппаратно - там всё и так понятно.

Изучите модель OSI, MAC передаётся только в пределах одного L2 уровня, дальше при маршрутизации по цепочке виден только MAC порта маршрутизатора с которого посылается фрейм.

Представьте себе квартиру с 2 комнатами, в каждой комнате разное количество человек, которые слышат друг друга в пределах одной комнаты, но не слышат людей из другой комнаты, а в дверном проёме стоит такой же человек, но который может говорить с любым человеком из любой комнаты. Он может передавать сообщение от человека 1й комнаты человеку во-второй. Но при этом человек во-второй будет слышать голос человека в проёме. Вот упрощенно, голос человека в проёме - это MAC-адрес, но это не значит, что человек в проёме не может сказать, что сообщение от условного Васи (IP-адрес) из 1й комнаты направлено Ане во-второй комнате.

Представьте себе квартиру с 2 комнатами, ...

Отлично написано! Вам книги надо писать аля «osi для дураков».

Отлично написано! Вам книги надо писать аля «osi для дураков».

Иногда упрощения для дураков создаются только для того, чтобы:

1. Зарабатывать при написании об этом книг

2. Зарабатывать на консалтинге, так как начитавшись все вокруг такой литературы у пользователей не получается никак решить задачу чуть сложнее.

Ведь в жизни встречается всякое. И прокинуть MAC во внутрь сети — proxy-arp, и dhcp релеить надо, и одновременно делать маршрутизатор и коммутатор в одном лице (да да, это я на свою статью тут недавно опубликованную намекаю).

Допустим есть такая схема сети:

(1) OpenWRT роутер с включенным DHCP. Все пользователи подключенные на его LAN портах, и через Free wifi сеть, имеют одну и туже подсеть 192.168.115.0/24 и проходят авторизацию (редирект трафика через iptables на локальный сервер этого роутера с дальнейшей переадресацией на сервер в интернете)

В его LAN порты втыкаются другие роутеры (2), но в режиме свича: 4-порта ethernet и 802.11. Пользователи подключающиеся на (2) так-же проходят авторизацию.

По сути (2) роутеры представляют собой ethernet-wifi комутаторы.

То есть вся сеть связана на link уровне, у них одна подсеть, и есть только один gate way и dhcp сервер.

И теперь если устройство отправляет пакеты в интернет, то к шлюзу она обратится напрямую или нет?))

Именно так. Фрейм от клиента беспроводной сети прозрачно добежит до главного роутера. Как ему бежать определяет таблица коммутации. Свитч/коммутатор всегда хранит таблицу соответствия MAC-адреса назначения и порта (на самом деле полностью MAC никто не хранит, ибо быстрая память очень дорога, поэтому используют хеши), и при получении фрейма на одном из портов, коммутатор проверяет таблицу и посылает фрейм только в тот порт, куда указывает таблица коммутации. В линуксе bridge-интерфейс тоже представляет собой программный коммутатор, в котором каждый добавленный системный интерфейс выступает портом и используя bridge-utils (brctl) можно посмотреть где какие MAC-адреса находятся относительно этого бриджа. Ну и там есть свои дополнительные условия по добавлению интерфейсов в бридж, интерфейс и его драйвер должны уметь менять MAC-адрес источника для прозрачной коммутации и уметь работать в режиме promisc (неразборчивый, то есть получать абсолютно все пакеты L2 уровня).

Раньше было различие в устройствах у вендоров - точка доступа и маршрутизатор/роутер. Вот точка доступа продавалась, как правило, с одним ethernet-портом и вай-фаем, и была абсолютно прозрачной на L2 уровне. В маршрутизаторе просто добавили собственно маршрутизацию в виде «внешнего» WAN-порта, под которым всех клиентов этого роутера видно. То есть soho-роутер это точка доступа в бридже с LAN-портами и непосредственно маршрутизатор между бриджом и WAN-портом, плюс для удобства фаервол, dhcp-сервер и прочие плюшки.

Я настроил сеть именно так, и теперь все работает) Спасибо за объяснение)

Спасибо, но написание книг и прочее я оставляю на будущую старость, если доживу :)

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

По-поводу proxy-arp, ещё в 2004-2005 годах именно по такой схеме строил сеть/пионернет. Логика была в следующем - разделить broadcast домены между собой, т.к. в те времена winXP из коробки у клиентов очень сильно болела заражениями по локальной сети через NetBios, вот приходилось хоть как-то купировать болезнь дешёвыми средствами.

По-поводу proxy-arp, ещё в 2004-2005 годах именно по такой схеме строил сеть/пионернет.

Напомнили, я несколькими годами раньше так же пионерил с proxy-arp что бы белые C-ки на куски не рубить. Начинали по простому, клиент с привязкой к мак :)

Иногда упрощения для дураков создаются только для того, чтобы:

Но иногда они бывают полезными совместно с оф. документацией. Во всяком случае в моей практике один раз было именно так, при изучении mac os x сервера, всякой отвлекающей ерунды в книге для дураков конечно хватает, но и полезное там есть. Правда я бы назвал это исключением из правил, тот самый момент когда хорошей документации очень мало.