Jump to content

Два наса на один пул ip, питання чисто теоретичне.


Recommended Posts

Цікаво а чи реально, реалізація кучаген, тип підключення pppoe, nas на різних іп. Але якщо брати з одного пулу іп абонентам. Розумію що збочена реалізація але цікаво все ж).

Edited by ppv
Link to post
Share on other sites
4 часа назад, ppv сказав:

Цікаво а чи реально, реалізація кучаген, тип підключення pppoe, nas на різних іп. Але якщо брати з одного пулу іп абонентам. Розумію що збочена реалізація але цікаво все ж).

КупаГену взагалі без різниці, що і для кого генерувати. Є абонент, в підмережі для якої власне вказано NAS і якийсь набір шаблонів атрибутів - він бере і генерує. Немає абонента - не генерує.

Якщо ви мрієте про якесь редандансі оцих ваших pppoe NAS-ів (чому вони в вас взагалі мають падати, залишимо за кадром) можете подумати, собі, на дозвіллі, навіщо потрібна ось ця от кнопочка і супутні їй механіки

 

spacer.png

Link to post
Share on other sites
3 minutes ago, nightfly said:

КупаГену взагалі без різниці, що і для кого генерувати. Є абонент, в підмережі для якої власне вказано NAS і якийсь набір шаблонів атрибутів - він бере і генерує. Немає абонента - не генерує.

Якщо ви мрієте про якесь редандансі оцих ваших pppoe NAS-ів (чому вони в вас взагалі мають падати, залишимо за кадром) можете подумати, собі, на дозвіллі, навіщо потрібна ось ця от кнопочка і супутні їй механіки

 

spacer.png

 

Ну за кастомні настройки я знаю, читав але не спробував, мене цікавить зі сторони балансування навантаження на nas.

Link to post
Share on other sites
14 минут назад, ppv сказав:

Ну за кастомні настройки я знаю, читав але не спробував, мене цікавить зі сторони балансування навантаження на nas.

 

Ну припустимо. Хай собі авторизуються "де вийде" або "хто перший той і тато". Або я все ще не розумію в що ви намагаєтесь.

 

spacer.png

 

Link to post
Share on other sites

Ні ну я звісно попробую, як буде час. Абоненти зрозуміло що попадати будуть на який перший той і тато. Але я так розумію вони дьоргати іп будуть всі з одного пулу абонентам? Мене тільки це цікавило. Чесно кажучи про кастом я трохи забув що він існує , і думав чи буде воно працювати якщо 2 наси окремі з вказуванням на один пул. 

image.png.585cfbc5608bab79e13298727e173b8e.pngimage.png.f3f2b21ca2f75f3bf555441bb9e8d208.png 

Link to post
Share on other sites
6 минут назад, ppv сказав:

і думав чи буде воно працювати якщо 2 наси окремі з вказуванням на один пул. 

Мало би. Це вже залежить, від того, наскільки ви складних шляхів шукаєте.

Link to post
Share on other sites
1 minute ago, nightfly said:

Мало би. Це вже залежить, від того, наскільки ви складних шляхів шукаєте.

Та не шукаю, тому дякую що нагадали за реалізацію 

Link to post
Share on other sites

Немає за що.

Просто не бачу глибинного сенсу, плодити пачки реальних НАСів для однієї і тієї ж мережі, коли тут чисто задача "хочу, щоб радіус тупо авторизував клієнтів там де мені заманеться".

Плодити реальні НАС-и має сенс у кейсі "я тут мігрую з PPPoE на IPoE і хочу різні атрибути для одних й тих самих абонентів", чи типу того.

UPD: щось типу такого

 

spacer.png

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By sanyadnepr
      Приветствую всех.
      Подскажите пожалуйста где копнуть и нет ли проблемы со стороны протокола взаимодействия сити24 или возможно не учтена необходимая проверка в модуле сити24 в Ubilling, пока писал понял что похоже в проверке payID, но это не точно.  
      Недавно обнаружилось с сити24 начали прилетать дубликаты платежей, в целом платежей мало, два одинаковых запроса Pay с одинаковым transactionID и payID в одну секунду одному платежному ID при этом биллинг "думает" примерно чуть больше минуты и отвечает одним ответом <result>0</result>, сити24 утверждает что ответ они не получили и по протоколу дальше повторяет запросы дублем, биллинг ответ и так по кругу, сити24 спрашивает каким образом с одинаковым payID от сити24 билл продолжает обрабатывать запросы и пополнять абоненту счет раз в 5 минут примерно, на одну и туже сумму, ведь этот payID уже был обработан предполагают сити24 согласно протоколу.
      Конечно есть вопрос к сити24 зачем они дублем присылают два запроса, но они отвечают что эта ситуация учтена в протоколе и проблема на стороне биллинга, потому что он пополняет счет по уже обработанному одинаковому payID.
      При этом transactionID в дублях одинаковый, но с каждым новым дублем разный.
      Если зафаерволить запросы от сити24, но оставить возможность отвечать то после блокировки билл отправляет 2-3 минуты 6 ответов <account>0001</account>  <result>0</result>.
      После снятия блокировки, дубли и платежи нескольких проблемных абонентов прилетают так же по кругу, при этом и с некоторыми новыми пополнениями происходит аналогичная ситуация.
      В openpayz в платежах transactionID и не видно payID.
    • By nightfly
      Ubilling 1.4.3 rev 9058 The Bladewood Grove
       
      Зміни в структурі БД. alter.ini: нові опції OPHANIMFLOW_ENABLED та OPHANIMFLOW_URLS котрі вмикають та керують інтеграцією з OphanimFlow. alter:ini: нова опція PHOTOSTORAGE_POSTPROCESSING, що вмикає післяобробку зображень при завантаженні в Сховище зображень. alter:ini: нова опція PHOTOSTORAGE_WATERMARK, що вмикає розміщення вотермарки на всіх зображеннях, що завантажуються. alter:ini: нова опція PHOTOSTORAGE_RECOMPRESS, що вмикає зміну компрессії завантажених зображень. alter:ini: нова опція PHOTOSTORAGE_AUTORESIZE, що вмикає автоматичне та лагідне масштабування зображень конячих розмірів. alter:ini: нова опція PHOTOSTORAGE_DRAWIMGINFO, що вмикає вдруковування в зображення відлагоджувальної інформації. alter.ini: нова опція ONDEMAND_CHARTS, що вмикає відкладене завантаження графіків завантаження користувацької смуги. userstats.ini: нова опція OPHANIM_ENABLED, що вмикає інтеграцію OphanimFlow в кабінеті користувача. Модуль Заздрість: тепер авторизаційні дані пристроїв, не відображаються в списку пристроїв. Модуль “Заздрість”: при створенні та редагуванні пристроїв, для полів “пароль” та “enable пароль” тепер використовуються інпути паролів. Модуль “Заздрість”: заздрісним пристроям додано нове поле “Порт”. Тепер в скриптах можна використовувати, відповідний макрос {PORT}. Модуль “Статистика трафіку користувача”: проведено радикальний рефакторинг. Модуль “Статистика трафіку користувача”: додано опційну можливість, відображення трафіку отриманого з OphanimFlow. Модуль “Статистика трафіку користувача”: виправлено проблему невірного відображення залишку коштів на кінець місяця, при використанні Ішимури. Модуль “Статистика трафіку користувача”: додано можливість відображення графіків за останню годину з OphanimFlow. Модуль “Користувачі”: додано опційну можливість, відображення трафіку отриманого з OphanimFlow. Модуль “Сховище зображень”: тепер додатково перевіряє завантажувані зображення на тему їх валідності. Модуль “Фінансові операції”: виправлено відображення суми платежів користувача. Remote API: новий виклик ophanimtraff, який просто бере і синхронізує локальну БД з віддаленими джерелами OphanimFlow. Remote API: виклик userbynum тепер також опційно містить поле з “Платіжним ID” користувача. Глобально: у всіх полях вводу паролів, окрім форми входу, тепер відображається елемент керування “показати/приховати” пароль. Кабінет користувача: в модулі “Трафік” додано опційну можливість, відображення трафіку отриманого з OphanimFlow. Кабінет користувача: в модулі “Трафік” виправлено проблему невірного відображення залишку коштів на кінець місяця, при використанні Ішимури. Кабінет користувача: в модулі “Відеоспостереження” для NVR WolfRecorder замінено розділювач попередньо заповнених даних авторизації. OpenPayz: додано frontend portmonemulti, для отримання платежів від різних контрагентів. Інформацію по контрагентам бере з біллінгу, також використовую розширену інформацію контрагента. Платіжна система в контрагенті мусить бути створена, як PORTMONE 1984tech: додано функціонал генерації RPZ для isc-bind, спасибі @misterromanbush  
      Повний чейнджлог
      Оновлена демка
       

    • By mac
      Здається, після оновлення PHP 7.4 до PHP 8.2 feesharvester припинив працювати:
       
      /usr/local/bin/curl "http://127.0.0.1/billing/?module=remoteapi&key={SERIAL}&action=feesharvester" <br /> <b>Fatal error</b>: Uncaught TypeError: Unsupported operand types: string - string in {UBPATH}/billing/api/libs/api.fundsflow.php:570 Stack trace: #0 {UBPATH}/billing/modules/remoteapi/feesharvester.php(22): FundsFlow-&gt;harvestFees('2024-01') ...  
      Невеличке розслідування врешті з'ясувало, що це через наявність пробілу у деяких логінах абонентів. Як так сталося? Тому що інколи був неуважно додан трейлінг пробіл до номеру будинка і цей пробіл потрапив до логіну абоненту. Логін абоненту неможливо змінити ніяким чином штатними засобами. Я не розглядаю створення нового абонента для усунення помілки.

      Був обран такий шлях вирішення проблеми. Заміну функції php explode() знайшов у мережі. Мабуть це станеться в нагоді:

       
      diff api.fundsflow.php.bak api.fundsflow.php.new 559c559 < $eachfee = explode(' ', $eachline); --- > $eachfee = preg_split("~(?<!\\\\)(?:\\\\{2})*'[^'\\\\]*(?:\\\\.[^'\\\\]*)*'(*SKIP)(*F)|\s+~s" , $eachline);  
    • By Dilan
      Собственно ищу кто сделает такую связку с нуля под ключ. Тз высылаю в личку. Заранее спасибо.
    • By ukrtelekom
      Доброго часу!
      Шукається адміністратор віддалений для разової роботи по коригуванню працюючого Ubilling з мікротами. Якщо стосунки зклєяться- то до постійної додаткової копійки. 
      Всім заздалегідь дякую. Хейти, бажано не писати. Контакти в приватні повідомлення або O73283344O
×
×
  • Create New...