Реальные IP клиентам, кто как выходит из положения?

[AndyDv]

Решили в сети убрать NAT и выдавать клиентам реальные IP. В нодени не предусмотрена динамическая выдача ип, а диапазон реальных IP не резиновый.  Отслеживать в ручном режиме их довольно сложно. Поскольку минусовой баланс не является критерием. Сейчас у клиента минус через 5 мин плюс.  Вобщем, нужен совет, кто как выходит из положения?

[Unix]

http://ip-as.ru/

покупай свою сеть внешних адресов и делаю bgp маршрутизацию.

[AndyDv]

http://ip-as.ru/

покупай свою сеть внешних адресов и делаю bgp маршрутизацию.

У меня есть сеть внешних ИП и не одна. И маршрутизация БГП тоже сделана.

Проблема в том, что бы выдать их динамически.  Эти сети не резиновые. И проплата за следующую сеть ип не гарантия того что новую сеть выдадут. Потому что придется доказывать, что предыдущая сеть исчерпана. Не зря райп просит заводить эти сети на графики МРТЖ

> Также, для ускорения обработки последущих заявок рекомендуем
> предоставлять статистику использования адресного пространства
> в виде MRTG-графиков. Сбор статистики можно начать уже сейчас.
> Подробнее об этом можно прочитать на сайте RIPE:
> http://www.ripe.net/rs/ipv4/ipv4-verification.html
> http://www.ripe.net/rs/ipv4/verification-graphs.html

Поэтому динамическая выдача это уже необходимость....   Учет реальных ИП превращается уже в кошмар.

[versus]

Динамической выдачи айпи для нодени пока нет. Потому что существует пока еще жесткая привязка айпи пользователя к пользователю
Это вам 52 версию надо ждать, там такой привявзки вроде бы нет.
Других вариантов для вас, кроме как бинат я не вижу.
 

[Efendy]

Динамической выдачи айпи для нодени пока нет. Потому что существует пока еще жесткая привязка айпи пользователя к пользователю
Это вам 52 версию надо ждать, там такой привявзки вроде бы нет.
Других вариантов для вас, кроме как бинат я не вижу.

кстати, да, в 52й:

ALTER TABLE `users` DROP `ip`
ALTER TABLE `users` DROP `mid`
ALTER TABLE `users` DROP `auth`
ALTER TABLE `users` DROP `money`
ALTER TABLE `users` DROP `sortip`
ALTER TABLE `users` DROP `srvs`
ALTER TABLE `users` DROP `hops`
ALTER TABLE `users` DROP `lstate`
ALTER TABLE `users` DROP `detail_traf`

[elite]

Динамической выдачи айпи для нодени пока нет. Потому что существует пока еще жесткая привязка айпи пользователя к пользователю
Это вам 52 версию надо ждать, там такой привявзки вроде бы нет.
Других вариантов для вас, кроме как бинат я не вижу.

кстати, да, в 52й:

ALTER TABLE `users` DROP `ip`
ALTER TABLE `users` DROP `mid`
ALTER TABLE `users` DROP `auth`
ALTER TABLE `users` DROP `money`
ALTER TABLE `users` DROP `sortip`
ALTER TABLE `users` DROP `srvs`
ALTER TABLE `users` DROP `hops`
ALTER TABLE `users` DROP `lstate`
ALTER TABLE `users` DROP `detail_traf`

заинтриговал
а структуру 52 версии нарисуешь?

[Efendy]

Ну, некоторые позиции. В общих словах и с соплями.

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

Во-вторых, я пытаюсь уйти от понятия "клиент")). Любая запись в базе - это объект. Пока везде фигурирует слово "клиент", но реально уже хранит объекты. (Походу, я не имею ввиду объекты ООП, хотя местами юзаю ООП, ну, или то, что им называют в perl-е:). Дополнительные (настраиваемые) поля описывают группу объектов. Об этом уже говорилось, однако я пошел дальше - у каждой группы свой набор свойств. Например, группа "роутеры" имеет шаблон данных "техданные роутеров", в них содержится Ip-адрес, который выдается роутеру, gps-расположение,  по которому привязывается к карте и т.д. Планирую пойти дальше и привязывать роутеры к точкам топологии, которые тоже будут объектами таблицы users. Хочу и админов и работников туда же. Получится единый механизм взаимодействия объектов.

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

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

В-пятых, mysql созрел для транзакций, гг, на самом деле уже пару лет назад, однако надо понимать, что архитектура NoDeny создавалась много лет назад, когда mysql трудно было назвать субд.

В-шестых, уже авторизация клиента не связана с ip - введено понятие "сессия" (см. Radius) - сколько сессий насоздавал клиент, столько и будет светиться. Т.е. возможен такой вариант - школе дается один логин и пароль клиента "школа", дальше все компы класса соединяются по pppoe (pptp) с сервером, им выдаются какие-то ипы, даже неважно какие, факт в том, что сколько бы не подключилось компов - все они будут принадлежать логину "школа" - иметь один id (никаких алиасов), но будут иметь разные идентификаторы сессий (динамические). У сессий будут параметры мак-адрес, ip и/или другие, какие есть.

