Freesco, NND, CDN, EOS

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"

_________________
www.kaczuszka.info - HOT-SPOT
http://theborg.pl/misioo/forum/ - forum klanu misioo "CS"

http://forum.freesco.pl/viewtopic.php?t ... 3%B1cze%F1

i Firewall-u Czerwo jest taka opcja

xmaster a jak zrobiłeś takie statystyki?

http://www.wiki.nnd.freesco.pl/index.ph ... izacja_NND

zastosowalem sie do wpisow i nadal lipa
userzy maja kupe ponad 60 polaczen


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???

_________________
www.kaczuszka.info - HOT-SPOT
http://theborg.pl/misioo/forum/ - forum klanu misioo "CS"

_________________

czy to ograniczenie ilosci polaczen jest tylko naTCP EST?? a na udp sie nie da czy po prostu u mnie nie dziala???

_________________
www.kaczuszka.info - HOT-SPOT
http://theborg.pl/misioo/forum/ - forum klanu misioo "CS"

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.

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ć ) i po tym łatwo rozpoznać go i zablokować na poziomie firewalla. W UDP nie ma czegoś takiego i pierwszy pakiet "połączenia" UDP w zasadzie niczym się nie różni od kolejnych. Nie znam metody ograniczania połączeń UDP, ale w każdym razie iptables/connlimit działa tylko na TCP Ciekawy jestem, czy jest jakaś metoda ograniczania ilości połączeń UDP na podstawie tablicy połączeń kernela.

PS. Aktualne połączenia można sobie zobaczyć poleceniem:

czyli mam rozumiec ze nie da sie ograniczyc ilosci UDP?
jesi tak to szkoda bo dsle maja slabe wyjscie na swiat

_________________
www.kaczuszka.info - HOT-SPOT
http://theborg.pl/misioo/forum/ - forum klanu misioo "CS"

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.

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.

Nie ma czegos takiego jak polaczenie UDP.

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? Bo BitComet ładnie leci Emule się nie łączy wogóle ale to chyba wina mojego emule.

edit2
chodziło mu pewnie o to:
http://www.faqs.org/docs/iptables/tcpconnections.html

Zależy, jak zdefiniujemy pojęcie "połączenie". Na http://www.wiki.nnd.freesco.pl/index.php/Optymalizacja_NND pisze: 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ń.
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.


Może bardziej o http://www.faqs.org/docs/iptables/udpconnections.html chociaż przyznaję, że nie do końca to wszystko rozumiem.

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):

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 . Wartosci dobrane sa "na oko", wiec przydaloby sie z nimi poeksperymentowac.

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 ...

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 Czy ktoś zna metodę usunięcia z conntrack wpisu dot. udp? (inną niż restart routera )

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.

_________________
Określenie przy nicku to tylko dla 'jaj'; tytuł za ilość postów.
Ja ciągle się uważam za niewinne dziecię w sprawach linuksa; żaden guru czy inny moderator

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.

_________________
FAQ dla NND: http://nnd-linux.pl/faq.php
Doswiadczenie, to cos, co zdobywasz tuz po chwili w ktorej go potrzebowales.

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.
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.
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ń.

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'