Перейти до

Ubilling + NAS на FreeBSD бортжурнал починаючого адміна


Рекомендованные сообщения

Опубліковано: (відредаговано)

я хочу  відмовився від EoIP після того як  напиляли урапвління DHCP сервером з білінгу.

менше інтерфейсів, менше сексу)

 

от з UHW тепер задачка, мережа(172.32.0.0/20) з насу змаршрутизована на білінг і 172.32.0.1 пінгується, але так як DHCP сервер на мікротіку, то білінг нічого незнає про МАК клієнта який на ньго попадає. (NMLEASES=/var/log/dhcpd.log)

 

 

 

 

 

у NMLEASES можна вказати два місця звідки витягувати невідомі ІР?

 

Хвилини 4 часу на таке потрібно. Можете назвати хоч одну причину навіщо це може бути потрібним хочаб одному адекватному провайдеру? Ключове слово - провайдеру.

 

ну тепер можу





/var/log/dhcpd.log

для локальних юзерів





NMLEASES = /var/log/messages

для юзерів з мікротіка.

Відредаговано mgo
Ссылка на сообщение
Поделиться на других сайтах
  • Відповіді 1,8k
  • Створено
  • Остання відповідь

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Вітаю Татко!   

Не так вже й багато   Ход коньом:   # cat /bin/clear_dhcpdlog #!/bin/sh /bin/echo > /var/log/dhcpd.log /usr/local/etc/rc.d/isc-dhcpd restart # chmod a+x /bin/clear_dhcpdlog # crontab -e

http://wiki.ubilling.net.ua/doku.php?id=userstats       Расист? http://wiki.ubilling.net.ua/doku.php?id=userstats

Posted Images

 

 

 

Как поднять EoIP туннель к Mikrotik'у? 

 

1. Source EoIP Mikrotik,   /usr/ports/net/ng_mikrotik_eoip/

2. Compile and Install ports,   make install clean

3. Refresh after Compile and Install,   rehash (enter), su (enter)

4. Now Configure EoIP on rc.local (startup freebsd) :

 

# EOIP id-xxx

ngctl mkpeer eiface t ether

ngctl rmhook t

ngctl mkpeer ngeth0: mikrotik_eoip ether xxx   > id EoIP

ngctl mkpeer ngeth0:ether ksocket out inet/raw/gre

ngctl msg ngeth0:ether.out connect inet/xxx.xxx.xxx.xxx  > remote address

ifconfig ngeth0 up   > set interface up or active

ifconfig ngeth0 ether xx:xx:xx:xx:xx:xx   > set mac-address

 

Вы делали это?  :)

 

Спасибо, установил - заработало! 

 

P.s. получился хороший мануал для работы с EoIP)

 

Кстати, как настроить чтоб при подключение двух NAS (в виде Mikrotik), юзеры использовали свой NAS(а он в свою очередь свой канал  напрямую в инет, а не в тунель)?

 

[думаю проблема будет с DHCP, так как используется один адрес шлюза]

Очень важно чтоб осталась одна сеть. (и одни и те же адреса у конечных пользователей)

 

 

 

я хочу  відмовився від EoIP після того як  напиляли урапвління DHCP сервером з білінгу.

А когда появилась такая функциональность? Можно по подробнее? Как я понял EoIP единственная возможность стабильной работы  DHCP и удаленного биллинга, разве не так?

Ссылка на сообщение
Поделиться на других сайтах
Кстати, как настроить чтоб при подключение двух NAS (в виде Mikrotik), юзеры использовали свой NAS(а он в свою очередь свой канал  напрямую в инет, а не в тунель)?

 

настаиваете как обычно WAN, NAT и т.п, а тоннель добавляется в бридж с пользовательскими интерфейсами...  :)

 

 

А когда появилась такая функциональность? Можно по подробнее?

Она и была изначально, только незадокументированная, т.к не работала должным образом... сейчас, в принципе, всё хорошо и с версии 0.4.3 сможете использовать, а сейчас могу предложить опробовать это дело на досуге, обновившись до current версии и обновив все скрипты в папке /etc/stargazer/...

 

 

 

Как я понял EoIP единственная возможность стабильной работы  DHCP и удаленного биллинга, разве не так?

EoIP - это возможность создать прозрачный L2 тоннель, по которому смогут пересылаться DHCP пакеты... По поводу стабильной работы DHCP на MikroTik я ничего сказать не могу, т.к сам это не использовал.. Поэтому я придерживаюсь того, чтобы использовать ISC-DHCP на FreeBSD, а использование MikroTik DHCP - только в самых-самых крайних случаях, но лично у меня они еще не наступали...  :)

