LANBilling + Mikrotik

[lidia]

Одной из самых популярных тем этого раздела форума является интеграция биллинга с Mikrotik.

Для того чтобы помочь операторам связи разобраться в этом вопросе, мы написали статью, в которой приводим пример интеграции АСР LANBilling с Mikrotik для сервисной модели IPoE с авторизацией по MAC адресу клиента. В скором времени планируем добавить описание интеграции АСР LANBilling с Mikrotik для PPPoE.

[saaremaa]

Спасибо за статью.

[lidia]

Написали статью по интеграции АСР LANBilling с Mikrotik для PPPoE, включающую как настройку биллинга, так и самого микротика.

Надеемся, что статья будет полезной.

[saaremaa]

Я бы не стал собирать все интерфейсы в бридж и вешать на него pppoe-server т.к. в конечном счете получите боооольшой l2 broadcast domain (если только не использовать split horizon). IMHO лучшим способом было вешать отдельный pppoe-server на каждый интерфейс терминации L2?

[vaddem]

7. Заключение

На этом настройку можно считать законченной. При желании возможно дополнить конфигурацию сбором Netflow статистики, правилами редиректа на страницу-заглушку при отрицательном балансе, добавить поддержку IPv6 адресации.

 

Интересно, каким способом реализовывают правила редиректов на страницу-заглушку при отрицательном балансе ?

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

 

Есть еще способы ?

[dereiff]

saaremaa Да, вы правы, объединение большого числа клиентов в один L2 может привести к проблемам с броудкаст штормом и прочим радостям. Но давайте честно, такую ситуацию можно получить и с pppoe сервером всего на одном порту. Не надо забывать что свичи тоже требуют настроек в части port isolate, broadcast limit.

Мы не старались написать статью в духе "как по быстрому стать интернет провайдером имея только mikrotik и LANBilling". Это лишь база, на основе которой каждый волен сделать подходящий для себя вариант.

[dereiff]

vaddem есть способ от самого микротика - http://wiki.mikrotik.com/wiki/Payment_Reminders

В свою очередь АСР вполне в состоянии выдавать различный набор RADIUS атрибутов при нормальной авторизации и при блокировке.

[vaddem]

vaddem есть способ от самого микротика - http://wiki.mikrotik.com/wiki/Payment_Reminders

В свою очередь АСР вполне в состоянии выдавать различный набор RADIUS атрибутов при нормальной авторизации и при блокировке.

 

А, понял - т.е. выдавать атрибут Mikrotik-Address-List, добавляя этим данного клиента в определенную группу

И уже настраивать правила для этой группы

 

Да, тоже вариант - мне даже больше нравится, чем с гостевой сетью. Спасибо :)

[Saab95]

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

 

Так же схема IPoE по маку устаревшая технология, почему бы не сделать то же самое, только на базе порта или влана?

 

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

 

Кроме всего зачем в инструкции по настройке PPPoE рисунок 9 в профиле указан бридж? Указание бриджа в профиле означает, что все абоненты будут добавляться в интерфейсы бриджа и между ними будет прямая L2 связь, что вообще для абонентского доступа не применимо и опасно, кроме всего вызывает разного рода глюки=) Эта настройка применяется для проброса L2 трафика по аналогии с EoIP туннелями, и корни ее идут из OVPN. Кроме всего ARP на интерфейсах, где работает PPPoE отключают, что бы не создавать излишнюю нагрузку, а так же MAC сервер.

[Saab95]

Мы не старались написать статью в духе "как по быстрому стать интернет провайдером имея только mikrotik и LANBilling". Это лишь база, на основе которой каждый волен сделать подходящий для себя вариант.

 

Статья в духе - "как я провел это лето", на практике ее применять опасно. На этой базе ничего сделать нельзя.

 

Интересно, каким способом реализовывают правила редиректов на страницу-заглушку при отрицательном балансе ?

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

 

Стандартный способ редиректа это веб прокси, никакие гостевые сети и вообще какие либо сети и IP адреса, отличные от тех, которые выдают абонентам, использовать нельзя. При PPPoE работает только PPPoE.

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

 

Я бы не стал собирать все интерфейсы в бридж и вешать на него pppoe-server т.к. в конечном счете получите боооольшой l2 broadcast domain (если только не использовать split horizon). IMHO лучшим способом было вешать отдельный pppoe-server на каждый интерфейс терминации L2?

 

