Отладка авторизации абонентов

Skip to end of metadata
Go to start of metadata

Статья пока что является черновиком, на основе копии аналогичной из Carbon AS 5, позже будет поправлена под Carbon AS 3.

Тем не менее, около 70% инструкций подходят и для AS 3.

Как ускорить первичную настройку Carbon AS 3

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

1. Узнать информацию о авторизованных пользователях

cat /var/lib/nas_users.dat

В этом файле записаны строки в виде:

ip | snat | negbal | mac

Как минимум IP пользователя должен быть записан в этом файле, если нет - переходим на следующий шаг.

2. Проверить команды от биллинга

tail -100 /var/log/ideco_nasd.log

если вы используете Carbon Billing 4 в качестве биллинга.

Туда записываются все передаваемые на маршрутизатор команды, а также ошибки в случае если что-то идёт не так.

Если команд нет, то переходим на следующий шаг.

Если команды есть, то проверьте, что данные которые приходят соответствуют действительности. Скорее всего проблема в настройках тарифа или данных пользователя.

psw incorrect. 123 !=
psw incorrect. 123 !=
psw incorrect. 123 !=
psw incorrect. 123 !=
psw incorrect. 123 !=
psw incorrect. 123 !=
psw incorrect. 123 !=
psw incorrect. 123 !=

Подобные ошибки означают, что в памяти демона ideco_nasd ещё старые переменные.

/etc/init.d/ideco_nasd restart или мягкая перезагрузка решают эту проблему.

3. Проверить настройки управления NAS'ом

Проверьте данные в локальном меню связанные с настройкой маршрутизатора.

Проверьте, правильно ли указан IP адрес биллинга, совпадает ли Radius Secret.

Проверьте, что не напутали с портами аккаунтинга и авторизации.

Если на вид всё верно, то переходим на следующий шаг.

4. Если команды были - проверьте наличие правил

Для примера IP пользователя: 10.0.201.100

Проверьте, что пользователю разрешён доступ к сети

 iptables -nvL | grep -w 10.0.201.100

Проверьте что есть SNAT, если он используется, либо, что его нет, если используются белые IP

iptables -t nat -nvL | grep 10.0.201.100

Проверьте маркировку пакетов пользователя для шейпера

iptables -t mangle -nvL | grep 10.0.201.100

Если один из этих пунктов даёт не те результаты, которые ожидаются, то нужно сперва проверить параметры пользователя в биллинге, если с ними всё в порядке, то связаться с технической поддержкой.

В новых версиях вы можете воспользоваться скриптом

 /usr/local/ics/support/as_debug.sh --help

5. Проверка доступа до биллинга

Самое банальное что можно сделать (но в 80% случаев этого и достаточно): проверить доступ до биллинга ping'ом.

Для примера IP адрес биллинга будет равен 10.0.0.10

ping -c 10 10.0.0.10

Если ответы есть, то это ещё не гарантия, что доступ полноценный.

Проверьте следующее:

arping -c 1 -I Eeth0 10.0.0.10

После -I должно идти имя внешнего интерфейса.

6. Проверьте что трафик вообще идёт

tcpdump -nvi any host 10.0.0.10

Должны идти пакеты на 44, 1812, 1813 и 9996 порты.

Для того чтобы заставить команды идти - попробуйте переподключить какого-нибудь пользователя с IP авторизацией.

Для PPTP-пользователей

Вы можете посмотреть что происходит с плагином авторизации по Radius:

 strace -s 500 -f -p `pidof pptpd`

Для того чтобы читать вывод трасировщика - придётся немного потренироваться.

В первую очередь стоит обратить внимание на коннекты до биллинга - если они возвращают 0 (Timeout), то это проблема с сетью, либо Radius-сервер не слушает на указанном в настройках порту.

Проверьте это командой

ps aux | grep radius

на биллинге. Если Radius не запущен, то само собой его надо запустить, предварительно узнав причину по которой он не запущен.

Для пользователей с IP авторизацией

На биллинге и на самом Carbon AS запустите

tcpdump -nvi any udp port 44

Отключите абонента в биллинге.

Должен уйти 1 или более пакетов с биллинга и точно такое же до AS.

Если пакеты не уходят - нужно опять же проверить запущен ли демон eventd

ps aux | grep event

Примеры работы с tcpdump

tcpdump -nvi any udp port 9996 # проверка netflow
tcpdump -nvi any port 1812 or port 1813 # проверка Radius
tcpdump -nvi any udp port 44 # проверка посылки команд

Отладка Radius

Возможно пользователи просто не авторизуются по Radius.

Для того чтобы понять что происходит - нужно запустить Radius сервер на биллинге в режиме дебага:

 ./radiusd -X

Логи

Если пользователю при авторизации по VPN показываются ошибки - стоит посмотреть лог /var/log/ppp.

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