Абоненты не могут авторизоваться

{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. Убедитесь, что если используете биллинг на виртуальной машине, то в момент возникновения ошибки не выполняются никакие "внешние" действия с ВМ (пример:бэкапирование)

{code}

А в аудите подключений
!Скрин1.png|border=1,width=800!
ошибки вида
{code}
Попытка подключения с запрещенного адреса: 10.0.19.152
{code}

Данная ошибка возникает, когда у абонентов в настройках учетной записи с типом авторизации *любая через RADIUS* указан *Host IP (только для VPN)*. Для решения этой проблемы необходимо удалить адрес из поля *Host IP (только для VPN)*.
Массово очистить данное поле у абонентов, находящихся в группе с ID 1364 и её подгруппах, можно с помощью api-запроса:
{code}
sqlexec "set list on; select u.id from users u left join abonents a on a.id=u.abonent_id where a.id in (SELECT abonent_id FROM GLN_RECURSIVE_ABONENTS_GET(1364))" | awk ' {print $2} ' | sed '/^$/d' | while read line; do curl -XPOST -d 'method1=objects.get&arg1={"id":'$line'}&method2=set&arg2={"host_ip":""}&method3=save&arg3={}' http://169.254.80.82:8082/rest_api/v2/Users/ -D - ; done
{code}