Это и есть правильная схема, кроме всего нужно по всему пути следования данных, если используются коммутаторы, заблокировать все. Все протоколы кроме PPPoE. Естественно, на коммутаторах изоляция портов абонента, и отдельный влан в центр с каждого коммутатора. Тогда не бывает проблем.

 

Одной из самых популярных тем этого раздела форума является интеграция биллинга с Mikrotik.

 

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

[vaddem]

Стандартный способ редиректа это веб прокси, никакие гостевые сети и вообще какие либо сети и IP адреса, отличные от тех, которые выдают абонентам, использовать нельзя. При PPPoE работает только PPPoE.

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

 

Имелось ввиду как на уровне биллинга делать, а не микротика - с настройками микротика все понятно.

 

Про гостевые сети - это IP, полученные при поднятии сессии PPPoE.

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

[Saab95]

Про гостевые сети - это IP, полученные при поднятии сессии PPPoE.

 

Нельзя так делать. Есть операторы которые выдают IP в сеть, и там же работает PPPoE. Типа что если абонент не настроил себе подключение, что бы вылезла соответствующая страничка уведомления. Это со стороны лояльности к абонентам правильно, а вот по нагрузке и мусору нет, т.к. на центральных устройствах количество полученных IP адресов примерно 70 процентов от всех абонентов. При этом даже некоторые роутеры IP адрес получают=) По итогу встречаются проблемы, почему интернет не работает - роутер или компьютер отправляет запросы на доступ в локалку, а не PPPoE соединение.

 

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

 

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

 

/ip firewall address-list
add address=10.10.10.10 list=balance_negative
/ip firewall filter
add action=drop chain=forward dst-address=!10.0.0.0/8 src-address-list= balance_negative
/ip firewall nat
add action=redirect chain=dstnat dst-address=!10.0.0.0/8 protocol=tcp src-address-list=balance_negative to-ports=8123
/ip proxy
set enabled=yes port=8123
/ip proxy access
add action=deny redirect-to=10.0.1.10

 

Только в данном примере локалка не блокируется, если нужно и ее блокировать, то вместо !10.0.0.0/8 нужно указать 10.0.1.10, то есть адрес сервера, на которое идет перенаправление.

[AKim]

Интересно, каким способом реализовывают правила редиректов на страницу-заглушку при отрицательном балансе ?

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

 

Есть еще способы ?

 

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

[vaddem]

Нельзя так делать. Есть операторы которые выдают IP в сеть, и там же работает PPPoE. Типа что если абонент не настроил себе подключение, что бы вылезла соответствующая страничка уведомления. Это со стороны лояльности к абонентам правильно, а вот по нагрузке и мусору нет, т.к. на центральных устройствах количество полученных IP адресов примерно 70 процентов от всех абонентов. При этом даже некоторые роутеры IP адрес получают=) По итогу встречаются проблемы, почему интернет не работает - роутер или компьютер отправляет запросы на доступ в локалку, а не PPPoE соединение.

 

Да не делаем мы так, не выдаем адреса по локальной сети :)

Речь идет именно про IP PPPoE сессии

 

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

 

Да, это я уже понял - выше и показали пример

Для заблокированных абонентов отправлять специальный RADIUS-атрибут (Mikrotik-Address-List) который поместит абонента в нужный address-list, который можно уже перенаправлять на заглушки и оставлять доступ только до определенных ресурсов.

 

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

 

Тут речь идет об авторизации абонентов через PPPoE

[Saab95]

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

 

Хотспот это только для хотспотов. Некоторые операторы используют его для предоставления услуг, что в корне не правильно.

 

Для заблокированных абонентов отправлять специальный RADIUS-атрибут (Mikrotik-Address-List) который поместит абонента в нужный address-list, который можно уже перенаправлять на заглушки и оставлять доступ только до определенных ресурсов.

 

Если абонент уже подключен, то указанный атрибут не повлияет на ситуацию.

Если используется радиус, то он должен только авторизовать абонентов при подключении, и выдать им нужную скорость. Блокировки лучше всего делать через отправляемые отдельно команды по ssh или telnet.

[AKim]

Хотспот это только для хотспотов. Некоторые операторы используют его для предоставления услуг, что в корне не правильно.

 

открываем обсуждаемый мануал, смотрим 6.Настройка Mikrotik

 

Хотспот отлично идёт под ipoe, вплоть до смены мак адреса через ввод пароля от лк на странице заглушке.

[vaddem]

Если абонент уже подключен, то указанный атрибут не повлияет на ситуацию.

Если используется радиус, то он должен только авторизовать абонентов при подключении, и выдать им нужную скорость. Блокировки лучше всего делать через отправляемые отдельно команды по ssh или telnet.

 

Тут Вы не правы.

Подключенному абоненту можно передать RADIUS атрибут через radclient

 

Например выдать нужную скорость:

echo "User-Name={Login},Mikrotik-Rate-Limit={Shape}" | radclient {NAS-IP}:3799 coa {SECRET}

 

Или поместить ip клиента в определенный Address-List

echo "User-Name={Login},Mikrotik-Address-List={List-Name}" | radclient {NAS-IP}:3799 coa {SECRET}

 

И не надо при этом дергать PPPoE сессию.

[Saab95]

Например выдать нужную скорость:

echo "User-Name={Login},Mikrotik-Rate-Limit={Shape}" | radclient {NAS-IP}:3799 coa {SECRET}

 

Или поместить ip клиента в определенный Address-List

echo "User-Name={Login},Mikrotik-Address-List={List-Name}" | radclient {NAS-IP}:3799 coa {SECRET}

 

А после подключения абонента как его собираетесь в другой адрес лист перекидывать и скорость изменять?

 

открываем обсуждаемый мануал, смотрим 6.Настройка Mikrotik

 

Хотспот отлично идёт под ipoe, вплоть до смены мак адреса через ввод пароля от лк на странице заглушке.

 

Это не правильно. Во первых, хотспот требует лицензии L6, если много абонентов, кроме всего сильно нагружает оборудование и не отличается должной стабильностью при большом количестве трафика. Все то же самое легко реализуется через DHCP сервер. Кроме всего представленный там хотспот не подходит под нормальное IPoE, когда каждый абонент в свой влан упакован. Некоторые операторы реализовывали такое на хотспоте - постоянно ловят разные проблемы.

[saaremaa]

 

А после подключения абонента как его собираетесь в другой адрес лист перекидывать и скорость изменять?

COA - же. Mikrotik-Rate-Limit и Mikrotik-Address-List можно менять динамически через Radius.

[vaddem]

А после подключения абонента как его собираетесь в другой адрес лист перекидывать и скорость изменять?

 

Теми же командами.

Какая разница то, или по ssh подключился - выполнил команду, или через CoA передал атрибуты (что в данном случае более правильно, т.к. авторизация работает через Radius) ?

Повторюсь, сессию клиента дергать при этом не надо - все выполняется динамически.

[Saab95]

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

 

Можно сделать полнофункциональный аналог на статических паролях на оборудовании с несколькими серверами доступа и т.п.

[AKim]

Это не правильно. Во первых, хотспот требует лицензии L6, если много абонентов, кроме всего сильно нагружает оборудование и не отличается должной стабильностью при большом количестве трафика. Все то же самое легко реализуется через DHCP сервер. Кроме всего представленный там хотспот не подходит под нормальное IPoE, когда каждый абонент в свой влан упакован. Некоторые операторы реализовывали такое на хотспоте - постоянно ловят разные проблемы.

 

рукалицо блин)

[vaddem]

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

 

Во время работ на сервере с биллингом, или каких либо там проблем, ничто не мешает использовать альтернативный Radius-сервер, где на все Access-Request можно отвечать Access-Accept. Так что на мой взгляд про то, что Radius не так технология - полный бред.

[Saab95]

Во время работ на сервере с биллингом, или каких либо там проблем, ничто не мешает использовать альтернативный Radius-сервер, где на все Access-Request можно отвечать Access-Accept. Так что на мой взгляд про то, что Radius не так технология - полный бред.

 

Ну и адреса раздавать из резервного пула?

 

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

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

 

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

[AKim]

Ну и адреса раздавать из резервного пула?

 

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

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

 

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

 

Сааб, ты временами как начнёшь загонять "свои теории заговоров".