[Andrei]

sudo rm /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt
sudo update-ca-certificates
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.

Но все равно в трафике обмена между серверами видно, что наш сервак отправляет в moovi ругань
"12    0.133664643    188.xxx.xxx.xxx    87.248.227.4    TLSv1.2    73    Alert (Level: Fatal, Description: Certificate Expired)"

[st_re]

тут /etc/ca-certificates.conf нет mozilla/DST_Root_CA_X3.crt ? 

убрать и еще раз update-ca-certificates ?

Странно что 0 removed

 

openssl s_client -showcerts -connect 87.248.227.4:443 < /dev/null > /dev/null
Can't use SSL_get_servername
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = account.mediaoperator.ru
verify return:1
DONE

там у вас должен быть бинарь 1.0.2 SSLя, если тоже самое сделать им ?

[Andrei]

9 часов назад, st_re сказал:

тут /etc/ca-certificates.conf нет mozilla/DST_Root_CA_X3.crt ? 

убрать и еще раз update-ca-certificates ?

Странно что 0 removed

Наверное потому, что я ранее уже в файле /etc/ca-certificates.conf  закомментировал строчку:

!mozilla/DST_Root_CA_X3.crt
и далее было
sudo update-ca-certificates
0 added, 1 removed; done.

 

9 часов назад, st_re сказал:

там у вас должен быть бинарь 1.0.2 SSLя, если тоже самое сделать им ?

Бинарь есть даже более новый:

openssl version
OpenSSL 1.1.1d  10 Sep 2019

openssl s_client -showcerts -connect 87.248.227.4:443 < /dev/null > /dev/null
Can't use SSL_get_servername
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = account.mediaoperator.ru
verify return:1
DONE

1.0.2 не видно

 dpkg -l | grep openssl
ii  libgnutls-openssl27:amd64       3.5.8-5+deb9u4                              amd64        GNU TLS library - OpenSSL wrapper
ii  openssl                         1.1.1d-1+0~20191009.15+debian9~1.gbpd6badf  amd64        Secure Sockets Layer toolkit - cryptographic utility
ii  perl-openssl-defaults:amd64     3                                           amd64        version compatibility baseline for Perl OpenSSL packages
ii  python-openssl                  16.2.0-1                                    all          Python 2 wrapper around the OpenSSL library

 

[st_re]

не 1.1.1 не интересно, он уже разруливает... интересен именно 1.0.2

 

вот 1.0.1 с выкушенным просроченным сертификатом

 

 openssl s_client -showcerts -connect 87.248.227.4:443 < /dev/null > /dev/null
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = account.mediaoperator.ru
verify return:1
DONE

 

[Andrei]

С 1.0.2 не работает и работать не будет. Такой вердикт от разработчиков.

Цитата из их ответа

Цитата

К сожалению ядро слинковано жёстко на libssl1.0.2
Тут поможет только обновление АСР и ОС

То что в системе стоит еще и OpenSSL 1.1 ни на что не влияет - LBcore слинкован именно на 1.0.2 и подмена библиотек ни к чему не приведёт (будет ошибка поиска сигнатур внутри библиотеки)

 

[st_re]

нормально все в 1.0.2 с ЛЕ работает.. разрабам лень мозгом думать. не более (ну и обновление таки продавать надо...). надо только найти где оно сертификаты берёт... возможно не из системы, а в своём месте... тогда выкашивать надо там.

[Andrei]

45 минут назад, st_re сказал:

надо только найти где оно сертификаты берёт...

Предлагаете сделать "реверс-инжиниринг" биллинга? :)

Хз, как там искать, где он эти сертификаты смотрит. Декомпилятором по коду лазить?

[st_re]

ну я бы поискал сначала по диску что похожего валяется (*.pem *.crt)... можно  раз запустить с strace тыкнуться, получить ошибку, и потом посмотреть, что оно читало.

 

в принципе Вам надо такой текст

-----BEGIN CERTIFICATE-----
MIIDSjCCAjKgAwIBAgIQRK+wgNajJ7qJMDmGLvhAazANBgkqhkiG9w0BAQUFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTAwMDkzMDIxMTIxOVoXDTIxMDkzMDE0MDExNVow
PzEkMCIGA1UEChMbRGlnaXRhbCBTaWduYXR1cmUgVHJ1c3QgQ28uMRcwFQYDVQQD
Ew5EU1QgUm9vdCBDQSBYMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AN+v6ZdQCINXtMxiZfaQguzH0yxrMMpb7NnDfcdAwRgUi+DoM3ZJKuM/IUmTrE4O
rz5Iy2Xu/NMhD2XSKtkyj4zl93ewEnu1lcCJo6m67XMuegwGMoOifooUMM0RoOEq
OLl5CjH9UL2AZd+3UWODyOKIYepLYYHsUmu5ouJLGiifSKOeDNoJjj4XLh7dIN9b
xiqKqy69cK3FCxolkHRyxXtqqzTWMIn/5WgTe1QLyNau7Fqckh49ZLOMxt+/yUFw
7BZy1SbsOFU5Q9D8/RhcQPGX69Wam40dutolucbY38EVAjqr2m7xPi71XAicPNaD
aeQQmxkqtilX4+U9m5/wAl0CAwEAAaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAOBgNV
HQ8BAf8EBAMCAQYwHQYDVR0OBBYEFMSnsaR7LHH62+FLkHX/xBVghYkQMA0GCSqG
SIb3DQEBBQUAA4IBAQCjGiybFwBcqR7uKGY3Or+Dxz9LwwmglSBd49lZRNI+DT69
ikugdB/OEIKcdBodfpga3csTS7MgROSR6cz8faXbauX+5v3gTt23ADq1cEmv8uXr
AvHRAosZy5Q6XkjEGB5YGV8eAlrwDPGxrancWYaLbumR9YbK+rlmM6pZW87ipxZz
R8srzJmwN0jP41ZL9c8PDHIyh8bwRLtTcm1D9SZImlJnt1ir/md2cXjbDaJWFBM5
JDGFoqgCWjBH4d1QB7wCCZAA62RjYJsWvIjJEubSfZGL+T0yjWW06XyxV3bqxbYo
Ob8VZRzI9neWagqNdwvYkQsEjgfbKbYK7p2CNTUQ
-----END CERTIFICATE-----

 найти.. ну к примеру

find / -type f \( -name '*.crt' -or -name '*.pem' \) -print0 | \
  xargs -0  fgrep --files-with-matches 'ikugdB/OEIKcdBodfpga3csTS7MgROSR6cz8faXbauX+5v3gTt23ADq1cEmv8uXr'

 

 

кстати, после update-ca-certificates Вы сервис LB рестартовали ? А то с них станется, список 1 раз зачитать.

 

 

[Andrei]

4 часа назад, st_re сказал:

кстати, после update-ca-certificates Вы сервис LB рестартовали ? А то с них станется, список 1 раз зачитать.

Нет, не рестартовал. Разработчики кстати только сейчас уточнили это.  :)

И еще рекомендовали обновить версию ssl с 1.0.2t до 1.0.2u.

[Andrei]

Посоветовали еще поменять строку в
/usr/local/billing/lib/python3.6/lib/python3.6/site-packages/requests/certs.py
return os.path.join(os.path.dirname(__file__), 'cacert.pem')
на строчку
return '/etc/ssl/certs/ca-certificates.crt'
и перезапустить ядро.
Но не помогло.

 

[st_re]

а в cacert.pem выкосить (это текстовый файл) приведённый выше церт ?

[Andrei]

18 часов назад, st_re сказал:

cacert.pem

в каком из...

[Andrei]

В 16.12.2022 в 17:40, st_re сказал:

а в cacert.pem выкосить (это текстовый файл) приведённый выше церт ?

Убрал его из всех cacert.pem, где нашел, сделал update-ca-certificates, рестартанул ядро, но всё равно не работает.

В логе ядра ЛБ

Цитата

17.12.2022 13:48:15 INFO    LWP8110 [blocks3.cpp:1051:HandleBlock]      Processing BLOCK task: record_id 427; blk_req = 0; vg_id = 1591; reqest_by = 2; comment = ; change_time = 2022-Dec-14 00:00:00
17.12.2022 13:48:18 ERROR   LWP27534 [messenger_queue.h:77:RunFunc]     Error handling message "block_service" ({ "blk_req": 0, "change_time": "2022-12-14 00:00:00", "is_additional_service": 1, "service_id": 151, "service_type_id": 10, "vg_id": 1591 }): moovi Error: "Operator agent agreement not found"
17.12.2022 13:48:35 INFO    LWP8117 [blocks3.cpp:1051:HandleBlock]      Processing BLOCK task: record_id 428; blk_req = 10; vg_id = 1591; reqest_by = 2; comment = ; change_time = 2022-Dec-14 00:00:00
17.12.2022 13:48:35 WARNING LWP8117 [api_services.cpp:1046:StopService] The service does not exist or is closed
17.12.2022 13:48:35 ERROR   LWP27534 [messenger_queue.h:77:RunFunc]     Error handling message "block_service" ({ "blk_req": 10, "change_time": "2022-12-14 00:00:00", "is_additional_service": 1, "service_id": 151, "service_type_id": 10, "vg_id": 1591 }): Can't disable moovi tarif, moovi user or vg doesn't exists

 

В общем похоже, что какая-то недоработка в интеграции, хотя на момент первоначально настройки (ноябрь 2020) всё работало.
Сборка ЛБ 2.0.31, а сейчас актуальная уже 42я. Никто старую дорабатывать не будет. СтОит ли обновляться ради этого - надо подумать.

[st_re]

В 17.12.2022 в 10:35, Andrei сказал:

в каком из...

ну последний скорее всего не от мира сего не от этого проекта, а в трех выше надо бы во всех, если он во всех был..

 

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

[Andrei]

Дело закончилось тем, что выяснили следующее. Интеграция ЛБ и Moovi нарушилась из-за смены принципа авторизации агентских договоров на платформе moovi: раньше это был номер агентского договора, а с какого-то времени они перешли на идентификатор агента - некоторый внутренний номер агента на платформе moovi, который нигде не видно (даже в личном кабинете moovi).

PS. Разработчикам ЛБ респект за проведенную работу,  за оказанную консультационную поддержку даже без договора.

[psih]

Ребят кто использует opt82 с OLT Eltex? Поделитесь реугляркой для парсинга, a то что в мануале биллинга написано не подходит вообще. В OLT параметр circuit-id записан как %GPON-PORT%%ONTID% в дамп прилетает в кодировке ascii. Все свои идеи я исчерпал, регулярок перепробовал кучу и результата нет. С OLT других вендоров проблем нет, там всё четко с opt82, а с Eltex какая то засада.

[Urs_ak]

Народ, у кого с ЛанБиллингом используется BRAS (RADIUS) ?

 

Cкажите, какое у вас значение выставлено в Агенты - RADIUS - Особые настройки -> Тайм-аут зависшей сессии (сек)

 

Хочу понять, есть ли смысл его уменьшить до 30 минут, например, чтобы при внештатной перезагрузке BRAS'а сессии быстрее очищались.

[No_name]

1 час назад, Urs_ak сказал:

Народ, у кого с ЛанБиллингом используется BRAS (RADIUS) ?

 

Cкажите, какое у вас значение выставлено в Агенты - RADIUS - Особые настройки -> Тайм-аут зависшей сессии (сек)

 

Хочу понять, есть ли смысл его уменьшить до 30 минут, например, чтобы при внештатной перезагрузке BRAS'а сессии быстрее очищались.

 

У меня 3 минуты стоит. Норм все отрабатывает. Брас фря, мпд.

[Andrei]

6 часов назад, Urs_ak сказал:

Cкажите, какое у вас значение выставлено в Агенты - RADIUS - Особые настройки -> Тайм-аут зависшей сессии (сек)

У меня 300 сек, BRAS - cisco ASR-1002

[Urs_ak]

Спасибо, будем тестировать уменьшение.

[Urs_ak]

Интересно, а как у вас там по 3 и 5 минут выставлено, если в LanBilling написано:

 

Цитата

• «Интервал между Interim-UPDATE запросами аккаунтинга» — интервал в секундах между Accounting-Update пакетами.
• «Тайм-аут зависшей сессии (сек)» — интервал в секундах между временем обработки последнего Accounting-Update пакета и текущим временем, при превышении которого сессия считается устаревшей. Минимально допустимым значением считается удвоенный интервал Interim-UPDATE. Максимально допустимым - 86400 сек., т.е. 1 день.

BRAS чаще чем 600 секунд, посылать Accounting-Update не может

 

Гм, у вас что, при таких параметрах постоянно новые сессии в ЛанБиллинг ? Каждые 5 минут ?

[Andrei]

17 минут назад, Urs_ak сказал:

BRAS чаще чем 600 секунд, посылать Accounting-Update не может

на циске:

aaa accounting update periodic 1

(1 минута)

 

17 минут назад, Urs_ak сказал:

Гм, у вас что, при таких параметрах постоянно новые сессии в ЛанБиллинг ? Каждые 5 минут ?

Почему?

[Urs_ak]

А, сisco может. У меня минимум 10 минут.

Ясно.

[No_name]

18 часов назад, Urs_ak сказал:

Интересно, а как у вас там по 3 и 5 минут выставлено, если в LanBilling написано:

 

BRAS чаще чем 600 секунд, посылать Accounting-Update не может

 

Гм, у вас что, при таких параметрах постоянно новые сессии в ЛанБиллинг ? Каждые 5 минут ?

 

Ничего там не пересоздается.

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

 

Так же, если в течении 3 минут клиент не отвечает на эхо запросы, то сбрасывается. Кстати, у некоторых старых или кривых(дешман) роутров, сессия от 20 сек до 2 мин(сами её сбрасывают)  если нет трафика. Да, вот так. И ничего со своей стороны не сделаешь.

 

 

[Andrei]

2 часа назад, No_name сказал:

у некоторых старых или кривых(дешман) роутров, сессия от 20 сек до 2 мин(сами её сбрасывают)  если нет трафика. Да, вот так. И ничего со своей стороны не сделаешь.

Тоже вижу у нескольких клиентов такую фигню.