Сделать из OpenWrt неуправляемый свитч + Wi-Fi

Зачем вообще openwrt то понадобился?

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

Со временем сеть сильно увеличилась, и этот девайс нужно сместить с authoritative на secondary/relay, вместо него будет стоять железка с немного бо́льшим количеством Ethernet-портов и значительно бо́льшим количеством сервисов и конечно же на FreeBSD.

Описанный выше режим бриджа/AP сейчас обычно в любом домашнем роутере есть и переключается парой кликов мыши с режима роутера.

Да, но шить обратно на сток во-первых геморно, во-вторых в случае обосрамса с сетапом вертать всё взад будет значительно более времязатратно.

Ох, теоретики…

надо будет покрутить яйца uHTTPd

Он по умолчанию слушает все адреса, а из вне закрыто файерволом. Который ты отключишь.

Поставь openwrt в виртуальную машину или eve-ng даже. И там изучай, если боишься сразу к железу лезть.

надо сказать, что там управляемый свитч уже стоит.

А мне нужен неуправляемый.

Как бы понятно что делать, вопрос только как.

Могу ещё посоветовать ютуб канал OneMarcFifty про openwrt. На английском

В последней разрешить всё и убрать masquerading. Так?

Сказали ж удалить!

На клиентах прилетит по dhcp сквозь мост. На сам роутер-мост, да, прописать дефолтный маршрут можно. Чтобы пакет ставить или диагностику до интернета запускать.

Он по умолчанию слушает все адреса

по умолчанию

