Перейти к содержимому
Калькуляторы

Поддержка POD/CoA для Linux pppd Для желающих потестить/допилить

Появилась необходимость на лету менять скорость/дропать клиентов на линуксовых насах; готового правильного решения не нашел, юзать 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 (разбираться, как это вытянуть из пппд, или пилить костыли мне было лень, если кто-то сделает это красиво - добавлю в код с удовольствием).

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.