Jump to content

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

Max

By Max,
in Stargazer development

 Share Followers 1

Recommended Posts

Max

Max 0

Posted
Posted (edited)

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

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

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

Edited by Max
Link to post
Share on other sites
Cell

Cell 7

Posted
Posted

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

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

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

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

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

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

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

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

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

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

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

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

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

Link to post
Share on other sites
Max

Max 0

Posted
  • Author
Posted

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....

Link to post
Share on other sites
Cell

Cell 7

Posted
Posted

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)

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

Link to post
Share on other sites
point

point 0

Posted
Posted

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

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

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

Link to post
Share on other sites
Bas

Bas 2

Posted
Posted

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

Link to post
Share on other sites
Max

Max 0

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

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

Link to post
Share on other sites
point

point 0

Posted
Posted

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

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

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

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

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

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

Link to post
Share on other sites
Wapr-Old

Wapr-Old 0

Posted
Posted

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

Link to post
Share on other sites
  • 1 month later...
Max

Max 0

Posted
  • Author
Posted

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

Link to post
Share on other sites
stg-34

stg-34 0

Posted
Posted
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

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

Link to post
Share on other sites
Max

Max 0

Posted
  • Author
Posted

а адрес юзера примиряется к этому направлению, если он подходит то есть 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 уже следующими двумя.

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

Link to post
Share on other sites
stg-34

stg-34 0

Posted
Posted

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

 

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

 

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

 

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

Link to post
Share on other sites
Max

Max 0

Posted
  • Author
Posted

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

тоесть:

первая группа: пусть имеет адрес 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 один и тот же! а цена то за транспорт разная! :(

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

Link to post
Share on other sites
stg-34

stg-34 0

Posted
Posted

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

Link to post
Share on other sites
stg-34

stg-34 0

Posted
Posted 

#первая группа:
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)

 

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

 

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

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

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

Link to post
Share on other sites
Max

Max 0

Posted
  • Author
Posted

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

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

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

Link to post
Share on other sites
stg-34

stg-34 0

Posted
Posted

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

Link to post
Share on other sites
Max

Max 0

Posted
  • Author
Posted

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

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

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Followers 1
Go to topic listing

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...