Изпечатай

[aviditko]

Здравейте, имам едина линикс машина за сървър който да разпределя нета на няколко човека но имам проблем с ограничението на конекциите. Ще ви покажа какво имам и ако може някой да ми помогне да го оправя ще съм му много благодарен.

   UW PICO™ 4.7                         File: /etc/rc.d/rc.connlimit


#!/bin/sh
#/usr/sbin/iptables -F FORWARD
#/usr/sbin/iptables -A FORWARD -p tcp -s 10.10.1.2 --syn -m connlimit --connlimit-above 20 -j REJECT
#--reject-with tcp-reset
/usr/sbin/iptables -A FORWARD -p tcp -s 10.10.1.4 --syn -m connlimit --connlimit-above 20 -j REJECT --reject-w$
/usr/sbin/iptables -A FORWARD -p tcp -s 10.10.1.5 --syn -m connlimit --connlimit-above 20 -j REJECT --reject-w$
#/usr/sbin/iptables -A FORWARD -p tcp -s 10.10.1.7 --syn -m connlimit --connlimit-above 20 -j REJECT
#--reject-with tcp-reset

Това е с което разполагам но то върши работа само за tcp а не ми помага за udp ... което ми задръства модема и ми спира почти нета.
   Та молбата ми е може ли някой да ми помогне с това да мога да ограничавам tcp i udp конекции. Аз съм със swackware 10.2 и машинката ми е доста слаба и като станат доста конекциите едвам влизам и с putty.

[VladSun]

Може би решението е И да ползваш някакъв трафик шейпър - примерно htb.init (потърси из google). Поне от това, което съм виждал по форумите наистина ти трябва ограничение на конекциите за да може ADSL-а да работи както трябва. Шейпъра го нагласи на 90% от максимум капацитета на канала.

[aviditko]

ако може да ограничава и скороста едновременно нема да е зле

[aviditko]

другия проблем при мен е е съм с 4 интерфеиса 2 модема като сега ще слагам втория единия за www другия за останалото 1 интерфейс който ползвам за фрее по ЛАН от друг доставчики 1 за моя ЛАН ... такова нещо из форумите не видях. Повечето са само с 2 интерфейса '>

[gat3way]

Няма такова нещо като udp или icmp конекции, тези протоколи сами по себе си не предвиждат установяването на връзка.

Твърде вероятно шейпването на трафик ще оправи нещата, но ще трябва да сложиш и правила за INGRES шейпинг.

[aviditko]

да но Skype ползва udp връзки а всички в мрежата ползват skype и се floodи модема с повече от 60 конекции едвам отварям страници без значение от скороста на теглене в момента или че конекциите са udp ... няма да споменавам тракери защото ако някой пусне тракер си отварям 1 час пощата ... а за icmp вчера единия от мрежата имаше някакъв вирус който ъплоудваше с макс скорост и не можех да го спра ... '>

[BRADATA]

Ползвам htb.init от около 3 години и досега не съм имал проблем с вируси, торенти, скайпове и други такива простотии. По-точно имах проблем с ъплоуда докато не сложих шейп и на изходящия канал. Интернета е през АДСЛ на БТК.

Поздрави

[aviditko]

Цитат

Ползвам htb.init от около 3 години и досега не съм имал проблем с вируси, торенти, скайпове и други такива простотии. По-точно имах проблем с ъплоуда докато не сложих шейп и на изходящия канал. Интернета е през АДСЛ на БТК.

аз съм на МНЕТ то е с модеми като БТК но имам 2 модема като единия трябва да е за 80-ти порт а другия за останалото потребление и един ЛАН доставчик от който се ползва само ДЦ++ а не съм работил досега изобщо със шейпъри затова пиша във форума за начинаещи ... машината беше готова обаче станахме повече хора и си пречим.
Ако някой има желание да се занимава с мен дори мога пасс да му дам да ми помогне с конфигурирането защото се спуках да чета за htb.init а още не мога да си го сложа

[gat3way]

Цитат

да но Skype ползва udp връзки а всички в мрежата ползват skype и се floodи модема с повече от 60 конекции едвам отварям страници без значение от скороста на теглене в момента или че конекциите са udp ... няма да споменавам тракери защото ако някой пусне тракер си отварям 1 час пощата ... а за icmp вчера единия от мрежата имаше някакъв вирус който ъплоудваше с макс скорост и не можех да го спра ...

Сега не искам да се заяждам, но няма такова нещо като "udp връзки". Има протоколи които надграждат UDP добавяйки му някаква степен на TCP-подобна функционалност (такъв е RUDP), които ужким са измисляни за стрийминг приложения с ужким  контролирано от потребителя качество върху бавни връзки алабала...но не знам да са влезнали в масова употреба. RDP използван за quicktime стриймване главно не е базиран върху UDP а върху IP.

Много  надълго ще стане ако тръгна да обяснявам каква е разликата между TCP и UDP, въпреки всичко това би трябвало да се знае от всеки човек, който претендира че се занимава с мрежови глупости.

Да, скайп и битторънт използват и двата протокола. UDP поради характера си има една много досадна характеристика - тъй като не се установява връзка, не можеш да върнеш един пакет с RST флаг и да видиш сметката на целия по-нататъшен трафик (това което прави netfilter кода в ядрото  като му набиеш лимит на TCP конекциите и ги превишиш).

От друга страна, UDP трафика си тече и отсрещната машина принципно няма идея дали получателя го получава, колко от него получава и с каква скорост смогва да обработи пакетите - неща които в TCP са решени чрез механизми като windows и sequence numbers. Поради тази причина  съвсем лесно се стига до твоят случай, когато по-голям udp трафик запълва цялата линия. От друга страна няма механизъм по който ти да кажеш на изпращащите хостове "спри, не искам да ми пращаш повече" или "намали скоростта на изпращане, не мога да ти смогна!"

Откъдето идва един неприятен момент - ingres шейпинг-а помага доста, стига трафика да е tcp, но при udp трафик и това не е гаранция. И все пак, шейпвайки го доволно добре постигаш един "психологически" момент (хаха) - когато един твой клиент види че разговорът му върви насечено, той ще спре да се опитва да говори и ще затвори. Това в кръга на шегата де '>

Битторънт протоколът съвсем спокойно може да си работи единствено по TCP, затова най-добре блокирай всичкия входящ/изходящ udp трафик на неговите портове (6880-7000 / udp). Както вече споменах, TCP много по-лесно се подава на контролиране.

Що се отнася до ICMP, с него проблемът е сходен. Ако някой от клиентите ти прихване лош вирус и тръгне да задръства линията с icmp пакети, лесно ще го орежеш с HTB/CBQ. Ако някой отвън реши да те задръсти обаче, дори ingres шейпинг-а няма да ти помогне особено - пакетите ще пристигат при теб, дали ще им обръщаш внимание или не няма значение тъй като няма механизъм по който да кажеш на изпращащият хост да спре или поне да намали скоростта на изпращане.

[aviditko]

Благодаря за изчерпателният отговор но в интерес на истината никъде не съм казвал че разбирам много от мрежова администрация '> аз само виждам фактите

10.10.1.2,15363                    80-195-253-145.cable.ubr03.d,24478 udp           60
10.10.1.2,15363                    ip-62-241-79-214.evc.net,4127      udp           59
ip-62-241-79-214.evc.net,4127      10.10.1.2,15363                    udp           45
80-195-253-145.cable.ubr03.d,24478 10.10.1.2,15363                    udp           45

аз виждам само това и като станат доста такива модема сгъва '> как да ги огранича е въпроса ... ако можеш някой готов скрипт да ми дадеш или нещо подобно само не ми казваи моляте да чета отнякъде на английски че четох четох и накрая нищо съществено не направих

[gat3way]

Значи ако условно наречем UDP трафика от даден хост/порт към някой порт на клиентска машина - *конекция*

*Не можеш да ограничиш броя на *конекциите*, за съжаление

*Можеш да ограничиш скоростта на трафика от *конекции* установени от твои клиенти към външни хостове (voip трафика носещ гласа на 8твоите клиенти)

* Можеш да ограничиш скоростта с която минава voip трафика  от рутера ти до твоите клиенти, но не и скоростта на същия трафик идващ от модема към рутера ти . (т.е voip трафика представляващ гласа на събеседника на клиентите ти, в пътя и от твоят рутер до конкретния твой клиент)

* С ingress шейпинг правиш горе долу същото, малко по-грубо, само че там ограничаваш скоростта малко преди това,т.е, скоростта с която целият трафик минава между момента в който влиза от входящия интерфейс до момента в който  бъде минат през рутинг и нат алгоритмите , след което важат ограниченията, които налагаш от горния параграф (бахмалоумното обяснение, съжалявам, но ми е малко трудно да го обясня без да начертая глупостите)

Така стоят нещата, грубо казано не можеш да контролираш това което влиза в мрежата ти от интернет. Можеш единствено да ограничаваш *надеждно* изходящият трафик. Понеже няма как да ти знам изискванията и ип адресите на клиентите въобще няма как да ти приготвя скрипта дето ще ти свърши работа. И все пак, прочети linux advanced routing & traffic control, http://www.lartc.org

Защо можеш да ограничаваш по-ефективно TCP трафик отколкото UDP такъв: все пак при TCP за всеки изпратен пакет се изискват потвърждения че е получен под формата на "потвърждаващ" TCP пакет. Колкото по-бавно се връщат тези потвърждения, толкова по-бавно ще бъде изпратен следващият пакет информация...докато при UDP никой не му дреме потвърждава ли се всеки изпратен пакет...и така

[VladSun]

Цитат (gat3way @ Сеп. 14 2006,17:00)

Сега не искам да се заяждам, но няма такова нещо като "udp връзки". Има протоколи които надграждат UDP добавяйки му някаква степен на TCP-подобна функционалност (такъв е RUDP), които ужким са измисляни за стрийминг приложения с ужким  контролирано от потребителя качество върху бавни връзки алабала...но не знам да са влезнали в масова употреба. RDP използван за quicktime стриймване главно не е базиран върху UDP а върху IP.

/off
@gat3way Идеята е, че доста рутери пускат приоритетно UDP тарфика, в качеството му на ненадежден протокол, пред TCP-трафика.

@aviditko
Щом си с повече от 2 интерфейса позлвай IMQ (потърси из google) за да можеш да правиш трафик шейпинг както трябва. По отношение на htb.init - свали го, разлгедай му сорса (има хелп вътре! в него), разгледай малко статиите в linux-bg.org и ще схванеш идеята.

[gat3way]

Единственият udp трафик дето би трябвало да се пуска приоритетно е DNS трафика според мен. И въпреки всичко приказките около злоупотребите с рекурсивни сървъри и amplification атаките свързани с тях разубеждават...

Но пък знам ли ги какви са им практиките из провайдърите, специално що се отнася до voip трафика съм чувал че при големите провайдъри си имало разни други, главно икономически съображения за QoS policies..там покрай дебата за network neutrality законите в Щатите нали имаше доста караници, както и едни флаш филмчета, разбира се с магистрали, коли и задръствания (странно защо нямаше с водопроводи, ХАХА)..

Обаче никога не съм работил в ISP, а и не обичам особено да се размотавам с  хора, занимаващи се с линукс или networking, освен колегите ми на работа де..така че нямам мнение по въпроса, просто нямам поглед върху това какво се прави из провайдърите...

[BRADATA]

//лек офтопик

Дайте идея как да си направя трафик генератор (с пинг работя в момента, ама не е много гъвкав) за тестове на NAT сървъри, трасета, вирелеси и  т.н. По принцип си мисля за нещо клиент-сървър ориентирано, да може да прави паралелни връзки на различни портове (TCP/UDP) и да праща/получава пакети с променлива големина (както реално се случва в интернет   ). Намерих и някакво програмче в sourceforge, ама така и не можах да го подкарам.

Очаквам вашите идеи.

Поздрави

[gat3way]

hping3 върши добра работа според мен '> Особено за тестване на NAT, firewalls, издържливост на tcp стека спрямо syn атаки или експерименти с ip фрагментация, etc