Freesco, NND, CDN, EOS http://forum.freesco.pl/ |
|
ograniczenie ilości połączeń http://forum.freesco.pl/viewtopic.php?f=22&t=11192 |
Strona 1 z 2 |
Autor: | xmaster [ piątek, 10 lutego 2006, 11:10 ] |
Tytuł: | ograniczenie ilości połączeń |
Cytuj: Statystyka ilosci polaczen
Godzina: 10:11 IP RAZEM TCP TCP EST. UDP 10.0.0.4 1 1 1 0 10.0.0.7 21 10 8 11 10.0.0.11 1 1 1 0 10.0.0.12 2 2 2 0 10.0.0.13 5 5 2 0 10.0.0.15 75 73 3 2 10.0.0.16 3017 2831 153 186 to jest user który dzili net na 3 kompy łącznie ze swoim mam pytanko czy można jakoś ograniczyć ilość połączeń?? i ile połączeń jest "normalne" |
Autor: | Dayson [ piątek, 10 lutego 2006, 11:48 ] |
Tytuł: | |
http://forum.freesco.pl/viewtopic.php?t ... 3%B1cze%F1 i Firewall-u Czerwo jest taka opcja |
Autor: | blackangel [ piątek, 10 lutego 2006, 14:12 ] |
Tytuł: | |
xmaster a jak zrobiłeś takie statystyki? |
Autor: | xmaster [ niedziela, 5 marca 2006, 23:31 ] |
Tytuł: | |
http://www.wiki.nnd.freesco.pl/index.ph ... izacja_NND zastosowalem sie do wpisow i nadal lipa userzy maja kupe ponad 60 polaczen Cytuj: Statystyka ilosci polaczen
Godzina: 22:34 IP RAZEM TCP TCP EST. UDP 10.0.0.7 629 65 17 564 10.0.0.14 6 6 2 0 10.0.0.16 125 52 2 73 10.0.0.17 356 81 21 275 i net potrafi chodzic fatalnie ping na wp wykonywany prosto z serwera czasem siega 4000 !!!!! nie wiem co sie dzieje w dodatku mam jakis dziwny komunikat podczas ladowania systemu gdzie sa logi z uruchamiania systemu? to wkleje je tutaj jak to naprawic??? |
Autor: | bartex [ poniedziałek, 6 marca 2006, 01:03 ] |
Tytuł: | |
http://linux.gery.pl/dzialy/podstawy/extra/logi |
Autor: | xmaster [ wtorek, 7 marca 2006, 18:32 ] |
Tytuł: | |
Cytuj: Statystyka ilosci polaczen
Godzina: 17:35 IP RAZEM TCP TCP EST. UDP 10.0.0.4 15 15 14 0 10.0.0.7 281 63 39 218 10.0.0.12 35 33 12 2 10.0.0.14 8 7 1 1 10.0.0.15 3 2 2 1 10.0.0.16 19 19 19 0 10.0.0.17 331 70 54 261 czy to ograniczenie ilosci polaczen jest tylko naTCP EST?? a na udp sie nie da czy po prostu u mnie nie dziala??? |
Autor: | marask [ wtorek, 7 marca 2006, 19:26 ] |
Tytuł: | |
nei ma czegoś takiego jak UDP Estab - nie ma nawiązanych połączeń UDP - pakiet jest po prostu wypychany w net, bez sprawdzania czy dotarł. Może przeoczyłeś szczegół, że limity działają tylko na NOWE połączenia - na te już nawiązane nie mają wpływu. |
Autor: | agbis [ wtorek, 7 marca 2006, 19:28 ] |
Tytuł: | |
Z UDP nie jest tak łatwo jak z TCP. Pierwszy pakiet połączenia TCP (pakiet nawiązujący połączenie) ma ustawioną flagę SYN (co by to miało nie znaczyć ![]() ![]() PS. Aktualne połączenia można sobie zobaczyć poleceniem: |
Autor: | xmaster [ wtorek, 7 marca 2006, 20:10 ] |
Tytuł: | |
czyli mam rozumiec ze nie da sie ograniczyc ilosci UDP? jesi tak to szkoda bo dsle maja slabe wyjscie na swiat ![]() |
Autor: | marask [ wtorek, 7 marca 2006, 20:53 ] |
Tytuł: | |
ja znam niezawodną metodę przycięcia ruchu udp do niezbędnego minimum* iptables -I INPUT -p udp -j DROP Nie zapomnijcie o przekierowaniu na własnego dns'a ![]() *czytaj do zera ![]() btw jak chcecie blokować "ilość połączeń UDP" skoro one nie są "nawiązywane" ? możecie ich ilość na sekundę ustalić. Chyba nic poza tym. |
Autor: | agbis [ wtorek, 7 marca 2006, 21:13 ] |
Tytuł: | |
marask pisze: jak chcecie blokować "ilość połączeń UDP" skoro one nie są "nawiązywane"
Każde połączenie udp podobnie jak tcp ma swoje odzwierciedlenie w tablicy połączeń kernela. Coś mogłoby analizować wpisy w tablicy i kasować nadmiarowe (ponad limit) lub nie dopuszczać do powstawania nowych wpisów. W iptables jest coś takiego jak "stateful inspection" i o ile się nie mylę, można rozróżnić pakiety udp o statusie "NEW" od "ESTABLISHED". To tylko taka luźna koncepcja bez konkretnego pomysłu na realizację. Wydaje mi się, że byłoby to potrzebne, bo ograniczanie ilości połączeń tcp jest nieskuteczne, kiedy sprawiające problemy programy p2p potrafią sobie naotwierać dużą ilość połączeń udp. |
Autor: | tasiorek [ wtorek, 7 marca 2006, 22:42 ] |
Tytuł: | |
agbis pisze: Nie znam metody ograniczania połączeń UDP agbis pisze: Każde połączenie udp podobnie jak tcp ma swoje odzwierciedlenie w tablicy połączeń kernela.
Nie ma czegos takiego jak polaczenie UDP. |
Autor: | marask [ wtorek, 7 marca 2006, 22:48 ] |
Tytuł: | |
tasiorek: dokładnie tak jak napisałem Ale koncepcja AGBIS'a jest dobra: iptables -I FORWARD -p udp -m ipp2p --ipp2p -m conntrack --ctstate NEW -j REJECT Ciekawe jakby się to sprawdziło. Przystępuję do testów edit testów testów.. ale jaki program używa tylko UDP? ![]() ![]() edit2 chodziło mu pewnie o to: http://www.faqs.org/docs/iptables/tcpconnections.html |
Autor: | agbis [ środa, 8 marca 2006, 01:10 ] |
Tytuł: | |
tasiorek pisze: Nie ma czegos takiego jak polaczenie UDP. Zależy, jak zdefiniujemy pojęcie "połączenie". Na http://www.wiki.nnd.freesco.pl/index.php/Optymalizacja_NND pisze: Cytuj: W przypadku dużej ilości użytkowników powstaje kolejny dość istotny problem - ilość połączeń. (...) Powyższe dotyczy w jednakowym stopniu protokołów tcp jak i udp. Z tym, że o ile przy tcp połączenie jest nawiązywane przez wymianę trzech pakietów (SYN, SYN+ACK, ACK), to w kontekście protokołu udp "połączenie" należy traktować jako ciąg związanych ze sobą pakietów, dla którego rezerwowana jest pozycja w tablicy połączeń.Wraz ze wzrostem oczywiscie ilosci polaczen nawiazanych (ESTABLISHED) zmniejsza się ilość portów przeznaczonych dla NAT-u. Przy standardowych ustawieniach portow dla NAT-u jest 8192. Przykład: Komp zza NATu wysyła pakiet udp z zapytaniem do serwera dns w internecie. Pakiet udp przechodząc przez router "zostawia ślad" w tablicy połączeń, żeby pakiet zawierający odpowiedź z serwera dns został przez router skierowany do tego kompa, który wysłał zapytanie. Wpis w tabeli połączeń zostaje aż do timeoutu, bo nie ma czegoś takiego jak pakiet zamykający połączenie udp. Cytuj: chodziło mu pewnie o to:
http://www.faqs.org/docs/iptables/tcpconnections.html Może bardziej o http://www.faqs.org/docs/iptables/udpconnections.html chociaż przyznaję, że nie do końca to wszystko rozumiem. |
Autor: | tasiorek [ środa, 8 marca 2006, 04:11 ] |
Tytuł: | |
Jak zdefiniowac polaczenie dowiesz sie np stad: http://pl.wikipedia.org/wiki/TCP http://pl.wikipedia.org/wiki/UDP Jednak faktem jest, ze tablica conntrack nadaje wlasne wpisy ciagom pakietow i potrafi odroznic ich stan. Wiecej info na ten temat mozna znalezc np tu: http://debian.one.pl/howto/iptables/iptables2-pl.html (rozdzial 5), albo tu: http://www.marcinmazurek.com/teksty/con ... ntrack.pdf Nie mozna wiec ograniczyc ilosci polaczen udp, bo czegos takiego nie ma. Mozna za to limitowac ilosc rozpoczynanych transmisji i ich intensywnosc. Pozbieralem do kupy informacje i wymyslilem cos takiego (kolejnosc wpisywania regul jest wazna): Cytuj: iptables -A FORWARD -s przycinane ip -m conntrack --ctproto udp --ctstate NEW -m limit --limit 6/h --limit-burst 15 -j ACCEPT
iptables -A FORWARD -s przycinane ip -m conntrack --ctproto udp --ctstate RELATED,ESTABLISHED -m limit --limit 1/s -m length --length 300:1500 -j ACCEPT iptables -A FORWARD -s przycinane ip -p udp -j DROP Wedlug mnie zezwoli to na rozpoczecie nowego "polaczenia" co 10 min, przy czym pierwsze 15 nie bedzie limitowane i na wysylanie 5 pakietow wiekszych od 300 bajtow co sekunde w ramach tych polaczen. Zapraszam do testow. Sam nie testuje, bo nie mam zamiaru ograniczac udp. Problem jest taki, ze limituje to wszystkie polaczenia udp, a ipp2p sobie zupelnie nie radzi: po dodaniu -m ipp2p --ipp2p (czy --edk) emule (a dokladnie kademila) nic sobie nie robi z tych regul. Nie polecam stosowac tego na jakims graczu np w csa. Chociaz jak mu lossy beda osiagaly wielkie wartosci, to sam do Was przyjdzie i wtedy bedzie mozna z nim porozmawiac o jego p2p ![]() |
Autor: | NertoM [ czwartek, 9 marca 2006, 08:01 ] |
Tytuł: | |
Witam ... Jesli hodzi o graczy to na UDP 70/s wystarczy spokojnie , wielkosc pakietu (polaczeniowe durze ,wieksze UDP 1000-1500 ale to tylko podczas whodzenia na serwer puzniej jusz idzie taki STRUMIEN ) QUAKE 64-260 CS 40-300 WS 150-400 Reszty nie sprawdzalem . Wlasnei ja mam problem z UDP co sie przeciska przez HTB i SHAPERA : ( calkowicie se go OLEWA ale to przy programach p2p ine sa OKI ( ARES ) dZIEKi ... |
Autor: | agbis [ piątek, 24 marca 2006, 16:57 ] |
Tytuł: | |
tasiorek pisze: Wiecej info na ten temat mozna znalezc np tu: http://www.marcinmazurek.com/teksty/con ... ntrack.pdf
Nie mozna wiec ograniczyc ilosci polaczen udp, bo czegos takiego nie ma. Mozna za to limitowac ilosc rozpoczynanych transmisji i ich intensywnosc. W tym dokumencie użyto pojęcia "strumień udp" w znaczeniu, w jakim ja pisałem o "połączenie udp" i chyba to określenie będzie najwłaściwsze. Przede wszystkim należaloby określić, co potrzeba limitować i dlaczego. Dlaczego duża ilość jednoczesnych połączeń/strumieni jest szkodliwa? Ja rozumiem to w ten sposób, że każde połączenie tcp i strumień udp przechodząc przez router (lub inne urządzenie, które z jakiegoś powodu śledzi połączenia) zostawia wpis w tablicy połączeń. Każdy wpis zabiera jakieś zasoby. Poza tym każdy kolejny pakiet należący do strumienia musi być porównany z tą tablicą i odpowiednio pokierowany przez router. Dlatego im więcej wpisów w tablicy połączeń tym większa moc obliczeniowa potrzebna do obsłużenia routingu. No i tutaj pojawiają się problemy z wydajnością. Taka jest moja teoria. Nie wiem, na ile słuszna. Nie pasuje mi do niej tylko jedno: od czasu do czasu spotykam się z tym, że ktoś wiąże przypadki zawieszania się accesspointów z ilością połączeń. Sam nie zauważyłem takiej zależności. Nie przypuszczam, żeby te urządzenia miały powód śledzić połączenia. Dla nich pakiet to pakiet: może być większy albo mniejszy, może ich być dużo lub mało, ale nie powinno je interesować, jakie flagi ma poustawiane ani do jakiego połączenia należy. Przypuszczam nawet (nie sprawdzałem), że accesspointy mogą przesyłać pakiety w innych niż ip protokołach czyli np. ipx/spx albo NetBEUI. Interesują mnie opinie, czy to co wyżej napisałem odzwierciedla rzeczywistość. Trzeba ograniczać połączenia tak, żeby rozwiązywało to nasze problemy a było to jak najmniej uciążliwe. Uważam, że klient, który płaci nam za neta ma prawo sam decydować, czy będzie oglądał www, grał w quake'a czy wymieniał się plikami przez p2p. Bo jak nie, to nas oleje i weźmie neostradę (miałem już tak - miał za długie pingi i wywalało go z serwera Call of Duty). Jeżeli źródło problemów jest takie, jak napisałem wyżej to najlepiej wypacować takie rozwiązanie, że każdy ma przydzieloną pulę połączeń tcp i strumieni udp. Limitowanie tcp jest rozwiązane przez connlimit. Natomiast dla udp widziałbym rozwiązanie oparte na cylkicznym analizowaniu tablicy conntrack, zliczaniu strumieni udp z poszczególnych ip i odpowiedniej reakcji na przekroczenie limitu. Reakcją tą mogłoby być: - blokada nie pozwalająca na rozpoczęcie kolejnych strumieni (dosyć proste w realizacji: iptables -A FORWARD -p udp -s $ip_użytkownika -j DROP lub coś w tym stylu); - skasowanie wszystkich strumieni:(/usr/sbin/clr_conns $ip_użytkownika - chyba zbyt restrykcyjne); - skasowanie ostatnio nawiązanych połączeń, które przekraczają limit (najlepsze, ale nie wiem jak zrealizować. Może coś opartego na hping2 ?) Zliczanie możnaby zrealizować w sposób zbliżony do zaprezentowanego w http://forum.freesco.pl/viewtopic.php?p=73401#73401 Wydaje mi się, że rozwiązanie tasiorka może spowodować problemy w grach, VoIP i pewnie paru innych zastosowaniach interetu. EDIT: Pisałem: skasowanie wszystkich strumieni:(/usr/sbin/clr_conns $ip_użytkownika) clr_conns odpada - działa tylko na tcp ![]() ![]() |
Autor: | Koriolan [ poniedziałek, 27 marca 2006, 15:47 ] |
Tytuł: | |
agbis pisze: ...1) Dlatego im więcej wpisów w tablicy połączeń tym większa moc obliczeniowa potrzebna do obsłużenia routingu.
...........2) że ktoś wiąże przypadki zawieszania się accesspointów z ilością połączeń. Sam nie zauważyłem takiej zależności. ............3) - skasowanie wszystkich strumieni:(/usr/sbin/clr_conns $ip_użytkownika - chyba zbyt restrykcyjne); - skasowanie ostatnio nawiązanych połączeń, które przekraczają limit (najlepsze, ale nie wiem jak zrealizować. Może coś opartego na hping2 ?) Ad 1) Rozwiązaniem jest parametr przy kompilacji jądra (a właściwie ip_conntrack) Ad.2) Duża ilość ruchu małymi pakietami zabija AP'ki stąd łączą to z dużą ilością połaczeń. AD. 3) NIE MA czegoś takiego jak skasowanie połaczeń UDP. Nie ma pakietów nawiązujących łaczność ( SYN, ACK) to nie nie ma kończących .RST. Można to załatwić zmniejszeniem czasu trzymania w tablicy 'połączeń' ip_conntrack. Kasowanie tablicy ip_conntrck UDP nie ma za wiele sensu. Zwalnianie zasobów też jest wątpliwym zyskiem. |
Autor: | tasiorek [ poniedziałek, 27 marca 2006, 17:00 ] |
Tytuł: | |
agbis pisze: - blokada nie pozwalająca na rozpoczęcie kolejnych strumieni (dosyć proste w realizacji: iptables -A FORWARD -p udp -s $ip_użytkownika -j DROP lub coś w tym stylu);
Popatrz na moj post powyzej i postaraj sie zrozumiec te reguly, ktore podalem. Moze jak sam bedziesz do tego dochodzil, to zrozumiesz, ze dzialaja wlasnie na tej zasadzie. |
Autor: | agbis [ poniedziałek, 27 marca 2006, 17:48 ] |
Tytuł: | |
Koriolan pisze: Rozwiązaniem jest parametr przy kompilacji jądra (a właściwie ip_conntrack) Chodzi o powiększenie tablicy conntrack? Z tego co wiem, można to zrobić na już skompilowanym kernelu przez umieszczenie odpowiedniej wartości w /proc/sys/net/ipv4/ip_conntrack_max. Ale to już raczej nie ma związku z zawieszaniem APków.Koriolan pisze: Duża ilość ruchu małymi pakietami zabija AP'ki stąd łączą to z dużą ilością połaczeń. I tej informacji było mi trzeba! W związku z tym wogóle nie ma się co czepiać ilości połączeń, tylko trzeba uwalać te małe pakiety tak, żeby nie było ich za dużo. I chyba najlepiej to robić na wejściu z internetu do lanu, bo te które wygenerują kompy w lanie to i tak muszą przejść przez APki zanim je router ubije.Koriolan pisze: NIE MA czegoś takiego jak skasowanie połaczeń UDP. Nie ma pakietów nawiązujących łaczność ( SYN, ACK) to nie nie ma kończących .RST. Widziałem, że clr_conns wysyła pakiety z flagą RST dla zamknięcia połączeń, ale chodziło mi raczej o jakś sposób, żeby wymusić na kernelu usunięcie niektórych wpisów z tablicy conntrack (czyli, żeby kernel poprostu zapomniał o niektórych połączeniach tak, jak to robi gdy router jest resetowany). Ale w świetle poprzedniej informacji nie ma sensu dalej zajmować się limitowaniem ilości połączeń.
Można to załatwić zmniejszeniem czasu trzymania w tablicy 'połączeń' ip_conntrack. Kasowanie tablicy ip_conntrck UDP nie ma za wiele sensu. Zwalnianie zasobów też jest wątpliwym zyskiem. Popracuję nad odpowiednimi wpisami do firewalla, któreby limitowały ilość małych pakietów. Trzeba to zrobić inteligentnie, żeby nie spowodować problemów w działaniu jakichś usług. Pomogłyby mi informacje: 1) Jakie programy używają małych pakietów? Przyjmuję, że "małe pakiety" mają poniżej 75 bajtów; Szczególnie interesują mnie: p2p wszelkiej maści, Skype i inne VoIP, gry. 2) Jaka ilość tych pakietów zabija APki? Dla chcących pomóc informacja: natężenie małych pakietów można sprawdzić: Na routerze - IPtrafem: Statistical breakdowns/By packet size lub na kliencie można podglądnąć te pakiety Etherealem http://www.ethereal.com/(jest wersja pod Windowsy i linuxa z X-ami) zakładając filtr pakietów o treści 'less 75' |
Strona 1 z 2 | Strefa czasowa UTC+2godz. |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |