jcomm

Ну, мне так захотелось.. Может я хочу использовать его, как основной сервер ДНС или в случае краха какого либо из "серверов" MikroTik иметь возможность временно зароутить весь трафик через биллинг? Да, достаточно... Как включить сервер в сеть - думать только вам.. Вот мне захотелось так...

# /usr/local/etc/rc.d/radiusd stop && radiusd -x При подключении пользователя по PPPoE, он подключается к микротику, на нем указан сервер FreeRADIUS и микротик у него спрашивает есть ли такой пользователь и какой у него праоль. Так вот, к чему я, эта пара (username Cleartext-Password := password) автоматом создаются для всех пользователей сети, для которой включена поддержка RADIUS. (Проверить можно сделав запрос в консоли разработчика - SELECT * FROM `radius_check`).. Далее радиус отвечает микротику и в случае успешной авторизации передает все атрибуты, которые вы указываете в м

Пара Логин-Пароль создаётся автоматически для каждого пользователя сети с включенным радиусом.. В этом модуле указываются только reply-атрибуты...

EoIP просто позволяет пользоваться всеми дополнительными сервисами, такими как UHW, редирект должников.. EoIP-тоннель - это как эмуляция воткнутого кабеля прямо в сервер FreeBSD.. Но, при пропадании связи по одному из аплинковых подключений - связь разрывается..

А как вы смотрите на вариант создания IPSec + EoIP (прозрачный L2-тоннель)?

Так в шаблоне указывается то имя, которое будет показываться в выпадающем списке: [define] DEVICE = "Device name" Точно установили здесь это значение?

/ip firewall mangle \ add chain=forward out-interface="ether1" action=add-src-to-address-list address-list="ONLINE" address-list-timeout="00:05:00" add chain=input protocol=17 dst-port=53 in-interface="bridge1" action=add-src-to-address-list address-list="ONLINE" address-list-timeout="00:05:00" Можно так, а можно так, как фантазия позволяет. Здесь в основе метода лежит добавление в список на определённое время при попадании под правило...

Саме так..

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

Чётко описано в документации по stargazer!.. Страница 12, опция FeeChargeType в файле /etc/stargazer/stargazer.conf

А вообще, если по-нормальному, в ubilling появился модуль "карта домов", где и можно видеть ваших пользователей on-line без всякой магии..

/ip firewall mangle \ add chain=forward out-interface="ether1" action=add-src-to-address-list address-list="ONLINE" address-list-timeout="00:05:00" Параметры подкручивайте под себя. P.S.: ether1 - ваш внешний порт (WAN)

оО

Вы ошибаетесь! Несмотря на то, что в адрес листе несколько айпишек, то правила фаервола исполняются отдельно для каждой! А управлять доступом к интернету с помощью ARP - это как использовать вилку, чтобы резать хлеб, вроде можно, но...

Можно еще написать в PM, если готовы платить за то, чтобы я вам это написал...

Эмм.. Вы немного заблуждаетесь. Есть такая вещь в MikroTik, Address List зовётся. К примеру, его можно использовать так: /ip firewall filter add chain=forward action=accept in-interface="LAN" out-interface="WAN" src-address-list="ALLOW" /ip firewall filter add chain=forward action=accept in-interface="WAN" out-interface="LAN" dst-address-list="ALLOW" Это добавляется через консоль - правила ограничения доступа. Обратите внимание на параметры src-address-list и dst-address-list. А потом для разрешения доступа вы создаёте запись в адрес листе, а для отключения делаете set disabled=yes или удаля

Этого я не знаю и не морочу голову о хранении id в БД. Концепция работы у меня такова такова: 1. Берём с микротика id записи по какому-либо уникальному параметру (например, логин пользователя) 2а. Если записи нет (в результате пусто) - она должна быть создана (add) 2b. Если запись есть (в результате, например, *86) - надо обновить запись (set) [-] - Одна лишняя команда, по сравнению с вашей реализацией, [+] - Нет головной боли при хранении актуальных id в БД

А, что фаервол использовать для таких задач уже не модно? Да, они динамически добавляются при добавлении записи..

А это как-раз таки исправлено в скриптах, идущих с 0.4.6 - rev 2939, только их нужно отдельно обновить: # cd /usr/local/www/apache22/data/billing # cp -r docs/presets/MikroTik/ /etc/stargazer # chmod a+x /etc/stargazer/On*

Обновитесь до вечерней сборки, заменив в скрипте autoubupdate.sh: UBILLING_RELEASE_URL="http://ubilling.net.ua/" UBILLING_RELEASE_NAME="ub.tgz" на: UBILLING_RELEASE_URL="http://snaps.ubilling.net.ua/" UBILLING_RELEASE_NAME="ub_current.tgz" и повторите замену скриптов: # cd /usr/local/www/apache22/data/billing # cp -r docs/presets/MikroTik/ /etc/stargazer # chmod a+x /etc/stargazer/On* там была печальная опечатка в функции добавления dhcp-leases..

1. кастомное ядро нужно для работы форвардинга на самом сервере биллинга. UHW, например, вы без него не настроете... вам решать как собирать..

да, можно.. только зачем такой геморрой?

1. ОК 2. ОК 3. Пока все так-же пишем... не очень уж востребована эта фича.. увы 4. Будет резать так, как укажете. а вообще на каждого будент создана простая очередь (simple queue)

Ничего, еще повеселимся.. Что-то боком и вылезет...