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

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

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

Вообще все связанное с Carbon AS стоит изучать выполнив смену корня, все команды ниже написаны с учётом того, что вы уже сделали это:

chroot /app/carbon_as

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

cat /var/lib/nas_users.dat

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

ip | snat | negbal | mac

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

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

tail -100 /var/log/ideco_nasd.log

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

tail -100 /var/log/carbon_nasd.log

Если вы используете Carbon Billing 5.

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

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

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

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

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

Проверьте, правильно ли указан 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

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

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

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

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

ping -c 4 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  порты.

Для того чтобы заставить их идти - попробуйте переподключить какого-нибудь пользователя с 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