Что такое br lan
Есть машинка TL-WR941ND с OpenWRT на борту.
Сейчас раздает Интернет с WAN на WiFi и ETH1-ETH4
Хочется сделать бридж между WiFi и ETH при этом
WiFi должна быть в режиме клиента (т.е. хочу просто подключить её ethernet клиентов к WiFi)
Пробовал:
/etc/config/dhcp
config dhcp lan
option ignore 1
Для того чтобы отключить dhcp
/etc/config/network
Для lan просто выставил статический ip из своей WiFi сетки
/etc/config/wireless
Исправил секцию
config wifi-iface
option 'device' 'radio0'
option 'network' 'lan'
option 'mode' 'sta'
option 'ssid' '*****'
option 'encryption' 'psk2'
option 'key' '*****'
Наивно полагал что заработает, но даже lan не отвечал на сттический ip. Хорошо что wan не торгал, получил ip по dhcp и смог на него зайти.
Я вообще не понимаю почему в /etc/config/network в секции:
config interface 'lan'
option ifname 'lan1 lan2 lan3 lan4'
option type 'bridge'
option proto 'static'
option ipaddr '192.168.100.254'
option netmask '255.255.255.0'
option ip6assign '60'
Отсутствует Wireless интерфейс но при этом:
Теоретически в /etc/config/wireless замена:
option 'mode' 'ap'
на
option 'mode' 'sta'
и отключение dhcp должны были превратить устройство в бридж между WiFi<->ETH но этого не произошло и даже eth не отвечал на свой адрес хотя br-lan именно его имел.
Для начала запусти отдельно wlan0 чтоб в sta заработало. Некоторые wifi просто не умеют чисто sta и им надо делать что-то типа:
Это конфиг который пришлось сгородить потому что вторая часть без первой просто не работала. Как только включаешь на wifi ap и sta одновременно - всё фурычит без проблем. Странно, но так вот есть. Хотя есть и плюс - типа ретранслятор появляется. Если правильно помню - это был tp-link wr703n, но не уверен.
В общем, надо просто вручную wifi понастраивать в разных режимах, выяснить в каком работает, а потом уже эти дурацкие конфиги писать.
Пробовал. Сначала описал ap потом sta но по ifconfig получил wlan0 и wlan0-1, при этом у wlan0 RX bytes,TX bytes растут а у wlan0-1 нет и при этом brctl show показывает что в br-lan входит именно wlan0-1. попробовал в конфиге первой сетью поставить sta а потом ap - результат тот же. Почему то в бридж ставится wlan0-1 статистика у которого по нулям. В эфире имя ap не появляется ни в первом ни во втором случае.
Так а на уровне iwconfig или там iw что происходит-то? Все эти конфиги - мутотень, на самом деле, важно только как настраивается wlan0 низкоуровневыми тулзами. Попробуй, используя iwconfig iwlist iwpiv и iw настроить wlan0 вручную, а уж потом в конфиги лезь.
Так а на уровне iwconfig или там iw что происходит-то? Все эти >конфиги - мутотень, на самом деле, важно только как >настраивается wlan0 низкоуровневыми тулзами. Попробуй, >используя iwconfig iwlist iwpiv и iw настроить wlan0 вручную, >а уж потом в конфиги лезь.
Вообще бриджа у меня не получилось. Сделал:
/etc/config/network добавил:
config interface 'wwan'
option proto 'dhcp'
config interface 'stabridge'
option proto 'relay'
option network 'lan wwan'
/etc/config/wireless:
config wifi-iface
option 'device' 'radio0'
option 'network' 'wwan'
option 'mode' 'sta'
option 'ssid' 'UPLINK'
option 'encryption' 'psk2'
option 'key' '*****'
config wifi-iface
option 'device' 'radio0'
option 'network' 'lan'
option 'mode' 'ap'
option 'ssid' 'MYAP'
option 'encryption' 'psk2'
option 'key' '*****'
в /etc/config/firewall везде wan переделал в wwan
После этого интернет виден - но не бриджем а роутером, а хочется сделать бридж.
Сейчас сделал контрольную замену всех wwan на wan в /etc/config/firewall
Рестартанул firewall - сети не стало.
Вернул всё взад.
Рестартанул - сеть есть.
config interface 'lan'
option ifname 'lan1 lan2 lan3 lan4 wlan0 wlan0-1'
Фуух. выяснил что просто сделал очепятку и ломился не на тот ip который начепятал.
В общем в обоих wlan поставил:
option 'wds' '1' но бридж так и не заработал.
и ведь в brctl show они есть :(
(ssid и настройки защиты соединения должны совпадать с настройками на другом маршрутизаторе)
Этого должно быть достаточно для работы в режиме беспроводного моста.
Для диагностики подключите компьютер к LAN порту маршрутизатора-клиента, вручную установите ip-адрес, например, 192.168.100.5, подключитесь к адресу lan-интерфейсва маршрутизатора 192.168.100.6
config dhcp wan
option interface wan
option ignore 1
/etc/config/network:
.
config interface 'lan'
option ifname 'lan1 lan2 lan3 lan4'
option type 'bridge'
option proto 'static'
option ipaddr '192.168.101.254'
option netmask '255.255.255.0'
option ip6assign '60'
config interface 'wan6'
option ifname '@wan'
option proto 'dhcpv6'
config interface 'wwan'
option proto 'dhcp'
config interface 'stabridge'
option proto 'relay'
option network 'lan wwan'
/etc/config/wireless:
.
config wifi-iface
option 'device' 'radio0'
option 'network' 'wwan'
option 'mode' 'sta'
option 'ssid' 'UPLINK'
option 'encryption' 'psk2'
option 'key' 'UpPass'
config wifi-iface
option 'device' 'radio0'
option 'network' 'lan'
option 'mode' 'ap'
option 'ssid' 'DOWNLINK'
option 'encryption' 'psk2'
option 'key' 'DownPass'
Интерфейс stabridge в /etc/config/network взял из какой то ссылки. Не появилось такого интерфейса но и не мешает - так что пусть живет.
В таком варианте машинка живет, но сети DOWNLINK не вижу в WiFi.
Для начала помогите добиться работы 2 WiFi интерфейсов. Сейчас работает только клиентский (UPLINK) - нужно заставить работать еще DOWNLINK как ap к которой могу подключить машинки и они будут в бридже с ETH интерфейсами. Уже потом можно попробовать изменить бридж ETH с ap интерфейсом на бридж ETH с sta интерфейсом. В идеале вообще хочу добиться конфигурации: 2 wan интерфейса с разными MAC - в дефолте получается 2 интерфейса с 1 MAC и получают один ip от dhcp (WiFi/Eth) - Если включаю eth то в консоли вижу появление у wlan0 того же ip как и у wan.
Ну да ладно - сначала ндо добиться работы ap в моей конфигурации а потом только плясать дальше.
n0mad ★★ ( 17.10.14 14:00:16 )Последнее исправление: n0mad 17.10.14 14:05:11 (всего исправлений: 1)
Если нужно только
WiFi должна быть в режиме клиента (т.е. хочу просто подключить её ethernet клиентов к WiFi)
WiFi должна быть в режиме клиента (т.е. хочу просто подключить >её ethernet клиентов к WiFi)
Изначально да, но пока не добился и решил более универсальную конфигурацию сделать.
Исходная задача в итоге не решилась и надо идти маленькими шагами - сначала сделать 2 WiFi, затем сделать бридж LANWiFi с lan и потом уже бридж WANWifi с wwan
Это было в дефолтном имидже OpenWRT для TL-WR941ND
Там есть br-lan в который включаются 4 lan порта.
eth это wan порт.
Не до конца понял что ты хочешь, но видимо тебе нужно, тоже самое что мне
Т.е. добавляешь bridge в декларацию нужных интерфейсов, а потом просто их перечисляешь все для wifi.
Второй беспроводной интерфейс имеет смысл только если нужна функциональность wifi-повторителя.
Второй беспроводной интерфейс имеет смысл только если нужна >функциональность wifi-повторителя.
Хочется универсальности. Один интерфейс на вход и другой на выход а wan в зависимости от контекста выбирать или WiFi или ETH
В общем то почти так и делал - но не заработало.
Я делал в /etc/config/wireless:
.
config wifi-iface
option 'device' 'radio0'
option 'network' 'lan'
option 'mode' 'sta'
option 'ssid' 'UPLINK'
option 'encryption' 'psk2'
option 'key' 'UpPass'
Спасибо за советы. Как будет время - попробую совет с одним lan sta WiFi в конфиге. Но я не понимаю в каком месте WiFi sta получает ip и можно ли его поднять со статическим ip?
Если только попробовать в /etc/config/network:
config interface 'wan'
option ifname 'wan'
option proto 'static'
и такой же выдать lan интерфейсу. Ну или попробую включить WiFi в бридж и не получать ip, а то видимо был бридж но br-lan получил 1 ip а wlan0 другой ip и по настройкам он выпадал из бриджа хотя по brctl он там был.
В любом случае как придем к заветной работающей конфигурации попробую её описать отдельным SEO ориентированным тредом :)
n0mad ★★ ( 17.10.14 18:20:44 )Последнее исправление: n0mad 17.10.14 18:28:12 (всего исправлений: 1)
У меня OpenWRT подключается к нативному ASUS NT-10U
Устройства MT5350, MT7688, MT7628, MT7620 содержат не менее 1 интерфейса LAN (4LAN), тогда это устройство может иметь переключатель между разными интерфейсами (switch) Специальное подключение. Большая часть внутренней структуры показана ниже:
Введите команду ifconfig в системе Linux, будет следующий вывод
br-lan = LAN мост
eth0 = lan-интерфейс (обратите внимание, что это порт LAN RJ45 на маршрутизаторе)
eth1 = интерфейс wan (обратите внимание на то же, что и выше)
wlan0 = беспроводной порт
Введите команду ifconfig в маршрутизаторе, и результат будет следующим:
eth0
eth0 - физическая сетевая карта. Все eth0.1 и eth0.2 виртуализированы с этого устройства.
eth0.1 - это порт LAN, ответвленный от vlan1.
eth0.2 - это wan-порт vlan.
rao raio
Эти два появляются парами, и вы можете видеть, что они являются беспроводными устройствами, каждое из которых соответствует SSID, 2,4G и 5G.
br-lan
Виртуальное устройство br-lan, используемое для моста устройства порта LAN, может использоваться brctl show Проверить использование.
br-lan = eth0.1 + rai0 + ra0, то есть порт проводной LANИ беспроводнойСеть равномерно делится наLAN, Легко управлять!
lo
вот виртуальное устройство, свое собственноеПетля 。 Сетевое оборудование.
pppoe-wan
Виртуальное устройство, которое представляет собой обычный коммутируемый широкополосный доступ в Интернет, требует имени пользователя и пароля, предоставленных поставщиком Интернет-услуг, и этот интерфейс можно активировать после подключения!
Разделение сетевого моста LAN (br-lan) Печать
Изменено: Чт, 23 Мар, 2017 at 12:52 PM
При использовании роутеров и контроллеров RTU, иногда, возникает необходимость разделить существующий интерфейсный мост br-lan, на два независимых интерфейса.
Сделаем разделение сетевого моста в два локальных с различными сетями.
1. Разделение моста
Открываем настройки сетевого моста:
Отключаем режим моста и указываем для нашей первой локальной сети интерфейс eth0
Сохраняем и применяем изменения:
2. Создание второго интерфейса и назначение зоны межсетевого экрана
Создаем новый интерфейс для второй подсети:
Указываем первичные параметры для создания интерфейса:
Вводим оставшиеся параметры сетевого интерфейса и выбираем зону экрана:
На этом этапе можно настроить DHCP сервер для второго интерфейса или оставить, как есть:
Назначаем межсетевую зону для нашего второго интерфейса:
Сохраняем и применяем новые параметры:
Смотрим, что получилось:
На этом разделение сетевого моста завершено.
3. Консольный вариант разделения сетевого моста
Редактируем файл /etc/config/network
Вносим изменения в структуру и сохраняем файл:
config interface 'lan'
option proto 'static'
option ipaddr '192.168.88.1'
option netmask '255.255.255.0'
option ip6assign '60'
option ifname 'eth0'
config interface 'lan2'
option proto 'static'
option ipaddr '192.168.99.1'
option netmask '255.255.255.0'
option ifname 'eth1'
Редактируем файл /etc/config/firewall
Вносим изменения в структуру и сохраняем файл:
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option network 'lan lan2'
Редактируем файл /etc/config/dhcp
Вносим изменения в структуру и сохраняем файл:
config dhcp 'lan2'
option start '100'
option leasetime '12h'
option limit '150'
option interface 'lan2'
Хотел бы поделиться опытом объединения сетей в трех географически удаленных квартирах, в каждой из которых в качестве шлюза используются роутеры с OpenWRT, в одну общую сеть. При выборе способа объединения сетей между L3 с маршрутизацией подсетей и L2 с бриджингом, когда все узлы сети будут находиться в одной подсети, было отдано предпочтение второму способу, более сложному в настройке, но дающим бОльшие возможности, так как в создаваемой сети планировалось прозрачное использование технологий Wake-on-Lan и DLNA.
Часть 1: Предыстория
В качестве протокола для реализации этой задачи изначально был выбран OpenVPN, так как, во-первых, он может создавать устройство tap, которое без проблем добавляется в мост, а во-вторых, OpenVPN поддерживает работу по протоколу TCP, что было также немаловажно, ведь ни в одной из квартир не имелось выделенного IP-адреса, а использовать STUN мне не удалось, так как мой провайдер почему-то блокирует входящие подключения по протоколу UDP из своих сетей, в то время как протокол TCP позволял мне пробросить порт VPN-сервера на арендуемый VPS при помощи SSH. Да, такой подход дает большую нагрузку, так как данные шифруются дважды, но вводить VPS в свою частную сеть я не захотел, так как оставался риск получения третьими лицами контроля над ним, следовательно, иметь в домашней сети такое устройство являлось крайне нежелательным и было решено заплатить за безопасность большим оверхедом.
Для проброса порта на роутере, на котором планировалось развернуть сервер, была использована программа sshtunnel. Описывать тонкости ее конфигурации не буду — это делается достаточно легко, просто отмечу, что ее задачей был проброс TCP-порта 1194 с роутера на VPS. Далее был настроен сервер OpenVPN на устройстве tap0, которое заводилось в мост br-lan. Проверив подключение к только что созданному серверу с ноутбука — стало понятно, что идея с пробросом порта себя оправдала и мой ноутбук стал членом сети роутера, хотя физически в ней не находился.
Дело оставалось за малым: нужно было распределить IP-адреса в разных квартирах так, чтобы они не конфликтовали и настроить маршрутизаторы в качестве OpenVPN-клиентов.
Были выбраны такие IP-адреса маршрутизаторов и диапазоны DHCP-серверов:
- 192.168.10.1 с диапазоном 192.168.10.2 — 192.168.10.80 для сервера
- 192.168.10.100 с диапазоном 192.168.10.101 — 192.168.10.149 для маршрутизатора в квартире №2
- 192.168.10.150 с диапазоном 192.168.10.151 — 192.168.10.199 для маршрутизатора в квартире №3
Также было необходимо назначить именно эти адреса для маршрутизаторов-клиентов OpenVPN-сервера, путем добавления в его конфигурацию строчки:
и добавлением следующих строк в файл /etc/openvpn/ipp.txt:
где flat1_id и flat2_id — это имена устройств, указываемые при создании сертификатов для подключения к OpenVPN
Далее на роутерах были настроены OpenVPN-клиенты, устройства tap0 на обоих были занесены в мост br-lan. На этом этапе казалось, что все в порядке, так как все три сети видят друг друга и работают как единое целое. Однако, выяснилась не очень приятная деталь: иногда устройства могли получить IP-адрес не от своего маршрутизатора, со всеми вытекающими последствиями. По какой-то причине, маршрутизатор в какой-то из квартир не успевал ответить вовремя на DHCPDISCOVER и устройство получало не свой адрес. Я понял, что мне нужно отфильтровать такие запросы в tap0 на каждом из маршрутизаторов, но, как выяснилось, iptables не может работать с устройством, если оно является частью моста и мне на помощь должен прийти ebtables. К моему сожалению, в моих прошивках его не оказалось и пришлось пересобирать образы для каждого устройства. Сделав это и добавив такие строки в /etc/rc.local каждого маршрутизатора проблема была решена:
Такая конфигурация просуществовала на протяжении трех лет.
Часть 2: Знакомство с WireGuard
В последнее время в Интернете все чаще стали говорить о WireGuard, восхищаясь простотой его конфигурации, высокой скоростью передачи, низким пингом при сопоставимой безопасности. Поиск дополнительной информации о нем давал понять, что ни работа в качестве члена моста, ни работа по протоколу TCP им не поддерживается, что наводило меня на мысли о том, что альтернатив OpenVPN для меня по-прежнему нет. Так я откладывал знакомство с WireGuard.
Несколько дней назад по ресурсам, так или иначе связанным с IT, пролетела новость о том, что WireGuard наконец будет включен в ядро Linux, начиная с версии 5.6. Новостные статьи, как всегда, хвалили WireGuard. Я вновь погрузился в поиски путей замены старого доброго OpenVPN. На этот раз я напоролся на эту статью . В ней говорилось о создании Ethernet-туннеля поверх L3 при помощи GRE. Эта статья вселила в меня надежду. Оставалось неясно что делать с протоколом UDP. Поиск приводил меня к статьям об использовании socat в связке с SSH-туннелем, для проброса UDP-порта, однако, в них отмечалось, что такой подход работает только в режиме одного соединения, то есть работа нескольких VPN-клиентов оказалась бы невозможной. Мне пришла идея поднять VPN-сервер на VPS, а для клиентов настроить GRE, но, как оказалось, GRE не поддерживает шифрование, что приведет к тому, что в случае получения доступа к серверу третьими лицами, в их руках оказывается весь трафик между моими сетями, что меня не устраивало в принципе.
Вновь было принято решение в пользу избыточного шифрования, путем использования VPN поверх VPN по следующей схеме:
VPN первого уровня:
VPS является сервером с внутренним адресом 192.168.30.1
МС является клиентом VPS с внутренним адресом 192.168.30.2
МК2 является клиентом VPS с внутренним адресом 192.168.30.3
МК3 является клиентом VPS с внутренним адресом 192.168.30.4
VPN второго уровня:
МС является сервером с внешним адресом 192.168.30.2 и внутренним 192.168.31.1
МК2 является клиентом МС с адресом 192.168.30.2 и имеет внутренний IP 192.168.31.2
МК3 является клиентом МС с адресом 192.168.30.2 и имеет внутренний IP 192.168.31.3
* МС — маршрутизатор-сервер в квартире 1, МК2 — маршрутизатор в квартире 2, МК3 — маршрутизатор в квартире 3
* Конфигурации устройств опубликованы в спойлере в конце статьи.
И так, пинги между узлами сети 192.168.31.0/24 ходят, пора перейти к настройке GRE-туннеля. Перед этим, дабы не терять доступ к маршрутизаторам, стоит настроить SSH-туннели для проброса 22 порта на VPS, таким образом, что, например, на 10022-ом порту VPS будет доступен маршрутизатор из квартиры 2, а на 11122-порту VPS будет доступен маршрутизатор из квартиры 3. Настройку проброса лучше всего выполнить все тем-же sshtunnel, так как он восстановит туннель в случае его падения.
Туннель настроен, можно подключаться к SSH через проброшенный порт:
Далее следует отключить OpenVPN:
Теперь настроим GRE-туннель на маршрутизаторе из квартиры 2:
И добавим созданный интерфейс в мост:
Аналогичную процедуру выполним на маршрутизаторе-сервере:
И, также, добавим созданный интерфейс в мост:
начиная с этого момента пинги начинают успешно ходить в новую сеть и я, с удовлетворением отправляюсь пить кофе. Затем, чтобы оценить, как работает сеть на другом конце провода, я пытаюсь подключиться по SSH к одному из компьютеров в квартире 2, но ssh-клиент «зависает», не предлагая ввести пароль. Пробую подключиться к этому компьютеру по telnet на 22 порт и вижу строку, из которой можно понять, что соединение устанавливается, SSH-сервер отвечает, просто по какой-то причине не предлагает мне войти.
Пытаюсь подключиться к нему же по VNC и вижу черный экран. Я убеждаю себя, что дело в удаленном компьютере, ведь к маршрутизатору из этой квартиры я спокойно могу подключиться по внутреннему адресу. Однако, я решаю подключиться к SSH этого компьютера через маршрутизатор и с удивлением обнаруживаю, что подключение удается, а удаленный компьютер работает вполне штатно, но при этом также не может подключиться к моему компьютеру.
Я вывожу устройство grelan0 из моста и запускаю OpenVPN на маршрутизаторе в квартире 2 и убеждаюсь, что сеть вновь работает как положено и соединения не обрываются. Поиском натыкаюсь на форумы, где люди жалуются на такие же проблемы, где им советуют поднять MTU. Сказано — сделано. Однако, пока MTU не был установлен достаточно большим — 7000 для устройств gretap, наблюдались либо обрывы соединений TCP, либо низкая скорость передачи. Из-за высокого MTU для gretap — MTU для соединений WireGuard первого и второго уровня были выставлены в 8000 и 7500 соответственно.
Провел аналогичную настройку и на маршрутизаторе из квартиры 3, с той лишь разницей, что на маршрутизаторе сервере добавился второй интерфейс gretap с именем grelan1, который также был добавлен в мост br-lan.
Все работает. Теперь можно поместить сборку gretap в автозагрузку. Для этого:
Поместил эти строки в /etc/rc.local на маршрутизаторе в квартире 2:
Добавил это в /etc/rc.local на маршрутизаторе в квартире 3:
И на маршрутизаторе-сервере:
После перезагрузки клиентских роутеров я обнаружил, что они по какой-то причине не подключаются к серверу. Подключившись к их SSH (благо, я предварительно настроил sshtunnel для этого) было обнаружено, что WireGuard зачем-то создает маршрут для endpoint, при этом неверный. Так, для 192.168.30.2 в таблице маршрутов был указан маршрут через интерфейс pppoe-wan, то есть через интернет, хотя маршрут до него должен был быть направлен через интерфейс wg0. После удаления этого маршрута соединение восстановилось. Найти где-то инструкций о том, как заставить WireGuard не создавать этих маршрутов мне не удалось. Более того, я даже не понял, особенность это OpenWRT, либо самого WireGuard. Не став долго разбираться с этой проблемой, я просто добавил на оба роутера в скрипт, зацикленный по таймеру, строку удалявшую этот маршрут:
Подводя итоги
Полного отказа от OpenVPN я пока не добился, так как мне нужно иногда подключаться к новой сети с ноутбука, либо телефона, а настройка gretap устройства на них в общем случае невозможна, но, несмотря на это, я получил преимущество в скорости передачи данных между квартирами и, например, использование VNC теперь не доставляет неудобств. Пинг уменьшился незначительно, но стал более стабильным:
При использовании OpenVPN:
При использовании WireGuard:
На него в большей степени влияет высокий пинг до VPS, который составляет примерно 61.5 мс
Однако, скорость увеличилась значительно. Так, в квартире с маршрутизатором-сервером я имею скорость подключения к Интернету 30 мбит/сек, а в остальных квартирах по 5 мбит/сек. При этом, во время использования OpenVPN мне не удавалось достичь скорости передачи данных между сетями больше 3,8 мбит/сек по показаниями iperf, в то время как WireGuard «прокачал» ее до тех же 5 мбит/сек.
Конфигурация WireGuard на VPS [Interface] Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>
[Peer] PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_1_МС>
AllowedIPs = 192.168.30.2/32
[Peer] PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК2>
AllowedIPs = 192.168.30.3/32
[Peer] PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК3>
AllowedIPs = 192.168.30.4/32
Конфигурация WireGuard на МС (добавляется в /etc/config/network)
Конфигурация WireGuard на МК2 (добавляется в /etc/config/network)
Конфигурация WireGuard на МК3 (добавляется в /etc/config/network)
В описанных конфигурациях для VPN второго уровня я указываю клиентам WireGuard порт 51821. По идее это не нужно, так как клиент установит соединение с любого свободного непривилегированного порта, но я сделал так, чтобы можно было запретить все входящие соединения на интерфейсах wg0 всех маршрутизаторов, кроме входящих UDP-соединений на порт 51821.
Читайте также: