l1ght

А в чем такие графики рисуются?

И что скрипты сделают?

У микрота нет снупинга. Если микрот как бридж - то можно сделать правило на бридже которое убивает udp 67\68 с левых маков. А вообще изоляция портов (traffic segmentation) - спасет мир от всех угроз

И сходу сюда же вопрос Как сделать таймаут сессии на фрирадиусе?

Для начала сбросте точку на заводские настройки. Настройте по новому. Когда клиент соединяется смотреть есть ли TX\RX (пример 240\270, но никак не 0\180 или 90\0). Дальше у вас клиенты соединенные имеют стаические адреса на антеннах или по DHCP или PPPoE получают адрес?

Значит опробовал связку mpd5 + freeradius. Нашел ошибку. В /usr/local/etc/raddb/sql/mysql/dialup.conf нужно поправить строку. Было (в /usr/local/www/apache22/data/billing/docs/freeradius/raddb/sql/mysql/dialup.conf) nas_query = "SELECT id, nasname, shortname, type, secret, server FROM ${nas_table}" Должно быть nas_query = "SELECT nasname, shortname, type, secret, server FROM ${nas_table}" То бишь нужно убрать id из запроса ибо в БД его нету и радиус из-за этого не хочет стартовать.

Ну при разработке Ubilling мы редко руководствуемся просто "желаниями". Как правило вся деятетельность растет ногами из каких-то срочных потребностей либо заказухи от существующих клиентов. Они в большинстве своем и подкреплялись ранее. Вы же в правду не считаете, что весь этот ад, который релизиться ежемесячно а иногда и дважды в месяц пишеться за счет святого духа и просто потому, что "захотелось"? Мы решили таким способом попробовать, просто уменьшить себестоимость для конечного потребителя. Если все будет хорошо - думаю со временем коммерческие модуля будут отвязываться от лицензирования, когда продажность перекроет себестоимость их разработки. Опять же, думаю вполне самоочевидно, что писаны они исходя из наших расценок от 20/час - далеко не за два часа. И как-бы не все хотят выкладывать полную стоимость разработки с нуля из своего кармана. Ну вообщем-то профотано все. Как и вся логика, которой дефакто там нету. Нет - соединение пользователей (к слову тоже древняя заказуха) работает себе соединением пользователей. Юрики - просто есть. Как минимум для ведения их реестра и выписки им счетов, договоров и прочей мути. Короче чисто менеджменто-бухгалтерская фиговина. Ну это как посчитать Я подозреваю, что в норме на все эти 5 точек включения должен быть предусмотрены договором какие-то вполне четкие условия. Энивей какое заказывали по ТЗ - такое есть. Это просто у вас нездоровое желание, искать смысл там где его нет изначально Я просто было подумал, что это что-то большее чем "менеджменто-бухгалтерская фиговина". От туда и поиск смысла

Under construction. Думаю сегодня-завтра. Очень жду! Как оказалось мое представление о времени является достаточно фиговым. http://wiki.ubilling.net.ua/doku.php?id=corps Я смотрю уже одного желания мало? Теперь модули подкрепляются финансовой поддержкой В любом случае юр. лица и карта ВОЛС - достаточно ценные модули, думаю на них спрос будет большой. Да и я вот планирую обзавестись онными. Хотелось бы конечно больше скриншотов как это выглядит и больше понимания логики. Допустим вот юр.лица - будут работать по принципу соединения пользователей? Потому как, когда пользователи соеденины и стоит конечно же один тариф на всех, как у родительского аккаунта, то 5 связаных с тарифом по 10 мегабит - будут иметь по факту 50 мегабит за одну цену. А так как с юриками у каждого нюансы свои (даже один тариф на каждого), то как-то размыто выходит. Больше бы объяснений логики работы хочется!

Under construction. Думаю сегодня-завтра. Очень жду!

А что по поводу документации по работе с юриками?

Насколько я помню - то нет. С микротиковским хотспотом вообще много чего можно сделать, особенно если связать его с фряхой или линем.

А я как владелец ната (1 айпи на 128 адресов) - знаю, что ипы банят только по 25 порту. Возражения принимаются. К тому же все нормальные вещи умеют по другим портам. Например 587 и 465 (кописпаст отсюда https://www.niks.by/page82.php).

Если править rc.conf то только ребутом. Касательно IPFW - то там нужно сделать все правила с -q (ipfw -q add 100 allow ip from any to any - пример) - значит тихий режим без вывода инфы на консоль. Что б рестартить ipfw используй /etc/rc.d/ipfw restart.

А какой бюджет вообще? Такой линк как вы хотите делается или полурабочими костылями или нормальным оборудованием. Под нормальным понимается РРЛ (радиорелейное линия) - дорого. Или костылём. Роутерборд + 3-4 радиолинка, на РБ делается бондинг - на приемной стороне тоже самое. Антенны которые принимают линки + РБ с бондингом. Воля ваша конечно. Но линки на 15км, могут не отличатся сверх стабильностью, особенно при зашумленных частотах. Имхо ищите оптику арендовать или свою проложить.

Не знаю, тьфу-тьфу работает

Год работали стабильно, а вот потом плоховато себя чувствовать начали. 911 годная замена, я думаю. В силу того, что таки поменяли. Чего-то я забыл про это упомянуть

У меня пара рокет дишей и на 40км работало. Только вот хреново очень Поменяли на микроты - гораздо лучше и по пингу и по пропускной вышло. Какие микротики брать и какие антенны для моста? Ну мы поставили: антенна - диш как и была, а вот микроты 711 пара. То есть просто вместо рокета поставили пару микротов. Вам надеюсь не нужно пробивать 40 км?) Ну а так - всё что дальше 3-4 км желательно подключать микрот к внешней антенне. 3-4км пробьет и родной корпус со встроенной антенной.

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