Вот только я лично его натравил только на внутреннюю сеть. Не спрашивай зачем. (=

eve-ng

Я с "простеньким" OpenWrt разобраться не могу, а ты предлагаешь сложный комбайн. (=

Так сбрось в дефолт.

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

Могу ещё посоветовать ютуб канал OneMarcFifty про openwrt. На английском

У меня нет проблем с английским, но формат видеоуроков/лекций — совершенно не моё.

В последней разрешить всё и убрать masquerading. Так?

Сказали ж удалить!

Там выше разночтение eth0.1||eth0, потому я немного запутался.

На клиентах прилетит по dhcp сквозь мост.

На OpenWrt по умолчанию dnsmasq в authoritative, так что маршрут прилетит на сам роутер (если он клиент), но до клиентов, подключенных к этому роутеру, не дойдёт. По-хорошему dnsmasq надо перенастроить в режим релея (в крайнем случае — отключить?).

Ты в курсе, например, что роутеру, работающему как мост, ip адрес можно назначить вообще не из твоей сети и он будет работать как мост.

Теперь в курсе. Благодарю.

Конфигурация свича должна быть такой:

Так как таггинга на cpu порту свича теперь нет, то и 802.1q субинтерфейсы на eth0 не нужны.

В бридж br-lan надо собирать eth0 и wlan интерфейсы.

Адрес и маску на br-lan можно оставить статические, добавить статический дефолт маршрут через новый роутер. Либо получать адрес, маску, и маршрут по dhcp с нового роутера через br-lan.

Dnsmasq на точке доступа не нужен, она же не выделяет адреса и dhcp сервером не является. Адреса выделяет и является dhcp сервером новый роутер.

Точка доступа не маршрутизирует и не натит. Поэтому зоны файервола ей не нужны. Форвардинг IP пакетов она не делает, а только бриджует Ethernet кадры. Поэтому ей достаточно input правил файервола на br-lan.

не получится. Как ни вертись, он останется управляемым.

Не вижу смысла.

Ну, значит иы не просто не можешь держать нить беседы и забываешь что писали 5 сообщений назад, а ещё и злостно отстаиваешь такую манеру диалога, печально.

А давай ты не будешь мне рассказывать что я должен делать

А давай ты не будешь делать вид, что действительно хотел решить полезную задачу, а не просто покрасноглазить.

Он конечно же появится магическим образом, ага. xD

Он появляется из DHCP - клиент шлёт DHCP-запрос (широковещательный), он через мост транслируется до роутера, роутер отвечает правильными настройками сети.

NyXzOr, MagicMirror.

Удалил wan, wan6, добавил eth0.1 и eth0.2 в br-lan, отключил на br-lan DHCP и файерволл.

Трафик туда-обратно ходит, на роутер зайти больше не могу.

Почему в OpenWrt всё так сложно?!
Почему нужно пройти АдЪ с гачи-чертями (и всё равно ничего не добиться)?!

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

на роутер зайти больше не могу.

DHCP клиент и/или статический адрес хоть на один интерфейс добавил?

Разумеется. На бридж (ибо хрен знает как добавить dhcp-клиента на несуществующий wan) добавлена (дефолтная подсеть 192.168.1.1/24 была оставлена) дополнительная подсеть статикой, IP на основном маршрутизаторе закреплён за OpenWrt-роутером. Всё DHCP клиенты получают с основного, дефолтную подсеть сабжевого роутера добавил алиасом, но ни по одному IP болезный не пингуется (а пинги идут через основной, не смотря на то, что пингую с клиента, подключенного к вторичному).

На бридж

На интерфейс lan, в котором бридж?

дополнительная подсеть статикой

Не 192.168.1.0/24, другая?

пингую с клиента

На котором прописаны несколько ip?

добавлена (дефолтная подсеть 192.168.1.1/24 была оставлена) дополнительная подсеть статикой

Если ничего не помогает, то надо уже прочитать документацию - https://openwrt.org/docs/guide-user/network/wifi/wifiextenders/bridgedap#step_1change_the_lan_interface еще одна подсеть не нужна, достаточно было изменить адрес lan на 192.168.1.2/24,

На бридж

На интерфейс lan, в котором бридж?

Да.

дополнительная подсеть статикой

Не 192.168.1.0/24, другая?

Да. 172.16.0.2/24 (1 — основной маршрутизатор).

пингую с клиента

На котором прописаны несколько ip?

172.16.0.33 клиент получил автоматически по DHCP от основного, 192.168.1.112 (последнее, что давало на вторичном) прописано вручную в попытке достучаться до.

https://openwrt.org/docs/guide-user/network/wifi/wifiextenders/bridgedap#step_1change_the_lan_interface

Я эту статью уже наизусть выучил. И нет, это не документация, это именно хаутушка.

достаточно было изменить адрес lan на 192.168.1.2/24

Интересно, а кто ж у меня роутить из основной 172.16.0.0/24 будет? И нахрена? (=

Надеюсь, ты понимаешь, OpenWRT и неуправляемый свитч - это оксюморон?

Почему в OpenWrt всё так сложно?!
Почему нужно пройти АдЪ с гачи-чертями (и всё равно ничего не добиться)?!

• У вас хромает базовое знание сетей - понимание routing/forwarding, VLAN и т.п. В итоге вы пытаетесь выполнить действия, которые до конца не понимаете и излишне паникуете из-за этого.
• роутер проще настраивать с подключенной консолью - для этого вскрывают корпус и припаивают к плате tx/rx/gnd (часто под них завод даже место оставляет). Сейчас бы просто подключились к нему и посмотрели - какой там в итоге адрес висит на интерфейсе br-lan и при необходимости сменили бы конфигурацию на корректную. А без консоли будете по несколько раз в дефолт сбрасывать в случае ошибки.
• openwrt разработчики толком ничего сами не тестируют и не тюнят под большую часть устройств - базово если завелось, то считается, что работает. Правда это к данном вопросу про режим бриджа отношения не имеет, это все же больше про стабильность/производительность драйверов речь.

Взять imagebuilder и выкинуть всё ненужное, как то примерно так:

make image PROFILE=имя_роутера PACKAGES="-dnsmasq -odhcp6c -odhcpd -odhcpd-ipv6only -ppp -ppp-mod-pppoe"

и отключать уже будет почти ничего не нужно.

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

Проблемы с самим железом могут оказаться, а больше никаких проблем нет. Т.е. либо у вас карточка в bridge заработает либо не заработает. Сейчас полно дешмань и не только дешмань софт вариантов карточек.

Просто отключаешь сервер DHCP на роутере и он превращается в хаб свитч.

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

Эта проблема с режимами работы к домашним роутерам (не самосборным из палок и интел чипов клиентских) отношения не имеет, т.к. в них никто не ставит чипы, которые не умеют работать в режиме точки доступа - это их основной функционал. С wifi же проблемы начинаются, когда пытаются использовать нестандартные режимы типа репитера (их вендоры костылями реализуют из-за особенностей wifi - используется 3 адреса, а для полной информации нужно 4).

У вас хромает базовое знание сетей

Я и не утверждал что я хоть как-то сетевик. (=

routing/forwarding

Это понимаю, но с routing до сих пор голова кругом.

VLAN

Тут — да, понимания вообще нет.

В итоге вы пытаетесь выполнить действия, которые до конца не понимаете и излишне паникуете из-за этого.

Я паниковал не из-за непонимания, а из-за того, что юзеры заклюют, если у них не будет интернета хоть сколько-то заметное время. Если бы можно было погрузиться (что я и сделал в итоге, откопав какой-то дешманский роутер, и настроив его чтобы просто был интернет) и вдумчиво разбираться — никаких проблем. А изначально нужно было херак-херак и в продакшн быстро.

роутер проще настраивать с подключенной консолью

Для этого надо разбирать, паять, искать провод, искать как его подключить…

А без консоли будете по несколько раз в дефолт сбрасывать в случае ошибки.

Так и было. (=

openwrt разработчики толком ничего сами не тестируют

У меня изначально складывалось такое впечатление. Причём местами даже нет согласования компонентов между собой.

Итак, решение!

• Network→Interfaces:
  • Вкладка Interfaces:
    • lan сделан DHCP-клиентом
    • wan и wan6 переключены в Unmanaged
  • Вкладка Devices:
    • В br-lan в Bridge ports указаны два VLANа: eth0.1 (LAN-порты) и eth0.2 (WAN-порт).

Сначала поделить свитч на два vlan-а, а потом сбриджевать эти vlan-ы на cpu. Шизофрения какая-то.

В br-lan в Bridge ports указаны два VLANа: eth0.1 (LAN-порты) и eth0.2 (WAN-порт).

Если вышестоящий роутер подключен в WAN порт (VLAN2), то трафик на LAN порты (VLAN1) будет идти не напрямую через свич на аппаратном уровне, а через CPU и обрабатываться софтварно. В итоге ресурсы CPU будут расходоваться впустую - так бы они расходовались только для пересылки трафика между WAN и WiFi. Как правильнее сделать писали здесь - Сделать из OpenWrt неуправляемый свитч + Wi-Fi (комментарий). Т.е. должен внутри свича существовать единственный VLAN, у которого все порты нетегированные. На CPU софтварный VLAN (eth0.1) нет смысла создавать, т.к. это опять-таки лишнее действие при обработке трафика будет - снимать и навешивать теги.

В гайдах по openwrt это описано здесь https://openwrt.org/docs/guide-user/network/wifi/wifiextenders/bridgedap#step... Надо только разобраться, как это должно быть реализовано под конкретную версию и конкретный девайс, т.к. могут быть разные варианты отображения портов в Linux (в любом случае все они должны быть сбриджованы вместе с WLAN интерфейсом):

• Все порты на одном интерфейсе - eth0
• LAN порты на eth0, WAN порт на eth1
• У каждого порта - свой интерфейс - eth0, eth1, eth2, eth3, eth4.

В любом случае вам все уже расписали, дальше только посидеть, понастраивать и разобраться. С подключенной консолью это было бы проще, конечно. Если не готовы разбираться, то тогда openwrt не для вас, т.к. это все-таки не готовая ОС, а скорее конструктор, где по умолчанию много нюансов не учтено и много железа полноценно не поддерживается. Но с другой стороны, если вендор прекратил поддержку устройства или там нет необходимого функционала, то использование openwrt может быть оправданным.

Ну ТС же честно признался, что не понимает VLAN совсем. Хотя без этой базы я бы вообще осторожно связывался с администрированием сетей, да и не так сложно с этим разобраться.

Сначала поделить свитч на два vlan-а

При удалении vlan2 (тот, что висел на WAN) сеть отваливается наглухо.

Как правильнее сделать писали здесь

Сделать из OpenWrt неуправляемый свитч + Wi-Fi (комментарий)

В гайдах по openwrt это описано здесь

В первую очередь им руководствовался, но либо там что-то упущено, либо я что-то не так понял, в итоге сеть отвалилась и пришлось делать ресет.

• Все порты на одном интерфейсе - eth0

Это мой случай.
Но изменение портов приводило к результату, описанному выше.

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

Теперь, когда есть бэкап рабочей (пусть и не идеальной) конфигурации, можно будет и поэкспериментировать на досуге.

С подключенной консолью это было бы проще, конечно.

Вероятно. Но у меня лапки.

Если не готовы разбираться, то тогда openwrt не для вас, т.к. это все-таки не готовая ОС, а скорее конструктор, где по умолчанию много нюансов не учтено и много железа полноценно не поддерживается.

Под это описание не только OpenWrt, но и Linux в целом подходит. (= С железом сильно лучше чем во FreeBSD, но операционной системой Linux как никогда не был, так никогда и не станет, по причине XKCD#927. (=

Но с другой стороны, если вендор прекратил поддержку устройства или там нет необходимого функционала, то использование openwrt может быть оправданным.

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

Дома на Linux только три тачки: сабжевый роутер на OpenWrt, виртуалка с Debian для Stable Diffusion (потому что в pip под FreeBSD ничего нет, надо компилять вручную, я не хочу этим заниматься), и Android-смартфон (который уже глючит и скоро будет заменён на что-нибудь яблочное или в крайнем случае кнопочное).

Ну ТС же честно признался, что не понимает VLAN совсем. Хотя без этой базы я бы вообще осторожно связывался с администрированием сетей, да и не так сложно с этим разобраться.

Я обязательно с этим разберусь. Но уже не на OpenWrt. (=