firstcalled Опубликовано 7 сентября, 2015 · Жалоба Добрый! Сразу расставлю точки над i: в linux новичок, поэтому большая просьба выражаться яснее и если вы используете спец. лексику, то используйте ее английские аналоги, чтобы я всегда мог загуглить и понять, о чем идет речь вообще. А теперь по существу вопроса. Что есть: системный блок с debian, 2 сетевых интерфейса, на этом деле настроена базовая маршрутизация и nat. Внешний интрефейс - eth0 - пусть будет 10.30.139.2/24, внутренний интерфейс - eth1 - пусть будет 192.168.1.2/24. Есть канал, равный 10мб в сек. Есть 10 пользователей. Чего хочется: чтобы он динамически делился, между всеми пользователями и чтобы все получали поровну. Прочитав мануалы с этих сайтов tldp.org/HOWTO/Traffic-Control-HOWTO/index.html и www.lartc.org/lartc.html и www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO.html и еще парочку, я примерно понял, как решение выглядит, но потом появился ряд вопросов: Во-первых, вся мощь tc утилины под linux используется только для исходящего трафика, входящий трафик мы не можем шейпить(shaping), все, что мы можем делать с ним - это откидывать(policing, согласно http://www.lartc.org), но я-то хочу не просто, чтобы 10 пользователей получали по 1мб. А чтобы, если канал используется двумя пользователями, то каждый бы получал по 5мб в среднем, если используется тремя, то по 3.3 и тд. Я думаю, вы поняли идею. А достичь этого просто при помощи отбрасывания пакетов мы не сможем. Начал искать и нашел такие вещи, как IMQ и IFB, но читая статьи про них и споры людей, понял, что это вроде бы как работает, но не является правильным использование этих "костылей". Тогда мне в голову пришла простая идея, ради которой и пишется сей опус, а что если шейпить входящий трафик(Internet -> eth0 -> внутренние процессы NAT и routing -> eth1 -> внутренняя сеть), но не на eth0, а на eth1?! Ведь для tc он будет считаться исходящим, ведь приходит он из внутренних процессов и отправляется в сеть, хотя для нас это, по факту, входяший трафик, верно? Или мои рассуждения неверны на корню? Во-вторых, насколько все-таки неверно использование IMQ и IFB? Правда ли это такие костыли, которых лучше избегать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
disappointed Опубликовано 7 сентября, 2015 · Жалоба Без разницы, что на eth1 шейпить, что отзеркаленный на ifb с eth0 - суть не меняет, это трафик который пришёл от удалённой стороны, с ним можно только что-то сделать в надежде, что удалённый хост приостановит передачу. В принципе то, что описано приемлемо работает, но нужно запас оставлять в корневом классе, процентов 10-15 от реальной полосы, чтобы не упираться в шейпер/полисер вышестоящего оператора. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
firstcalled Опубликовано 7 сентября, 2015 · Жалоба Без разницы, что на eth1 шейпить, что отзеркаленный на ifb с eth0 - суть не меняет, это трафик который пришёл от удалённой стороны, с ним можно только что-то сделать в надежде, что удалённый хост приостановит передачу. В принципе то, что описано приемлемо работает, но нужно запас оставлять в корневом классе, процентов 10-15 от реальной полосы, чтобы не упираться в шейпер/полисер вышестоящего оператора. Спасибо за ответ! Насколько я помню и исходя из того, что я понял из QoS, если передающая сторона видит, что нет подтверждения от принимающей стороны того, что пакеты были доставлены, она, передающая сторона, должна уменьшить скорость передачи и повторить передачу недошедших пакетов. В squid это прекрасно работает. Должно работать и в tc. Есть, например, youtube и человек качает фильм, при этом полностью вычерпывает весь свой трафик, если мы настроим все правильно, то входящие пакеты, из-за отсутсвия места в очереди, будут отбрасываться, youtube будет снижать скорость и мы получаем то, что нужно. Верно же? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 7 сентября, 2015 · Жалоба QoS немного из другой оперы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
evil-man Опубликовано 8 сентября, 2015 (изменено) · Жалоба его хочется: чтобы он динамически делился, между всеми пользователями и чтобы все получали поровну. Прочитав мануалы с этих сайтов tldp.org/HOWTO/Traffic-Control-HOWTO/index.html и www.lartc.org/lartc.html и www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO.html и еще парочку, я примерно понял, как решение выглядит, но потом появился ряд вопросов: Добрый день! Того, что Вы описали, можно достигнуть, используя дисциплины очереди SFQ/FQ/QFQ и иже с ними, то есть любую Fair Queue дисциплину, которая распределяет ресурсы примерно равными частями между потоками. Так как вы отталкиваетесь от адреса источника (клиентский адрес), то надо будет повесить flow-фильтр с хешированием по адресу источника (на интерфейсе который смотрит в интернет) и адресу назначения (на интерфейсе, который смотрит в сторону клиентской сети). Изменено 8 сентября, 2015 пользователем evil-man Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
disappointed Опубликовано 9 сентября, 2015 · Жалоба если передающая сторона видит, что нет подтверждения от принимающей стороны того, что пакеты были доставлены, она, передающая сторона, должна уменьшить скорость передачи и повторить передачу недошедших пакетов. Да, работает неплохо. Я в пору введения безлимов, когда цена каждого метра была поистине конской таким образом удерживал приемлемый интернет в условиях почти круглосуточной "полки". Самым критичным была именно подушка - запас по полосе, подбиралось экспереминтально, и ещё было важно чтобы вышестоящий оператор ни в коем случае не шейпил, а полисил, с большим бёрстом. Чтобы у него не образовывалась неподконтрольная очередь входящих пакетов. Тогда вообще на ура работать будет. Если применять сейчас то возможно будет проблема с торрентами по UDP, они довольно агрессивно работают. Можно попытаться дропать такой трафик по сигнатурам, там было за что зацепится на этапе установки соединения, но как с этим протоколом сейчас дела обстоят не знаю, возможно его уже обфусцировали. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vop Опубликовано 10 сентября, 2015 · Жалоба Если я правильно понял суть вопроса - старая проблема скрещивания NAT и shaper. Для того и используются либо псевдо-устройства, типа ifb, либо маркировка трафика до NATа для шейпера индивидуально для каждого абонента. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 11 сентября, 2015 · Жалоба vop Нет, у человека нет тоннелей или любых других виртуальных интерфейсов. Ему ничто не мешает шейпить на физических eth0 и eth1. Нужные примеры для реализации честного деления между абонентами есть в lartc, там 10 строк получится(HTB+SFQ и настройка rate/ceil). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
disappointed Опубликовано 12 сентября, 2015 · Жалоба там 10 строк получится(HTB+SFQ и настройка rate/ceil). На полосах в сотни мегабит SFQ плохо придерживала торренты, я использовал bfifo с большим буфером. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vop Опубликовано 16 сентября, 2015 · Жалоба vopНет, у человека нет тоннелей или любых других виртуальных интерфейсов. Ему ничто не мешает шейпить на физических eth0 и eth1. У него есть NAT, и внешний интерфейс, на котором после ната трафик по абонентам не разделить. Или нет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...