Расширение зон тарификации и поля Ip-адрес юзера

[Max 0]

Возникла идея внести два больших изменения в стг касаемых тарифных зон и подсетей юзеров.

1)Тарифные зоны:

сейчас как известно поддерживается следующий формат

 

proto to_net/mask:port dir

 

тоесть

 

tcp 10.0.0.0/24:80 DIR0

 

это думаю комментировать не надо, а очень бы хотелось видеть следующий формат:

 

из_сети(н):порт(н) -> в_сеть:порт(н) прото дир

 

где (н) это не обязательный параметр

 

тоесть

 

85.202.0.0/24 -> 85.202.1.0/24 ALL DIR0

85.202.2.0/24:9996 -> 0.0.0.0/24:80 TCP_UDP DIR1

 

Просто односторонние руез очень ограничены в функционале, когда например важно учитывать откуда пришел трафик.

 

Интересны коментарии и предложения касаемо изменений.

 

Теперь вторая часть

2)сейчас юзеру можно присвоить тока один ип адрес!

это очень не удобно

если например юзеру нужна сеть /24?

судя текущей логике придётся создавать 254 аккаунта

что не есть гуд.

поэтому есть предложение расширить поле ip address

для поддержки формата CIDR (10.10.0.0/24)

это будет означать что юзеру будут тарифицировать все адреса в данном диапазоне от 10.10.0.1 до 10.10.0.254, при этом и в онконект будет пердаваться не адрес а сеть! Приэто естественно ничего не мешает указывать попрежнему один адрес незабыв отметить его правильной маской например 192.168.0.1/32

Вопросы и комментарии?

Відредаговано 2007-09-17 13:43:00 Max

[Cell 7]

  Max сказав:

2)сейчас юзеру можно присвоить тока один ип адрес!

это очень не удобно

если например юзеру нужна сеть /24?

судя текущей логике придётся создавать 254 аккаунта

что не есть гуд.

поэтому есть предложение расширить поле ip address

для поддержки формата CIDR (10.10.0.0/24)

это будет означать что юзеру будут тарифицировать все адреса в данном диапазоне от 10.10.0.1 до 10.10.0.254, при этом и в онконект будет пердаваться не адрес а сеть!

Вопросы и комментарии?

C первой частью обеими руками за

Со второй не очень могу себе представить ситуацию описанную выше.

Как я понимаю речь идет об включении в биллинг организации по одному аккаунту... Решается установкой роутера и запуска на нем авторизатора.

В предложенном варианте в организации включается N авторизаторов и подсчет идет на один аккаунт при этом увеличивается нагрузка на сервер ИХМО.

[Max 0]

  Cell сказав:

  Max сказав:

2)сейчас юзеру можно присвоить тока один ип адрес!

это очень не удобно

если например юзеру нужна сеть /24?

судя текущей логике придётся создавать 254 аккаунта

что не есть гуд.

поэтому есть предложение расширить поле ip address

для поддержки формата CIDR (10.10.0.0/24)

это будет означать что юзеру будут тарифицировать все адреса в данном диапазоне от 10.10.0.1 до 10.10.0.254, при этом и в онконект будет пердаваться не адрес а сеть!

Вопросы и комментарии?

C первой частью обеими руками за

Со второй не очень могу себе представить ситуацию описанную выше.

Как я понимаю речь идет об включении в биллинг организации по одному аккаунту... Решается установкой роутера и запуска на нем авторизатора.

В предложенном варианте в организации включается N авторизаторов и подсчет идет на один аккаунт при этом увеличивается нагрузка на сервер ИХМО.

Есть несколько ограничений вашем варианте:

1) А если у организации /24 адреса?

2) А если у организации не роутер на *nix, а cisco? Да ещё и при этом им нада сеть смаршутизить на этот роутер??

3) А если у организации нет (денег на граничный роутер|места под роутер|желения |роутера) зато есть потребность в /28 адресов прикажите создавать 16 аккаунтов?

4) А если у организации стоит ещё например адпак.....

 

Короче говоря ситуаций много, кторые ваши способ не решает....

 

В нашем случае речь идёт всего лиж о добавлении маски перфикса к адресу, тоесть вместо старой записи например 192.168.2.15 надо будет писать 192.168.2.15/30....

[Колян 2]

Да, это нужно! Действительно!

[Cell 7]

  Max сказав:

  Cell сказав:

  Max сказав:

2)сейчас юзеру можно присвоить тока один ип адрес!

это очень не удобно

если например юзеру нужна сеть /24?

судя текущей логике придётся создавать 254 аккаунта

что не есть гуд.

поэтому есть предложение расширить поле ip address

для поддержки формата CIDR (10.10.0.0/24)

это будет означать что юзеру будут тарифицировать все адреса в данном диапазоне от 10.10.0.1 до 10.10.0.254, при этом и в онконект будет пердаваться не адрес а сеть!

Вопросы и комментарии?

C первой частью обеими руками за

Со второй не очень могу себе представить ситуацию описанную выше.

Как я понимаю речь идет об включении в биллинг организации по одному аккаунту... Решается установкой роутера и запуска на нем авторизатора.

В предложенном варианте в организации включается N авторизаторов и подсчет идет на один аккаунт при этом увеличивается нагрузка на сервер ИХМО.

Есть несколько ограничений вашем варианте:

1) А если у организации /24 адреса?

2) А если у организации не роутер на *nix, а cisco? Да ещё и при этом им нада сеть смаршутизить на этот роутер??

3) А если у организации нет (денег на граничный роутер|места под роутер|желения |роутера) зато есть потребность в /28 адресов прикажите создавать 16 аккаунтов?

4) А если у организации стоит ещё например адпак.....

 

Короче говоря ситуаций много, кторые ваши способ не решает....

 