Ну 300 мегабит одним линком вы врятле прожуете. Имеется опыт при линке в 2км почти синхронные 100мбит были. Ну как всегда - тесты одно, реально показало чуть хуже. Пинги в час пик были до 30мс. В вашем случае если вы хотите 300 мегабит - то скорее всего нужно делать 2(3) линка пихать их в один микротик и делать per packet balancing. Пакетов прожует любой микротик довольно много в режиме простого моста, больше внимания стоит уделить устройству которое будет это дело объединять.

ещё раз спрошу: точка-точка или точка-многоточка? а то мне ваш ответ непонятен

с твоим бюджетом - разве что мост на нанобриджах да рокет с сектором. и тут бюджет закончится. и про 100мбит можешь забыть, мегабит 40, в лучшем случае ближе к 60 вытащишь.

меньше километра - это точка-точка или точка-многоточка?

/64 рекоммендуемая вообще выдача на абона. И по всем делам - /64 минимально делимая сеть. ну я же говорил - влом искать обновления в документах, то что изменилось - я в курсе Ну у меня /32, и пока особого смысла давать эти адреса пользователям не вижу. Можно было бы в качестве бонуса давать, но к сожалению наш текущий биллинг этого не умеет В принципе по идее если л2 коннектед - то должно просто сквозняком пропустить, только вот трафик тегируется - а вот тут интересно.... Если тегировать будет - тогда всё ок, нужна поддержка на выдаче - раутинге - и конечного абона, в промежутке тогда поидее не надо в6 реди оборудование - но опять таки тестить надо.

dual stack тоже не очень простая штука, хотя при наличии в6+в4 - приоритет на в6 идет. А у меня ассоциация на в4+в6 - микротик. Но что бы дать абону в6 + его сеть \64 - надо извращатся. Дать абону \128 и через этот \128 раутить абонскую \64. Причём \128 - в 99.9% - статикой. И в догоночку - как ты у себя организовывать будешь выдачу\шейп и в4 и в6? А если в4 серые, а они часто серые - то ещё и нат на в4. Кстати гугл рассказал, что дамминет с в6 работает на 30-40% медленнее чем с в4 (я кстати не понял, как это "медленнее"). А по сути конструкция типо, такой простенький пример, позволяет шейпить одним пайпом трафик и в4 и в6. ipfw pipe 1 config bw 50Mbit ipfw add 2 ip from any to any via igb0 ipfw add 3 ipv6 from any to any via igb0 Я предлагаю всем кто курил уже в6 делится соображениями по поводу применений. Я лично считаю что нужно тянуть до браса л2 конектед вешать на влан \64 сеть, туда же повесить RA (router advertisement) + dhcp. Конечно же при условии влан на абона. Но тут возникает вопрос, что ж такого плохого DHCP слелал, что б заставлять его слушать столько вланов? Хотя можно просто прорелеить. Потому что именно Best Practive IPv6 предполагает выдачу абонентам \64. Хотя как по мне это сильно много. Это весь пул в4^2. В принципе не забьёт абон столько адресов, в жизни просто не сможет. Моя жаба говорит мне что лучше просто делать сегменты сети и выдавать \64 на район(подставить нужное) скажем. Просто выпуливать весь пул из \64 туда, а скорость резать просто на порту у коммутатора доступа. Кароче всё получается очень сумбурно, но на что-то надо опираться. Придумать какую-то модель более-менее автоматизированную. Так как всем известно что чем меньше извращений - тем лучше.

/64 рекоммендуемая вообще выдача на абона. И по всем делам - /64 минимально делимая сеть. При покупке /48 - в наличии будет 65536 сетей по /64. А вот я считаю что СОХО роутеры помрут при IPv6. Т.к. просто не нужны как таковые будут. Будет что угодно: свич, точка доступа, но не роутер. Т.к. роутить ничего не надо. Просто делать влан пер юзер и давать на влан \64 и скармливать её абону. В v6 не будет же как в v4, с жесткой экономией адресов. Просто гвоздь в том, что на дхцп держать на 65к интерфейсов при раздаче полной \48. А так да, так всё понятно и просто. Да и по поводу шейпера - можно хоть дамминетом, можно скорость прямо на порту ограничивать.