А такое возможно ?

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

А такое возможно ?

irix
Hello Openbsd,

   Будет  ли  работать  такая фишка как просьбы pf к удалённой стороне
   слать  поток  данных  помедленней  по tcp протоколу. Единственная
   легитимная фишка попыток замедлить входящий tcp поток. Исскуственно
   вызывая перегрузку канала для определённого tcp соединения если его
   входящая   скорость  превышает  определённый  порог.  Но  при  этом
   пришедшие  пакеты и прочие данные не дропаються и не выстраиваються
   в  очередь. Просто удалённая сторона считает что у нас перегрузка и
   начинает слать данные медлененее. И не использовать при этом altq с
   его  дрочингом  над  исходящим  потоком.  т.е  чтобы эта штука была
   независима от altq и небыло никаких очередей.

--
Best regards,
 irix                          mailto:[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: А такое возможно ?

Ilya A. Kovalenko
Ничего конкретного, просто пара замечаний.

>   Будет  ли  работать  такая фишка как просьбы pf к удалённой стороне
> слать  поток  данных  помедленней  по tcp протоколу.
> {...}
> И не использовать при этом altq с его дрочингом  над  исходящим
> потоком. т.е  чтобы эта штука была независима от altq и небыло
> никаких очередей.
строго говоря, если на peer-ах работает ECN, то до переполнения
очереди, и связанных с ней проблем дойти не должно. Единственное что
мне лично не нравится в PF-реализации ECN, это невозможность включить
ECN без RED (возможно в RED есть свои плюсы, но идея искусственного
уменьшения достоверности канала мне категорически не нравится).

>    Единственная легитимная фишка попыток замедлить входящий tcp
> поток.
AFAIK, очереди вполне кошерно справляются с замедлением TCP-потока,
т.к. нормальное TCP-соединение не может перегрузить очередь до
необходимости дропа.

--
С уважением,
Илья А. Коваленко                     (mailto:[hidden email])
Системный администратор
ЗАО Оганер-Сервис
+7 3919 348-629


Reply | Threaded
Open this post in threaded view
|

Re: А такое возможно ?

irix
Hello Ilya,

Tuesday, August 4, 2009, 6:10:29 AM, you wrote:

IAK> Ничего конкретного, просто пара замечаний.

>>   Будет  ли  работать  такая фишка как просьбы pf к удалённой стороне
>> слать  поток  данных  помедленней  по tcp протоколу.
>> {...}
>> И не использовать при этом altq с его дрочингом  над  исходящим
>> потоком. т.е  чтобы эта штука была независима от altq и небыло
>> никаких очередей.
IAK> строго говоря, если на peer-ах работает ECN, то до переполнения
IAK> очереди, и связанных с ней проблем дойти не должно. Единственное что
IAK> мне лично не нравится в PF-реализации ECN, это невозможность включить
IAK> ECN без RED (возможно в RED есть свои плюсы, но идея искусственного
IAK> уменьшения достоверности канала мне категорически не нравится).

>>    Единственная легитимная фишка попыток замедлить входящий tcp
>> поток.
IAK> AFAIK, очереди вполне кошерно справляются с замедлением TCP-потока,
IAK> т.к. нормальное TCP-соединение не может перегрузить очередь до
IAK> необходимости дропа.


Просто  почему  я затронул вопрос относительно того чтобы небыло altq,
при этом

Например стоит одинкой ftp, и некто на него хочет записать файл.
Чтобы  ограничить  скорость получения файла на сервере создана очередь
для отправляющего хоста с значением bandwidth 8Kb, при таком bandwidth
скорость  приёма будет ~ 70-72 килобайта, но вот файло закачано и этот
же  хост уже хочет не закачать а скачать файло, и упираеться в эти 8Kb
и  сидит благополучно улыбаеться в очереди. И качает файло на скорости
1 килобайт.

--
Best regards,
 irix                            mailto:[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: А такое возможно ?

Anton Maksimenkov-2
4 августа 2009 г. 9:45 пользователь irix ([hidden email]) написал:
> Например стоит одинкой ftp, и некто на него хочет записать файл.
> Чтобы  ограничить  скорость получения файла...
> ...уже хочет не закачать а скачать файло

use pure-ftpd
--
antonvm
Reply | Threaded
Open this post in threaded view
|

Re: А такое возможно ?

irix
Hello Anton,

Tuesday, August 4, 2009, 6:59:57 AM, you wrote:

AM> 4 августа 2009 г. 9:45 пользователь irix ([hidden email]) написал:
>> Например стоит одинкой ftp, и некто на него хочет записать файл.
>> Чтобы  ограничить  скорость получения файла...
>> ...уже хочет не закачать а скачать файло

AM> use pure-ftpd

Круто,  но  ftp  это  лишь  один из вариатов. Файло можно ещё например
закачмвать по ssh, как тогда в самом демоне регулировать ? :)

--
Best regards,
 irix                            mailto:[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: А такое возможно ?

Anton Maksimenkov-2
4 августа 2009 г. 10:12 пользователь irix ([hidden email]) написал:
> AM> use pure-ftpd
> Круто,  но  ftp  это  лишь  один из вариатов. Файло можно ещё например
> закачмвать по ssh, как тогда в самом демоне регулировать ? :)

отключить sftp :)
--
antonvm
Reply | Threaded
Open this post in threaded view
|

