[XeonVs]

если я использую на сервере pf, то как мне это прикрутить?

Пересобрать модуль(/sys/modules/ipfw) ipfw c прописанным в /etc/make.conf CFLAGS+= -DIPFIREWALL_DEFAULT_TO_ACCEPT

и потом уже штатно:

kldload ipfw

kldload ng_ipfw

kldload ....

 

порядок работы будет зависеть от порядка загрузки модулей фаерволов.

 

 

[Zohan]

если я использую на сервере pf, то как мне это прикрутить?

Пересобрать модуль(/sys/modules/ipfw) ipfw c прописанным в /etc/make.conf CFLAGS+= -DIPFIREWALL_DEFAULT_TO_ACCEPT

и потом уже штатно:

kldload ipfw

kldload ng_ipfw

kldload ....

 

порядок работы будет зависеть от порядка загрузки модулей фаерволов.

можно в /usr/src/sys/modules/ipfw/Makefile?

 

потом

make && make install?

[ghost]

Почитав кое-что из этой ветки задался вопросом - как отслеживать подобные тенденции вцелом?

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

(bps/8)/pps, и получил... что средний размер пакета на входе инетовского канала как был примерно 700 байт - так и остался, явного треда нет (по крайней мере на моих аплинках), есть некоторое уменьшение исходящих пакетов с 250 до 225 байт, с чем связяно - не знаю.

 

это конечно охоже на "среднюю температуру по больнице", но ключевые тенденции должны при таком подходе проявляться, особенно при резких изменениях.

[XeonVs]

если я использую на сервере pf, то как мне это прикрутить?

Пересобрать модуль(/sys/modules/ipfw) ipfw c прописанным в /etc/make.conf CFLAGS+= -DIPFIREWALL_DEFAULT_TO_ACCEPT

и потом уже штатно:

kldload ipfw

kldload ng_ipfw

kldload ....

 

порядок работы будет зависеть от порядка загрузки модулей фаерволов.

можно в /usr/src/sys/modules/ipfw/Makefile?

 

потом

make && make install?

можно и так, но при cvsup потрётся.

остальное верно.

 

[Zohan]

если я использую на сервере pf, то как мне это прикрутить?

Пересобрать модуль(/sys/modules/ipfw) ipfw c прописанным в /etc/make.conf CFLAGS+= -DIPFIREWALL_DEFAULT_TO_ACCEPT

и потом уже штатно:

kldload ipfw

kldload ng_ipfw

kldload ....

 

порядок работы будет зависеть от порядка загрузки модулей фаерволов.

можно в /usr/src/sys/modules/ipfw/Makefile?

 

потом

make && make install?

можно и так, но при cvsup потрётся.

остальное верно.

 

Хм, такой фильтр не работает

Работает такой:

 

/usr/sbin/ngctl -f- <<-SEQ
        mkpeer ipfw: bpf 61 ipfw_hook61
        name ipfw:61 bpf_utp_filter
        mkpeer bpf_utp_filter: tag matched tag_utp
        name bpf_utp_filter:matched tag_utp_tagger
SEQ

ngctl msg bpf_utp_filter: setprogram { thisHook=\"ipfw_hook61\" ifNotMatch=\"ipfw_hook61\" ifMatch=\"matched\" bpf_prog_len=12 bpf_prog=[ { code=48 jt=0 jf=0 k=0 } { code=84 jt=0 jf=0 k=240 } { code=21 jt=0 jf=8 k=64 } { code=48 jt=0 jf=0 k=9 } { code=21 jt=0 jf=6 k=17 } { code=40 jt=0 jf=0 k=6 } { code=69 jt=4 jf=0 k=8191 } { code=177 jt=0 jf=0 k=0 } { code=64 jt=0 jf=0 k=20 } { code=21 jt=0 jf=1 k=2147483647 } { code=6 jt=0 jf=0 k=65535 } { code=6 jt=0 jf=0 k=0 } ] }
ngctl msg bpf_utp_filter: setprogram { thisHook=\"matched\" ifMatch=\"ipfw_hook61\" bpf_prog_len=1 bpf_prog=[ { code=6 jt=0 jf=0 k=96 } ] }
ngctl msg tag_utp_tagger: sethookin { thisHook=\"tag_utp\" ifNotMatch=\"tag_utp\" }
ngctl msg tag_utp_tagger: sethookout { thisHook=\"tag_utp\" tag_cookie=1148380143 tag_id=61 }


ipfw add netgraph 61 udp from any to any iplen 0-61
ipfw add deny udp from any to any tagged 0-61

 

и обязательно: sysctl net.inet.ip.fw.one_pass=0

 

[emp]

Кто-нить уже начал?

Я не в курсе. Вообще, во фре уже давно имеется отлтчный встроеный механизм защиты от ICMP флуда (настраивается через sysctl net.inet.icmp.icmplim), поэтому рискну предположить, что такую фичу совершенно не сложно нарисовать на уровне ядра применительно, например, к всему ip либо отдельно tcp/icmp/udp и т.д траффику не прибегая к будующим возможностям IPFW. Хотя такой способ, несмотря на скорость работы значительно уступает настраиваемым правилам по гибкости.

net.inet.icmp.icmplim не влияет на транзитный трафик

 

[thefree]

_http://lists.freebsd.org/pipermail/freebsd-ipfw/2003-April/000074.html

[Taras]

Почитав кое-что из этой ветки задался вопросом - как отслеживать подобные тенденции вцелом?

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

(bps/8)/pps, и получил... что средний размер пакета на входе инетовского канала как был примерно 700 байт - так и остался, явного треда нет (по крайней мере на моих аплинках), есть некоторое уменьшение исходящих пакетов с 250 до 225 байт, с чем связяно - не знаю.

 

это конечно охоже на "среднюю температуру по больнице", но ключевые тенденции должны при таком подходе проявляться, особенно при резких изменениях.

А тут как раз заметно введение фильтации: и pps снизился и bpp вырос, при возросшем! трафике. А то что изменения произошли плавно объясняется тем, что включение фильтра не рубит уже качающиеся торренты.

Изменено 12 марта, 2010 пользователем Taras

[XeonVs]

А тут как раз заметно введение фильтации: и pps снизился и bpp вырос, при возросшем! трафике.

а чем с циски снимали bpp? или это уже по готовому netflow?

[Taras]

А тут как раз заметно введение фильтации: и pps снизился и bpp вырос, при возросшем! трафике.

а чем с циски снимали bpp? или это уже по готовому netflow?

bps/pps

[valeps]

Народ у меня cisco 7507 бордером, можно что нибуть для нее посоветовать, как зарезать этот долбаный uTP?????

Изменено 16 марта, 2010 пользователем valeps

[woody]

Чтоб, в конце-то концов, хомячковый роутер перестал виснуть от pps.

До тех пор, пока хомяк не рубанет uTP у себя - его мыльница будет вешаться, ведь траф рубится на коммутаторах/серверах. Кстати,возник резонный вопрос: а что вообще происходит с uTorrent, когда он понимает, что через uTP установить связь не получается? Как долго он продолжает бомбежку пакетами, затыкается ли? Если затыкается, надолго ли?

 

Возможность проверить есть, но никак не дойдут руки :) Может кто ставил эксперименты?

воистину ваша правда. bt.transp.disposition=5 и жизнь вернулась

[MaDDoG]

вчера проверил

 

class-map type access-control match-any Torrent

match start l3-start offset 40 size 5 regex "\x7F\xFF\xFF\xFF\xAB"

 

policy-map type access-control Torrent

class Torrent

drop

 

interface GigabitEthernet0/0

service-policy type access-control input Torrent

помогло

[DrakoN]

Зарезал на сервере доступа:

iptables -A FORWARD -p udp -m length --length 61 -m string --hex-string "|7F FF FF FF|" --algo kmp --from 40 --to 44 -j DROP

В результате загрузка CPU на бордере в пике уменьшилась с 56% до 36% при том же bandwidth, и сможем ввести новые тарифные планы без боязни потерять в качестве или количестве обслуживаемых клиентов.

 

Посмотрел заодно, откуда идёт uTP-трафик: корбилайн не режет, сибирь не режет, казахстан и прибалтика тоже.

[Дегтярев Илья]

корбилайн не режет, сибирь не режет

Крупняк фигней не страдает.

 

[Nic]

Дегтярев Илья, крупняк просто тормозит, да и не в курсе скорее всего...

[Pretender]

Зарезал на сервере доступа:

iptables -A FORWARD -p udp -m length --length 61 -m string --hex-string "|7F FF FF FF|" --algo kmp --from 40 --to 44 -j DROP

В результате загрузка CPU на бордере в пике уменьшилась с 56% до 36% при том же bandwidth, и сможем ввести новые тарифные планы без боязни потерять в качестве или количестве обслуживаемых клиентов.

 

Посмотрел заодно, откуда идёт uTP-трафик: корбилайн не режет, сибирь не режет, казахстан и прибалтика тоже.

может

--algo kmp --from 40 --to _43_

коль правило порезали?

Изменено 18 марта, 2010 пользователем Pretender

[DpakoH]

может

--algo kmp --from 40 --to _43_

коль правило порезали?

Да хоть --to 41, это указывается промежуток начала подстроки.

Изменено 18 марта, 2010 пользователем DpakoH

[wsimons]

Хм, такой фильтр не работает

Работает такой:

 

/usr/sbin/ngctl -f- <<-SEQ
        mkpeer ipfw: bpf 61 ipfw_hook61
        name ipfw:61 bpf_utp_filter
        mkpeer bpf_utp_filter: tag matched tag_utp
        name bpf_utp_filter:matched tag_utp_tagger
SEQ

ngctl msg bpf_utp_filter: setprogram { thisHook=\"ipfw_hook61\" ifNotMatch=\"ipfw_hook61\" ifMatch=\"matched\" bpf_prog_len=12 bpf_prog=[ { code=48 jt=0 jf=0 k=0 } { code=84 jt=0 jf=0 k=240 } { code=21 jt=0 jf=8 k=64 } { code=48 jt=0 jf=0 k=9 } { code=21 jt=0 jf=6 k=17 } { code=40 jt=0 jf=0 k=6 } { code=69 jt=4 jf=0 k=8191 } { code=177 jt=0 jf=0 k=0 } { code=64 jt=0 jf=0 k=20 } { code=21 jt=0 jf=1 k=2147483647 } { code=6 jt=0 jf=0 k=65535 } { code=6 jt=0 jf=0 k=0 } ] }
ngctl msg bpf_utp_filter: setprogram { thisHook=\"matched\" ifMatch=\"ipfw_hook61\" bpf_prog_len=1 bpf_prog=[ { code=6 jt=0 jf=0 k=96 } ] }
ngctl msg tag_utp_tagger: sethookin { thisHook=\"tag_utp\" ifNotMatch=\"tag_utp\" }
ngctl msg tag_utp_tagger: sethookout { thisHook=\"tag_utp\" tag_cookie=1148380143 tag_id=61 }


ipfw add netgraph 61 udp from any to any iplen 0-61
ipfw add deny udp from any to any tagged 0-61

 

и обязательно: sysctl net.inet.ip.fw.one_pass=0

А как стату с него снять?

Изменено 18 марта, 2010 пользователем wsimons

[wsimons]

И еще вопросик, как вообще выявить тех самых клиентов, с активно работающим uTP? (на FreeBSD шлюзе).

[XeonVs]

И еще вопросик, как вообще выявить тех самых клиентов, с активно работающим uTP? (на FreeBSD шлюзе).

tcpdump -Xni vlan0 "ip[40:4]=0x7FFFFFFF and ip[44:1]=0xAB"

 

статистика снимается примерно так: ngctl msg bpf_utp_filter: getstats \"matched\"

Изменено 18 марта, 2010 пользователем XeonVs

[wsimons]

Спасибо.

[Mallorn]

Зарезал на сервере доступа:

iptables -A FORWARD -p udp -m length --length 61 -m string --hex-string "|7F FF FF FF|" --algo kmp --from 40 --to 44 -j DROP

В результате загрузка CPU на бордере в пике уменьшилась с 56% до 36% при том же bandwidth, и сможем ввести новые тарифные планы без боязни потерять в качестве или количестве обслуживаемых клиентов.

 

Посмотрел заодно, откуда идёт uTP-трафик: корбилайн не режет, сибирь не режет, казахстан и прибалтика тоже.

Сибирь и Казахстан не режут по причине более низких kbps на абонента и, как следствие, меньшего числа качальщиков.

Сегодня проверил на своем шлюзе - порядка 10-50 pps с харакетерным "7ffffffab", хотя это не час пик был.

Добавил правило "по рецепту", дропы пакетов пошли. Через сутки покажу результаты.

 

PS.Кстати, есть подозрение, что линуховый шейпер tc пропускает мелкие пакеты, не видя их вовсе.

 

Изменено 23 марта, 2010 пользователем Mallorn

[A1z]

ещё в начале месяца, включая в торренте bt.transp_disposition в значение 15(оно по умолчанию, сам выставляю в 5) можно было наблюдать десяток, на сотню качальщиков, с буковками uTP. сейчас-же их совсем мало.

 

PS.Кстати, есть подозрение, что линуховый шейпер tc пропускает мелкие пакеты, не видя их вовсе.

можно подробнее?

[YuryD]

И еще вопросик, как вообще выявить тех самых клиентов, с активно работающим uTP? (на FreeBSD шлюзе).

tcpdump -Xni vlan0 "ip[40:4]=0x7FFFFFFF and ip[44:1]=0xAB"

 

статистика снимается примерно так: ngctl msg bpf_utp_filter: getstats \"matched\"

Включил, режется примерно 10% от udp iplen 0-61 про приведенным сигнатурам

65200 1978856 104679041 netgraph 61 udp from any to any iplen 0-61

65300 264668 16144748 deny udp from any to any tagged 0-61