Поддержка POD/CoA для Linux pppd

[NiTr0]

Появилась необходимость на лету менять скорость/дропать клиентов на линуксовых насах; готового правильного решения не нашел, юзать ssh для этих целей - показалось слишком корявым, решил писать сам, взяв за основу древний радиус-демон от Cistron и изрядно кастрировал его, убрав все явно излишнее для данной задачи, после чего - навешал за недельку стафф для работы с RFC3576 запросами и взаимодействием с pppd и сетевой подсистемой. То, что получилось, выложил сюда. Выглядит немного коряво, кое-где проглядывает (а кое-где даже нагло выпирает) мохнатая седая щетина и прочие излишние непотребства от оригинального демона - тщательно чистить код мне было лень, но оно работает.

 

Коротко, что умеет:

1) Определение интерфейса по связке Framed-Protocol+Nas-Port, по Nas-Port-Id или по Framed-Ip (если указано несколько аттрибутов - пытается проверить их соответствие друг другу);

2) Для СоА - модификация /var/run/radattr.pppX согласно полученным аттрибутам, после - SIGUSR1 нужному процессу (который по этому сигналу после наложения патча должен вызывать скрипт /etc/ppp/ip-mod, оригинальный же - просто включал-выключал дебаг), патч для 2.4.4 прилагается;

3) Для DR - SIGHUP нужного процесса.

 

Из того, что явно не умеет - аутентификация по логину и по Session-Id (разбираться, как это вытянуть из пппд, или пилить костыли мне было лень, если кто-то сделает это красиво - добавлю в код с удовольствием).

 

 

[EvilShadow]

Может я не совсем понял требования к функционалу, но почему не snmptrapd?

[Ivan Rostovikov]

IMHO крайне необходимый фукнционал.

Если у кого то получится скрестить с BGB - прошу отписать.

[ates]

Почему возникла идея делать это в виде отдельного демона вместо плугина для pppd?

[Abram]

Почему возникла идея делать это в виде отдельного демона вместо плугина для pppd?

Потому что было кое-что готовое, что надо было лишь допилить.

[NiTr0]

но почему не snmptrapd?

А зачем пилить скриптовые костыли к snmptrapd для обработки/модификации radattr, если есть почти стандартизированное решение, используемое в других насах (кисках, mpd5) довольно долго?

 

Почему возникла идея делать это в виде отдельного демона вместо плугина для pppd?

А как несколько разных процессов будут слушать один и тот же сокет, и разбираться, что кому пришло, где корректный запрос, а где требование отключить/зашейпить давно померший интерфейс?

Ну и + проще частично переписать готовый демон, заменив ф-ю обработки пакета аккаунтинга обработкой RFC3576 пакета (ну и + выкинуть обработку пакетов аутентификации, и сменить порт по умолчанию), чем писать это же с нуля.

[NiTr0]

Поправил баг со 100% загрузкой проца демоном. Новая версия - на сорсфорже.

[phaoost]

скажите, а как его юзать-то?

[NiTr0]

Патчите pppd (чтобы по SIGUSR1 не дебаг включал, а скрипт дергал), вносите в /etc/radcoaddb/clients адрес и пароль хоста, с которого будут приходить запросы, и запускаете radcoad (для журналирования в логи - с ключиками "-l syslog -g local0"). Ну и делаете скрипт /etc/ppp/ip-mod который будет анализировать устанавливать новую скорость согласно /var/run/radattr.pppX - обо всем остальном позаботится radcoad

[telecom]

Патчите pppd (чтобы по SIGUSR1 не дебаг включал, а скрипт дергал), вносите в /etc/radcoaddb/clients адрес и пароль хоста, с которого будут приходить запросы, и запускаете radcoad (для журналирования в логи - с ключиками "-l syslog -g local0"). Ну и делаете скрипт /etc/ppp/ip-mod который будет анализировать устанавливать новую скорость согласно /var/run/radattr.pppX - обо всем остальном позаботится radcoad

Доброго здоровья!

Продолжается ли работа над сабжем?

[NiTr0]

Да собссно вроде пока работает адекватно, функционала хватает - от того более глубоко интегрировать в pppd смысла нет. Тем более, если есть accel-ppp, у которого RFC3576 имеется искаропки.

[telecom]

Да собссно вроде пока работает адекватно, функционала хватает - от того более глубоко интегрировать в pppd смысла нет. Тем более, если есть accel-ppp, у которого RFC3576 имеется искаропки.

 

По функционалу - согласен. ip-mod и сброс сессии это все что нужно.

А почистить код, устранить варнинги при make и ошибки при make install?

И самое интересное, как ведет себя при большой нагрузке?

 

По поводу accel-ppp смотрел, он мне не понравился. У меня pppoe ядрённое (kernel mode), очень удобно навешивать на виланы и не грузит систему. Аксель интересен в основном для pptp-шников.

[2c2i]

По поводу accel-ppp смотрел, он мне не понравился. У меня pppoe ядрённое (kernel mode), очень удобно навешивать на виланы и не грузит систему. Аксель интересен в основном для pptp-шников.

 

accel сейчас умеет pppoe, там еще проще навешивать вланы (есть телнет консоль для управления), кроме того умеет много вкусностей именно для pppoe - задержку PADO ответа к примеру для балансировки клиентов между серверами и возможность ступенчатого ограничения количества коннектов.

[NiTr0]

А почистить код, устранить варнинги при make и ошибки при make install?

 

На это нужно время. А сейчас у меня есть более нужные/приоритетные задачи. Если есть желание - можете заняться, заведу под это дело гит на сорсфорже.

 

И самое интересное, как ведет себя при большой нагрузке?

 

Никаких проблем с ним не наблюдал. В т.ч. и при смене интервала, когда нескольким десяткам человек, сидящих на пакетах с переменной скорсотью, хором (как биллинговый скрипт успевал выплевывать радиус-запросы) перенастраивались шейперы. Да и в принципе ему-то пофиг нагрузка, пакет обработал, нашел процесс, послал сигнал процессу, выплюнул ответ, начал обрабатывать следующий пакет...

По поводу непрерывной работы - аптайм брасов поболее 100 суток.

[telecom]

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

А нескольким тысячам?

 

Если есть желание - можете заняться, заведу под это дело гит на сорсфорже.

 

Я не программер(((

[NiTr0]

А нескольким тысячам?

Демону самому пофиг. Его дело малое, сколько пакетов жевать - без разницы, прожует и выплюнет по очереди ответы заодно с сигналами соответствующим процессам.

А вот как шейпер управится с многочисленными вызовами, и как сервер переживет массовое изменение тарифов скриптами (LA может сильно вырасти) - неизестно, в теории все нормально должно быть, но на практике - всяко случается.