Re: А такое возможно ?

irix
Hello Anton,

Tuesday, August 4, 2009, 7:25:53 AM, you wrote:

AM> 4 августа 2009 г. 10:12 пользователь irix ([hidden email]) написал:
>> AM> use pure-ftpd
>> Круто,  но  ftp  это  лишь  один из вариатов. Файло можно ещё например
>> закачмвать по ssh, как тогда в самом демоне регулировать ? :)

AM> отключить sftp :)

а если это нада. :)

--
Best regards,
 irix                            mailto:[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re[2]: А такое возможно ?

Ilya A. Kovalenko
In reply to this post by irix
> Например стоит одинкой ftp, и некто на него хочет записать файл.
> Чтобы  ограничить  скорость получения файла на сервере создана очередь
> для отправляющего хоста с значением bandwidth 8Kb, при таком bandwidth
> скорость  приёма будет ~ 70-72 килобайта

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

в свое время я тестировал подобную позу и забраковал, т.к. c
отношением in/out ~1:27 и управление получается весьма грубое, и
ограничения неприемлемы.

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


Reply | Threaded
Open this post in threaded view
|

Re: А такое возможно ?

Ilya A. Kovalenko
In reply to this post by irix
>    Исскуственно вызывая перегрузку канала для определённого tcp
> соединения если его входящая   скорость  превышает  определённый
> порог. Но при этом пришедшие пакеты и прочие данные не дропаються и
> не выстраиваються в  очередь. Просто удалённая сторона считает что
> у нас перегрузка и начинает слать данные медлененее. И не
> использовать при этом altq с его  дрочингом  над  исходящим
> потоком.  т.е  чтобы эта штука была независима от altq и небыло
> никаких очередей.

  Поддержка ECN в самом ядре есть, но боюсь что исключительно для
применения по назначению - т.е. для при реальной перегрузке или только
для серверов на самом obsd.

  Эмуляция же перегрузки, наверно, реализована только в ALTQ.

  Кстати, я что-то не пойму, о какой схеме связи идет речь ? Если в
ней присутствует выделенный OpenBSD-роутер, то с шейпингом (и
эмуляцияей ECN в процессе) в обоих направлениях проблем возникать не
должно (в особенности на 4.6+, где наконец шейпинг отвязали от
фильтрации).

  Быть может, разве что, можно сделать какую-нибудь хитрую шейпинговую
дисциплину на базе CBQ, которая не будет ставить пакеты в очередь, а
соединениями будет управлять исключительно с помощью ECN.


Reply | Threaded
Open this post in threaded view
|

Re: А такое возможно ?

Anton Maksimenkov-2
> ...в особенности на 4.6+, где наконец шейпинг отвязали от фильтрации.

не поясните ли этот тезис?
--
antonvm
Reply | Threaded
Open this post in threaded view
|

Re: А такое возможно ?

irix
Hello Anton,

Tuesday, August 4, 2009, 1:57:06 PM, you wrote:

>> ...в особенности на 4.6+, где наконец шейпинг отвязали от фильтрации.

AM> не поясните ли этот тезис?

Мне тоже интересно :)

--
Best regards,
 irix                            mailto:[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: А такое возможно ?

irix
In reply to this post by Ilya A. Kovalenko
Hello Ilya,

Tuesday, August 4, 2009, 1:27:33 PM, you wrote:

>>    Исскуственно вызывая перегрузку канала для определённого tcp
>> соединения если его входящая   скорость  превышает  определённый
>> порог. Но при этом пришедшие пакеты и прочие данные не дропаються и
>> не выстраиваються в  очередь. Просто удалённая сторона считает что
>> у нас перегрузка и начинает слать данные медлененее. И не
>> использовать при этом altq с его  дрочингом  над  исходящим
>> потоком.  т.е  чтобы эта штука была независима от altq и небыло
>> никаких очередей.

IAK>   Поддержка ECN в самом ядре есть, но боюсь что исключительно для
IAK> применения по назначению - т.е. для при реальной перегрузке или только
IAK> для серверов на самом obsd.

IAK>   Эмуляция же перегрузки, наверно, реализована только в ALTQ.

IAK>   Кстати, я что-то не пойму, о какой схеме связи идет речь ? Если в
IAK> ней присутствует выделенный OpenBSD-роутер, то с шейпингом (и
IAK> эмуляцияей ECN в процессе) в обоих направлениях проблем возникать не
IAK> должно (в особенности на 4.6+, где наконец шейпинг отвязали от
IAK> фильтрации).

IAK>   Быть может, разве что, можно сделать какую-нибудь хитрую шейпинговую
IAK> дисциплину на базе CBQ, которая не будет ставить пакеты в очередь, а
IAK> соединениями будет управлять исключительно с помощью ECN.

ECN по умолчанию везде выключена (винда, линух, фря, опёнка).

Тут  не  в  дисциплене  дело,  вообще грубо говоря traffic police типа
ALTQ_CDNR,  кондиционер  дропает  всё  что больше рэйта, а эта фишкабы
обрабатывала только tcp и пакеты не дропала. Просто пыталасьбы наебать
удалённый хост что у неё перегруз и чтобы он слал медленее.

Ну   типа  как  в  любой  виндовой  качалке  Download  manager,  можно
высталять  ограничение  на  скорость  скачивания  файла.  И  эта штука
работает.  Файло  начинает  качаться  медлее и освобождает полосу. Т.е
наёбка удалённого хоста успешна.







--
Best regards,
 irix                            mailto:[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: А такое возможно ?

irix
Hello irix,

Tuesday, August 4, 2009, 3:38:55 PM, you wrote:

i> Hello Ilya,

i> Tuesday, August 4, 2009, 1:27:33 PM, you wrote:

>>>    Исскуственно вызывая перегрузку канала для определённого tcp
>>> соединения если его входящая   скорость  превышает  определённый
>>> порог. Но при этом пришедшие пакеты и прочие данные не дропаються и
>>> не выстраиваються в  очередь. Просто удалённая сторона считает что
>>> у нас перегрузка и начинает слать данные медлененее. И не
>>> использовать при этом altq с его  дрочингом  над  исходящим
>>> потоком.  т.е  чтобы эта штука была независима от altq и небыло
>>> никаких очередей.

IAK>>   Поддержка ECN в самом ядре есть, но боюсь что исключительно для
IAK>> применения по назначению - т.е. для при реальной перегрузке или только
IAK>> для серверов на самом obsd.

IAK>>   Эмуляция же перегрузки, наверно, реализована только в ALTQ.

IAK>>   Кстати, я что-то не пойму, о какой схеме связи идет речь ? Если в
IAK>> ней присутствует выделенный OpenBSD-роутер, то с шейпингом (и
IAK>> эмуляцияей ECN в процессе) в обоих направлениях проблем возникать не
IAK>> должно (в особенности на 4.6+, где наконец шейпинг отвязали от
IAK>> фильтрации).

IAK>>   Быть может, разве что, можно сделать какую-нибудь хитрую шейпинговую
IAK>> дисциплину на базе CBQ, которая не будет ставить пакеты в очередь, а
IAK>> соединениями будет управлять исключительно с помощью ECN.

i> ECN по умолчанию везде выключена (винда, линух, фря, опёнка).

i> Тут  не  в  дисциплене  дело,  вообще грубо говоря traffic police типа
i> ALTQ_CDNR,  кондиционер  дропает  всё  что больше рэйта, а эта фишкабы
i> обрабатывала только tcp и пакеты не дропала. Просто пыталасьбы наебать
i> удалённый хост что у неё перегруз и чтобы он слал медленее.

i> Ну   типа  как  в  любой  виндовой  качалке  Download  manager,  можно
i> высталять  ограничение  на  скорость  скачивания  файла.  И  эта штука
i> работает.  Файло  начинает  качаться  медлее и освобождает полосу. Т.е
i> наёбка удалённого хоста успешна.

      ну или чтобы совсем просто

      в любом ftpd есть опции

      upload bandwidth - ск какой скоростью принемать файло
      download bandwidth - с какой скоростью отдавать файло

      Обе опции работают.

      Так  сделать  тоже самое но на уровне pf, чтобы такое можно было
      на любое прилдожение вешать.








--
Best regards,
 irix                            mailto:[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re[2]: А такое возможно ?

Ilya A. Kovalenko
In reply to this post by Anton Maksimenkov-2
>> ...в особенности на 4.6+, где наконец шейпинг отвязали от фильтрации.
> не поясните ли этот тезис?

извольте :)

До 4.6 Привязка определенного трафика к определенной очереди ALTQ,
выполняется только добавлением модификатора queue в правило
фильтрации pass (или block). Это, с одной стороны позволяет
привязывать трафик весьма гибко (по сравнению с ALTQ до интеграции в
PF), но с другой стороны привязывает фильтрацию к шейпингу и
наоборот. Пока они идут вместе, проблем не создается, но если правила
фильтрации сложнее или проще чем правила шейпинга, то, в зависимости
от случая вы вынуждены либо перегружать рулесет, либо задуманная
схема реализуема только на ДВУХ последовательных OpenBSD-шлюза.

В 4.6 добавили правило "match" которое не блокирует и не пропускает
трафик, лишь назначая опции (включая шейпинг) которые не
перегружаются last-matching правилами pass/block если эти
модификаторы там не определены явно. То есть, при необходимости,
можно полностью отделить друг от друга правила шейпинга и фильтрации.

Пара практических примеров:

Пример 1 (фильтрация сложнее шейпинга):

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

Вводные по фильтрации:
  убить трафик RPC (135-139 445)
  убить udp-порт MS-SQL
  заблокировать трафик в несуществующие и закрытые сети
  открыть icmp и некоторые порты отдельных серверов
  заблокировать отдельные клиентские IP от локалки
  и т.п.

Итог:
  До 4.6 при прописывании правил фильтрации в out- или
  in/out-правилах отгребаем необходимость прописывания модификатора
  "queue" в каждом божьем правиле "pass"

Пример 1 (шейпинг сложнее фильтрафии):

Вводные по шейпингу:
  ограничиваем скорость нескольким клиентам (скажем восьми), для
  разных ресурсов (инет, локалка, p2p, Lineage, IRC ...), на
  различных интерфейсах

Вводные по фильтрации (NB: экспериментальный рулесет):
базовый рулесет организован в четыре правила:

  set skip on lo0

  block drop in all
  block return-rst in proto tcp all
  pass from <Known> to <UnProtected> flags S/SA keep state
  pass from <Trusted> to <Protected> flags S/SA keep state

где все существующие хосты и сети записаны в <Known>, а также
разложены в таблицы <Trusted> <UnTrusted> и таблицы
<Protected> и <UnProtected> (названия, должны говорить за себя)

Итог:
  До 4.6. Схема НА ОДНОМ ШЛЮЗЕ не реализуема.


Reply | Threaded
Open this post in threaded view
|

Re[2]: А такое возможно ?

Ilya A. Kovalenko
In reply to this post by irix
> ECN по умолчанию везде выключена (винда, линух, фря, опёнка).
угу

> Тут  не  в  дисциплене  дело,  вообще грубо говоря traffic police типа
> ALTQ_CDNR,  кондиционер  дропает  всё  что больше рэйта, а эта фишкабы
> обрабатывала только tcp и пакеты не дропала. Просто пыталасьбы наебать
> удалённый хост что у неё перегруз и чтобы он слал медленее.
такой обработке (если такая тема реализуема и имеет нужный эффект),
как раз место в ALTQ, не понятно, почему вы от него открещиваетесь.
другой вопрос, что, к сожалению пока ALTQ многого не умеет, а
разработчики не распинываются :) т.к. не понимают важности
некоторых вещей, и/или не имеют времени/возможности

> Ну   типа  как  в  любой  виндовой  качалке  Download  manager,  можно
> высталять  ограничение  на  скорость  скачивания  файла.  И  эта штука
> работает.  Файло  начинает  качаться  медлее и освобождает полосу. Т.е
> наёбка удалённого хоста успешна.

Download manager делает это НЕ ЧИТАЯ данные из буфера IP-стека, таким
образом, в буфере не освобождается места, стек клиента не посылает
серверу не новые значения "окна", и сервер не высылает новых данных.

Точно так же, ALTQ на шлюзе ставит пакеты с данными в очередь, данные не
приходят на клиента, стек клиент не высылает новые значения "окна"
.. см. выше

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


Reply | Threaded
Open this post in threaded view
|

Re: А такое возможно ?

irix
Hello Ilya,

Wednesday, August 5, 2009, 9:45:34 AM, you wrote:

>> ECN по умолчанию везде выключена (винда, линух, фря, опёнка).
IAK> угу

>> Тут  не  в  дисциплене  дело,  вообще грубо говоря traffic police типа
>> ALTQ_CDNR,  кондиционер  дропает  всё  что больше рэйта, а эта фишкабы
>> обрабатывала только tcp и пакеты не дропала. Просто пыталасьбы наебать
>> удалённый хост что у неё перегруз и чтобы он слал медленее.
IAK> такой обработке (если такая тема реализуема и имеет нужный эффект),
IAK> как раз место в ALTQ, не понятно, почему вы от него открещиваетесь.
IAK> другой вопрос, что, к сожалению пока ALTQ многого не умеет, а
IAK> разработчики не распинываются :) т.к. не понимают важности
IAK> некоторых вещей, и/или не имеют времени/возможности

>> Ну   типа  как  в  любой  виндовой  качалке  Download  manager,  можно
>> высталять  ограничение  на  скорость  скачивания  файла.  И  эта штука
>> работает.  Файло  начинает  качаться  медлее и освобождает полосу. Т.е
>> наёбка удалённого хоста успешна.

IAK> Download manager делает это НЕ ЧИТАЯ данные из буфера IP-стека, таким
IAK> образом, в буфере не освобождается места, стек клиента не посылает
IAK> серверу не новые значения "окна", и сервер не высылает новых данных.

IAK> Точно так же, ALTQ на шлюзе ставит пакеты с данными в очередь, данные не
IAK> приходят на клиента, стек клиент не высылает новые значения "окна"
IAK> .. см. выше

IAK> ECN, по-моему, будут, как минимум, менее эффективны, т.к. поток
IAK> данных по получению ECN (AFAIK) не прекращается, а лишь уменьшается
IAK> настолько насколько это понимают удаленные (по отношению к шлюзу)
IAK> сервер или клиент.

  Может  быть  у  вас  есть  возможность научить pf понимать ALTQ_CDNR
  который уже в ядре с 2001 года, но до pf никак не дойдёт :)
  Разработчики заявили что им на altq  насрать.





--
Best regards,
 irix                            mailto:[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re[2]: А такое возможно ?

Ilya A. Kovalenko
Здравствуйте, irix.
>   Может  быть  у  вас  есть  возможность научить pf понимать ALTQ_CDNR
>   который уже в ядре с 2001 года, но до pf никак не дойдёт :)
вы издеваетесь ? :)


Reply | Threaded
Open this post in threaded view
|

Re: А такое возможно ?

Anton Maksimenkov-2
In reply to this post by irix
5 августа 2009 г. 15:30 пользователь irix ([hidden email]) написал:
>...
>>> ...
> IAK>...

и это... цитирование кучи воды без пользы смыслу - зло.
--
antonvm