Подключен интерфейс ether1/wlan1 (режим станции, без WDS).

Ну, у роутера статический IP, а клиент, подключенный к ether1, это клиент на XP в режиме DHCP.

Станция без WDS не может быть бриджена. Изучайте IEEE 802.11. Точка.

Ну, да, если мы говорим о "мосте" в традиционном смысле, вы правы. Без WDS это невозможно. Собственно, это и есть главная причина существования WDS. Однако, на рынке существует масса устройств (от компаний, как, например, этой и этой, например, это устройство), которые делают то, что вы утверждаете, невозможно. По моему опыту, они обычно решают проблему мостинга 802.11 одним из двух способов: они "зацепляются" за первый MAC-адрес, который видят на своем ethernet-порте, и "притворяются" этим MAC на своем беспроводном интерфейсе (при подключении к точке доступа и т.д.). Обычно устройства, которые делают это так, могут мостить только ОДНО ethernet-устройство через беспроводное соединение. Они подключаются к точке доступа, используя свой собственный MAC, и переписывают адрес источника MAC в любом ethernet-фрейме, генерируемом устройствами, подключенными к его ethernet-порту, чтобы он соответствовал его собственному MAC. (Чтение: MAC-NAT). Эти устройства обычно могут мостить фиксированное количество ethernet-устройств через беспроводное соединение. Эти виды "мостов" способны разбираться, какой входящий трафик на беспроводном интерфейсе следует отправлять на какой MAC на его ethernet-интерфейсе, поддерживая внутренние таблицы для разных видов трафика. Например, большинство поддерживают таблицу IP → MAC (возможно, полученную путем наблюдения за ARP-ответами от устройств, подключенных к его ethernet-порту?) для входящего IP-трафика, и я знаю некоторые устройства, которые поддерживают таблицу PPPoE Host-Uniq → MAC, которая использует тег Host-Uniq, отправляемый в пакетах PPPoE-Discovery, чтобы позволить мостинг нескольких PPPoE-туннелей между 802.11 и ethernet-интерфейсом. Когда я впервые увидел новый параметр MAC-NAT в разделе Bridge Firewall в 2.9, я подумал, что смогу использовать эту функцию, чтобы воспроизвести функциональность 802.11 ↔ ethernet-мостов, подобных описанным выше, но у меня не получилось. Теоретически, это должно быть технически возможно с помощью MAC-NAT, если только MikroTik не решила в своем коде игнорировать любой и весь трафик, поступающий или предназначенный для беспроводного интерфейса, установленного в режиме "station". Если они это сделали, я вежливо попрошу их удалить это искусственное ограничение в своем коде моста, чтобы те, кто хотел бы или даже нуждался в возможности построить MAC-NAT "мост" через 802.11-соединение без WDS, могли это сделать. Если они этого не сделали, и кто-нибудь другой смог успешно создать правила MAC-NAT на своем мосту MikroTik, включающие 802.11-интерфейс в режиме "station", не смог бы этот кто-нибудь любезно опубликовать, в качестве примера, свою рабочую конфигурацию? – Nathan

Вот что я и пытался сделать (безуспешно). Просто MAC-NAT bridge для одного MAC. В списке действий NAT для моста нет "masquerade". Ну да, MikroTik заявили (хотя я и не помню где… может, видел в документации), что MAC-NAT полностью без сохранения состояния, потому что в их реализации нет никакого трекинга соединений. И если бы он был, то это не создало бы настоящий мост, все пакеты были бы NAT’д за одним MAC. Я уже признал это ограничение, когда сказал, что это не настоящий мост. Просто кажется проще использовать WDS. …кроме случаев, когда ты пытаешься подключить MikroTik CPE к AP, который НЕ поддерживает WDS и/или не находится под твоим контролем, и тебе (по какой-то причине) не хочется маршрутизировать на самом MikroTik CPE. Есть веские причины для необходимости этой функции. Тот факт, что это не настоящий мост, не означает, что он не имеет своего места и не ограничивает его полезность в таких ситуациях. – Nathan

DirectWireless, возможно, ваш DHCP-сервер настроен на отправку ответов только на широковещательные MAC-адреса? Может, широковещательный трафик проходит через station-mode bridge без проблем… – Nathan

Итак, наконец-то у меня заработал 1-в-1 MAC-NAT практически полностью! Я толком не понимаю, что именно я сделал по-другому на этот раз, потому что, кажется, я пытался сделать точно то же самое и раньше, но, в общем, получилось. Единственное условие — в этот же момент я смог проверить свою теорию о вопросе DHCP от DirectWireless: ваш DHCP-сервер должен иметь установленный параметр "always-broadcast" в значение "yes" (если это DHCP-сервер MikroTik… используйте эквивалентный параметр на том, что используете вы, если это не MikroTik), чтобы DHCP успешно работал через "мост", даже при MAC-NAT правилах. Когда я отключаю эту опцию "always-broadcast", DHCP-сервер видит ЗАПРОС, отправляет ПРЕДЛОЖЕНИЕ, но клиент никогда его не видит и просто продолжает отправлять ЗАПРОС за ЗАПРОСОМ бесконечно. (Я, честно говоря, не уверен, почему так, хотя, возможно, дело в том, что MAC DHCP-клиента включен в полезную нагрузку DHCP-пакета в дополнение к заголовку ethernet-кадра, и в ситуации MAC-NAT эти значения не будут совпадать, потому что MAC-NAT меняет исходный адрес только в заголовке кадра. DHCP-сервер, вероятно, отправляет ответ обратно в unicast на MAC, встроенный в DHCP-запрос, вместо исходного MAC-адреса в соответствии с заголовком ethernet-пакета. Просто догадка). Кроме того, ARP, похоже, не передается через "мост" правильно. Есть своего рода обходной путь, который я покажу в своем примере (ниже), но вам придется знать MAC-адрес вашего шлюза и статически прописать его в CPE MikroTik. Если MAC шлюза изменится, вам придется менять правило NAT для всех клиентов, настроенных таким образом. Также, как уже обсуждалось, нет опции "masquerade", поэтому с помощью этой техники можно "перемостовать" только один ethernet MAC через беспроводное соединение. Так что все это позволит вам лишь перенести маршрутизацию с MikroTik на устройство, подключенное к ethernet MikroTik. Вы не сможете подключить коммутатор с кучей устройств к нему. Ну, давайте перейдем к примеру. Вот что я сделал:

/ interface bridge
add name="bridge1"

/ interface bridge port
add interface=wlan1 bridge=bridge1
add interface=ether1 bridge=bridge1

/ interface bridge nat
add chain=srcnat src-mac-address=00:11:22:33:44:55/FF:FF:FF:FF:FF:FF \
   action=src-nat to-src-mac-address=00:55:44:33:22:11
add chain=dstnat dst-mac-address=00:55:44:33:22:11/FF:FF:FF:FF:FF:FF \
   action=dst-nat to-dst-mac-address=00:11:22:33:44:55
add chain=dstnat mac-protocol=arp arp-opcode=request \
   arp-src-mac-address=00:11:22:33:44:55/FF:FF:FF:FF:FF:FF action=arp-reply \
   to-arp-reply-mac-address=00:77:77:77:77:77

Где:
00:11:22:33:44:55 == MAC ethernet-устройства, которое вы хотите передать
00:55:44:33:22:11 == MAC беспроводного интерфейса в режиме "station"
00:77:77:77:77:77 == MAC шлюза для вашей IP-подсети, который находится за пределами AP, к которому вы подключаетесь.

Первые два правила должны быть довольно понятны. Третье правило MAC-NAT говорит о том, что если ethernet-устройство отправляет ARP-запрос, который транслируется через мост, то автоматически генерируется ответ на это устройство локально на CPE MikroTik. Если вы этого не сделаете, вам придется добавить статическую ARP-запись на устройство, подключенное к MikroTik через ethernet (что тоже работает отлично). Интересно, что PPPoE работает отлично через этот псевдо-мост, даже несмотря на то, что unicast DHCP и ARP не работают. Что и говорить. Очевидно, если вы используете PPPoE, вам не нужна rule NAT для автоматической генерации ответов для ARP-запросов.

Надеюсь, это поможет, – Nathan

Что мешает пакетам PPPoE нормально объединяться в мост? И как это делает его псевдо-мостом, если вы уже используете мостинг?

Я не понимаю, почему так много людей хотят подобную ерунду. Потому что бывают моменты, когда это лучший способ выполнить задачу. А что, если вам просто нужно создать "повторитель сигнала", чтобы ретранслировать сигнал для 2-3 компьютеров… это можно легко сделать с Tranzeo CPE, подключенным к любому готовому AP, но не с Mikrotik… Я использую WDS в своей сети для создания мостовой станции для PPPoE-клиентов, но у этого есть существенные недостатки. С обычной (не-WDS) станцией можно отключить пересылку на AP, предотвращая создание людьми собственных сетей внутри вашего AP. При использовании WDS вам приходится добавлять станцию в мост, что обходит изоляцию, создаваемую отключением пересылки, и тем самым увеличивает влияние трафика широковещания на вашу сеть. Это также использует дополнительную мощность процессора на AP, и когда вы используете RB500 или WRAP платы для ваших AP, у вас мало процессорной мощности, которую можно потратить впустую… так что WDS может быть правильным способом мостинга через станцию к AP, если вы пытаетесь мостить только для PPPoE-трафика, это не "правильный" способ, потому что вы фактически ухудшаете производительность вашей сети, позволяя дополнительный и совершенно ненужный трафик широковещания, а также подвергаете ваших клиентов потенциальным атакам от других клиентов на том же AP. Мы знаем, что мостинг не работает в соответствии со стандартами 802.11 без WDS, но WDS — это не самое лучшее решение для каждой ситуации Z(и, как многие люди отметили, иногда это даже не вариант)… нарушение стандарта, чтобы разрешить мостинг даже к максимуму 1 машинам на Ethernet-порту, определенно имеет свое место и должно быть добавлено как опция, без необходимости проходить через серию сложных правил bridge-nat, которые приходится вручную переписывать каждый раз, когда меняется MAC-адрес клиента. Что следует добавить, это bridge-nat-srcnat, который динамически использует первый MAC-адрес для NAT'а, и будет переназначаться, если он не видит трафика от этого MAC в течение X минут (чтобы избежать необходимости перезагрузки после изменения устройства, которое MAC-NAT'ится).

И чтобы все остальные ребята поставили свои сетевые адаптеры в режим "прожорливости" и читали мой трафик? Спасибо, не надо.