Пока хватит)

[smallcms]

В-шестых, уже авторизация клиента не связана с ip - введено понятие "сессия" (см. Radius) - сколько сессий насоздавал клиент, столько и будет светиться. Т.е. возможен такой вариант - школе дается один логин и пароль клиента "школа", дальше все компы класса соединяются по pppoe (pptp) с сервером, им выдаются какие-то ипы, даже неважно какие, факт в том, что сколько бы не подключилось компов - все они будут принадлежать логину "школа" - иметь один id (никаких алиасов), но будут иметь разные идентификаторы сессий (динамические). У сессий будут параметры мак-адрес, ip и/или другие, какие есть.

Мне сразу воображение нарисовало почему-то 1 логин/пароль которым деляться друг с другом по всему району города/области/страны...

[Efendy]

В-шестых, уже авторизация клиента не связана с ip - введено понятие "сессия" (см. Radius) - сколько сессий насоздавал клиент, столько и будет светиться. Т.е. возможен такой вариант - школе дается один логин и пароль клиента "школа", дальше все компы класса соединяются по pppoe (pptp) с сервером, им выдаются какие-то ипы, даже неважно какие, факт в том, что сколько бы не подключилось компов - все они будут принадлежать логину "школа" - иметь один id (никаких алиасов), но будут иметь разные идентификаторы сессий (динамические). У сессий будут параметры мак-адрес, ip и/или другие, какие есть.

Мне сразу воображение нарисовало почему-то 1 логин/пароль которым деляться друг с другом по всему району города/области/страны...

ну и что? разве нет желания подсадить на инет тех людей, которых вам найдет абонент-жулик? Статистика по макам и сессиям ведется. Выжидаете месяц, потом блочите клиента, лепите ему штраф. Все халявщики, попробовав бесплатное демо вашего интернета, остаются без этого наркотика - идут к вам подключаться. Ищите позитив. "Плохой" абонет реально ищет вам клиентуру. Если этими клиентами будут уже ваши состоявшиеся абоненты - лепите всем штраф - надо соблюдать законы. Не хотите платить? - идите нахуй к конкурентам, потом вернетесь.

Ребята, я вам _отвечаю_, поверьте мне, я поработал немало на клиентов, я знаю - будете давать нормальное качество - вам будут побоку все эти игры, вы, наоборот, будете извлекать из этого пользу. Поймите, абонент вас всегда сможет наебать, упав на мороз "я логин никому не давал". Надо создать условия чтоб клиенту было _выгодно_ вас не обманывать. А ему выгодно тогда, когда цена соответствует качеству, когда ему выгодней потратить деньги и очень удобно иметь инет в любой момент времени, не боясь быть застуканным и имея чистую совесть.  Если вы даете гавноуслуги - чтоб вы не делали - будут уходить/обманывать и т.д. А процент "хакиров" есть  в любой сети - для них гордось "сломать провайдера" стыряв у кого-нить пароль или расшарив инет. Таких тоже можно на пользу использовать. Но это маркетинг. Пока вы не достигнете абонентской массы, скажем, в 1000 душ - вам все это как для марсианина балет, я понимаю, но вы к этому придете

[smallcms]

Да это я так... Демагогии ради. Ибо http://freeradius.org/radiusd/doc/Simultaneous-Use никто не отменял. 
Не выйдет у моих дурить. А указанной массы достичь вряд ли удастся ближайшее время. Плюс при работе в домосетях можно самому внезапно упасть на мороз. Контингент, знаете ли, "местный"...

[AndyDv]

В-шестых, уже авторизация клиента не связана с ip - введено понятие "сессия" (см. Radius) - сколько сессий насоздавал клиент, столько и будет светиться. Т.е. возможен такой вариант - школе дается один логин и пароль клиента "школа", дальше все компы класса соединяются по pppoe (pptp) с сервером, им выдаются какие-то ипы, даже неважно какие, факт в том, что сколько бы не подключилось компов - все они будут принадлежать логину "школа" - иметь один id (никаких алиасов), но будут иметь разные идентификаторы сессий (динамические). У сессий будут параметры мак-адрес, ip и/или другие, какие есть.

Пока хватит)

Неплохо.  При таком подходе можно ставить дублирующие PPPoE сервера и назначать им в пулл реальные ИП сети. А не только динамические ИП делать. Ждем новую версию...

[elite]

Можно сделать проще: ввести параметр количество одновременных сессий с 1 логина.
Вот и все

[Efendy]

Можно сделать проще: ввести параметр количество одновременных сессий с 1 логина.
Вот и все

именно

[AndyDv]

А вообще большие сложности прикрутить, динамическую выдачу ИП в текущую версию?  Я совсем уперся уже, райп отказал в выдаче еще одной сети,  а у меня даже половина ИП не используется в час пик.

Откатываться на нат нет никакого желания, конкуренты тоже давят. Практически у всех ип выдаются белые.

[elite]

А вообще большие сложности прикрутить, динамическую выдачу ИП в текущую версию? 

большие...
это надо переписывать ядро, noserver и т.п. = фактически то, что делается в новой версии