... {toc:maxLevel=2} h1. При использовании RADIUS В первую очередь, необходимо обратиться к логу RADIUS. Следить за ошибками в реальном времени, а так же вывести 50 последних строк: {code}tail -n 50 -f /app/asr_billing/var/log/radius/radius.log{code} h2. В логе нет запросов вообще или с определённого NAS-сервера Проверьте снифером идет ли с NAS трафик на порт авторизации (по-умолчанию 1812) и IP-адресу шлюза: {code:title=Команда}tcpdump -nnei any port 1812 and host 192.168.200.11{code} Тут возможны варианты. h3. Запросы идут не на тот порт Если фильтр снифера по IP и порту не дал результата, попробуйте посмотреть только по IP {code:title=Команда}tcpdump -nnei any host 192.168.200.11{code} Если есть трафик, проверьте что на NAS-сервере в настройках RADIUS-клиента указан правильный порт RADIUS-сервера. {note}Запросы идут еще и на порт аккаунтинга, так что если на 1812 нет, а на 1813 есть - проблема точно в этом{note} h3. Запросы идут не с того IP Если нет запросов по IP NAS-сервера, запустите снифер по порту авторизации. {code:title=Команда}tcpdump -nnei any port 1812{code} * Возможно у Вас несколько NAS-серверов, тогда постарайтесь найти в выводе незнакомый Вам IP-адрес * Возможно на NAS-сервере настроено несколько IP-адресов и он просто шлёт запросы не с адреса указанного в биллинге Если это Ваш случай, укажите в настройках NAS на биллинге тот IP сервера, с которого идут запросы в поле h3. Запросы действительно не идут Возможно что-то случилось с NAS-сервером, проверьте настройки RADIUS-клиента: * IP RADIUS-сервера * Порты авторизации и аккаунтинга * IP NAS-сервера с которого отправляются запросы * Проверьте что есть доступ: запустите пинг до IP RADIUS-сервера h3. Firewall на биллинге не пропускает запросы Если в выводе снифера есть трафик с правильного IP и на правильный порт, убедитесь что они проходят Firewall: # Проверьте что правило вообще есть: {code:title=Команда, где 1812 - порт авторизации, а 169.254.80.81 - IP NAS}iptables-save | grep nas_clients | grep 1812 | grep 169.254.80.81{code} {code:title=Вывод, видно что правило есть}-A nas_clients -s 169.254.80.81/32 -p udp -m udp --dport 1812 -j ACCEPT{code} # Проверьте что до него доходят пакеты {code:title=Команда, где 1812 - порт авторизации, а 169.254.80.81 - IP NAS}iptables -nvL | grep 1812 | grep 169.254.80.81{code} {code:title=Вывод, по первым двум столбцам видно что пакеты до него доходят} 15 1500 ACCEPT udp -- * * 169.254.80.81 0.0.0.0/0 udp dpt:1812{code} h2. Error: Ignoring request to authentication address 169.254.18.12 port 1812 from unknown client 10.15.20.30 port 59282 Возможные причины: # Запрос приходит от не [интегрированного NAS|CarbonBilling:Интеграция с оборудованием] # Если NAS интегрирован: ## убедитесь что он есть в clients.conf {code} # cat /app/asr_billing/etc/raddb/clients.conf client 169.254.18.12 { shortname = Carbon_XGE_local secret = algosolarsystem } client 10.15.20.30 { shortname = Test-NAS secret = secret } {code} ## Перезапустите RADIUS {code} # chroot /app/asr_billing/ /etc/init.d/radiusd restart Останавливается radiusd: [ СБОЙ ] Останавливается radiusd_acc: [ OK ] Запускается radiusd: [ СБОЙ ] Запускается radiusd_acc: [ OK ] {code} При этом так же перезапускается радиус аккаунтинга. В примере радиус не был запущен, потому в вывод при остановке сервиса - СБОЙ. ## Если ситуация не исправилась перезапуском RADIUS, попробуйте пересоздать конфиги {code} mv /app/asr_billing/etc/raddb /app/asr_billing/etc/raddb.backup /app/asr_billing/service restart {code} h2. Auth: Login incorrect: \[Administrator/<via Auth-Type = mschap>\] (from client Test-NAS port 15732262 cli 10.7.3.4) Возможные причины: # Пользователь вводит неверный логин или пароль # Убедитесь, что в [учетной записи|CarbonBilling:Учетная запись. Создание и изменение.] выставлен корректный тип авторизации # Если предыдущие варианты не помогли, включите [radius debug|CarbonBilling:Настройки (в файле)] в настройках биллинга, снова попытайтесь автозизоваться, получив лог ошибки обратитесь в [техподдержку|CarbonBilling:Контакты] h2. Сессия устанавливается, но сбрасывается биллингом: Idle-Timeout Для диагностики проблемы необходимо обратиться к логу RADIUS и к аудиту подключений. Аудит подключений Вы можете посмотреть в карточке абонента, на вкладке "Аудит" !Скрин1.png|border=1,width=800! Если в аудите подключений присутствуют записи вида: {code} 13.10.2018 10:37:34 RAD6_ACCT_START ACCT_START DONE. (FRAMED_IP_ADDRESS=172.16.202.21, START_TIME=2018-10-13 10:37:34, ACCT_SESSION_ID=36556407625070894786034131920739579, NAS_IP_ADDRESS=192.168.97.6, CALLING_STATION_ID=e4:8f:8f:2f:2f:ff, SQL_USER_NAME=172.16.202.21) 13.10.2018 10:38:08 RAD6_ACCT_STOP ACCT_STOP DONE. (ACCT_TERMINATE_CAUSE=Idle-Timeout, FRAMED_IP_ADDRESS=172.16.202.21, STOP_TIME=2018-10-13 10:38:07, ACCT_SESSION_ID=36556407625070894786034131920739579, NAS_IP_ADDRESS=192.168.97.6) Истекло время допустимого бездействия (Idle timer). {code} То сессия обрывается по таймауту. Это может быть связано с тем, что в настройках NAS добавлен атрибут Idle-Timeout, который имеет слишком маленькое значение. В этом случае необходимо проверить radius атрибуты в настройках NAS !Скрин2.png|border=1,width=800! В этом случае, необходимо увеличить значение атрибута Idle-Timeout h2. Дублирование запросов на авторизацию Error: Discarding duplicate request from client Данная ошибка фиксируется в логе */app/asr_billing/var/log/radius/radius.log* и выглядит следующим образом {code} Mon Sep 28 10:00:36 2020 : Error: Request 5994 has been waiting in the processing queue for 5 seconds. Check that all databases are running properly! Mon Sep 28 10:00:37 2020 : Error: Discarding duplicate request from client ib-bras-00 port 1645 - ID: 14 due to unfinished request 6008 Mon Sep 28 10:00:37 2020 : Error: Discarding duplicate request from client ib-bras-00 port 1645 - ID: 15 due to unfinished request 6009 Mon Sep 28 14:40:26 2020 : Error: rlm_sql_firebird. Fetch problem:'lock conflict on no wait transaction. deadlock. update conflicts with concurrent update. concurrent transaction number is 226490005. At procedure 'RAD6_CHECK' line: 1, col: 523' Mon Sep 28 14:40:26 2020 : Error: CARBON rlm_sql_getvpdata: fetch_res=-1 {code} Причиной возникновения ошибки является запрос от NAS на авторизацию абонента, ранее переданный в биллинг, но до текущего момента он не был обработан и ответ в NAS не поступал. Это обычно связано с тем, что биллинг не смог обработать запрос за нужное время, так как база данных была занята. Для ее решения, необходимо: 1. Проверить нагрузку на сервере [по документации|CarbonBilling:Биллинг медленно работает]. 2. Убедитесь, что если используете биллинг на виртуальной машине, то в момент возникновения ошибки не выполняются никакие "внешние" действия с ВМ (пример:бэкапирование) h2. Попытка подключения с запрещенного адреса Данная ошибка может возникать при типе авторизации *любая через RADIUS* В логе Radius */app/asr_billing/var/log/radius/radius.log* при этом будут присутствовать записи: {code} Wed May 19 04:53:46 2021 : Auth: Login incorrect (rlm_chap: Clear text password not available): [testold/<CHAP-Password>] (from client 10.10.0.33 port 15761811 cli 10.0.19.152) {code} А в аудите подключений !Скрин1.png|border=1,width=800! ошибки вида {code} Попытка подключения с запрещенного адреса: 10.0.19.152 {code} Данная ошибка возникает, когда у абонентов в настройках учетной записи с типом авторизации *любая через RADIUS* указан *Host IP (только для VPN)*. Для решения этой проблемы необходимо удалить адрес из поля *Host IP (только для VPN)*. Массово очистить данное поле у абонентов, находящихся в группе с ID 1364 и её подгруппах, можно с помощью api-запроса: {code}
|