Перейти до

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 користувачів

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

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

    • Від Remez
      Ценник 5,500
       
      в наличии 3 шт
       
       





    • Від mac
      Глюк в тому, що один (так - тільки один) mac адрес onu існує в білінгу у вигляді строки. Це трохи заважає.
      olt - bdcom gepon.
      Наскільки зрозумів, це виключно проблема реалізації snmpwalk у freebsd, де snmpwalk може на свій розсуд віддати mac адресу не як hex-string, а як звичайний string.
      Можливо snmpwalk тригериться на якомусь символі, мені невідомо.
       
      # tcpdump -vv -i em0 udp port 161 and host olt and host ub | grep "3320.101.10.4.1.1.241 ... olt.snmp > ub.47940: [udp sum ok] { SNMPv2c C="*****" { GetResponse(44) R=93278354 E:3320.101.10.4.1.1.241="8LO"W*" } } ub.47940 > olt.snmp: [udp sum ok] { SNMPv2c C="*****" { GetNextRequest(34) R=93278355 E:3320.101.10.4.1.1.241 } } snmpwalk -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1 SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = STRING: "8LO\"W*" snmpwalk -Ox -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1 SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = Hex-STRING: 38 4C 4F 22 57 2A  
      Це стосується таких параметрів у snmp конфізі bdcom
       
      [signal] MACINDEX=".1.3.6.1.4.1.3320.101.10.4.1.1" [misc] ONUINDEX=".1.3.6.1.4.1.3320.101.11.1.1.3"  
      За для усунення глюку спробував трошки змінити код і завдати тип snmp параметру явно у ./api/libs/api.ponbdcom.php у function collect()
      Це працює. Мабуть станеться у нагоді:
       
      # diff api.ponbdcom.php{.new,.bak} 37c37 < $onuIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE); --- > $onuIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE); 91c91 < $macIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE); --- > $macIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE);  
      P.S. Створив тему, а зараз міркую: а може це глюк у ПЗ olt. Оновлю фірмваре olt та перевірю...
       

    • Від Plastilin
      Вітаю. Маю наступний комплект. Ubilling на Debian + Mikrotik CHR як маршрутизатор. Наче все запустилось, але виникло питання яке не вдається розрулити. Читав Wiki, ковиряв, читав знову Wiki, знову ковиряв - не допомогло.
      Чи можливо якось визначити конкретну IP адресу з пулу який видає Mikrotik клієнту через Radius? Мені пропонує обрати наступну вільну адресу з пулу при спробі зміни адреси?
      З цього з'являється додаткове питання, чи можливо контролювати доступ користувачам у яких IP назначений статично, тобто прописаний вручну? Наприклад при зміні статусу не активний - пхати до Firewall Mikrotik правила заборони доступу з IP адреси визначеної вручну, навіть якщо вона не отримана по DHCP.
       
      UPD: з першою частиною знайшов: IP_CUSTOM=1 в alter.ini 
    • Від ppv
      Потрібно було витерти одну мережу, всі абоненти з неї були перенесені в іншу. Але світить що 6 IP зайняті, хоча вона повністю вільна.
       
      ID    Мережа/CID           RВсього IP        Використано IP ▾           Вільно IPСервіс
      6      172.16.70.0/23        506                    6                                       500
       
      Підкажіть як правильно це підчистити щоб видалити мережу.
    • Від 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.

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