Wi-CAT LLC

Wireless Comprehensive Advanced Technology. Build your network now.

Wi-CAT LLC
Навигация Форума
Вы должны войти, чтобы создавать сообщения и темы.

Формируем ToDo по функционалу (только внятные технически грамотные обоснования)

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

  1. поддержка EOIP/L2TPv3 туннелей для объединения на L2 территориально разнесённых сетей путём туннелирования (выполнено)
  2. в настройки dnsserver добавить возможность управления локальными записями (в момент генерации /etc/hosts)
  3. добавить ipv6 filters в webui фаервол для управления цепочкой FORWARD, возможность выборочно разрешить доступ к ipv6 хостам из internet по dst ipv6/dst ports/mac (аналогично v4)
  4. сводная таблица засветившихся клиентов dhcp lease/arp table/arpwatch/stalist ( https://wi-cat.ru/forums/topic/perechen-vseh-devaysov-podklyuchennyih-k-marshrutizatoru/?part=1#postid-1711 ), т.е. максимально доступные данные по сетевым устройствам в локалке

 

Чтобы попасть в эту очередь, нужно предложить интересную вещь, грамотно описать, что она должна делать и где применима. Тогда мы сможем прикинуть трудозатраты, оценить необходимость и возможность реализации. И только после этого хотелка может появиться в списке.

 

Добрый день

по мотивам

CURRENT HOOKS FOR ADVANCED USER LOGIC:

1) /etc/udhcp.d - scripts start after udcpc renew lease
2) /etc/vlan.d - scripts start after vlans configure
3) /etc/ip(6)tables.d - scripts start after netfilter configure
4) /etc/ppp-l2tpsrv/ip-up(down).d - scripts start after client connect(disconnect) to VPN server
5) /etc/ppp/ip-up(down).d - scripts start after router connetc(disconnect) to external VPN server
6) /etc/scripts/wan_up.sh - this script start after WAN up and full services reinit
Предлагаю добавить в прошивку следующее:
Чтобы после обновления прошивки заново не править эти файлы (или не загружать свой rw-fs с этими правками например), предлагаю добавить в эти файлы процедуру проверки наличия определенного скрипта в определенной папке и если он есть, его выполнение.
Приведу пример:
В скрипте ip-up происходит проверка наличия скрипта ip-up.sh в папке /opt/userscripts Туда вписываются свои команды, которые надо выполнить. К примеру, пишу туда отправку мне уведомления в телеграм с актуальным ip. Или кто-то другой свое туда вписывает. И если этот файл есть, то он выполняется. Если нет, соответственно ничего не происходит.
Размещение предлагаю либо /opt/userscripts если подключена флешка с настроенным entware, либо если на флеше роутера есть раздел, который не затирается при перепрошивке (в том числе при перезаписи rw-fs), то в нем.
Ну и например выводить это в лог. Вида found user script ip-up. Success (ну или error если что-то пошло не так)
Надеюсь понятно расписал)
  1. Можно вообще не сбрасывать RWFS при обновлении, для этого галочка в роже есть. Если мной не правился инит то сброс не обязателен. Достаточно перед обновлением глянуть в changelog,  я стараюсь не менять это дело без нужды. Плюс далеко не все правки в /etc  (которая и есть rwfs) нужны конкретному юзверю. И если юзверь что-то своё подсаживает в систему то он может и оценить надо ему обновлять/сбрасывать rwfs или нет
  2. Модификации вносимые пользователем в rwfs могут быть оформлены пакетом и править руками после обновления ничего не надо будет, нужно будет просто загрузить свои модификации из рожи, как описывал тут https://forum.nag.ru/index.php?/topic/102590-wive-ng-mt-kastomizaciya-proshivki-s-pomoschyu-rwfs/
    Т.е. просто делаем себе пакетик со своими скриптами, и после обновления следом загружаем его.
  3. С оптварью и так при подключении запускается /opt/etc/init.d/rc.unslung start дальше можно штатно положить нужную логику в саму оптварь и вызывать из её инита уже

П2 - must have. Оформляйте свои модификации RWFS в виде пакета и тогда восстановление модификаций сведётся к загрузке этого самого пакета через морду после обновления/сброса. Проще не куда.

Так же при загрузке пакета, исполняется и скрипт находящийся в нём scripts/userrwfs.sh куда можно добавить любую доп логику. Например модифицировать значение в nvram или вообще автоматом разворачивать оптварь и т.д.

Собсно эта штука сделана в т.ч. и для преконфигурации с завода. Что бы можно было просто пакетиком внести нужные модификации. Какие-то доп хуки для этого не нужны от слова совсем.

Хотелка:

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

  1. Обрезать медленные скорости -  для повышения скорости работы (быстрое прохождение служебных фреймов, идущих на базовой скорости). Очевидное уменьшение радиуса сети зачастую не критично для работы в помещении.
  2. Обрезать высокие скорости - для повышения стабильности работы (уменьшения повторов) на пределе дальности.

В своем офисе на Mikrotik-овских точках доступа обрезание нижних basic rate помогло заметно увеличить скорость.

Возможно использую не совсем точные термины по стандарту 802.11, опираюсь опять на то, что видел в Mikrotik.

Не имеет смысла, т.к. в отличии от микротик rate_alg у нас отлажен от и до. А неиспользуемые рэйты обрезаются автоматом в зависимости от режима. Т.е. в отличии от микротик в g/n режиме мы автоматом даже не анонсируем CCK рэйты.

Т.е. если rate_alg не справился с подстройкой рэйта, то вероятность улучшить ситуацию руками почти без шансов.

У микротик rate_alg работает просто безобразно, остюда и необходимость крутилок.

Как бы 100500 раз проверено нашими заказчиками и их клиентами на собственной шкуре.

А для офиса я бы крайне рекомендовал бы использовать схему ME1 в роли шлюза, с отключенным wifi (или переведённым отдельно чисто для диагностики) + нужное число SNR-CPE-AP2 в каждом помещении с настроенными RRM/FT (которые у микротик вообще отсутствуют) и подогнанными уровнями, разнесёнными по частоте и т.д. и т.п.

Это в итоге гораздо более эффективно и надёжно, нежели пытаться приземлить полуглухих/косых и туалетных клиенов на одно устройство устраивая пляски с бубном в виде колупания рэйтов руками.

На сайте на эту тему начат целый цикл статей, под общей категорией "роуминг". К сожалению правда со временем совсем напряжёнка и написание цикла застряло на 1/3 от запланированного.

  1. Автоматическое обновления прошивки из вебморды (как у zyxel/mikrotik)  + нормальный чейнджлог там же (не всегда понятно есть ли смысл ставить новую версию)
  2. ID устройств в списке активных подключений wi-fi
  1. вот точно не надо этого счастья с автообновлениями, особенно на фоне того, что железо не ориентировано на розницу, а для операторов доступно как минимум  2 варианта контроля версий (CWMP/Wive-Control). Нормальный ченджлог лежит в гите. И доступен 24/7 в риалтайме.
  2. что значит ID устройств? Какой такой вообще ID?
  1. имелось в виду не автоматическое обновление в фоне, а обновление прошивки нажатием на одну кнопку (при наличии более новой версии)
  2. в большинстве роутеров это называется "имя устройства" (Device Name/ Client Name)Kb22764 004 En V6

понимаю что пример немного не оттуда, но на тех же точках доступа от ubiquiti имя устройства отображается

  1. откуда я должен сделать такое неавтоматическое обновления если существует 100500 модификаций операторских ? Ещё раз, это железо не для розничного рынка. Будет официальная розница - будем думать.
  2. ничего не смущает? Это не device name и не id, это всего лишь данные из DHCP и доступны они у нас (как и на вашей картинке) там где и должны быть, на странице DHCP. Более того, их может не быть вовсе, или может быть откровенная лабуда (чаще всего). На уровне 802.11 нет никаких ID кроме MAC.
Загруженные файлы:
  • Вам нужно войти, чтобы просматривать прикрепленные файлы..

понимаю что пример немного не оттуда, но на тех же точках доступа от ubiquiti имя устройства отображается

Не немного, а совсем не оттуда.

Более того, в режиме голой АП на устройстве нет DHCP сервера, и данных взять о "имени" банально не откуда. Т.е. эти данные доступны только на железке на которой крутиться DHCP сервер, и клиент при запросе адреса передаёт некую абракатабру и то не всегда т.к. не обязан от слова совсем.

А в радио нет ничего подобного. Что конечно на мой взгляд в PSK режиме очень зря. Но 802.11 разработан не нами и увы мы не можем на это никак повлиять.

Возможно ли сделать поле для сохранения серийного номера устройства?

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

Такие вопросы только через wifi@nag.ru. Они производители вот объясняйте им насчёт серийников и т.д. Не забудьте представиться и описать зачем вам это надо. Иначе вопрос ответ будет таким же. Т.к. смысл сего действа не понятен от слова совсем, т.е. до оценки возможности или рентабельности дело даже не дойдёт.

Ок, понятно - не до такой степени нужно.

Теперь по поводу инфо о клиентах, подключенных к АП. На данный момент в разделе Station List они отображаются общим списком, т.е. все, кто подключен к основному интерфейсу, независимо от поднятых на нем SSID.. Нельзя ли в таблице сделать доп. столбик, где будет отображаться ssid, к которому подключен конкретный клиент? Или для каждого созданного ssid формировать отдельную таблицу подключенных клиентов (со статистикой), что было бы удобнее?

 

 

  1. меня этот вопрос (по серийникам) наводит на некоторые мысли, потому попрошу деанонимизироваться, т.к. для ЧЛ это (серийники) точно не нужно
  2. нет нельзя, драйвер вываливает это дело общим списком
  3. крайне не рекомендую использовать MBSSID без крайней нужды независимо от железа и ситуации

И давайте вы всё же первый пост перечитаете? Генераторов идей и фантазёров у нас своих море. Смысл не нагенерировать море идей вида "а вот было бы круто и удобно если" и тем более "а вон у соседа".

Смысл в решении конеретных задач заказчиков и клиентов заказчиков. Ну и возможно что-то интересное. Предложения по оптимизации WEB можете оформить отдельной темой списком. Когда WEBер освободиться (что будет не скоро) посмотрит, что имеет смысл реализовать.

В ближайший месяц точно предложения по WEB можно не вносить. Идёт переезд на новый web сервер и не только. Т.е. заниматься этим будет банально не кому в любом случае, да и не где пока, т.к. в контексте старого сервера уже нет смысла реализовывать, в контексте нового ещё рано, т.к. перезд не завешили.

Так что у вас есть время оформить внятно отдельным списком  в отдельной теме свои предложения по WEB. С нормальным описанием когда и зачем это может понадобиться. Впрочем любые запросы должны включать в себя чёткий ответ на вопрос: "а нафига?". Даже вопрос о серийниках.

  1. К вопросу о сохранении серийников... Да как-то не думал я, что сгенерировал крутую идею или "открыл Америку"... Как уже сказал, не настолько это важно, чтобы доказывать необходимость этого разработчику и производителю - просто на всех упр.свичах, которые встречал, серийник забит в память устройства с завода - вот и захотел узнать нет ли в планах это сделать. Что ЧЛ, что часто ФЛ-клиентам серийник устройства не нужен ... но тем, кто их по клиентам расставляет и обслуживает может пригодится для ведения истории конкретного экземпляра (коробки теряются-выкидываются, этикетки портятся-стираются и удаленно их не увидишь ...)
  2. Понятно
  3. Если возможность заложена (даже если не рекомендуется), то есть желание ее использовать где возможно необходимо. А почему, кстати, "не рекомендуется"?
  1. я даже не в курсе откуда они эти серийники рисуют, скорее всего оно просто тупо формируется для бумажек отдельно, на стадии калибровки о них вероятно никто вообще нифига не знает
  2. .
  3. Многие почему-то считают что MBSSID эт такая независимая сущность. По факту это чисто логическая реализация. Которая до кучи заметно увеличивает оверхид на тему таймаутов ожидания и дополнительного пуляния managment фрэймов в эфир. Т.е. заведомо приводит к большему засёру эфира, понижени производительности и т.д. Некоторые "особо умные" товарищи предустанавливая клиенту роутеры на втором MBSSID разворачивают гостевой доступ с каптивом затягивая отдельным вланом. А потом стонут, что их юзвери стонут что связь никакая. В голову ведь не приходит, что любой клиент с улицы упавший на эту "гостевую" MBSSID утилизирует всё доступное эфирное время для этой АП работая на очень низких рэйтах, в силу понятных думаю причин. В итоге нормально не сможет работать ни основной клиент, ни "халявщик". И методов по нормальному решить этот вопрос к контексте одного физического радиомодуля нет. Проще говоря, применимость MBSSID очень сильно ограниченна тем, что физически это остаётся одним радиомодулем, и клиент на нём ничем не отличается от основного клиента.

Добра. Бэкпорт wireguard-a не планируется ?

Нет. С криптой всё очень просто. Обеспечивается ровно та крипта, которая используется на доступе операторами. Т.е. из коробки ничего сверх того что есть не будет точно. Иначе наши заказчики резко попадут на необходимость сертификации как средства шифрования при ввозе + мы получим сразу пристальное внимание органов, с которыми нам общаться не хочется совсем ни в каком виде.

Так что разве что в entware появиться какой-то вариант, но это уже не к нам.

P.S. Я не думаю, что нашим пользователям очень понравиться если нами заинтересуются органы и нам придётся либо сделать проект закрытым, либо вообще закрыться, либо катапультироваться из РФ. =) Потому сам проект был есть и будет белым и пушистым. Что в общем-то не мешает особо страждущим (сырцы открыты) прикрутить всё, что им вздумается.

Добрый день!

На тестирование попало устройство SNR-CPE-AP2. Функционал вполне достаточен под задачи. В настройках управления устройством, однако, нигде нет увязки VLAN-IP-интерфейс управления. Говоря проще, я не могу "загнать" интерфейс управления в теггированный VLAN и работать через него. Это например есть в D-Link 1100, 1210 сериях  и Mikrotik CRS, RB устройствах (тут вообще полная вольница). Управлять устройством, которое находится в общей сети, не хотелось бы по массе причин (для этого собственно управление серверами, сетевыми устройствами и находится в отдельной сети).

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

Добрый.

Мне всегда было интересно, а что даст запихивание управления в отдельный влан на уровне конечного устройства? Как-то сложнее будет его скомпроментировать если уже физически имеешь доступ к сети? Дык нет, снять/одеть тэг в любой точке запросто, побег из влана так же вполне возможен и т.д. и т.п.

Если речь идёт о доп безопасности, то тут вланы не очень вам помогут.

Решение тут видится одно - жёстко зафаерволить доступ к UI/SSH с кокретных адресов/подсетей  в настройках фаервола. Можно по макам зафильтровать. Ну и юзайте стойкие пароли. Мы не микротики (с вечно дырявым винбоксом), и не *линки =))), за безопасностью следим в части уязвимостей и т.д. Т.е. даже если оставить всё открытым во всех стороны при этом использовать длинные сложные пароли, то можно лишь пожелать удачи атакующему.

Городушки с типа отдельно управляющим вланом нагородить можно. Но как бы что в итоге например делать ещё с мультикаст трафиком iapp ? Тоже во влан? И как будем слышать OTD от клиентов типа яблофонов тогда? =)

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

Вот такой подход.

Не нужно городить лишние сущности.

P.S. Нет ну можно радио и вланами нарезать по радиомодулям (ради изоляции клиентов например), но нетегированный сегмент должен быть в любом случае общим ибо там бегают iapp данные между AP. Поэтому я бы точно не извращался бы с вланами внутри wireless сегмента.

PP.S. Управление и клиенты абсолютно не обязаны находиться в одном адресном пространстве.  Рассматривайте AP как прозрачный бридж из Wireless в LAN, для клиента она никаких уникастовых сервисов не предоставляет, а значит адрес LAN на AP может быть из любой подсети, абсолютно не обязательно что бы был из подсети клиента.

В нашем случае сетевых "хитрецов" полагаем, что нет (уровень не тот), т.е сверх сильной защиты как бы и не нужно. Что касается паролей, то безусловно требование к сложности и длине есть и оно соблюдается. Да и брутить особенно некому. Думаю коммутатором раскидаем кому и чего, если прочих вариантов нет. )

Насчёт "бритвы оккама", то тут конечно нельзя не согласиться ))

 

Ну не. Зафаерволить надо, запретить доступ из пользовательской подсети доступ к UI вообще. А на LAN апшкам повесить какую-нить левую, относительно клиентской подсети адресацию и будет счастье.  Т.е. что бы начать что-то брутить придётся для начала выяснить а куда брутить. Да и брутить умрёшь, у нас ratelimit на все управляющие сущности из коробки. =))

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

WEB можно вообще отрубить за ненадобностью. Или ограничить HTTPS.

Просто вот откровенно накручивать логику с вланами ради реализации схемы которая кроме самоуспокоения реализующего ничего не даёт, ну ИМХО бред какой-то. Кто-то натворил когда-то глупость, остальные повторили. Стадный инкстинкт какой-то. =)

 

Если сильно хочется поизвращаться, то можно вообще отрубить нафиг доступ к UI/SSH с физ интерфейсов, включить L2TP сервер с MPPE (винда кстати такую схему не умеет) и приземлить всё это дело на управлялке с wive-ng-contorl. =)

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

