Freesco, NND, CDN, EOS
http://forum.freesco.pl/

Po raz kolejny wiszące połączenia
http://forum.freesco.pl/viewtopic.php?f=22&t=16291		 Strona 1 z 1
Autor:  b0dzi0 [ sobota, 1 grudnia 2007, 09:46 ]
Tytuł:  Po raz kolejny wiszące połączenia
Witam,
Mam w sieci 2 osoby które narzekają że stronki nie zawsze im się otwierają. Strona po prostu wczytuje się wczytuje wczytuje i wyświetla nie można wyświetlić strony. Jedna z tych osób to maniak p2p, a druga nałogowy gracz online. Zrobiłem dziś w nocy u siebie eksperyment, włączyłem p2p pełną parą, bez żadnych ograniczeń połączeń w programie, ograniczenia dał mi serwer. rano wyłączyłem p2p, ale połączenia w pamięci zostały, ping do wp.pl miał 30% straty.
Wyłączenie i właczenie połączenia sieciowego pomaga jedynie na chwile, wystarczy że włacze kolejnych kilka stron, lub połącze się z jakąś grą i po chwili znowu gubie dużo pakietów.
Z serwera wykrywa mi tyle połączeń:
: [/] [] ()
netstat-nat -n -s 192.168.7.5
Proto NATed Address                  Foreign Address                State
tcp   192.168.7.5:1040               85.232.236.127:80              ESTABLISHED
tcp   192.168.7.5:2588               83.168.77.36:33566             ESTABLISHED
tcp   192.168.7.5:4338               216.8.128.173:25688            ESTABLISHED
tcp   192.168.7.5:2584               83.20.85.187:11312             ESTABLISHED
tcp   192.168.7.5:2467               83.6.175.203:55944             ESTABLISHED
tcp   192.168.7.5:3617               216.8.128.173:25688            ESTABLISHED
tcp   192.168.7.5:2072               76.224.121.135:24139           ESTABLISHED
tcp   192.168.7.5:4615               89.174.40.130:25412            ESTABLISHED
tcp   192.168.7.5:4640               76.240.107.216:24139           ESTABLISHED
tcp   192.168.7.5:3644               89.174.83.65:25412             ESTABLISHED
tcp   192.168.7.5:4971               81.190.129.129:55437           ESTABLISHED
tcp   192.168.7.5:1453               89.174.40.27:25412             ESTABLISHED
tcp   192.168.7.5:1260               209.85.135.91:80               TIME_WAIT
tcp   192.168.7.5:3285               86.133.199.68:28246            ESTABLISHED
tcp   192.168.7.5:1194               77.223.199.1:80                ESTABLISHED
tcp   192.168.7.5:1658               83.6.175.203:55944             ESTABLISHED
tcp   192.168.7.5:2779               89.174.83.150:25412            ESTABLISHED
tcp   192.168.7.5:1237               217.17.45.143:8074             ESTABLISHED
tcp   192.168.7.5:2855               216.8.128.173:25688            ESTABLISHED
tcp   192.168.7.5:3062               87.205.236.254:23510           ESTABLISHED
tcp   192.168.7.5:1258               77.45.6.1:80                   TIME_WAIT
tcp   192.168.7.5:4948               38.99.76.235:80                ESTABLISHED
tcp   192.168.7.5:2439               81.190.129.129:55437           ESTABLISHED
tcp   192.168.7.5:4034               82.3.242.117:57849             ESTABLISHED
tcp   192.168.7.5:3263               81.190.135.84:23522            ESTABLISHED
tcp   192.168.7.5:2876               89.174.40.63:25412             ESTABLISHED
tcp   192.168.7.5:3099               194.88.244.5:11976             ESTABLISHED
tcp   192.168.7.5:4419               195.136.169.77:35609           ESTABLISHED
tcp   192.168.7.5:1069               86.133.199.68:28246            ESTABLISHED
[root@RudLan ~]# netstat-nat -n -d 192.168.7.5
Proto NATed Address                  Foreign Address                State
tcp   158.75.237.247:41872           192.168.7.5:55555              ESTABLISHED
tcp   212.76.37.186:59401            192.168.7.5:55555              ESTABLISHED
tcp   62.121.127.134:3307            192.168.7.5:55555              ESTABLISHED
tcp   79.185.82.134:1138             192.168.7.5:55555              ESTABLISHED
tcp   82.139.13.231:2345             192.168.7.5:55555              ESTABLISHED
tcp   83.15.108.74:1562              192.168.7.5:55555              ESTABLISHED
tcp   87.206.31.66:57937             192.168.7.5:55555              ESTABLISHED
tcp   87.207.59.46:2374              192.168.7.5:55555              ESTABLISHED
tcp   89.174.40.191:3522             192.168.7.5:55555              ESTABLISHED
tcp   89.77.149.99:1907              192.168.7.5:55555              ESTABLISHED
tcp   89.77.149.99:2022              192.168.7.5:55555              ESTABLISHED
tcp   89.79.114.38:2020              192.168.7.5:55555              ESTABLISHED
tcp   99.240.107.93:4439             192.168.7.5:55555              ESTABLISHED
udp   125.123.52.231:11141           192.168.7.5:55555              UNREPLIED
GeSHi © Codebox Plus

Chyba musze je zakończyć aby wróciło wszystko do normy :?:
Niestety wszystkie linki z forum jakie znalazłem do clr_conns są martwe. Może ktoś podesłać działające, lub może zna sposób aby coś takiego nie występowało :?:
Jak wspomniałem 1 klient gra non stop w gry online, i dzieje mu się to właśnie podczas grania. ciąganie p2p u niego nie istnieje.
Autor:  Terminator [ sobota, 1 grudnia 2007, 10:57 ]
Tytuł: 
Lepiej zapobiegać niż leczyć
http://forum.freesco.pl/viewtopic.php?t=16188&highlight=limit+po%B3%B1cze%F1
poczytaj i ustaw wedle swoich wymagań
A jeśli to będzie za mało to poszukaj "limit połączeń" , "ilość połączeń" , "ograniczenie połączeń"
Autor:  b0dzi0 [ sobota, 1 grudnia 2007, 11:13 ]
Tytuł: 
obecnie mialem ustawione takie ograniczenie:
: [/] [] ()
iptables -A FORWARD -s 192.168.7.0/24 -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -m connlimit --connlimit-above 100 --connlimit-mask 32 -j DROP
GeSHi © Codebox Plus
oraz takie regułki:
: [/] [] ()
echo "2400" > /proc/sys/net/ipv4/tcp_keepalive_time
echo "30" > /proc/sys/net/ipv4/tcp_fin_timeout
echo "60" > /proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout
echo "20" > /proc/sys/net/ipv4/netfilter/ip_conntrack_icmp_timeout
echo "60" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait
echo "1" > /proc/sys/net/ipv4/igmp_max_memberships
echo "0" > /proc/sys/net/ipv4/tcp_window_scaling
echo "0" > /proc/sys/net/ipv4/tcp_sack
echo "32768-64000" > /proc/sys/net/ipv4/ip_local_port_range
#echo "86400" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
echo "43200" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
echo "5" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close
echo "20" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_fin_wait
echo "30" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_last_ack
echo "20480" > /proc/sys/net/ipv4/ip_conntrack_max
echo "10240" > /proc/sys/net/ipv4/netfilter/ip_conntrack_max
echo "40" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait
echo "30" > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
echo "180" > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream
echo "20" > /proc/sys/net/ipv4/ipfrag_time
echo "1280" > /proc/sys/net/ipv4/tcp_max_syn_backlog
#echo "0" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_log_out_of_window
#echo "0" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_log_invalid_scale
######## Inne dodatki ################################################################
# Wlaczenie mechanizmu wykrywania oczywistych falszerstw
echo "1" >/proc/sys/net/ipv4/conf/all/rp_filter

# Ochrona przed atakiem typu Smurf
echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

# Nie aktceptujemy pakietow "source route"
echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route

# Nie przyjmujemy pakietow ICMP rediect, ktore moga zmienic tablice routingu
echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects

# Wlaczamy ochrone przed blednymi komunikatami ICMP error
echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

# Wlacza logowanie dziwnych (spoofed, source routed, redirects) pakietow
echo "1" > /proc/sys/net/ipv4/conf/all/log_martians
# TCP timestamps protection
echo "1" > /proc/sys/net/ipv4/tcp_timestamps

# Ignore redirected packets
echo "0" > /proc/sys/net/ipv4/conf/all/send_redirects
echo "100 1200 128 512 500 5000 500 1884 1" > /proc/sys/vm/bdflush
#echo "80 10 60" > /proc/sys/vm/buffermem
echo 6144 > /proc/sys/fs/file-max
#echo 24576 > /proc/sys/fs/inode-max
# wylaczamy odpowiedzi na pingi
#echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all
#zabezpieczenie przed skanowaniem ftp
iptables -A INPUT -p tcp --dport 21 -m recent --name FTP --seconds 60 --update -j DROP
iptables -A INPUT -p tcp --dport 21 -m limit --limit 5/second --limit-burst 15 -m recent --name FTP --set -j ACCEPT

