accel-ppp.org

Приветствую!

В биллинговой системе, что мы используем, при поднятии соединения выданный абоненту айпи адрес резервируется. Настроен биллинг таким образом, что освобождение данного адреса происходит только после того как придет Stop Packet от наса, в нашем случае от accel-ppp. Так вот по заверениям тех. поддержки биллинговой системы, ошибки, что выскакивают в логах биллинга могут быть либо по причине множественных попыток подключения под одной учетной записью, что запрещено, либо, если нас не отсылает эти самые стоп пакеты для освобождения адреса. Первый вариант уже исключили, остается второй.

Отсюда вопрос: как можно проверить отсылаются ли стоп пакеты насом? Какая опция в файле конфигурации отвечает за эту возможность?

[radius]
verbose=1
[log]
level=4

и наблюдать обмен сообщениями с радиусом в логе

Первый параметр установлен изначально. Уровень логирования был 3. Сменил на 4 и перезагрузил конфиг. Буду проверять.

Ниже вывод вырезки из лога. Я так понимаю стоп пакеты отсылаются и Result 1 говорит об их успешности.

[2017-05-11 12:32:42]: info: ppp571: send [PPTP Stop-Ctrl-Conn-Request <Reason 0>]
[2017-05-11 12:32:42]: info: ppp571: recv [PPTP Stop-Ctrl-Conn-Reply <Result 1> <Error 0>]
[2017-05-11 12:32:42]: info: ppp238: send [PPTP Stop-Ctrl-Conn-Request <Reason 0>]
[2017-05-11 12:32:42]: info: ppp238: recv [PPTP Stop-Ctrl-Conn-Reply <Result 1> <Error 0>]
[2017-05-11 12:32:42]: info: ppp775: send [PPTP Stop-Ctrl-Conn-Request <Reason 0>]
[2017-05-11 12:32:42]: info: ppp775: recv [PPTP Stop-Ctrl-Conn-Reply <Result 1> <Error 0>]
[2017-05-11 12:32:42]: info: ppp726: send [PPTP Stop-Ctrl-Conn-Request <Reason 0>]
[2017-05-11 12:32:42]: info: ppp726: recv [PPTP Stop-Ctrl-Conn-Reply <Result 1> <Error 0>]
[2017-05-11 12:32:42]: info: ppp779: send [PPTP Stop-Ctrl-Conn-Request <Reason 0>]
[2017-05-11 12:32:42]: info: ppp779: recv [PPTP Stop-Ctrl-Conn-Reply <Result 1> <Error 0>]
[2017-05-11 12:32:43]: info: ppp398: send [PPTP Stop-Ctrl-Conn-Request <Reason 0>]
[2017-05-11 12:32:43]: info: ppp398: recv [PPTP Stop-Ctrl-Conn-Reply <Result 1> <Error 0>]
[2017-05-11 12:32:44]: info: ppp733: send [PPTP Stop-Ctrl-Conn-Request <Reason 0>]
[2017-05-11 12:32:44]: info: ppp733: recv [PPTP Stop-Ctrl-Conn-Reply <Result 1> <Error 0>]
[2017-05-11 12:32:44]: info: ppp740: send [PPTP Stop-Ctrl-Conn-Request <Reason 0>]
[2017-05-11 12:32:44]: info: ppp740: recv [PPTP Stop-Ctrl-Conn-Request <Reason 3>]
[2017-05-11 12:32:44]: info: ppp740: send [PPTP Stop-Ctrl-Conn-Reply <Result 1> <Error 0>]

Можете дать подтверждение моим предположениям, описанным ваше?

нет, это не то
должно быть send [RADIUS Accounting-Request ... <Acct-Status-Type Stop> ...]

Я думаю, что это то, что нужно.

[2017-05-12 09:16:09]: info: ppp161: send [RADIUS(1) Accounting-Request id=e <User-Name "radjabovapa"> <NAS-Identifier "nas02"> <NAS-IP-Address 192.168.0.13> <NAS-Port 161> <NAS-Port-Type Virtual> <Tunnel-Type PPTP> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "172.17.100.205"> <Called-Station-Id "172.16.0.3"> <Acct-Status-Type Stop> <Acct-Authentic RADIUS> <Acct-Session-Id "1534ee7faeeedcc5"> <Acct-Session-Time 1576> <Acct-Input-Octets 683094> <Acct-Output-Octets 27794> <Acct-Input-Packets 11446> <Acct-Output-Packets 202> <Acct-Input-Gigawords 0> <Acct-Output-Gigawords 0> <Framed-IP-Address 10.10.12.13> <Acct-Terminate-Cause Lost-Carrier>]

[2017-05-12 09:17:31]: info: ppp894: send [RADIUS(1) Accounting-Request id=d0 <User-Name "magomedovkc"> <NAS-Identifier "nas02"> <NAS-IP-Address 192.168.0.13> <NAS-Port 894> <NAS-Port-Type Virtual> <Tunnel-Type PPTP> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "172.17.37.133"> <Called-Station-Id "172.16.0.3"> <Acct-Status-Type Stop> <Acct-Authentic RADIUS> <Acct-Session-Id "1534ee7faee92c99"> <Acct-Session-Time 86405> <Acct-Input-Octets 156587837> <Acct-Output-Octets 1980154966> <Acct-Input-Packets 729243> <Acct-Output-Packets 1477277> <Acct-Input-Gigawords 0> <Acct-Output-Gigawords 0> <Framed-IP-Address 10.10.9.112> <Acct-Terminate-Cause Session-Timeout>]

В биллинге не предусмотрена обработка Acct-Terminate-Cause Session-Timeout и Acct-Terminate-Cause Lost-Carrier? что за биллинг такой?
хотя <Acct-Status-Type Stop> то прилетает.

NetUp UTM 5.3-004 последняя версия. Когда использовали ветку 5.2 подобных проблем не было. Недавно обновились, и началось.
Постоянно в логах радиуса записи типа:
May 12 10:58:48 ERROR : 17c1a700 AuthQueue: Unable to lease IP from 'djafarovafs'

Обратились в тех. поддержку: там сказали, что НАС не шлет стоп пакеты, поэтому выданный абону адрес не освобождается.

А трафик сессий считается вообще? Радиусом?
Может на биллинговом сервере tcpdump посмотреть по порту 1813