Перейти до

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


Рекомендованные сообщения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)сейчас юзеру можно присвоить тока один ип адрес!

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

если например юзеру нужна сеть /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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

 

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

 

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

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

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

тоесть:

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

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

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

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

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

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

 

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

×
×
  • Створити нове...