_dx Опубликовано 4 августа, 2011 · Жалоба Расклад: Около 100 клиентов подключены к VPN(openvpn) серверу(Debian) и роутятся(+NAT) через него во внешний мир. Гоняют они в основном VOIP траффик(skype). Разумеется, не между собой, а во внешний мир и обратно. Задача: Максимально эффективно и поровну распределить имеющуюся полосу(100мбит) Ограничение скорости реализовано на клиентском роутере(в штатном режиме). Сервер, средствами openvpn, ограничивает клиенту download в случае если клиент будет взломан(в штатном режиме в это ограничение клиент не упирается никгда). Т.е. ограничение скорости средствами tc вроде не нужно. Только fair queueing. Первая мысль: Исходящий траффик со всех tun интерфейсов сервера зарулить в IFB, а на него навесить SFQ. По айпишникам клиентов раскидывать по классам... На сколько это оптимально/правильно? Как быть со входящим траффиком? Хотелось бы раскидывать входящие пакеты так-же равномерно всем клиентам, а не как Бог даст.. VOIP же всё-таки. Но там NAT всё портит и у меня нет пока хорошей идеи как сделать SFQ на входящий траффик. Посоветуйте что-нибудь плиз. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
m0xf Опубликовано 4 августа, 2011 · Жалоба При наличии nat редирект на ifb нужно делать с внутренних интерфейсов (в данном случае tun), тогда можно фильтровать по серым ip. Входящий и исходящий трафик лучше перебросить на разные ifb. Дальше на ifb можно нацепить sfq или drr совместно с flow hash классификатором. Это для исходящего трафика, для входящего (из интернета), чтобы не образовывался затык на интерфейсе нужно ещё подрезать полосу например с помощью htb. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_dx Опубликовано 4 августа, 2011 · Жалоба Аа, ну да, что же это я не подумал, что на другой ifb можно входящие пакеты тех-же tun'ов перебрасывать. В моём случае что лучше выбрать sfq или drr? С маркировка пакетов средствами iptables уже имел дело, но мне кажется это медленно..хотя на LORе сказали, что нет. В общем стоит заморчаиваться с u32 или нет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_dx Опубликовано 5 августа, 2011 · Жалоба Уже понял, что предыдущие вопросы был глупыми ) Снова пересмотрел lartc..ничего не нашел про flow hash классификаторы.. гугление тоже пока не дало результатов.. Опыта особого нет пока.. может быть кто на пальцах объяснит что к чему и зачем нужен flow hash к sfq и в чём тут соль? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_dx Опубликовано 6 августа, 2011 · Жалоба я кажется запутался что есть egress а что ingress с обычной сетевушкой всё ясно: после egress идёт кабель. но egress у tun0 на сервере это то, что отправляет клиент? правильно я понимаю? вот клиент хочет пингануть сервер и эхо реквесты ложаться в egress tun0? и на egress мы можем спокойно вешать шейпер и без всяких извратов с ifb. или таки нет? или у tun0 egress по аналогии с сетевухой это кабель и egress идёт к vpn клиенту? вроде так логичнее..да. но меня смутило вот что: в интернетах везде пишут tc filter add dev tun0 parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0 mirred egress же! т.е. я перенаправляю на ifb0 то, что и так можно шейпить без ifb. но когда я заменил egress на ingress - получил матюг mirred ingres not supported at the moment так вот я и не понял вообще как мне входящий(для клиента) траффик шейпить то? и где на самом деле у tun ingress а где egress? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_dx Опубликовано 6 августа, 2011 (изменено) · Жалоба что ж такое, а. как только вопрос задам - сразу ответ нахожу. дошло в общем. когда мы задаём tc filter add dev tun0 parent ffff: .. мы уже имеем дело с ingress tun0. а дальше мы говорим action mirred egress redirect dev ifb0 т.е. пакеты из ingress tun0, которые подошли под критерии фильтра редиректить в egress ifb0. уж извините, что тему всё время апаю... разбираюсь в общем как-бэ... )) Изменено 6 августа, 2011 пользователем _dx Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_dx Опубликовано 7 августа, 2011 (изменено) · Жалоба На сервере будет одна сетевуха и я хотел прибить openvpn демоны к 127.0.0.1 а с eth0 форвардить порт для распределения нагрузки по разным демонам(потому что openvpn однопоточный и тормозной). Но DNAT не хочет перекидывать пакеты на 127.0.0.1 Тупо фильтровать на INPUTe тоже получается как-то не весело ибо как отличить пакеты, пробравшиеся прямо с eth0 на конкретный порт и перекинутые по DNAT? Получается маркировать надо, а потом по меткам разбирать.. ерунда всё это... лишние правила ещё и в достаточно нагруженной таблице filter...не оптимально совсем.. Может какой виртуальный интерфейс поднять тогда? но тоже как-то слишком жирно выходит.. Что в таких случаях делают? Куда забиндить openvpn чтобы к нему доступа не было без форвардинга? Изменено 7 августа, 2011 пользователем _dx Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_dx Опубликовано 10 августа, 2011 · Жалоба Разобрался практичеси со всеми интересующими вопросами.. Сейчас уже работает "объединение" ingress и egress всех tun в два разных ifb, на которых успешно работает sfq с flow hash keys, а также испытал в комбинации с htb. У меня вопрос по WAN интерфейсу(eth0). Какую дисциплину там лучше использовать? Кому отдать приоритет? Напомню топологию: (к примеру клиент передаёт данные на nag.ru) vpn_client->{INTERNET}->eth0->ovpn->tun0->(nat)eth0->{INTERNET}->nag.ru Таким образом на eth0 присутствуют как пакеты openvpn так и остальной траффик идущий туда/сюда по запросам клиентов. С одной стороны была идея жестко разделить полосу 50/50 для openvpn пакетов и остальных и обрабатывать эти две очереди по очереди(round robin). Потом подумал, что sfq было бы правильнее, но видимо нужно дать больший приоритет openvpn пакетам, т.к. vpn соединений может быть 10, а остальных коннектов 100... И главный вопрос: где ограничивать скорость интерфейса? на eth или на ifb. А скорее и там и там(точнее везде, где хотим обрабатывать очередь)? Т.е. везде цеплять в root htb?(или есть что-то более оптимальное для таких случаев? может быт red? им вообще кто-то пользуется? ) ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zurz Опубликовано 10 августа, 2011 · Жалоба имхо вешать sfq на входящий из инета както бесполезно - повлиять на то, в каком порядке пакеты придут от провайдера-апстрима невозможно, и в этом случае sfq будет влиять только на порядок обработки пакетов самим роутером. а это будет заметно только если у роутера затык по CPU Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 10 августа, 2011 · Жалоба имхо вешать sfq на входящий из инета както бесполезно - повлиять на то, в каком порядке пакеты придут от провайдера-апстрима невозможно, и в этом случае sfq будет влиять только на порядок обработки пакетов самим роутером. И что с того? Задержится (а после дропнется) часть пакетов - скорость упадет, ибо клиент увидит congestion. Так собссно все ешйперы и работают. P.S. Лучше пользовать не SFQ, а ESFQ, с хешем по ип адресу источника или назначения (смотря в какую сторону шейпер). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_dx Опубликовано 10 августа, 2011 (изменено) · Жалоба а это будет заметно только если у роутера затык по CPU Всё вроде верно, но пока только не понял про затык по CPU...как одно с другим связано то? P.S. Лучше пользовать не SFQ, а ESFQ, с хешем по ип адресу источника или назначения (смотря в какую сторону шейпер). Ну так к sfq прилагается же flow hash keys dst/src(смотря в какую сторону шейпер). Полчуается в точности тоже самое, что и ESFQ(кстати deprecated вроде как). И всё-же: какой-то эффект в качестве обслуживания будет от sfq на ingress? мы говорим сейчас о voip траффике же, т.е. задержка важна и я почему-то думаю, что если роутер будет создавать "эффект параллельности", раздавая пакеты из очереди всем по порядку - будет лучше... Как оно на практике то будет? Ну и ворос с ограничением скорости интерфейсов остаётся пока для меня открытым... Изменено 10 августа, 2011 пользователем _dx Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...