форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Открытые системы на сервере (Квоты, ограничения, QoS / Linux)
Изначальное сообщение		[ Отслеживать ]

"Опознание трафика, проходящего через шлюз."	+/–
Сообщение от tapapax (ok) on 29-Июл-11, 15:50
Здравствуйте! Я столкнулся с непростой проблемой, которая уже начинает казаться мне неразрешимой. Я сейчас настраиваю новый шлюз для организации, в которой очень узкий интернет-канал (~2Мбит). Народу тут много, поэтому необходимо ставить шейпер, который, в частности, мог бы QoS'ом рулить приоритететами разного трафика. Сейчас на старом шлюзе вертится IPFire, но использовать его и на новом очень не хочется, т.к. есть необходимость в полноценной линукс-системе на шлюзе. Основная проблема: если конкретно трафику скайпа не повышать в IPFire приоритет, то общаться через него становится невозможно => необходимо научить новый шлюз его опознавать. Вопрос: как? Я уже пристально смотрел в сторону l7, но, на сколько я понял, команда разработки перестала его поддерживать. Userspace модуль вообще не работает с новыми библиотеками libnetfilter-* (уже почти 2 года). Есть ли аналогичное решение?
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

2. "Опознание трафика, проходящего через шлюз."	+/–
Сообщение от anonymous (??) on 30-Июл-11, 12:56
>[оверквотинг удален] > в частности, мог бы QoS'ом рулить приоритететами разного трафика. Сейчас на > старом шлюзе вертится IPFire, но использовать его и на новом очень > не хочется, т.к. есть необходимость в полноценной линукс-системе на шлюзе. > Основная проблема: если конкретно трафику скайпа не повышать в IPFire приоритет, то > общаться через него становится невозможно => необходимо научить новый шлюз его > опознавать. > Вопрос: как? > Я уже пристально смотрел в сторону l7, но, на сколько я понял, > команда разработки перестала его поддерживать. Userspace модуль вообще не работает с > новыми библиотеками libnetfilter-* (уже почти 2 года). Есть ли аналогичное решение? ППЦ люди зажрались... 2мбита - узкий канал... LARTC есть на этом сайте. Читайте его и таких вопросов возникать не будет. Внимательно.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Опознание трафика, проходящего через шлюз."	+/–
	Сообщение от tapapax (ok) on 30-Июл-11, 18:16
	>[оверквотинг удален] >> Основная проблема: если конкретно трафику скайпа не повышать в IPFire приоритет, то >> общаться через него становится невозможно => необходимо научить новый шлюз его >> опознавать. >> Вопрос: как? >> Я уже пристально смотрел в сторону l7, но, на сколько я понял, >> команда разработки перестала его поддерживать. Userspace модуль вообще не работает с >> новыми библиотеками libnetfilter-* (уже почти 2 года). Есть ли аналогичное решение? > ППЦ люди зажрались... 2мбита - узкий канал... > LARTC есть на этом сайте. Читайте его и таких вопросов возникать не > будет. Внимательно. Мы не зажрались. Его действительно по каким-то причинам не хватает. Повторюсь, с IPFire'ом на шлюзе через скайп возможно разговаривать только если очень сильно повысить ему приоритет над другим трафиком (в IPFire это реализовано как раз с помощью l7). LARTC я читал (не вдаваясь, правда, во все детали), но распознавать-то трафик скайпа ядро само не может. Если же без руления приоритетами в стиле QoS... Какой пропускной способности будет достаточно скайпу на вход и выход?
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	5. "Опознание трафика, проходящего через шлюз."	+/–
	Сообщение от anonymous (??) on 30-Июл-11, 18:47
	>[оверквотинг удален] >> ППЦ люди зажрались... 2мбита - узкий канал... >> LARTC есть на этом сайте. Читайте его и таких вопросов возникать не >> будет. Внимательно. > Мы не зажрались. Его действительно по каким-то причинам не хватает. Повторюсь, с > IPFire'ом на шлюзе через скайп возможно разговаривать только если очень сильно > повысить ему приоритет над другим трафиком (в IPFire это реализовано как > раз с помощью l7). LARTC я читал (не вдаваясь, правда, во > все детали), но распознавать-то трафик скайпа ядро само не может. > Если же без руления приоритетами в стиле QoS... Какой пропускной способности будет > достаточно скайпу на вход и выход? Вообще скайпу без видео хватит и 128 килобит. Войсовому траффику важнее задержки. Сколько человек в организации? Всякие айпифаеры и прочие сделать-за-5-минут решения - фуфло. Продумайте самостоятельно всю ситуацию, расставьте приоритеты, и шейпите траффик с помощью tc. Относительно большинства типов траффика - хватает определения сервиса на основе портов. Относительно скайпа - поищите, где-то была сигнатура для iptables -m string, далее помечаем это соединение и отправляем в наиболее приоритетную полосу. Посидите денек, помониторьте траффик на серваке, кто забивает, чем забивает. Продумайте все хорошо, потом один раз настройте и больше никогда не будете к этому возвращаться. http-соединения, например, можно гнать через кеширующий прокси. NAT делать только для избранных, из избранных любителей покачать торренты резать им полосу и так далее...
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

3. "Опознание трафика, проходящего через шлюз."	+/–
Сообщение от qwek (ok) on 30-Июл-11, 12:56
Посмотрите в сторону FreeBSD и ipfw + dummynet. Ничего сложного в этой связке нет, а с вашим каналом можно удовлетворить 1000 человек без проблем, главное выделить им каждому полосу и пусть в её пределах хоть на голове ходят. Для VIP персон можно скорость вообще не ограничивать, но и понимание с их стороны должно присутствовать при этом. Если нет понимания - в стойло как и остальных.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Опознание трафика, проходящего через шлюз."	+1 +/–
Сообщение от vbv (ok) on 31-Июл-11, 21:39
>[оверквотинг удален] > в частности, мог бы QoS'ом рулить приоритететами разного трафика. Сейчас на > старом шлюзе вертится IPFire, но использовать его и на новом очень > не хочется, т.к. есть необходимость в полноценной линукс-системе на шлюзе. > Основная проблема: если конкретно трафику скайпа не повышать в IPFire приоритет, то > общаться через него становится невозможно => необходимо научить новый шлюз его > опознавать. > Вопрос: как? > Я уже пристально смотрел в сторону l7, но, на сколько я понял, > команда разработки перестала его поддерживать. Userspace модуль вообще не работает с > новыми библиотеками libnetfilter-* (уже почти 2 года). Есть ли аналогичное решение? Сталкивался с подобной проблемой, только в направлении кодированного torrent. Вменяемое решение так и не было найдено. l7 - пробовал но только не помогло. Относительно скайпа - там помоему все немного проще, а именно порты известны. Не в моем стиле кидатся ссылками, но обнаружена такая инфа: http://www.skypeclub.ru/skype_faq.htm#138 ------------ Цитата: К вопросу о лучшем качестве голоса также можно добавить об открытии входящего TCP и/или UDP трафика на отдельный порт, который вы можете увидеть в настройках Skype. Этот порт выбирается случайным образом при установке программы Skype. В случае файерволла его можно легко настроить. В некоторых роутерах, вы не можете сконфигурировать входящие UDP для всех (но вы все таки можете настроить переадресацию входящих TCP портов, что и надо сделать). ------------ Конец цитаты ------------- таким образом прийдется подстроить клиенты и на сервере пропустить настроенные порты в первую очередь... Чего-то типа такого. PS: для умников Люди читайте вопрос который задал человек. Вас ни кто не спрашивал о том как организовать политику QOS. Вопрос был конкретный: как поймать отдельный p2p (в данном случае) скайп - ВСЕ!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Опознание трафика, проходящего через шлюз."	+/–
	Сообщение от tapapax (ok) on 02-Авг-11, 22:34
	> таким образом прийдется подстроить клиенты и на сервере пропустить настроенные порты в > первую очередь... > Чего-то типа такого. Да, реализую этот способ, т.к. других вариантов у меня больше нет. Спасибо!!
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	8. "Опознание трафика, проходящего через шлюз."	+/–
	Сообщение от qwek (ok) on 02-Сен-11, 22:22
	> PS: для умников > Люди читайте вопрос который задал человек. > Вас ни кто не спрашивал о том как организовать политику QOS. > Вопрос был конкретный: как поймать отдельный p2p (в данном случае) скайп - > ВСЕ! Здесь вы не правы. Обратимся к источнику: ++++++++++ Я сейчас настраиваю новый шлюз для организации, в которой очень узкий интернет-канал (~2Мбит). Народу тут много, поэтому необходимо ставить шейпер, который, в частности, мог бы QoS'ом рулить приоритететами разного трафика. ++++++++++ товарищу был предложен вариант жестко поделить трафик между абонентами, вместо того, чтобы настраивать приоритезацию в общем канале. На мой взгляд такое решение куда более рационально, чем пытаться отловить неуловимое, а затем мучительно направлять его в пайпы.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

9. "Опознание трафика, проходящего через шлюз."	+/–
Сообщение от LSTemp (ok) on 07-Сен-11, 05:32
> Здравствуйте! Я столкнулся с непростой проблемой, которая уже начинает казаться мне неразрешимой. > Я сейчас настраиваю новый шлюз для организации, в которой очень узкий > интернет-канал (~2Мбит). Народу тут много, поэтому необходимо ставить шейпер, который, > в частности, мог бы QoS'ом рулить приоритететами разного трафика. а кто твой QOS по маршруту трафика поддерживать будет? Сейчас на > старом шлюзе вертится IPFire, но использовать его и на новом очень > не хочется, т.к. есть необходимость в полноценной линукс-системе на шлюзе. > Основная проблема: если конкретно трафику скайпа не повышать в IPFire приоритет, то > общаться через него становится невозможно => необходимо научить новый шлюз его > опознавать. > Вопрос: как? > Я уже пристально смотрел в сторону l7, но, на сколько я понял, > команда разработки перестала его поддерживать. Userspace модуль вообще не работает с > новыми библиотеками libnetfilter-* (уже почти 2 года). Есть ли аналогичное решение?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема