Статья пока что является черновиком, на основе копии аналогичной из 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

если вы используете Ideco ACP 3 в качестве биллинга.

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

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

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

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.