В нашем случае речь идёт всего лиж о добавлении маски перфикса к адресу, тоесть вместо старой записи например 192.168.2.15 надо будет писать 192.168.2.15/30....

Все так... да не так

Я роутер на старом пристаром пне делал для 9 машин - что там про 16 говорить.

Насчет аппаратных роутеров - можно хитрым образом завернуть udp траффик через них ))) так тоже делал (при этом был всего 1 акк и NAT)

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

[point 0]

можно еще сделать не маску а несколько айпи

допустим фирма с 3я компами на 1 акк

зачем им выделять маску прописать айпи и все

[Bas 2]

Я может чего-то не понимаю, но на моём аккаунте 2 IP адреса и работает. Указаны через запятую.

[Max 0]

  Bas сказав:

Я может чего-то не понимаю, но на моём аккаунте 2 IP адреса и работает. Указаны через запятую.

одновременно или по очереди?

[point 0]

по очереди пашут

а вот одновременно нет

[Max 0]

  point сказав:

по очереди пашут

а вот одновременно нет

а маска даст возможность работать одновременно

[point 0]

маска не всегда удобно

в любом случае штука нужная

я б еще сделал скриптовые тарифы

например с по 1 цена с по 2 цена с по n цена

а так же разная цена на вход и исход для тех у кого спутник

несколько порогов

[Wapr-Old 0]

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

[Max 0]

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

[stg-34 0]

  Max сказав:

85.202.0.0/24 -> 85.202.1.0/24 ALL DIR0

85.202.2.0/24:9996 -> 0.0.0.0/24:80 TCP_UDP DIR1

Как я понял, есть адрес источника и назначения, а где находится адрес юзера?

[Max 0]

а адрес юзера примиряется к этому направлению, если он подходит то есть match

тоесть например

у юзера адрес 85.202.1.2

в стг есть направление:

85.202.0.0/24 -> 85.202.1.0/24 DIR0

85.202.1.0/24 -> 85.202.0.0/24 DIR0

85.202.2.0/24 -> 85.202.1.0/24 DIR2

85.202.1.0/24 -> 85.202.2.0/24 DIR2

0.0.0.0/0 -> 0.0.0.0/0 DIR3

Соотвественно мы можем применить гибкие случаи тарификации

например локальный трафик с ценой 1 считается первыми двумя строками, а с ценой 2 уже следующими двумя.

ну а конец всегда один....

[stg-34 0]

Как-то сложно и непонятно получается...

 

Может эту же схему предстваить расширением правил таким образом:

 

ALL 10.0.0.0/24 UP DIR0

ALL 10.0.0.0/24 DOWN DIR1

ALL 192.168.0.0/24 UP_DOWN DIR2

 

Имхо, понятнее и проще а смысл тот же.

[Max 0]

как раз задача стоит в поддержке поля src!....

[stg-34 0]

src - всегда клиент, если это не клиент, то смысл этого правила?

[Max 0]

просто схема когда маршрут относителен не может помочь в случае когда есть например две группы клиентов, с разной стоимостью за транспорт

тоесть:

первая группа: пусть имеет адрес 85.202.0.10-100

вторая группа 85.202.50.10-100

при этом стоимость транспорта из точки родной сети в сеть 192.168.0.1/24 у первой группы 10 коп, у второй 20 коп

вот и описываем:

 

#первая группа:

85.202.0.0/24 -> 192.168.0.0/24 ALL DIR0

192.168.0.0/24 -> 85.202.0.0/24 ALL DIR0

#вторая группа:

85.202.50.0/24 -> 192.168.0.0/24 ALL DIR1

192.168.0.0/24 -> 85.202.50.0/24 ALL DIR1

Как мы видим в случае исходящего трафика клиент разный (это укладывается в вашу логику), но dst один и тот же! а цена то за транспорт разная!

или опять что то не понятно?!

[stg-34 0]

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

[Max 0]

ну мы же не можем делать кучу направлений под названием LOCAL1 LOCAL2 и тд... тем более что их всего 10

[stg-34 0]

#первая группа:
85.202.0.0/24 -> 192.168.0.0/24 ALL DIR0 (предположим DIR0 это локаль)
192.168.0.0/24 -> 85.202.0.0/24 ALL DIR0 (локаль)
#вторая группа:
85.202.50.0/24 -> 192.168.0.0/24 ALL DIR1(предположим DIR1 это мир)
192.168.0.0/24 -> 85.202.50.0/24 ALL DIR1(мир)

 

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

 

#первая группа:
85.202.0.0/24 -> 192.168.0.0/24 ALL DIR0 (локаль_1)
192.168.0.0/24 -> 85.202.0.0/24 ALL DIR0 (локаль_1)
#вторая группа:
85.202.50.0/24 -> 192.168.0.0/24 ALL DIR1(локаль_2)
192.168.0.0/24 -> 85.202.50.0/24 ALL DIR1(локаль_2)

 

Но это тоже странно: две локали.

 

И еще давай вернемся к самому началу топика. Там была твоя фраза:

  Цитата

Просто односторонние руез очень ограничены в функционале, когда например важно учитывать откуда пришел трафик.

Давай попробуем более точно описать что ты имел ввиду и соотв поищем решение проблемы. Т.к. мне кажется, что мы немного съехали с темы.

[Max 0]

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

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

Как альтернативу можно канечно придумать что то типа поднаправления... Тоесть трафик то локальный, но локальный в нашем случае тоже разный бывает.....

[stg-34 0]

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

[Max 0]

давайте! итог подвёл в предпоследнем посте, а как решить проблему по другому я не знаю....

а самый кровавый, это описывать тарифы и рулесы все вместе, тоесть создаёшь тариф и сразу в него загоняешь сети, сразу проставляя сети! кстати мысль....