Здравствуйте! Я столкнулся с непростой проблемой, которая уже начинает казаться мне неразрешимой. Я сейчас настраиваю новый шлюз для организации, в которой очень узкий интернет-канал (~2Мбит). Народу тут много, поэтому необходимо ставить шейпер, который, в частности, мог бы QoS'ом рулить приоритететами разного трафика. Сейчас на старом шлюзе вертится IPFire, но использовать его и на новом очень не хочется, т.к. есть необходимость в полноценной линукс-системе на шлюзе.

Основная проблема: если конкретно трафику скайпа не повышать в IPFire приоритет, то общаться через него становится невозможно => необходимо научить новый шлюз его опознавать.
Вопрос: как?

Я уже пристально смотрел в сторону l7, но, на сколько я понял, команда разработки перестала его поддерживать. Userspace модуль вообще не работает с новыми библиотеками libnetfilter-* (уже почти 2 года). Есть ли аналогичное решение?

• Опознание трафика, проходящего через шлюз.,anonymous, 12:56 , 30-Июл-11
  • Опознание трафика, проходящего через шлюз.,tapapax, 18:16 , 30-Июл-11
    • Опознание трафика, проходящего через шлюз.,anonymous, 18:47 , 30-Июл-11
• Опознание трафика, проходящего через шлюз.,qwek, 12:56 , 30-Июл-11
• Опознание трафика, проходящего через шлюз.,vbv, 21:39 , 31-Июл-11
  • Опознание трафика, проходящего через шлюз.,tapapax, 22:34 , 02-Авг-11
  • Опознание трафика, проходящего через шлюз.,qwek, 22:22 , 02-Сен-11
• Опознание трафика, проходящего через шлюз.,LSTemp, 05:32 , 07-Сен-11

>[оверквотинг удален]
> в частности, мог бы QoS'ом рулить приоритететами разного трафика. Сейчас на
> старом шлюзе вертится IPFire, но использовать его и на новом очень
> не хочется, т.к. есть необходимость в полноценной линукс-системе на шлюзе.
> Основная проблема: если конкретно трафику скайпа не повышать в IPFire приоритет, то
> общаться через него становится невозможно => необходимо научить новый шлюз его
> опознавать.
> Вопрос: как?
> Я уже пристально смотрел в сторону l7, но, на сколько я понял,
> команда разработки перестала его поддерживать. Userspace модуль вообще не работает с
> новыми библиотеками libnetfilter-* (уже почти 2 года). Есть ли аналогичное решение?

ППЦ люди зажрались... 2мбита - узкий канал...
LARTC есть на этом сайте. Читайте его и таких вопросов возникать не будет. Внимательно.

>[оверквотинг удален]
>> Основная проблема: если конкретно трафику скайпа не повышать в IPFire приоритет, то
>> общаться через него становится невозможно => необходимо научить новый шлюз его
>> опознавать.
>> Вопрос: как?
>> Я уже пристально смотрел в сторону l7, но, на сколько я понял,
>> команда разработки перестала его поддерживать. Userspace модуль вообще не работает с
>> новыми библиотеками libnetfilter-* (уже почти 2 года). Есть ли аналогичное решение?
> ППЦ люди зажрались... 2мбита - узкий канал...
> LARTC есть на этом сайте. Читайте его и таких вопросов возникать не
> будет. Внимательно.

Мы не зажрались. Его действительно по каким-то причинам не хватает. Повторюсь, с IPFire'ом на шлюзе через скайп возможно разговаривать только если очень сильно повысить ему приоритет над другим трафиком (в IPFire это реализовано как раз с помощью l7). LARTC я читал (не вдаваясь, правда, во все детали), но распознавать-то трафик скайпа ядро само не может.
Если же без руления приоритетами в стиле QoS... Какой пропускной способности будет достаточно скайпу на вход и выход?

>[оверквотинг удален]
>> ППЦ люди зажрались... 2мбита - узкий канал...
>> LARTC есть на этом сайте. Читайте его и таких вопросов возникать не
>> будет. Внимательно.
> Мы не зажрались. Его действительно по каким-то причинам не хватает. Повторюсь, с
> IPFire'ом на шлюзе через скайп возможно разговаривать только если очень сильно
> повысить ему приоритет над другим трафиком (в IPFire это реализовано как
> раз с помощью l7). LARTC я читал (не вдаваясь, правда, во
> все детали), но распознавать-то трафик скайпа ядро само не может.
> Если же без руления приоритетами в стиле QoS... Какой пропускной способности будет
> достаточно скайпу на вход и выход?

Вообще скайпу без видео хватит и 128 килобит. Войсовому траффику важнее задержки. Сколько человек в организации?
Всякие айпифаеры и прочие сделать-за-5-минут решения - фуфло. Продумайте самостоятельно всю ситуацию, расставьте приоритеты, и шейпите траффик с помощью tc. Относительно большинства типов траффика - хватает определения сервиса на основе портов. Относительно скайпа - поищите, где-то была сигнатура для iptables -m string, далее помечаем это соединение и отправляем в наиболее приоритетную полосу.
Посидите денек, помониторьте траффик на серваке, кто забивает, чем забивает. Продумайте все хорошо, потом один раз настройте и больше никогда не будете к этому возвращаться.
http-соединения, например, можно гнать через кеширующий прокси. NAT делать только для избранных, из избранных любителей покачать торренты резать им полосу и так далее...

Посмотрите в сторону FreeBSD и ipfw + dummynet. Ничего сложного в этой связке нет, а с вашим каналом можно удовлетворить 1000 человек без проблем, главное выделить им каждому полосу и пусть в её пределах хоть на голове ходят.

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

>[оверквотинг удален]
> в частности, мог бы 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 (в данном случае) скайп - ВСЕ!

> таким образом прийдется подстроить клиенты и на сервере пропустить настроенные порты в
> первую очередь...
> Чего-то типа такого.

Да, реализую этот способ, т.к. других вариантов у меня больше нет.
Спасибо!!

> PS: для умников
> Люди читайте вопрос который задал человек.
> Вас ни кто не спрашивал о том как организовать политику QOS.
> Вопрос был конкретный: как поймать отдельный p2p (в данном случае) скайп -
> ВСЕ!

Здесь вы не правы. Обратимся к источнику:
++++++++++
Я сейчас настраиваю новый шлюз для организации, в которой очень узкий интернет-канал (~2Мбит). Народу тут много, поэтому необходимо ставить шейпер, который, в частности, мог бы QoS'ом рулить приоритететами разного трафика.
++++++++++

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

> Здравствуйте! Я столкнулся с непростой проблемой, которая уже начинает казаться мне неразрешимой.
> Я сейчас настраиваю новый шлюз для организации, в которой очень узкий
> интернет-канал (~2Мбит). Народу тут много, поэтому необходимо ставить шейпер, который,
> в частности, мог бы QoS'ом рулить приоритететами разного трафика.

а кто твой QOS по маршруту трафика поддерживать будет?

Сейчас на
> старом шлюзе вертится IPFire, но использовать его и на новом очень
> не хочется, т.к. есть необходимость в полноценной линукс-системе на шлюзе.
> Основная проблема: если конкретно трафику скайпа не повышать в IPFire приоритет, то
> общаться через него становится невозможно => необходимо научить новый шлюз его
> опознавать.
> Вопрос: как?
> Я уже пристально смотрел в сторону l7, но, на сколько я понял,
> команда разработки перестала его поддерживать. Userspace модуль вообще не работает с
> новыми библиотеками libnetfilter-* (уже почти 2 года). Есть ли аналогичное решение?