Shaman
то же самое, только -D
iptables -I FORWARD 1 -m udp -p udp -m string --hex-string "|7FFFFFFFAB|" --algo bm --from 40 --to 44 -j REJECT --reject-with icmp-port-unreachable #добавить
iptables -D FORWARD -m udp -p udp -m string --hex-string "|7FFFFFFFAB|" --algo bm --from 40 --to 44 -j REJECT --reject-with icmp-port-unreachable #удалить

уже разобрался, там можно ещё более лёгким способом, единственное походу какието приколы с iptables, вдруг с ничего начал сбрасывает все правила и настройки при перезагрузки, даже те которые были сохранены ранее, не смотря на то что делаю sudo rc.d save iptables

+я так понял не сработало, скачка этой машиной, порядка 6-7 метров скорость закача, ~90% цп(

top
Non-standard uts for running kernel:
release 3.0-ARCH=3.0.0 gives version code 196608
Unknown HZ value! (94) Assume 100.
  8:59pm  up 16 min,  2 users,  load average: 1.18, 0.55, 0.30
101 processes: 97 sleeping, 4 running, 0 zombie, 0 stopped
CPU states: 18.3% user,  9.9% system,  0.2% nice, 71.4% idle
Mem:  2581292K av,  945088K used, 1636204K free,       0K shrd,   43228K buff
Swap:       0K av,       0K used,       0K free                  594760K cached
  PID USER     PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME COMMAND
 1450 root      20   0  2104  720   608 R       0 27.1  0.0   0:16 pptpgw
 1790 dolphin   20   0  118M  43M 13204 S       0 23.2  1.7   0:25 transmission
    3 root      20   0     0    0     0 SW      0 11.6  0.0   0:06 ksoftirqd/0
   23 root      20   0     0    0     0 SW      0 11.6  0.0   0:03 kworker/0:2
  170 root      20   0     0    0     0 RW      0  9.6  0.0   0:06 kworker/0:3
  833 root      20   0  6504 2432  1984 S       0  0.9  0.0   0:00 syslog-ng
  971 dolphin   20   0  152M  17M  3380 S       0  0.9  0.7   0:10 mpd
  980 dolphin   20   0  155M 6528  5328 S       0  0.9  0.2   0:10 pulseaudio
 1273 dolphin   20   0  417M  95M 27832 S       0  0.9  3.7   0:38 gnome-shell
 2029 dolphin   20   0  2444  968   760 R       0  0.9  0.0   0:00 top
    1 root      20   0  1896  552   480 S       0  0.0  0.0   0:00 init
    2 root      20   0     0    0     0 SW      0  0.0  0.0   0:00 kthreadd
    6 root      0K   0     0    0     0 SW      0  0.0  0.0   0:00 migration/0
    7 root      0K   0     0    0     0 SW      0  0.0  0.0   0:00 watchdog/0
    8 root       0 -20     0    0     0 SW<     0  0.0  0.0   0:00 cpuset
    9 root       0 -20     0    0     0 SW<     0  0.0  0.0   0:00 khelper
   10 root       0 -20     0    0     0 SW<     0  0.0  0.0   0:00 netns
Shaman
Это уже готовые правила. На скорость не влияют совсем. Просто торрент будет качать по tcp

замечательно, а насчёт непредвиденных проблем, как эти правила можно отменить?
Shaman
ну как я понял, не только мюторрент страдает этой болезнью. протокол utp виноват
смысл этого метода в том, что дропаются пакеты которые соответствуют сигнатуре. сигнатуры же люди там находили (на форуме).
но есть вероятность (не большая) что будут дропаться пакеты не utp.
iptables -I FORWARD 1 -m udp -p udp -m string --hex-string "|7FFFFFFFAB|" --algo bm --from 40 --to 44 -j REJECT --reject-with icmp-port-unreachable
iptables -I FORWARD 2 -m udp -p udp -m string --hex-string "|7fffffff0003|" --algo bm --from 36 --to 41 -j REJECT --reject-with icmp-port-unreachable
iptables -I FORWARD 3 -m udp -p udp -m string --hex-string "|0000000000380000|" --algo bm --from 36 --to 43 -j REJECT --reject-with icmp-port-unreachable
вот такое заклинание убило мне utp полностью. торрент качал по tcp.

премного благодарен! насколько я понимаю эта магия улучшает судьбу процессору, но как это влияет на отдачу и прием торрентов по скорости? это не маловажный вопрос в эру высокоскоростных инетов и ратио которое прямо пропорционально от него зависит)) готов попробовать Ваши письмена, но если что-то пойдет не так, то какова антимагия? насколько а понимаю это правило для иптейбелс, знаю что -D удаляет правило но а как здесь это правильно будет написать? заранее спасибо!
Shaman
насколько я помню pptp крайне прожорливая штука, шифрование + сжатие сильно грузят проц. а торрент очень щедр на пакеты. он срет кучей мелких udp пакетов (по умолчанию, протокол utp). отсюда и нагрузка. на шлюзе можно попробовать зарезать utp протокол (не реклама, форум nag.ru тема “а торрент ли”), тогда торрент-клиент перейдет на tcp, и кол-во пакетов уменьшиться (размер возрастет), нагрузка на проц должна упасть.

раз пошла такая пьянка… я ещё не уверен на 100%, но кажется версия правдива, если качает торрент всё плохо, но если что-то другое всё ок. вопрос лично к Вам, чем чревато лечение этим способом в случае закача с из этой машины и через эту машину, а самое главное как это сделать для чайников? я не гик, и с сетями не особо дружу как и с арчём, хотя не первый год +из всех сил стараюс… я прочитал почти всю статью, за что отдельное спасибо, но особо ничего не усек, люди придираются к мюторенту но им я не юзаю, у меня трансмишн и делюга, + всё как-то замудренно и как мне показалось с изобретениями велосипедов… если вам не сложно, распишите по полкам и без лишней инфы как в том форуме, и даже если это будут издержки или копипаст оттуда, думаю здесь это будет актуально и интересно почитать многим… отсутствие жалоб - не означает отсутствие симптомов
показатели top при отдаче трафика другой машине, получилось выжать около 6М, загругка цп около 65-70%:

top
Non-standard uts for running kernel:
release 3.0-ARCH=3.0.0 gives version code 196608
  2:19am  up 16 min,  2 users,  load average: 0.00, 0.02, 0.05
99 processes: 96 sleeping, 3 running, 0 zombie, 0 stopped
CPU states: 12.5% user, 42.7% system,  0.0% nice, 44.6% idle
Mem:  2581292K av,  428468K used, 2152824K free,       0K shrd,   35324K buff
Swap:       0K av,       0K used,       0K free                  169420K cached
  PID USER     PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME COMMAND
 1480 root      20   0  2104  720   608 R       0 26.7  0.0   0:37 pptpgw
   23 root      20   0     0    0     0 RW      0 16.8  0.0   0:18 kworker/0:2
    3 root      20   0     0    0     0 SW      0 11.3  0.0   0:16 ksoftirqd/0
 1542 root      20   0     0    0     0 SW      0  4.9  0.0   0:04 kworker/0:1
 1270 dolphin   20   0  406M  89M 27384 S       0  0.7  3.5   0:07 gnome-shell
  835 root      20   0  6504 2432  1984 S       0  0.3  0.0   0:00 syslog-ng
  973 root      20   0  123M  65M  9688 S       0  0.3  2.6   0:07 Xorg
 1600 dolphin   20   0  2412 1008   792 R       0  0.3  0.0   0:00 top
    1 root      20   0  1896  552   480 S       0  0.0  0.0   0:00 init
    2 root      20   0     0    0     0 SW      0  0.0  0.0   0:00 kthreadd
    6 root      0K   0     0    0     0 SW      0  0.0  0.0   0:00 migration/0
    7 root      0K   0     0    0     0 SW      0  0.0  0.0   0:00 watchdog/0
    8 root       0 -20     0    0     0 SW<     0  0.0  0.0   0:00 cpuset
    9 root       0 -20     0    0     0 SW<     0  0.0  0.0   0:00 khelper
   10 root       0 -20     0    0     0 SW<     0  0.0  0.0   0:00 netns
   11 root      20   0     0    0     0 SW      0  0.0  0.0   0:00 sync_supers
   12 root      20   0     0    0     0 SW      0  0.0  0.0   0:00 bdi-default

P.S. тысячи извинений по поводу игнора top, системный монитор по непонятным причинам действительно утаивал нагрузку процессами pptpgw и kworker/0:0(эт иногда доходит до 23%), но лично я до сих пор в неведении что с этим делать
Показатели top когда качаю я, это не самый пик скорости которую я наблюдал ренее,но… как видно из таблици я попытался нагрузить машину торентом, штук 6 одновременных закачей, скорость порядка 4-х-5-ти метров, цп в районе 90%

top
Non-standard uts for running kernel:
release 3.0-ARCH=3.0.0 gives version code 196608
  1:25am  up 2 days,  5:21,  2 users,  load average: 0.94, 0.93, 0.54
106 processes: 103 sleeping, 3 running, 0 zombie, 0 stopped
CPU states: 35.7% user, 55.0% system,  0.0% nice,  9.2% idle
Mem:  2581292K av, 1661496K used,  919796K free,       0K shrd,   48392K buff
Swap:       0K av,       0K used,       0K free                 1065296K cached
  PID USER     PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME COMMAND
31565 dolphin   20   0  159M  82M 13284 S       0 29.9  3.2   3:58 transmission
30926 root      20   0  2104  724   608 R       0 24.9  0.0   2:26 pptpgw
    3 root      20   0     0    0     0 SW      0 12.0  0.0  47:51 ksoftirqd/0
32218 root      20   0     0    0     0 SW      0  9.1  0.0   0:03 kworker/0:3
31299 root      20   0     0    0     0 SW      0  6.1  0.0   0:21 kworker/0:1
  831 root      20   0  6504 1356   912 S       0  1.5  0.0   1:47 syslog-ng
  957 root      20   0  160M  98M  6112 S       0  1.3  3.9  45:54 Xorg
 1262 dolphin   20   0  590M 240M 16476 S       0  0.9  9.5  65:48 gnome-shell
  517 root      20   0     0    0     0 SW      0  0.1  0.0   0:04 jbd2/sdb6-8
 1324 dolphin   20   0 50720 1904   952 S       0  0.1  0.0   4:09 conky
32225 dolphin   20   0  2416 1016   792 R       0  0.1  0.0   0:00 top
    1 root      20   0  1896  504   432 S       0  0.0  0.0   0:02 init
    2 root      20   0     0    0     0 SW      0  0.0  0.0   0:00 kthreadd
    6 root      0K   0     0    0     0 SW      0  0.0  0.0   0:00 migration/0
    7 root      0K   0     0    0     0 SW      0  0.0  0.0   0:00 watchdog/0
    8 root       0 -20     0    0     0 SW<     0  0.0  0.0   0:00 cpuset
    9 root       0 -20     0    0     0 SW<     0  0.0  0.0   0:00 khelper
показатели top когда качает другая машина с этой выложу чуть позже, и они то на мой взгляд более абсурдны чем эти
sleepycat
sudo sysctl -a | grep ip.forw
?

sudo sysctl -a | grep ip.forw
error: permission denied on key ‘vm.compact_memory’
error: permission denied on key ‘net.ipv4.route.flush’
net.ipv4.ip_forward = 1
error: permission denied on key ‘net.ipv6.route.flush’

я не особо разбирался с sysctl… всё плохо?) net.ipv4.ip_forward = 1 вроде бы как хорошо, иначе через меня не ходили пакеты, если память не обшибает, в остальном я пасс… если всё же плохо, то если не сложно, подскажите лечение… буду Вам очень признателен
и ещё одно, боюсь проблема более глобальна чем просто раздача интернета + цп на 100, когда я активно что-то качаю машина тоже уходит в аут, жить можно но примитивным способом… включение буфера в настройках инета помогает, но это опять же не выход, так как теряются пакеты, вар лог щимится от ошибок и скорость инета падает как минимум в двое… если бы так было и раньше - я бы и тему не создавал, но ранее такого не наблюдал ещё со времен второго гнома, передача по ssh сейчас мне кажется детским лепетом
аля скритпик которым раздаю инет (прописан в башрц):

alias inet_off='sudo iptables -t nat -D POSTROUTING -j MASQUERADE -s'
alias inet_share='sudo iptables -t nat -A POSTROUTING -j MASQUERADE -s'
alias inet_shared='sudo iptables -t nat -L'

скрипт которым подымаю инет (находится в /etc/ppp/peers), логин и сервак конечноже имеют свои, правильный значения, но так как к делу не имеет отношения заменил инфу:

name логин
remotename сервак
defaultroute
lock
noauth
#refuse-pap
#refuse-chap
refuse-mschap
#refuse-mschap2
lcp-echo-interval 10
lcp-echo-failure 10
# Compression
# Turn off compression protocols we know won't be used
#novj
#novjccomp
nobsdcomp
nodeflate
#nopcomp
#noaccomp
nomppe
#noproxyarp
#nocrtscts
persist
maxfail 0
holdoff 10
mtu 1496
pty "/usr/sbin/pptp сервак --nolaunchpppd --nobuffer"

насчет правил iptables - руководствовался только этой статьей, сделано практически один в один, но проблема появилась ранее, при дефолтовом состоянии iptables… но всеже вот ссылка на статью:

http://farmal.in/2011/07/borba-s-ddos-atakami-sredstvami-iptables-i-sysctl/

шейперов нету, мелькала идея, но вродь по слухам он не особо сейчас то и работает, поэтому не стал и замарачиваться.
Shaman
как бы больше стоит доверять показателю load average.
uptime
за три года не успел разочароваться как в системном мониторе так и в коньках+sensors, хотя вполне согласен что второй вариант малость брешет периодически… но суть не в этом, процессор с геометрической прогрессией стремится к 100% загруженности, причём за счёт трафика который отдаётся другой машине, так как процессы во время этого ведут вполне прилично, и смотря на них можно сказать что система вполне стабильна… всё в деталях изложено выше. принимаю любые логические догадки по этому поводу, без отклонений на ерунду не имеющей отношения к делу.
Shaman
а откуда вы взяли число 80-90%?
О_о ну как бы об этом свидетельствую показатели коньков и системного монитора… это был риторический вопрос?