P.S. Классический вариант убрать нафиг WEB, ssh с жирным паролем утащить на далёкий нестандартный порт, зафаерволить доступ утащив оный в другую подсеть и больше нафиг ничего не надо. При этом остаётся возможность для того кто знает явки, адреса и пароли получить доступ к управлению из произвольной точки без извращений. Что часто ну крайне полезно (когда на стремянке под потолком в позе галки находишься например).

На поля запишу, для схемы с AP чисто UI и SSH перевесить на отдельный влан не сложно. Но сейчас завал с новыми железками так что к этому вопросу раньше февраля всяко не получиться вернуться. Да и ИМХО смысла немного.

Просто в одном шировещательном домене устройства тупо видят друг дружку. А не хочется же, чтобы Петя например видел AP в этой сети, вдруг руки шаловливые. Отдельная сеть, которая затем приходит на маршрутизатор, который решает кому куда можно, а кому нельзя, уже более безопасно. Файрволом всё там уже и разделено. Ну и разумеется сеть управления это другой L2 домен. Даже и по индикации коммутатора видно, где какой вилан )) Сеть управления моргнула пару раз, в основной сетке трафик будь здоров, диоды только и мигают )

Ну будем рады, если функционал нет нет, да и появится ))

Причём тут управление-то тогда. Да АП все будут так и сяк видеть друг дружку и юзверь будет видеть все АП. И что? Более того АП между собой общаются.

Ну вот что Петя пришедший с WLAN с этим сделает? Мак подменит на мак АП? Ну подменил и что? Можно вообще не анонсить AP arp`ом. Клиенты как ходили так ходить и будут.

Кстати подменить он его не сможет без отключения, т.е. придётся отключиться, сменить и подключиться. =) Ну мы же можем в acl drop в настройках wifi загнать адреса собственных AP, мы же их знаем заранее. И пусть хоть заподключается. И мак шлюза туда же.

Единственный ну ооочень слабый аргумент это индикация на свитче.

Если Петя захочет завалить WIFI сеть то ему даже подключаться для этого не потребуется. Более того вектор атаки будет на клиента. Реализуется это на коленке на раз независимо от того какие крутые АП у вас юзаюся. Пете даже к сети подключаться не придётся.

802.11 архитектурно убог в части защиты от подобного, и даже PMF вас никакие не спасут.

Т.е. надо понимать от чего защищаемся. От того что бы положить сеть? Ну дык в 802.11 нет защиты ибо см выше. От компроментации управления? Ну дык там всё прекрасно SSH+длинный пароль. От перехвата трафика? Use шифрование всегда даже на публичных сетях офисцентров (да да повесить пароль на стены =)). Защита от спуфинга и т.д. на уровне дров имеется.

Короче от Пети с шаловливыми ручками желающего устроить DOS в 802.11 на данный момент никакой защиты нет. Потуги с PMF чуть усложняют это дело, но полностью не решают. Да и клиентов умеющих PMF пока меньше 30%.

В общем wifi нельзя рассматривать как базу для отказоустойчивых сервисов ибо сам 802.11 архитектурно не позволяет гарантировать даже номинально защиту от DOS, не важно что там юзается.

С перехватом трафика и компроментацией самих устройств худо бедно что-то таки выродили. И даже управляющие фрэймы спустя 2 десятилетия шифроать решили (PMF), достижение. =))) Но увы. Поэтому шаловлятор скорее просто устроит массовую "стерилизацию" эфира, чем будет напрягаться. =)

Цитата: ObiVan от 13/11/2018, 18:22

Ну будем рады, если функционал нет нет, да и появится ))

Напомните ближе к февралю (можно тут апнуть), сделаем. Но вопросы остальные в силе. =)

Цитата: sfstudio от 13/11/2018, 18:54
Цитата: ObiVan от 13/11/2018, 18:22

Ну будем рады, если функционал нет нет, да и появится ))

Напомните ближе к февралю (можно тут апнуть), сделаем.

Лады! ))

Добрый день, нет ли планов добавить  vlan на wan в UI?

Нет не планируем. У наших заказчиков на сетях схема с Internet in VLAN не используется (видимо об этом речь идёт). IPTV/SIP во вланах с WAN у нас поддерживаются в полном объеме.

Более того MT века закрыта для функциональных изменений. Только поддержка текущего функционала + фиксы ошибок.

Эта тема более не актуальна.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: