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

Skip to end of metadata
Go to start of metadata

При использовании RADIUS

В первую очередь, необходимо обратиться к логу RADIUS. Следить за ошибками в реальном времени, а так же вывести 50 последних строк:

tail -n 50 -f /app/asr_billing/var/log/radius/radius.log

В логе нет запросов вообще или с определённого NAS-сервера

Проверьте снифером идет ли с NAS трафик на порт авторизации (по-умолчанию 1812) и IP-адресу шлюза:

Команда
tcpdump -nnei any port 1812 and host 192.168.200.11

Тут возможны варианты.

Запросы идут не на тот порт

Если фильтр снифера по IP и порту не дал результата, попробуйте посмотреть только по IP

Команда
tcpdump -nnei any host 192.168.200.11

Если есть трафик, проверьте что на NAS-сервере в настройках RADIUS-клиента указан правильный порт RADIUS-сервера.

Запросы идут еще и на порт аккаунтинга, так что если на 1812 нет, а на 1813 есть - проблема точно в этом

Запросы идут не с того IP

Если нет запросов по IP NAS-сервера, запустите снифер по порту авторизации.

Команда
tcpdump -nnei any port 1812
  • Возможно у Вас несколько NAS-серверов, тогда постарайтесь найти в выводе незнакомый Вам IP-адрес
  • Возможно на NAS-сервере настроено несколько IP-адресов и он просто шлёт запросы не с адреса указанного в биллинге

Если это Ваш случай, укажите в настройках NAS на биллинге тот IP сервера, с которого идут запросы в поле

Запросы действительно не идут

Возможно что-то случилось с NAS-сервером, проверьте настройки RADIUS-клиента:

  • IP RADIUS-сервера
  • Порты авторизации и аккаунтинга
  • IP NAS-сервера с которого отправляются запросы
  • Проверьте что есть доступ: запустите пинг до IP RADIUS-сервера

Firewall на биллинге не пропускает запросы

Если в выводе снифера есть трафик с правильного IP и на правильный порт, убедитесь что они проходят Firewall:

  1. Проверьте что правило вообще есть:
    Команда, где 1812 - порт авторизации, а 169.254.80.81 - IP NAS
    iptables-save | grep nas_clients | grep 1812 | grep 169.254.80.81
    Вывод, видно что правило есть
    -A nas_clients -s 169.254.80.81/32 -p udp -m udp --dport 1812 -j ACCEPT
  2. Проверьте что до него доходят пакеты
    Команда, где 1812 - порт авторизации, а 169.254.80.81 - IP NAS
    iptables -nvL | grep 1812 | grep 169.254.80.81
    Вывод, по первым двум столбцам видно что пакеты до него доходят
       15  1500 ACCEPT     udp  --  *      *       169.254.80.81        0.0.0.0/0           udp dpt:1812

Error: Ignoring request to authentication address 169.254.18.12 port 1812 from unknown client 10.15.20.30 port 59282

Возможные причины:

  1. Запрос приходит от не интегрированного NAS
  2. Если NAS интегрирован:
    1. убедитесь что он есть в clients.conf
      # 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
      }
      
    2. Перезапустите RADIUS
      # chroot /app/asr_billing/ /etc/init.d/radiusd restart
      Останавливается radiusd:                                   [  СБОЙ  ]
      Останавливается radiusd_acc:                               [  OK  ]
      Запускается radiusd:                                       [  СБОЙ  ]
      Запускается radiusd_acc:                                   [  OK  ]
      

      При этом так же перезапускается радиус аккаунтинга. В примере радиус не был запущен, потому в вывод при остановке сервиса - СБОЙ.

    3. Если ситуация не исправилась перезапуском RADIUS, попробуйте пересоздать конфиги
      mv /app/asr_billing/etc/raddb /app/asr_billing/etc/raddb.backup
      /app/asr_billing/service restart
      

Auth: Login incorrect: [Administrator/<via Auth-Type = mschap>] (from client Test-NAS port 15732262 cli 10.7.3.4)

Возможные причины:

  1. Пользователь вводит неверный логин или пароль
  2. Убедитесь, что в учетной записи выставлен корректный тип авторизации
  3. Если предыдущие варианты не помогли, включите radius debug в настройках биллинга, снова попытайтесь автозизоваться, получив лог ошибки обратитесь в техподдержку

Сессия устанавливается, но сбрасывается биллингом: Idle-Timeout

Для диагностики проблемы необходимо обратиться к логу RADIUS и к аудиту подключений. Аудит подключений Вы можете посмотреть в карточке абонента, на вкладке "Аудит"

Если в аудите подключений присутствуют записи вида:

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).

То сессия обрывается по таймауту.
Это может быть связано с тем, что в настройках NAS добавлен атрибут Idle-Timeout, который имеет слишком маленькое значение.
В этом случае необходимо проверить radius атрибуты в настройках NAS

В этом случае, необходимо увеличить значение атрибута Idle-Timeout

Дублирование запросов на авторизацию Error: Discarding duplicate request from client

Данная ошибка фиксируется в логе /app/asr_billing/var/log/radius/radius.log и выглядит следующим образом

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

Причиной возникновения ошибки является запрос от NAS на авторизацию абонента, ранее переданный в биллинг, но до текущего момента он не был обработан и ответ в NAS не поступал. Это обычно связано с тем, что биллинг не смог обработать запрос за нужное время, так как база данных была занята.
Для ее решения, необходимо:
1. Проверить нагрузку на сервере по документации.
2. Убедитесь, что если используете биллинг на виртуальной машине, то в момент возникновения ошибки не выполняются никакие "внешние" действия с ВМ (пример:бэкапирование)

Попытка подключения с запрещенного адреса

Данная ошибка может возникать при типе авторизации любая через RADIUS
В логе Radius /app/asr_billing/var/log/radius/radius.log при этом будут присутствовать записи:

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)

А в аудите подключений

ошибки вида

Попытка подключения с запрещенного адреса: 10.0.19.152

Данная ошибка возникает, когда у абонентов в настройках учетной записи с типом авторизации любая через RADIUS указан Host IP (только для VPN). Для решения этой проблемы необходимо удалить адрес из поля Host IP (только для VPN).
Массово очистить данное поле у абонентов, находящихся в группе с ID 1364 и её подгруппах, можно с помощью api-запроса:

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

Массовые некорректные запросы на авторизацию

Количество запросов к radius серверу ограничено 30 запросами в секунду при постоянной нагрузке, и 60 запросов в секунду при пиках. При привышении лимита запросы авторизации будут отброшены. Это сделано, чтобы защитить БД от массовых запросов авторизации со сбойнго оборудования.
Найти сбойное клиентское оборудование можно по radius логу. Следующая команда выдаст список логинов и паролей, которые не были авторизованы, а также количество попыток авторизации.

Команда
fgrep 'Login incorrect' /app/asr_billing/var/log/radius/radius.log | grep -oE "\[.*\]" | sort | uniq -c
Результат
  13578 [0002445/887799]
  13568 [^^0002445/FFFFFFFFFFFFF]
      3 [00596-00-00/618743509401]

Найдите устройства на своей сети используя таблицу сессий вашего НАС.

Введите метки, чтобы добавить к этой странице:
Please wait 
Ищите метку? просто начните печатать.