lidia Опубликовано 19 января, 2017 · Жалоба Одной из самых популярных тем этого раздела форума является интеграция биллинга с Mikrotik. Для того чтобы помочь операторам связи разобраться в этом вопросе, мы написали статью, в которой приводим пример интеграции АСР LANBilling с Mikrotik для сервисной модели IPoE с авторизацией по MAC адресу клиента. В скором времени планируем добавить описание интеграции АСР LANBilling с Mikrotik для PPPoE. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
saaremaa Опубликовано 19 января, 2017 · Жалоба Спасибо за статью. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lidia Опубликовано 31 января, 2017 · Жалоба Написали статью по интеграции АСР LANBilling с Mikrotik для PPPoE, включающую как настройку биллинга, так и самого микротика. Надеемся, что статья будет полезной. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
saaremaa Опубликовано 31 января, 2017 · Жалоба Я бы не стал собирать все интерфейсы в бридж и вешать на него pppoe-server т.к. в конечном счете получите боооольшой l2 broadcast domain (если только не использовать split horizon). IMHO лучшим способом было вешать отдельный pppoe-server на каждый интерфейс терминации L2? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vaddem Опубликовано 1 февраля, 2017 · Жалоба 7. ЗаключениеНа этом настройку можно считать законченной. При желании возможно дополнить конфигурацию сбором Netflow статистики, правилами редиректа на страницу-заглушку при отрицательном балансе, добавить поддержку IPv6 адресации. Интересно, каким способом реализовывают правила редиректов на страницу-заглушку при отрицательном балансе ? Пока вижу только вариант использования для pppoe авторизации гостевую сеть, и заворачивать ее на заглушку - а иначе сессия подниматься не будет и доступа никуда нет. Есть еще способы ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dereiff Опубликовано 1 февраля, 2017 · Жалоба saaremaa Да, вы правы, объединение большого числа клиентов в один L2 может привести к проблемам с броудкаст штормом и прочим радостям. Но давайте честно, такую ситуацию можно получить и с pppoe сервером всего на одном порту. Не надо забывать что свичи тоже требуют настроек в части port isolate, broadcast limit. Мы не старались написать статью в духе "как по быстрому стать интернет провайдером имея только mikrotik и LANBilling". Это лишь база, на основе которой каждый волен сделать подходящий для себя вариант. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dereiff Опубликовано 1 февраля, 2017 · Жалоба vaddem есть способ от самого микротика - http://wiki.mikrotik.com/wiki/Payment_Reminders В свою очередь АСР вполне в состоянии выдавать различный набор RADIUS атрибутов при нормальной авторизации и при блокировке. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vaddem Опубликовано 1 февраля, 2017 · Жалоба vaddem есть способ от самого микротика - http://wiki.mikrotik.com/wiki/Payment_Reminders В свою очередь АСР вполне в состоянии выдавать различный набор RADIUS атрибутов при нормальной авторизации и при блокировке. А, понял - т.е. выдавать атрибут Mikrotik-Address-List, добавляя этим данного клиента в определенную группу И уже настраивать правила для этой группы Да, тоже вариант - мне даже больше нравится, чем с гостевой сетью. Спасибо :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 1 февраля, 2017 · Жалоба Нужно не выдавать полную конфигурацию микротика, а только то, что нужно. Если авторизация PPPoE - то только настройка связки PPPoE и биллинга. Про создание серверов на интерфейсах, бриджи и т.п. вообще не надо упоминать. Так же схема IPoE по маку устаревшая технология, почему бы не сделать то же самое, только на базе порта или влана? Получается новички провайдеры почитают настройки, сделают все не правильно, и появятся проблемы там, где их можно было бы избежать. Кроме всего зачем в инструкции по настройке PPPoE рисунок 9 в профиле указан бридж? Указание бриджа в профиле означает, что все абоненты будут добавляться в интерфейсы бриджа и между ними будет прямая L2 связь, что вообще для абонентского доступа не применимо и опасно, кроме всего вызывает разного рода глюки=) Эта настройка применяется для проброса L2 трафика по аналогии с EoIP туннелями, и корни ее идут из OVPN. Кроме всего ARP на интерфейсах, где работает PPPoE отключают, что бы не создавать излишнюю нагрузку, а так же MAC сервер. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 1 февраля, 2017 · Жалоба Мы не старались написать статью в духе "как по быстрому стать интернет провайдером имея только mikrotik и LANBilling". Это лишь база, на основе которой каждый волен сделать подходящий для себя вариант. Статья в духе - "как я провел это лето", на практике ее применять опасно. На этой базе ничего сделать нельзя. Интересно, каким способом реализовывают правила редиректов на страницу-заглушку при отрицательном балансе ? Пока вижу только вариант использования для pppoe авторизации гостевую сеть, и заворачивать ее на заглушку - а иначе сессия подниматься не будет и доступа никуда нет. Стандартный способ редиректа это веб прокси, никакие гостевые сети и вообще какие либо сети и IP адреса, отличные от тех, которые выдают абонентам, использовать нельзя. При PPPoE работает только PPPoE. Единственное, для чего можно менять IP адреса у абонентов - это если раздаются белые адреса, и их на всех не хватает, и те, кто не заплатил, что бы не занимали их в ущерб других пользователей. Я бы не стал собирать все интерфейсы в бридж и вешать на него pppoe-server т.к. в конечном счете получите боооольшой l2 broadcast domain (если только не использовать split horizon). IMHO лучшим способом было вешать отдельный pppoe-server на каждый интерфейс терминации L2? Это и есть правильная схема, кроме всего нужно по всему пути следования данных, если используются коммутаторы, заблокировать все. Все протоколы кроме PPPoE. Естественно, на коммутаторах изоляция портов абонента, и отдельный влан в центр с каждого коммутатора. Тогда не бывает проблем. Одной из самых популярных тем этого раздела форума является интеграция биллинга с Mikrotik. Она по этому и является, что постоянно хотят странного. Вот и разработчики биллинга решили показать свое видение по этому вопросу, вместо того, что бы уточнить у своих клиентов, какие схемы настройки они используют и провести выборку настроек, действительно отработанных на реальной сети, где все ошибки уже устранены. Или посмотреть что пишут по этому поводу в интернете. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vaddem Опубликовано 1 февраля, 2017 · Жалоба Стандартный способ редиректа это веб прокси, никакие гостевые сети и вообще какие либо сети и IP адреса, отличные от тех, которые выдают абонентам, использовать нельзя. При PPPoE работает только PPPoE. Единственное, для чего можно менять IP адреса у абонентов - это если раздаются белые адреса, и их на всех не хватает, и те, кто не заплатил, что бы не занимали их в ущерб других пользователей. Имелось ввиду как на уровне биллинга делать, а не микротика - с настройками микротика все понятно. Про гостевые сети - это IP, полученные при поднятии сессии PPPoE. Сейчас просто у нас это как работает, если абонент активный - выдается адрес из одной сети, если не активный (заблокированный по балансу например) - то выдается из другой сети, на которую настроены правила редиректа на заглушку с информацией о текущем балансе клиента и что ему необходимо пополнить баланс. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 1 февраля, 2017 · Жалоба Про гостевые сети - это 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, то есть адрес сервера, на которое идет перенаправление. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AKim Опубликовано 2 февраля, 2017 · Жалоба Интересно, каким способом реализовывают правила редиректов на страницу-заглушку при отрицательном балансе ? Пока вижу только вариант использования для pppoe авторизации гостевую сеть, и заворачивать ее на заглушку - а иначе сессия подниматься не будет и доступа никуда нет. Есть еще способы ? если используется hotspot, то не авторизованный абонент попадает на заглушку по умолчанию. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vaddem Опубликовано 2 февраля, 2017 · Жалоба Нельзя так делать. Есть операторы которые выдают IP в сеть, и там же работает PPPoE. Типа что если абонент не настроил себе подключение, что бы вылезла соответствующая страничка уведомления. Это со стороны лояльности к абонентам правильно, а вот по нагрузке и мусору нет, т.к. на центральных устройствах количество полученных IP адресов примерно 70 процентов от всех абонентов. При этом даже некоторые роутеры IP адрес получают=) По итогу встречаются проблемы, почему интернет не работает - роутер или компьютер отправляет запросы на доступ в локалку, а не PPPoE соединение. Да не делаем мы так, не выдаем адреса по локальной сети :) Речь идет именно про IP PPPoE сессии Если абонент не активный, то его IP адрес нужно помещать в адресный лист микротика, по этому адрес листу делать перенаправление на веб прокси, а оно перекинет на страничку уведомления. При этом там же создается блокировка на доступ с этих адресов в интернет и локалку, если есть. В этом случае решаются сразу все проблемы. Ведь представьте, конец месяца и у абонента нет средств, ему нужно заменить IP адрес, а тут абонент увидел что нет средств и захотел взять обещанный платеж, ему опять нужно вернуть старый IP, а потом он не оплатил обещанную сумму и снова его IP перекинуть, потом заплатил и вновь менять IP адрес=) Да, это я уже понял - выше и показали пример Для заблокированных абонентов отправлять специальный RADIUS-атрибут (Mikrotik-Address-List) который поместит абонента в нужный address-list, который можно уже перенаправлять на заглушки и оставлять доступ только до определенных ресурсов. если используется hotspot, то не авторизованный абонент попадает на заглушку по умолчанию. Тут речь идет об авторизации абонентов через PPPoE Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 2 февраля, 2017 · Жалоба если используется hotspot, то не авторизованный абонент попадает на заглушку по умолчанию. Хотспот это только для хотспотов. Некоторые операторы используют его для предоставления услуг, что в корне не правильно. Для заблокированных абонентов отправлять специальный RADIUS-атрибут (Mikrotik-Address-List) который поместит абонента в нужный address-list, который можно уже перенаправлять на заглушки и оставлять доступ только до определенных ресурсов. Если абонент уже подключен, то указанный атрибут не повлияет на ситуацию. Если используется радиус, то он должен только авторизовать абонентов при подключении, и выдать им нужную скорость. Блокировки лучше всего делать через отправляемые отдельно команды по ssh или telnet. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AKim Опубликовано 2 февраля, 2017 · Жалоба Хотспот это только для хотспотов. Некоторые операторы используют его для предоставления услуг, что в корне не правильно. открываем обсуждаемый мануал, смотрим 6.Настройка Mikrotik Хотспот отлично идёт под ipoe, вплоть до смены мак адреса через ввод пароля от лк на странице заглушке. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vaddem Опубликовано 3 февраля, 2017 · Жалоба Если абонент уже подключен, то указанный атрибут не повлияет на ситуацию. Если используется радиус, то он должен только авторизовать абонентов при подключении, и выдать им нужную скорость. Блокировки лучше всего делать через отправляемые отдельно команды по 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 сессию. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 3 февраля, 2017 · Жалоба Например выдать нужную скорость: 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, когда каждый абонент в свой влан упакован. Некоторые операторы реализовывали такое на хотспоте - постоянно ловят разные проблемы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
saaremaa Опубликовано 3 февраля, 2017 · Жалоба А после подключения абонента как его собираетесь в другой адрес лист перекидывать и скорость изменять? COA - же. Mikrotik-Rate-Limit и Mikrotik-Address-List можно менять динамически через Radius. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vaddem Опубликовано 3 февраля, 2017 · Жалоба А после подключения абонента как его собираетесь в другой адрес лист перекидывать и скорость изменять? Теми же командами. Какая разница то, или по ssh подключился - выполнил команду, или через CoA передал атрибуты (что в данном случае более правильно, т.к. авторизация работает через Radius) ? Повторюсь, сессию клиента дергать при этом не надо - все выполняется динамически. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 3 февраля, 2017 · Жалоба Radius не та технология, которую можно использовать на подобного рода биллингах. Т.к. в случае проблем с биллингом абоненты не смогут авторизоваться. Можно сделать полнофункциональный аналог на статических паролях на оборудовании с несколькими серверами доступа и т.п. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AKim Опубликовано 4 февраля, 2017 · Жалоба Это не правильно. Во первых, хотспот требует лицензии L6, если много абонентов, кроме всего сильно нагружает оборудование и не отличается должной стабильностью при большом количестве трафика. Все то же самое легко реализуется через DHCP сервер. Кроме всего представленный там хотспот не подходит под нормальное IPoE, когда каждый абонент в свой влан упакован. Некоторые операторы реализовывали такое на хотспоте - постоянно ловят разные проблемы. рукалицо блин) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vaddem Опубликовано 4 февраля, 2017 · Жалоба Radius не та технология, которую можно использовать на подобного рода биллингах. Т.к. в случае проблем с биллингом абоненты не смогут авторизоваться. Во время работ на сервере с биллингом, или каких либо там проблем, ничто не мешает использовать альтернативный Radius-сервер, где на все Access-Request можно отвечать Access-Accept. Так что на мой взгляд про то, что Radius не так технология - полный бред. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 4 февраля, 2017 · Жалоба Во время работ на сервере с биллингом, или каких либо там проблем, ничто не мешает использовать альтернативный Radius-сервер, где на все Access-Request можно отвечать Access-Accept. Так что на мой взгляд про то, что Radius не так технология - полный бред. Ну и адреса раздавать из резервного пула? Вообще, радиус нужен там, где он нужен - например есть несколько серверов доступа, или разные абоненты подключаются к своим серверам в разных местах и т.п. То есть в тех случаях, где применение статических записей не удобно. При этом для резервирования применяют не указанные вами радиус сервера, которые тупо всех пускают, а работающие по нормальной, резервной схеме, где на них заранее загружены соответствующие таблицы, либо они работают с сетевой базой, или схема резервирования биллингов сама себя резервирует. Если сервер доступа только один, и биллинг один, то работать по схеме с радиусом не самая лучшая схема - все то же самое можно сделать и на статических записях, если это PPPoE или иные туннельные протоколы. Для IPoE можно вообще без радиуса работать, если абонент жестко к своему влану привязан. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AKim Опубликовано 4 февраля, 2017 · Жалоба Ну и адреса раздавать из резервного пула? Вообще, радиус нужен там, где он нужен - например есть несколько серверов доступа, или разные абоненты подключаются к своим серверам в разных местах и т.п. То есть в тех случаях, где применение статических записей не удобно. При этом для резервирования применяют не указанные вами радиус сервера, которые тупо всех пускают, а работающие по нормальной, резервной схеме, где на них заранее загружены соответствующие таблицы, либо они работают с сетевой базой, или схема резервирования биллингов сама себя резервирует. Если сервер доступа только один, и биллинг один, то работать по схеме с радиусом не самая лучшая схема - все то же самое можно сделать и на статических записях, если это PPPoE или иные туннельные протоколы. Для IPoE можно вообще без радиуса работать, если абонент жестко к своему влану привязан. Сааб, ты временами как начнёшь загонять "свои теории заговоров". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...