#Pokiety UDP o dlugości ponad 8000bit
iptables -I FORWARD  -m length --length 1501:65535 -j REJECT
GeSHi © Codebox Plus

Chodzi o to że serwer dobrze to pilnuje, ale ich nie kasuje i wiszą one dość długo, mimo że program już dawno został wyłączony
Autor:  zciech [ sobota, 1 grudnia 2007, 12:22 ]
Tytuł: 
1. Te polaczenie tak naprawde to nie umieraja tylko dlatego ze komputer lokalny zostal wylaczony, sa przesylane pakiety od partnera w internecie
2. Skoro masz ograniczenie ilosci polaczem to CO SIĘ DZIWISZ?
3. http://zciech.w.interia.pl/nnd/clr_conns.tgz
4. Wylacz to ograniczanie ilosci polaczen, nie ma zadnego racjonalnego powodu by utrzymywac cos takiego na serwerze.
Np. w sieci z ok 150 userami na łączu 4/4 mBit/s maksymalna ilosc polaczen to ok. 10 000.
Autor:  b0dzi0 [ sobota, 1 grudnia 2007, 13:31 ]
Tytuł: 
zciech pisze:
1. Te polaczenie tak naprawde to nie umieraja tylko dlatego ze komputer lokalny zostal wylaczony, sa przesylane pakiety od partnera w internecie
- dokładniej rzecz ujmując to nie komputer został wyłączony a jedynie program p2p. Skoro został on wyłączony dlaczego zostały wiszące połączenia :?:
zciech pisze:
2. Skoro masz ograniczenie ilosci polaczem to CO SIĘ DZIWISZ?
- nie dziwie się że dzieje się tak jak się dzieje, tylko nie rozumiem dlaczego po wyłączeniu programu nadal jest źle.
zciech pisze:
3. http://zciech.w.interia.pl/nnd/clr_conns.tgz
- Dzięki
zciech pisze:
4. Wylacz to ograniczanie ilosci polaczen, nie ma zadnego racjonalnego powodu by utrzymywac cos takiego na serwerze.
Np. w sieci z ok 150 userami na łączu 4/4 mBit/s maksymalna ilosc polaczen to ok. 10 000.
- akurat nie mam symetryka 4/4 mBit/s, mam marne dsl 8mb na które coraz bardziej narzekam, zapewne nie wytrzyma on 10.000 połączeń. Sieć swoją mam opartą w większości na WIFI, więc wydaje mi się, że gdy wyłączę ten limit to cała radiówka umrze od nadmiernej ilości połączeń. Jeśli się mylę prosze o wyprowadzenie mnie z błędu.
Autor:  b0dzi0 [ sobota, 1 grudnia 2007, 14:20 ]
Tytuł: 
nie no nie wytrzymam zaraz, spójrzcie co się dzieje:
: [/] [] ()
C:\Documents and Settings\Admin>ping wp.pl -n 20

Badanie wp.pl [212.77.100.101] z użyciem 32 bajtów danych:

Odpowiedź z 212.77.100.101: bajtów=32 czas=40ms TTL=122
Odpowiedź z 212.77.100.101: bajtów=32 czas=41ms TTL=122
Upłynął limit czasu żądania.
Upłynął limit czasu żądania.
Odpowiedź z 212.77.100.101: bajtów=32 czas=39ms TTL=122
Odpowiedź z 212.77.100.101: bajtów=32 czas=51ms TTL=122
Upłynął limit czasu żądania.
Upłynął limit czasu żądania.
Upłynął limit czasu żądania.
Odpowiedź z 212.77.100.101: bajtów=32 czas=40ms TTL=122
Odpowiedź z 212.77.100.101: bajtów=32 czas=41ms TTL=122
Upłynął limit czasu żądania.
Odpowiedź z 212.77.100.101: bajtów=32 czas=66ms TTL=122
Odpowiedź z 212.77.100.101: bajtów=32 czas=46ms TTL=122
Odpowiedź z 212.77.100.101: bajtów=32 czas=47ms TTL=122
Upłynął limit czasu żądania.
Odpowiedź z 212.77.100.101: bajtów=32 czas=39ms TTL=122
Upłynął limit czasu żądania.
Upłynął limit czasu żądania.
Odpowiedź z 212.77.100.101: bajtów=32 czas=72ms TTL=122

Statystyka badania ping dla 212.77.100.101:
    Pakiety: Wysłane = 20, Odebrane = 11, Utracone = 9 (45% straty),
Szacunkowy czas błądzenia pakietów w millisekundach:
    Minimum = 39 ms, Maksimum = 72 ms, Czas średni = 47 ms

C:\Documents and Settings\Admin>ping 192.168.7.1 -n 20

Badanie 192.168.7.1 z użyciem 32 bajtów danych:

Odpowiedź z 192.168.7.1: bajtów=32 czas<1 ms TTL=64
Odpowiedź z 192.168.7.1: bajtów=32 czas<1 ms TTL=64
Odpowiedź z 192.168.7.1: bajtów=32 czas<1 ms TTL=64
Odpowiedź z 192.168.7.1: bajtów=32 czas<1 ms TTL=64
Upłynął limit czasu żądania.
Odpowiedź z 192.168.7.1: bajtów=32 czas<1 ms TTL=64
Odpowiedź z 192.168.7.1: bajtów=32 czas<1 ms TTL=64
Odpowiedź z 192.168.7.1: bajtów=32 czas<1 ms TTL=64
Odpowiedź z 192.168.7.1: bajtów=32 czas<1 ms TTL=64
Odpowiedź z 192.168.7.1: bajtów=32 czas<1 ms TTL=64
Upłynął limit czasu żądania.
Odpowiedź z 192.168.7.1: bajtów=32 czas<1 ms TTL=64
Odpowiedź z 192.168.7.1: bajtów=32 czas<1 ms TTL=64
Upłynął limit czasu żądania.
Upłynął limit czasu żądania.
Upłynął limit czasu żądania.
Odpowiedź z 192.168.7.1: bajtów=32 czas<1 ms TTL=64
Odpowiedź z 192.168.7.1: bajtów=32 czas<1 ms TTL=64
Odpowiedź z 192.168.7.1: bajtów=32 czas<1 ms TTL=64
Odpowiedź z 192.168.7.1: bajtów=32 czas<1 ms TTL=64

Statystyka badania ping dla 192.168.7.1:
    Pakiety: Wysłane = 20, Odebrane = 15, Utracone = 5 (25% straty),
Szacunkowy czas błądzenia pakietów w millisekundach:
    Minimum = 0 ms, Maksimum = 0 ms, Czas średni = 0 ms
GeSHi © Codebox Plus
Po wyłączeniu połączenia sieciowego i ponownym włączeniu wszystko wraca do normy i jest ok przez jakiś czas - czasem 2 godziny, czasem 20 minut :?
Ma ktoś jakiś pomysł co się z tym dzieje :?: Połączenia odpadają, od rana przeglądam tylko stronki www.
Autor:  zciech [ sobota, 1 grudnia 2007, 18:23 ]
Tytuł: 
1. napisalem przeciez
2. patrz p.1

sam sobie odpowiedziales:
"mam marne dsl 8mb na które coraz bardziej narzekam"

Mysle ze urzadzenia transmitujace nie zdaja sobie sprawy czy przesylany pakiet nalezy do jakiegos polaczenia a nastepny do tego samego czy i nnego, jest to informacja ktorej nie porzebuja i nie wykorzystuja do niczego.

A ograniczenie moze byc nalozone na predkosc przesylania lub/i ilosc przeslanych pakietow.

Wyglada na to ze masz przeciażona siec wewnetrzna, byc moze uszkodzona karta eth1 w serwerze lub jakis swicz/hub AP po drodze do ciebie.
Autor:  b0dzi0 [ sobota, 1 grudnia 2007, 19:06 ]
Tytuł: 
zciech pisze:
A ograniczenie moze byc nalozone na predkosc przesylania lub/i ilosc przeslanych pakietow.
Może przykład jakiejś regułki :?: wifi mam oparte na mt, więc na nim mogę również wpisać jakieś blokady.
zciech pisze:
Wyglada na to ze masz przeciażona siec wewnetrzna, byc moze uszkodzona karta eth1 w serwerze lub jakis swicz/hub AP po drodze do ciebie.
Trudno mi uwierzyć w przeciążenie sieci, na Lanie mam 6 osób, reszta na wifi. Ale z uszkodzeniem switcha to może być prawda - ostatnio co jakiś czas wyskakuje mi "kabel sieciowy jest odłączony". Swtich to PLANET FSD-1600. Jest możliwość z diagnozowania go czy coś jest nie tak :?:
Autor:  -MW- [ sobota, 1 grudnia 2007, 19:18 ]
Tytuł: 
rownie dobrze do kabla mogla dostac sie woda.
Autor:  rikardo7 [ niedziela, 2 grudnia 2007, 01:26 ]
Tytuł: 
masz 6 osob po lanie reszta to wi-fi,a swich ma 16 portow, przepnij kable w inne porty, moze sie ktorys zablokowal, mam dwa swiche tej firmy tylko ze 24 portowe i w jednym nie dziala mi 1-y port(boze co ja sie nakombinowalem zanim do tego doszedlem!)
Strona 1 z 1 Strefa czasowa UTC+2godz.
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/