Ссылка на сообщение
Поделиться на других сайтах

 

Кстати, как настроить чтоб при подключение двух NAS (в виде Mikrotik), юзеры использовали свой NAS(а он в свою очередь свой канал  напрямую в инет, а не в тунель)?

 

настаиваете как обычно WAN, NAT и т.п, а тоннель добавляется в бридж с пользовательскими интерфейсами...  :)

 

 

 

 

 

И тогда при использование двух NAS, куда пойдут пакеты(на какой будет default gateway) ?

 

note:

GW для всех юзеров одной под сети раздается один и тот же! На одном и на втором NAS'е ,? так как получат они онфигу с одного dhcp(c billing'a) 

 

т.е. пусть будет IP 172.16.0.1 в виде настроенного default gateway в конфиге dhcp на биллинге.

 юзеры c  первом Mikrotik'а получат туже самую конфигу, и пойдут правильно, найдя нужный порт  и адрес на текущем Mikrotik'е!

 юзеры со второго Mikrotik'а получат туже самую конфигу, и все дружно будут ходить через указанный шлюз, а он на первом!

Ссылка на сообщение
Поделиться на других сайтах

 

И тогда при использование двух NAS, куда пойдут пакеты(на какой будет default gateway) ?

note:

GW для всех юзеров одной под сети раздается один и тот же! На одном и на втором NAS'е ,? так как получат они онфигу с одного dhcp(c billing'a) 

т.е. пусть будет IP 172.16.0.1 в виде настроенного default gateway в конфиге dhcp на биллинге.

 юзеры c  первом Mikrotik'а получат туже самую конфигу, и пойдут правильно, найдя нужный порт  и адрес на текущем Mikrotik'е!

 юзеры со второго Mikrotik'а получат туже самую конфигу, и все дружно будут ходить через указанный шлюз, а он на первом!

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

Ссылка на сообщение
Поделиться на других сайтах

шейпер на реальний IP адрес

 

на мене (зоніший IP білінгу) змаршрутизована підмережа рельників, аліасом стоїть перший IP на юер інтерфейсі.

клієнт получає адресу, ходить в нет, все супер.

 

тільки  його не шейпить((

підкажіть де грабля

Ссылка на сообщение
Поделиться на других сайтах

Дивимось via який інтерфейс в нас намальовано правила шейпу, і слухаємо на ньому tcpdump. Більше там нічому "не працювати".

Ссылка на сообщение
Поделиться на других сайтах
  • 4 weeks later...

цікава ситуація з одним із насів Мікротік

 

юзера з негативним балансом не відрубує при знятті АП.

 

/var/stargazer/allconnect.log 

запису про подію немає  при ресеті "підвисшого"  корстувача, але варто зробити йому баланс >=0 і назад в мінус зразу все працює (відключає).

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

нічого не змінилося

юзер якому міняв баланс  на 0 і знову в мінус ресетиться 

решта ні(  незалежно що там стирчить 

Відредаговано mgo
Ссылка на сообщение
Поделиться на других сайтах

Стоп. Я тупий - не дочитав вашу проблему до кінця.

 

1. stargazer вважає, що якщо в користувача "Бабло < Кредит" - користувач "неактивний"

2. для "неактивного" користувача не виконуються жодні OnDisconnect - оскільки він вже "неактивний" і нічого для нього виконувати, та OnConnect - оскільки він теж неактивний.

3. при переході цієї межі активності, а також при встановленні флагів "відморожено" та "вимкнено" stargazer одноразово виконує OnDisconnect.

4. все вищевказане також стосується віддалених NAS під керуванням rscriptd

 

Якщо при переході межі "активності"  юзера не дісконектнуло, на це є рівно одна причина - було втрачено звязок з віддаленим NAS. У випадку використання Direct також частим є залипання самого ssh сервера мікротіка при численних зверненнях. Тому зараз рекомендується використовувати тільки ось цю реалізацію від jcomm.

Ссылка на сообщение
Поделиться на других сайтах

саме ця реалізація і використовується від jcomm

 

було втрачено звязок з віддаленим NAS

 

теж так подумав зразу але це вже другий місяць і цей самий нас.

ось лог неактивного користувача якому тицьнув  ресет 

/var/stargazer/allconnect.log

2013-08-01 14:30:04 - [Ubilling] - OnConnect started for user `klcentralna30ap_t1ne`:
2013-08-01 14:30:05 - [Executer] - SUCCESS: Address List entry with ID - `*39` was updated;
2013-08-01 14:30:05 - [Executer] - SUCCESS: Queue entry with ID - `*3B` was updated;
2013-08-01 14:30:05 - [Executer] - SUCCESS: ARP entry with ID - `*11B` was updated;
2013-08-01 14:30:05 - [Ubilling] - Elapsed time: 1.363 sec.

2013-08-01 14:30:06 - [Ubilling] - OnDisconnect started for user `klcentralna30ap_t1ne`:
2013-08-01 14:30:07 - [Executer] - SUCCESS: Address List entry with ID - `*39` was updated;
2013-08-01 14:30:07 - [Ubilling] - Elapsed time: 0.632 sec.

так  з усіма неактивними (баланс < кредит) на всіх насах.

окрім "підвисших",

 

 

 

2. для "неактивного" користувача не виконуються жодні OnDisconnect - оскільки він вже "неактивний" і нічого для нього виконувати, та OnConnect - оскільки він теж неактивний.

3. при переході цієї межі активності, а також при встановленні флагів "відморожено" та "вимкнено" stargazer одноразово виконує OnDisconnect.

 

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

Ссылка на сообщение
Поделиться на других сайтах

 

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

Для користувача з "грошей<кредит" цього взагалі не повинно відбуватись.

Ссылка на сообщение
Поделиться на других сайтах

рестарт старгейзера і все гут, усі боржники   відключені.

 

Для користувача з "грошей<кредит" цього взагалі не повинно відбуватись.

 

алеж відбувається.

Ссылка на сообщение
Поделиться на других сайтах

 

алеж відбувається.

Але не може ж.

Старгейзер не вміє і не повинен кликати OnDisconnect для вже відімкнених користувачів.

Ссылка на сообщение
Поделиться на других сайтах

подивився більш детально, тільки свіжим викликається (тим, що тількищо баланс перейшов у мінус), мабудь з іншого насу тоже на такого свіжого попав і зробив висновок для всіх.

 

після рестарту старгейзера локальний нас  загнувся((

юзер адресу одержує, по мак пінгується 1-3мс, по IP пінг до 3000 доходить, або взагалі відсутний.

активні в табличках 3 і 4 сидять.

а нет не їде.

от думаю, що  поламав

1. БД 

     але ж усі решта наси фунциклірують

...

Ссылка на сообщение
Поделиться на других сайтах

 

по IP пінг до 3000 доходить, або взагалі відсутний.

Эммм, а це точно не фізична проблема, з дротами/портами скажімо?

 

 

після рестарту старгейзера локальний нас  загнувся((

оО

Ссылка на сообщение
Поделиться на других сайтах

 

 

Цитата

 

 

 

після рестарту старгейзера локальний нас загнувся((

 

оО

killall stargazer зробив х-зна може через неочікуване завершення база покоцалась

 

у одного юзеря мак пропав(

при спробі переписати каже, що уже такий є.

 

Эммм, а це точно не фізична проблема, з дротами/портами скажімо?

 

по мак пінгується 1-3мс

 

але йду дроти/порти первіряти.

Ссылка на сообщение
Поделиться на других сайтах

 

при спробі переписати каже, що уже такий є.

SELECT * from `nethosts` WHERE `mac` LIKE 'отой_мак_юзера'

 

 

по мак пінгується 1-3мс

це пофіг

Ссылка на сообщение
Поделиться на других сайтах

 

з якогось перепугу був на видаленому юзеру Спасибі!

Хрінь якась - nethosts при видаленні мав би чиститись в першу чергу. Зараз перевірю.

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)
Хрінь якась 

 

 

після 

DELETE * from `nethosts` WHERE `mac` LIKE 'отой_мак_юзера' 

мак  став нормально.

 

до того пробував шукати через пошук юзера по мак (вебморда) нічого не знаходив.

Відредаговано mgo
Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від 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.
    • Від 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  
      Повний чейнджлог
      Оновлена демка
       

    • Від 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);  
    • Від Zend
      Продам сабж.
      2 контроллера CA07336-C001, в каждом по одном интерфейсном модуле CA07336-C009 (2 x 1Gbps iSCSI)
      HDD: 24 x 900GB SAS 10K
      Исправен.
      С ним могу продать шкафчик того же вендора.
       
      Стоимость - $4000, торг
       

    • Від Dilan
      Собственно ищу кто сделает такую связку с нуля под ключ. Тз высылаю в личку. Заранее спасибо.

×
×
  • Створити нове...