[_dx]

Расклад:

Около 100 клиентов подключены к VPN(openvpn) серверу(Debian) и роутятся(+NAT) через него во внешний мир.

Гоняют они в основном VOIP траффик(skype).

Разумеется, не между собой, а во внешний мир и обратно.

 

Задача:

Максимально эффективно и поровну распределить имеющуюся полосу(100мбит) Ограничение скорости реализовано на клиентском роутере(в штатном режиме).

Сервер, средствами openvpn, ограничивает клиенту download в случае если клиент будет взломан(в штатном режиме в это ограничение клиент не упирается никгда).

Т.е. ограничение скорости средствами tc вроде не нужно. Только fair queueing.

 

Первая мысль:

Исходящий траффик со всех tun интерфейсов сервера зарулить в IFB, а на него навесить SFQ. По айпишникам клиентов раскидывать по классам...

На сколько это оптимально/правильно?

Как быть со входящим траффиком? Хотелось бы раскидывать входящие пакеты так-же равномерно всем клиентам, а не как Бог даст.. VOIP же всё-таки.

Но там NAT всё портит и у меня нет пока хорошей идеи как сделать SFQ на входящий траффик.

 

Посоветуйте что-нибудь плиз.

[m0xf]

При наличии nat редирект на ifb нужно делать с внутренних интерфейсов (в данном случае tun), тогда можно фильтровать по серым ip. Входящий и исходящий трафик лучше перебросить на разные ifb. Дальше на ifb можно нацепить sfq или drr совместно с flow hash классификатором. Это для исходящего трафика, для входящего (из интернета), чтобы не образовывался затык на интерфейсе нужно ещё подрезать полосу например с помощью htb.

[_dx]

Аа, ну да, что же это я не подумал, что на другой ifb можно входящие пакеты тех-же tun'ов перебрасывать.

В моём случае что лучше выбрать sfq или drr?

С маркировка пакетов средствами iptables уже имел дело, но мне кажется это медленно..хотя на LORе сказали, что нет.

В общем стоит заморчаиваться с u32 или нет?

[_dx]

Уже понял, что предыдущие вопросы был глупыми )

Снова пересмотрел lartc..ничего не нашел про flow hash классификаторы.. гугление тоже пока не дало результатов..

Опыта особого нет пока.. может быть кто на пальцах объяснит что к чему и зачем нужен flow hash к sfq и в чём тут соль?

[_dx]

я кажется запутался что есть 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?

[_dx]

что ж такое, а. как только вопрос задам - сразу ответ нахожу.

дошло в общем.

когда мы задаём tc filter add dev tun0 parent ffff: .. мы уже имеем дело с ingress tun0.

а дальше мы говорим action mirred egress redirect dev ifb0 т.е. пакеты из ingress tun0, которые подошли под критерии фильтра редиректить в egress ifb0.

 

уж извините, что тему всё время апаю... разбираюсь в общем как-бэ... ))

Изменено 6 августа, 2011 пользователем _dx

[_dx]

На сервере будет одна сетевуха и я хотел прибить openvpn демоны к 127.0.0.1 а с eth0 форвардить порт для распределения нагрузки по разным демонам(потому что openvpn однопоточный и тормозной).

Но DNAT не хочет перекидывать пакеты на 127.0.0.1

 

Тупо фильтровать на INPUTe тоже получается как-то не весело ибо как отличить пакеты, пробравшиеся прямо с eth0 на конкретный порт и перекинутые по DNAT?

Получается маркировать надо, а потом по меткам разбирать.. ерунда всё это... лишние правила ещё и в достаточно нагруженной таблице filter...не оптимально совсем..

 

Может какой виртуальный интерфейс поднять тогда? но тоже как-то слишком жирно выходит..

Что в таких случаях делают? Куда забиндить openvpn чтобы к нему доступа не было без форвардинга?

Изменено 7 августа, 2011 пользователем _dx

[_dx]

Разобрался практичеси со всеми интересующими вопросами..

Сейчас уже работает "объединение" 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? им вообще кто-то пользуется? ) )

[zurz]

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

[NiTr0]

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

И что с того? Задержится (а после дропнется) часть пакетов - скорость упадет, ибо клиент увидит congestion. Так собссно все ешйперы и работают.

 

P.S. Лучше пользовать не SFQ, а ESFQ, с хешем по ип адресу источника или назначения (смотря в какую сторону шейпер).

[_dx]

а это будет заметно только если у роутера затык по CPU

Всё вроде верно, но пока только не понял про затык по CPU...как одно с другим связано то?

P.S. Лучше пользовать не SFQ, а ESFQ, с хешем по ип адресу источника или назначения (смотря в какую сторону шейпер).

Ну так к sfq прилагается же flow hash keys dst/src(смотря в какую сторону шейпер). Полчуается в точности тоже самое, что и ESFQ(кстати deprecated вроде как).

 

И всё-же: какой-то эффект в качестве обслуживания будет от sfq на ingress? мы говорим сейчас о voip траффике же, т.е. задержка важна и я почему-то думаю, что если роутер будет создавать "эффект параллельности", раздавая пакеты из очереди всем по порядку - будет лучше...

Как оно на практике то будет?

Ну и ворос с ограничением скорости интерфейсов остаётся пока для меня открытым...

Изменено 10 августа, 2011 пользователем _dx