Freesco, NND, CDN, EOS

http://www.freesco.pl
Dzisiaj jest piątek, 11 lipca 2025, 22:47

Strefa czasowa UTC+2godz.




Nowy temat Odpowiedz w temacie  [ Posty: 20 ] 
Autor Wiadomość
Post: poniedziałek, 18 października 2004, 01:54 
Offline
Użytkownik

Rejestracja: niedziela, 23 maja 2004, 22:03
Posty: 128
Lokalizacja: Radom
Witam...

w logach mam takie INFO

Oct 17 10:19:38 kernel: NET: 70 messages suppressed.
Oct 17 10:19:38 kernel: ip_conntrack: table full, dropping packet.
Oct 17 10:19:43 kernel: NET: 68 messages suppressed.
Oct 17 10:19:43 kernel: ip_conntrack: table full, dropping packet.
Oct 17 10:19:48 kernel: NET: 78 messages suppressed.
Oct 17 10:19:48 kernel: ip_conntrack: table full, dropping packet.

i jak pinguje wtenczas do serwera to gubi mi pakiety .
Rozwiązanie znalazłem na GOOGle
http://www.linuxfan.pl/dyskusje/pcol.20 ... 10249.php3
ale jak wpisałem w ip_conntrack_max (zwiększyłem ilość do 65535 ) to po restarcie miąłem tyle samo co przed zmianą ( 4096 ) .


1. A pytanie mam takie , jak zrobić żeby pozostała ta ilość co wpisałem . To polecenie nie zadziałało echo "65535" > /proc/sys/net/ipv4/ip_conntrack_max jak i bezpośrednia zmian przy użyciu MC w pliku ip_conntrack_max . Po restarcie serwa mam z powrotem 4096

2. Czy jest ( na pewno ) plik taki jak ip_conntrack_proto_tcp.c aby było morza ustawić ilość (czas podtrzymania połączeń ) DNI , bo standardowo przechowuje otwarte połączenia przez 5 dni a kciał bym skrócić je do 1 godziny.

3.Wiem że to jest połowiczne rozwiązanie ( zwiększenia limitu dla ip_conntrack_max z 4096 na 65535 )
Mam zablokowane porty blastera i takich tam innych gu** [typu iptables -I FORWARD -p tcp -d 0/0 -m multiport --dport 135,137,138,139,445,1025,2745,3127,4751,5000,6129,6346,17300 -j DROP] (chodzi mi tu o wirusy)

4.Teraz mam 64 mb ramu na serwie czy pomorze mu to jak dołorze więcej .

5.W ipfwadm jest taka komenda co to załatwiała (ipfwadm -M -s 7200 10 600 # Timeouts TCP, after TCP, UDP ) czy jest cos podobnego w IPTABLES ( skracała czasy dla połączeń )


dZIEKi...


Na górę
 Wyświetl profil  
 
 Tytuł:
Post: poniedziałek, 18 października 2004, 05:22 
Offline
Użytkownik

Rejestracja: niedziela, 23 maja 2004, 22:03
Posty: 128
Lokalizacja: Radom
Witam ...

Co do 4 pytania to już znalazłem odpowiedz

ip_conntrack_max
64mb -- 4096
192mb -- 12288

tylko teraz się nasuwa jedno pytanie jak zrobić więcej bez dodawania PAMIECI na przykład 65535 to z prostej kalkulacji wynika rze musiał bym włożyć 1024mb ( a jak pisałem w innym poście NND nie widzi WIECEJ nisz 800mb [ http://forum.freesco.pl/viewtopic.php?t=5240&highlight= ]

6. A wiec jak można zrobić więcej bez zwiększania pamięci..

dZIEKi...


Na górę
 Wyświetl profil  
 
 Tytuł:
Post: poniedziałek, 18 października 2004, 05:53 
Offline
PGF

Rejestracja: niedziela, 14 lipca 2002, 14:33
Posty: 3234
Lokalizacja: Radziejów
echo "65535" > /proc/sys/net/ipv4/ip_conntrack_max

wpisz do /etc/rc.d/rc.firewall

zainstaluj "moje" statystyki tam zobaczysz kto generuje taki ruch.

Serwer reliserv.pl z ponad setka userow maksymalnie mial ok 3000 polaczen.
Musisz sprawdzic kto i czym tak sieje.

Jesli Ci brakuje polaczen to nie dlatego ze sa zadlugo przechowywane. w miare potrezby "stare" nieczynne polaczenia sa kasowane. Widocznie wszystkie masz czynne.
Obrazek


Na górę
 Wyświetl profil  
 
 Tytuł:
Post: wtorek, 19 października 2004, 01:16 
Offline
Użytkownik

Rejestracja: niedziela, 23 maja 2004, 22:03
Posty: 128
Lokalizacja: Radom
Witam...

A wiec tak
Co to
1. OKI wpisałem
2. Co do 2 pytania nie wiesz morze gdzie to morza zmniejszyć ( morze to cos DA )
3. HY 5 pytanie gdzieś to kiedyś widziałem a teraz nie mogę znaleźć ( zawsze tak jest :# )
4. PO wpisaniu w FIREWALA polecenia [echo "65535" > /proc/sys/net/ipv4/ip_conntrack_max
zaznaczam rze w tym monecie mam jusz 192mb ramu ] już o godzinie 22:58:10 pokazały się następne LOGI z BLEDEM w tablicy kernela
Oct 18 22:58:10 kernel: Neighbour table overflow.
Oct 18 22:58:10 kernel: MASQUERADE: No route: Rusty's brain broke!
Oct 18 22:58:10 kernel: Neighbour table overflow.
Oct 18 22:58:10 kernel: MASQUERADE: No route: Rusty's brain broke!
Oct 18 22:58:10 kernel: Neighbour table overflow.
Oct 18 22:58:10 kernel: MASQUERADE: No route: Rusty's brain broke!
Oct 18 22:58:11 kernel: Neighbour table overflow.
Oct 18 22:58:11 kernel: MASQUERADE: No route: Rusty's brain broke!
Oct 18 22:58:11 kernel: Neighbour table overflow.
Oct 18 22:58:11 kernel: MASQUERADE: No route: Rusty's brain broke!
Oct 18 22:58:16 kernel: NET: 96 messages suppressed.
Oct 18 22:58:16 kernel: Neighbour table overflow.
Oct 18 22:58:21 kernel: NET: 97 messages suppressed.
Oct 18 22:58:21 kernel: Neighbour table overflow.
Oct 18 22:58:25 kernel: NET: 97 messages suppressed.
Oct 18 22:58:25 kernel: Neighbour table overflow.
Oct 18 22:58:42 kernel: NET: 29 messages suppressed.
Oct 18 22:58:42 kernel: Neighbour table overflow.
Oct 18 22:58:42 kernel: MASQUERADE: No route: Rusty's brain broke!
Oct 18 22:58:42 kernel: Neighbour table overflow.
Oct 18 22:58:50 kernel: NET: 5 messages suppressed.
Oct 18 22:58:50 kernel: Neighbour table overflow.
Oct 18 22:58:50 kernel: MASQUERADE: No route: Rusty's brain broke!
Co prawda trochę się różnią od tamtych ale tym bardziej mnie martwią ( bo nie tłumaczy tablicy maskowania <- czy cos takiego )
Moje tłumaczenie to [Neighbour table overflow]<=>[otoczenie tablicy przepełnione] , [MASQUERADE: No route: Rusty's brain broke!]<=>[w Maskaradzie :Nie zostalo zrutowane z powodu ?? ZARDZEWIENIA zepsutego umyslu ?? ] , [NET: 29 messages suppressed]<=>[Wiadomość stłumiona ]
MAM nadzieje rze w miarę dobrze to przetłumaczyłem ale i tak nie mam pojęcia jak ten problem rozwiązać .
Jeszcze bym zmniejszył te czasy ale nie mogę tego znaleźć.

5. Co do statystyk to zainstalowałem te http://reliserv.pl/nnd/statystyka.tgz. ( bez HTB wychaszowane ) w rc.stat ( ale z tego co widziałem nie ma nic wspólnego z http://192.168.0.1:82/ilosc.html ) a tam cos niezabardzo mi to działa NA dole pokazuje

Log polaczen ponad 2500: /var/log/maskarada .

(ale już to sobie zrobię ) .Jeszcze spróbuje te statystyki http://nnd.freesco.pl/download/pakiety/ ... -beta3.tgz

dZIEKi...
ps .
napewno ktos sieje :(


Na górę
 Wyświetl profil  
 
 Tytuł:
Post: wtorek, 19 października 2004, 10:40 
Offline
PGF

Rejestracja: niedziela, 14 lipca 2002, 14:33
Posty: 3234
Lokalizacja: Radziejów
cat /proc/net/ip_conntrack >plik
a potem zobacz w plik:
: [/] [] ()
tcp      6 180946 ESTABLISHED src=81.101.126.126 dst=83.26.242.36 sport=3586 dport=6881 src=10.3.51.11 dst=81.101.126.126 sport=6881 dport=3586 [ASSURED] use=1 bytes=658125
tcp      6 45865 ESTABLISHED src=80.53.162.70 dst=83.26.231.218 sport=24619 dport=6881 src=10.3.51.11 dst=80.53.162.70 sport=6881 dport=24619 [ASSURED] use=1 bytes=108557
tcp      6 18359 ESTABLISHED src=24.11.202.173 dst=83.26.254.92 sport=62718 dport=6881 src=10.3.51.11 dst=24.11.202.173 sport=6881 dport=62718 [ASSURED] use=1 bytes=206103
tcp      6 40198 ESTABLISHED src=80.53.162.70 dst=83.26.231.218 sport=24851 dport=6881 src=10.3.51.11 dst=80.53.162.70 sport=6881 dport=24851 [ASSURED] use=1 bytes=158487
tcp      6 250115 ESTABLISHED src=212.33.91.100 dst=83.26.230.28 sport=1804 dport=6881 src=10.3.51.11 dst=212.33.91.100 sport=6881 dport=1804 [ASSURED] use=1 bytes=604863
tcp      6 14674 ESTABLISHED src=80.55.88.122 dst=83.26.254.92 sport=4096 dport=6881 src=10.3.51.11 dst=80.55.88.122 sport=6881 dport=4096 [ASSURED] use=1 bytes=72602


Zapewne bardzo szybko zobaczysz sprawce :))

Ale wyzej masz tabelke z iloscia polaczen:

Statystyka ilosci polaczen

Godzina: 10:43

IP RAZEM TCP TCP ESTABLISHED UDP
Pierwszy 6 5 0 1
Drugi 2 2 2 0
Trzeci 1 1 1 0
Log polaczen ponad 2500: /var/log/maskarada
version 0.2-04.09.16 <Zciech> <http://reliserv.pl/nnd>


Na górę
 Wyświetl profil  
 
 Tytuł:
Post: wtorek, 19 października 2004, 12:20 
Offline
MODERATOR

Rejestracja: poniedziałek, 29 lipca 2002, 15:45
Posty: 1385
Lokalizacja: Polska
NertoM pisze:
Witam...
Oct 18 22:58:10 kernel: Neighbour table overflow.


Heh.. to już przećwiczyłem.
Ja miałem przypadkiem wpisany jako brame WŁASNY interfejs zew.

Np. do internetu 195....1 i w bramie to samo 195.....1.

Po ustawieniu bramy było ok!

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


Na górę
 Wyświetl profil  
 
 Tytuł:
Post: niedziela, 31 października 2004, 11:04 
Offline
Użytkownik

Rejestracja: niedziela, 27 czerwca 2004, 11:45
Posty: 317
Witam,

Ostatnio okazało się że ja mam tak samo: table full
Znalazłem winowajcę - jeden użytkownik ma już na wstępie ok.200 połączeń /samych ESTABLISHED/ :x o ile bym to przeżył to po jakimś czasie zwiększa się: 300... 400... 500... ostatnią wartością jaką zapisałem było ponad 800 /więcej nie sprawdzałem bo staty tak obciążały mi serwer że musiałem je wyłączyć/
Dla wnikliwych kawałek z /proc/net/ip_conntrack:
Cytuj:
tcp 6 82 SYN_SENT src=192.168.0.11 dst=81.50.184.81 sport=2589 dport=12889 [UNREPLIED] src=81.50.184.81 dst=83.17.23.114 sport=12889 dport=2589 use=1 bytes=144
tcp 6 96 SYN_SENT src=192.168.0.11 dst=82.168.94.252 sport=3324 dport=8954 [UNREPLIED] src=82.168.94.252 dst=83.17.23.114 sport=8954 dport=3324 use=1 bytes=48
tcp 6 101 SYN_SENT src=192.168.0.8 dst=62.143.17.190 sport=3837 dport=6346 [UNREPLIED] src=62.143.17.190 dst=83.17.23.114 sport=6346 dport=3837 use=1 bytes=156
tcp 6 100 SYN_SENT src=192.168.0.11 dst=80.125.73.40 sport=3333 dport=22892 [UNREPLIED] src=80.125.73.40 dst=83.17.23.114 sport=22892 dport=3333 use=1 bytes=144
tcp 6 60 SYN_SENT src=192.168.0.11 dst=80.140.151.105 sport=3304 dport=6881 [UNREPLIED] src=80.140.151.105 dst=83.17.23.114 sport=6881 dport=3304 use=1 bytes=144
tcp 6 49 TIME_WAIT src=192.168.0.11 dst=217.75.120.114 sport=2567 dport=80 src=217.75.120.114 dst=83.17.23.114 sport=80 dport=2567 [ASSURED] use=1 bytes=1400
tcp 6 30 TIME_WAIT src=192.168.0.11 dst=216.66.19.138 sport=2545 dport=80 src=216.66.19.138 dst=83.17.23.114 sport=80 dport=2545 [ASSURED] use=1 bytes=1403
tcp 6 41 TIME_WAIT src=192.168.0.11 dst=172.202.83.36 sport=2498 dport=6881 src=172.202.83.36 dst=83.17.23.114 sport=6881 dport=2498 [ASSURED] use=1 bytes=788
tcp 6 431990 ESTABLISHED src=192.168.0.11 dst=24.103.94.9 sport=2603 dport=6881 src=24.103.94.9 dst=83.17.23.114 sport=6881 dport=2603 [ASSURED] use=1 bytes=1353
tcp 6 86 SYN_SENT src=192.168.0.8 dst=24.166.4.138 sport=3828 dport=6346 [UNREPLIED] src=24.166.4.138 dst=83.17.23.114 sport=6346 dport=3828 use=1 bytes=156
tcp 6 431944 ESTABLISHED src=192.168.0.11 dst=62.142.182.142 sport=2571 dport=6898 src=62.142.182.142 dst=83.17.23.114 sport=6898 dport=2571 [ASSURED] use=1 bytes=965
tcp 6 431966 ESTABLISHED src=192.168.0.11 dst=64.230.120.59 sport=2555 dport=50200 src=64.230.120.59 dst=83.17.23.114 sport=50200 dport=2555 [ASSURED] use=1 bytes=1325
tcp 6 91 TIME_WAIT src=80.55.117.218 dst=83.17.23.114 sport=1234 dport=80 src=83.17.23.114 dst=80.55.117.218 sport=80 dport=1234 [ASSURED] use=1 bytes=2984
udp 17 179 src=192.168.0.11 dst=168.226.129.145 sport=12926 dport=12218 src=168.226.129.145 dst=83.17.23.114 sport=12218 dport=12926 [ASSURED] use=7 bytes=349234
tcp 6 431980 ESTABLISHED src=192.168.0.11 dst=141.224.236.8 sport=2770 dport=6881 src=141.224.236.8 dst=83.17.23.114 sport=6881 dport=2770 [ASSURED] use=1 bytes=760590
tcp 6 117 SYN_SENT src=192.168.0.8 dst=195.218.109.30 sport=3845 dport=11621 [UNREPLIED] src=195.218.109.30 dst=83.17.23.114 sport=11621 dport=3845 use=1 bytes=156
udp 17 179 src=192.168.0.11 dst=217.42.11.103 sport=12402 dport=55459 src=217.42.11.103 dst=83.17.23.114 sport=55459 dport=12402 [ASSURED] use=5 bytes=11331191
tcp 6 48 TIME_WAIT src=192.168.0.11 dst=81.64.177.22 sport=3291 dport=6882 src=81.64.177.22 dst=83.17.23.114 sport=6882 dport=3291 [ASSURED] use=1 bytes=814
tcp 6 2 SYN_SENT src=192.168.0.11 dst=24.25.205.93 sport=2519 dport=6881 [UNREPLIED] src=24.25.205.93 dst=83.17.23.114 sport=6881 dport=2519 use=1 bytes=144
tcp 6 5 SYN_SENT src=192.168.0.11 dst=62.195.49.216 sport=2523 dport=6882 [UNREPLIED] src=62.195.49.216 dst=83.17.23.114 sport=6882 dport=2523 use=1 bytes=144
tcp 6 431995 ESTABLISHED src=192.168.0.11 dst=213.46.17.202 sport=3137 dport=22942 src=213.46.17.202 dst=83.17.23.114 sport=22942 dport=3137 [ASSURED] use=2 bytes=225135
tcp 6 66 TIME_WAIT src=192.168.0.11 dst=82.74.56.51 sport=2561 dport=6881 src=82.74.56.51 dst=83.17.23.114 sport=6881 dport=2561 [ASSURED] use=1 bytes=700
tcp 6 117 SYN_SENT src=192.168.0.11 dst=66.198.41.17 sport=2614 dport=13543 [UNREPLIED] src=66.198.41.17 dst=83.17.23.114 sport=13543 dport=2614 use=2 bytes=144
tcp 6 118 TIME_WAIT src=192.168.0.11 dst=83.28.143.254 sport=2613 dport=6881 src=83.28.143.254 dst=83.17.23.114 sport=6881 dport=2613 [ASSURED] use=1 bytes=552
tcp 6 38 TIME_WAIT src=192.168.0.11 dst=194.236.63.180 sport=3276 dport=9379 src=194.236.63.180 dst=83.17.23.114 sport=9379 dport=3276 [ASSURED] use=1 bytes=492
tcp 6 11 TIME_WAIT src=192.168.0.11 dst=69.11.110.147 sport=2520 dport=6881 src=69.11.110.147 dst=83.17.23.114 sport=6881 dport=2520 [ASSURED] use=1 bytes=740
udp 17 179 src=192.168.0.11 dst=195.210.223.161 sport=12402 dport=33279 src=195.210.223.161 dst=83.17.23.114 sport=33279 dport=12402 [ASSURED] use=10 bytes=581204
tcp 6 47 SYN_SENT src=192.168.0.11 dst=210.0.200.240 sport=3292 dport=7842 [UNREPLIED] src=210.0.200.240 dst=83.17.23.114 sport=7842 dport=3292 use=1 bytes=144
tcp 6 431962 ESTABLISHED src=192.168.0.11 dst=68.150.60.43 sport=2370 dport=6881 src=68.150.60.43 dst=83.17.23.114 sport=6881 dport=2370 [ASSURED] use=1 bytes=1770
tcp 6 431992 ESTABLISHED src=192.168.0.10 dst=163.121.131.55 sport=4004 dport=6881 src=163.121.131.55 dst=83.17.23.114 sport=6881 dport=4004 [ASSURED] use=1 bytes=220811
udp 17 8 src=192.168.0.11 dst=131.107.1.10 sport=27981 dport=123 src=131.107.1.10 dst=83.17.23.114 sport=123 dport=27981 use=1 bytes=152
tcp 6 47 SYN_SENT src=192.168.0.11 dst=83.72.54.64 sport=2559 dport=15824 [UNREPLIED] src=83.72.54.64 dst=83.17.23.114 sport=15824 dport=2559 use=1 bytes=96
tcp 6 431983 ESTABLISHED src=192.168.0.11 dst=69.157.191.226 sport=2262 dport=6881 src=69.157.191.226 dst=83.17.23.114 sport=6881 dport=2262 [ASSURED] use=1 bytes=220700
tcp 6 431982 ESTABLISHED src=192.168.0.11 dst=217.255.63.56 sport=2833 dport=6881 src=217.255.63.56 dst=83.17.23.114 sport=6881 dport=2833 [ASSURED] use=1 bytes=156429
tcp 6 431990 ESTABLISHED src=192.168.0.11 dst=80.0.13.76 sport=2307 dport=6881 src=80.0.13.76 dst=83.17.23.114 sport=6881 dport=2307 use=1 bytes=416206
tcp 6 431999 ESTABLISHED src=192.168.0.11 dst=217.153.145.235 sport=3355 dport=80 src=217.153.145.235 dst=83.17.23.114 sport=80 dport=3355 [ASSURED] use=1 bytes=37041
tcp 6 73 SYN_SENT src=192.168.0.8 dst=213.54.15.66 sport=3821 dport=13643 [UNREPLIED] src=213.54.15.66 dst=83.17.23.114 sport=13643 dport=3821 use=1 bytes=156
tcp 6 103 TIME_WAIT src=192.168.0.11 dst=80.142.99.105 sport=2570 dport=6882 src=80.142.99.105 dst=83.17.23.114 sport=6882 dport=2570 [ASSURED] use=1 bytes=1069
tcp 6 431988 ESTABLISHED src=192.168.0.11 dst=81.79.36.28 sport=2271 dport=6881 src=81.79.36.28 dst=83.17.23.114 sport=6881 dport=2271 [ASSURED] use=1 bytes=139065
tcp 6 79 SYN_SENT src=192.168.0.11 dst=68.232.84.108 sport=2584 dport=6910 [UNREPLIED] src=68.232.84.108 dst=83.17.23.114 sport=6910 dport=2584 use=1 bytes=144
tcp 6 52 SYN_SENT src=192.168.0.8 dst=217.226.159.105 sport=3810 dport=1163 [UNREPLIED] src=217.226.159.105 dst=83.17.23.114 sport=1163 dport=3810 use=1 bytes=156
udp 17 146 src=192.168.0.11 dst=84.9.22.145 sport=12402 dport=11268 src=84.9.22.145 dst=83.17.23.114 sport=11268 dport=12402 [ASSURED] use=1 bytes=8365
tcp 6 431976 ESTABLISHED src=192.168.0.11 dst=200.104.86.143 sport=3321 dport=6882 src=200.104.86.143 dst=83.17.23.114 sport=6882 dport=3321 [ASSURED] use=1 bytes=1223
tcp 6 111 TIME_WAIT src=192.168.0.11 dst=194.249.24.253 sport=2583 dport=6881 src=194.249.24.253 dst=83.17.23.114 sport=6881 dport=2583 [ASSURED] use=1 bytes=592
tcp 6 61 SYN_SENT src=192.168.0.11 dst=213.23.36.251 sport=2572 dport=6887 [UNREPLIED] src=213.23.36.251 dst=83.17.23.114 sport=6887 dport=2572 use=1 bytes=144
tcp 6 100 SYN_SENT src=192.168.0.8 dst=68.215.114.62 sport=3836 dport=6346 [UNREPLIED] src=68.215.114.62 dst=83.17.23.114 sport=6346 dport=3836 use=1 bytes=156
tcp 6 431899 ESTABLISHED src=192.168.0.11 dst=66.74.228.221 sport=2534 dport=6881 src=66.74.228.221 dst=83.17.23.114 sport=6881 dport=2534 [ASSURED] use=1 bytes=1969
tcp 6 431977 ESTABLISHED src=192.168.0.11 dst=217.255.116.189 sport=2769 dport=3881 src=217.255.116.189 dst=83.17.23.114 sport=3881 dport=2769 [ASSURED] use=1 bytes=38519
tcp 6 89 SYN_SENT src=192.168.0.11 dst=80.125.73.40 sport=3318 dport=22892 [UNREPLIED] src=80.125.73.40 dst=83.17.23.114 sport=22892 dport=3318 use=1 bytes=144
tcp 6 431956 ESTABLISHED src=192.168.0.11 dst=70.24.23.197 sport=2269 dport=24825 src=70.24.23.197 dst=83.17.23.114 sport=24825 dport=2269 [ASSURED] use=1 bytes=218228
tcp 6 431873 ESTABLISHED src=192.168.0.11 dst=217.187.155.250 sport=2777 dport=10025 src=217.187.155.250 dst=83.17.23.114 sport=10025 dport=2777 [ASSURED] use=1 bytes=2069
tcp 6 431994 ESTABLISHED src=192.168.0.10 dst=218.79.99.142 sport=3360 dport=8881 src=218.79.99.142 dst=83.17.23.114 sport=8881 dport=3360 use=4 bytes=1761255
tcp 6 431970 ESTABLISHED src=192.168.0.11 dst=80.167.220.105 sport=2449 dport=6881 src=80.167.220.105 dst=83.17.23.114 sport=6881 dport=2449 [ASSURED] use=1 bytes=1817
tcp 6 431986 ESTABLISHED src=192.168.0.11 dst=207.192.199.11 sport=3005 dport=6881 src=207.192.199.11 dst=83.17.23.114 sport=6881 dport=3005 [ASSURED] use=1 bytes=92977
tcp 6 55 TIME_WAIT src=192.168.0.11 dst=68.105.129.115 sport=3299 dport=6881 src=68.105.129.115 dst=83.17.23.114 sport=6881 dport=3299 [ASSURED] use=1 bytes=532
tcp 6 35 SYN_SENT src=192.168.0.11 dst=217.75.120.114 sport=2544 dport=80 [UNREPLIED] src=217.75.120.114 dst=83.17.23.114 sport=80 dport=2544 use=1 bytes=144
tcp 6 25 TIME_WAIT src=192.168.0.11 dst=217.153.145.234 sport=3267 dport=80 src=217.153.145.234 dst=83.17.23.114 sport=80 dport=3267 [ASSURED] use=1 bytes=3848
tcp 6 431888 ESTABLISHED src=192.168.0.11 dst=213.39.163.116 sport=2174 dport=6882 src=213.39.163.116 dst=83.17.23.114 sport=6882 dport=2174 [ASSURED] use=1 bytes=3935
tcp 6 431996 ESTABLISHED src=192.168.0.11 dst=193.158.161.66 sport=4845 dport=1214 src=193.158.161.66 dst=83.17.23.114 sport=1214 dport=4845 use=1 bytes=251239
tcp 6 431998 ESTABLISHED src=192.168.0.11 dst=82.161.96.202 sport=2619 dport=6881 src=82.161.96.202 dst=83.17.23.114 sport=6881 dport=2619 [ASSURED] use=2 bytes=380
tcp 6 431983 ESTABLISHED src=192.168.0.11 dst=219.74.100.145 sport=2207 dport=6886 src=219.74.100.145 dst=83.17.23.114 sport=6886 dport=2207 [ASSURED] use=1 bytes=271589
tcp 6 115 SYN_SENT src=192.168.0.8 dst=24.223.233.225 sport=3841 dport=6346 [UNREPLIED] src=24.223.233.225 dst=83.17.23.114 sport=6346 dport=3841 use=1 bytes=156
tcp 6 431999 ESTABLISHED src=192.168.0.11 dst=83.27.152.158 sport=2601 dport=6881 src=83.27.152.158 dst=83.17.23.114 sport=6881 dport=2601 [ASSURED] use=4 bytes=4957
tcp 6 2 SYN_SENT src=192.168.0.8 dst=217.121.248.210 sport=3785 dport=11411 [UNREPLIED] src=217.121.248.210 dst=83.17.23.114 sport=11411 dport=3785 use=1 bytes=156
tcp 6 33 SYN_SENT src=192.168.0.8 dst=65.95.163.39 sport=3800 dport=6346 [UNREPLIED] src=65.95.163.39 dst=83.17.23.114 sport=6346 dport=3800 use=1 bytes=156
tcp 6 431998 ESTABLISHED src=192.168.0.11 dst=193.77.113.160 sport=2274 dport=6881 src=193.77.113.160 dst=83.17.23.114 sport=6881 dport=2274 [ASSURED] use=1 bytes=55845
tcp 6 117 SYN_SENT src=192.168.0.8 dst=209.121.37.122 sport=3844 dport=6346 [UNREPLIED] src=209.121.37.122 dst=83.17.23.114 sport=6346 dport=3844 use=1 bytes=156
tcp 6 82 SYN_SENT src=192.168.0.11 dst=24.112.128.74 sport=2588 dport=43385 [UNREPLIED] src=24.112.128.74 dst=83.17.23.114 sport=43385 dport=2588 use=1 bytes=144

z tego co zauważyłem to głównie używa Emule, Torrenta /czasem też Kazaa i pewnie inne p2p/...
Chciałbym się dowiedzieć jak sobie radzicie z takimi userami? Ja myślałem o zmniejszeniu połączeń dla tego usera, ale jak to jest w praktyce? daje spodziewane efekty? Czy może lepsze by było echo "65535" > /proc/sys/net/ipv4/ip_conntrack_max ?


Na górę
 Wyświetl profil  
 
 Tytuł:
Post: niedziela, 31 października 2004, 23:42 
Offline
Użytkownik

Rejestracja: niedziela, 23 listopada 2003, 22:05
Posty: 344
Daj connlimit'a na iptables i bedzie spokoj. Problem byl juz na forum.


Na górę
 Wyświetl profil  
 
 Tytuł:
Post: poniedziałek, 1 listopada 2004, 13:28 
Offline
Użytkownik

Rejestracja: niedziela, 27 czerwca 2004, 11:45
Posty: 317
Wiem że był, ale niestety nie wszystkim to działało :(
ja próbowałem takich regułek:
nakpierw iptables -I FORWARD -s $IP -p tcp -m connlimit --connlimit-above 100 -j DROP
nie zadziałało więc dałem:
iptables -I FORWARD -p tcp -o eth0 --dport 1024:65535 -m connlimit --connlimit-above 50 --connlimit-mask 32 -j REJECT --reject-with tcp-reset
i nie wiedzieć czemu też nie działa. A Tobie prg080 podobno działa ta druga? A może źle ma to związek z momentem w którym się uruchamia :?: czy uruchomienie którejś z regułek podczas pracy serwera powinno dać rezultaty czy musi być to przy starcie?


Na górę
 Wyświetl profil  
 
 Tytuł:
Post: poniedziałek, 1 listopada 2004, 18:19 
Offline
Użytkownik

Rejestracja: niedziela, 23 listopada 2003, 22:05
Posty: 344
Ja mam ta ostatnia i dziala. Trzeba oczywiscie zwrocic uwage w ktorym miejscu siedzi ta regulka w lancuchu iptables. Moze masz cos wczesniej co ja omija.

Dopisane: U mnie siedzi na samym poczatku lancucha FORWARD.


Na górę
 Wyświetl profil  
 
 Tytuł:
Post: poniedziałek, 1 listopada 2004, 23:16 
Offline
Użytkownik

Rejestracja: czwartek, 29 kwietnia 2004, 14:13
Posty: 205
Lokalizacja: B-st
limit limitem ale powiedzcie dlaczego NND utrzymuje tą uzyskana ilość połączeń nawet po wyłączeniu torenta w statystykach MRTG

_________________
Jarek


Na górę
 Wyświetl profil  
 
 Tytuł:
Post: poniedziałek, 1 listopada 2004, 23:44 
Offline
Użytkownik

Rejestracja: niedziela, 27 czerwca 2004, 11:45
Posty: 317
prg080 pisze:
Ja mam ta ostatnia i dziala. Trzeba oczywiscie zwrocic uwage w ktorym miejscu siedzi ta regulka w lancuchu iptables. Moze masz cos wczesniej co ja omija.

Dopisane: U mnie siedzi na samym poczatku lancucha FORWARD.

Chyba u mnie /pewnie tak jak u niektórych/ jest ten problem. A czy mógłbyś napisać dokładnie jak masz tę regułkę wpisaną /jak dla laika z iptables :) /


Na górę
 Wyświetl profil  
 
 Tytuł:
Post: poniedziałek, 1 listopada 2004, 23:54 
Offline
Użytkownik

Rejestracja: czwartek, 29 kwietnia 2004, 14:13
Posty: 205
Lokalizacja: B-st
WPISZ TU U MNIE DZIAŁA TO OGRANICZENIE
POD KONIEC FREWALA

#limit inaczej zciecha konkretne ip lub wszystkie
#iptables -I FORWARD -s 192.168.0.9/24 -p tcp -m connlimit --connlimit-above
#iptables -I FORWARD -s $IP -p tcp -m connlimit --connlimit-above 100 -j DROP

# Logujemy pakiety ktore nie zostaly zaakceptowane przez
# zadna z powyzszych regulek. Zostana one wyblokowane dzieki
# polityce DROP we wszystkich tablicach
$i -A INPUT -j LOG -m limit --limit 3/hour --log-prefix "INPUT DENY: "
$i -A FORWARD -j LOG -m limit --limit 3/hour --log-prefix "FORWARD DENY: "
echo "Firewall wlaczony... DONE"

_________________
Jarek


Na górę
 Wyświetl profil  
 
 Tytuł:
Post: wtorek, 2 listopada 2004, 00:18 
Offline
Użytkownik

Rejestracja: niedziela, 27 czerwca 2004, 11:45
Posty: 317
jarekjarek... a powiedz mi czy już u Ciebie limituje do takiej wartości jaką masz? bo we wcześniejszych postach w innym topicu pisałeś że nie dokońca ta regułka zdaje egzamin?


Na górę
 Wyświetl profil  
 
 Tytuł:
Post: wtorek, 2 listopada 2004, 00:21 
Offline
Użytkownik

Rejestracja: czwartek, 29 kwietnia 2004, 14:13
Posty: 205
Lokalizacja: B-st
ta dzieki za przypomnienie limituje x7 tak było jak gostek miał Blastera jak widzisz teraz mam zachaszowane te regułki zobacz sam najwyzej daj 7 razy mniej

_________________
Jarek


Na górę
 Wyświetl profil  
 
 Tytuł:
Post: piątek, 5 listopada 2004, 13:37 
Offline
Użytkownik

Rejestracja: niedziela, 27 czerwca 2004, 11:45
Posty: 317
zauważyłem jedną zależność - gdy w firewall`u Zciecha uruchomimy blokadę p2p to wtedy działa regułka:
iptables -I FORWARD -s $IP -p tcp -m connlimit --connlimit-above 100 -j DROP
jeszcze nie sprawdzałem tej drugiej:
iptables -I FORWARD -p tcp -o eth0 --dport 1024:65535 -m connlimit --connlimit-above 50 --connlimit-mask 32 -j REJECT --reject-with tcp-reset
ale być może też będzie działać. Test zrobiłem kiedy blokada p2p była aktywna - niewiem natomiast jak to się ma gdy jest nieaktywna.
Może komuś wpadnie jakiś pomysł do głowy żeby dało się ograniczać ilość połączeń bez blokady p2p :)


Na górę
 Wyświetl profil  
 
 Tytuł:
Post: niedziela, 14 listopada 2004, 13:16 
Offline
Użytkownik

Rejestracja: niedziela, 27 czerwca 2004, 11:45
Posty: 317
A jednak lipa :(
Po wielu dniach testów okazało się że dalej nie blokuje. Sama blokada P2P z firewall`a ZCiecha powodowała wolniejsze przybywanie ilości połączeń a nie jak wcześniej myślałem :/
Zastanawia mnie tylko jedno - jeśli jest ograniczenie P2P to czy nie powinno całkowicie uniemożliwić ustanawianie połączeń czy jak?
Bo mimo blokady - u jednego usera mam około 1000 połączeń /głównie na portach od emule, bittorenta/... co z tym fantem zrobić, bo inaczej czekają mnie resety raz dziennie? jak nie zresetuje to wiadomo co - zapycha się łącze :/
A może jest jakiś sposób na resetowanie połączeń dla danego usera - to by jakoś rozwiązało sprawę tymczasowo?
I jeszcze jedno - próbował ktoś w nowym NND skutecznie ograniczać połączenia?


Na górę
 Wyświetl profil  
 
 Tytuł:
Post: niedziela, 14 listopada 2004, 14:09 
Offline
Użytkownik

Rejestracja: niedziela, 27 czerwca 2004, 11:45
Posty: 317
Mam dobrą wiadomość /a przynajmniej wstępnie dobrze rokuje 8) /
Cytuj:
# ograniczenie polaczen /wersja testowa/ - jak na razie jest OK :)
$i -A FORWARD -p tcp --syn -s 192.168.x.x -m connlimit --connlimit-above 30 -j REJECT
$i -A FORWARD -p tcp --syn -d 192.168.x.x -m connlimit --connlimit-above 30 -j REJECT

i dodałem ją do firewall`a ZCiecha przed:
Cytuj:
# Uzytkownicy wymienieni w /etc/hosts polaczenia dozwolone
# maskarada [ tylko IP z sieci wewnetrznej ]
g

P.S. oczywiscie tam gdzie 192.168.x.x trzeba wpisać konkretne IP /nie próbowałem dla całej sieci, bo... mam tylko jednego takiego usera :)
i nie wychodzi poza limit /60 - czyli po 30 na każdą regułkę/ :)
zapowiada sie że będzie ok, gdyż po usunięciu regułki i restarcie firewall`a od razu połączenia skoczyły do góry.
I jeszcze jedno:po dodaniu regułek restartowałem cały serwer żeby nie mieć poprzednich połączeń.

P.S2. sorry, że tak jeden post pod drugim ale w przypływie radości, że działa chciałem jak najszybicej podzielić się swoimi opiniami :)


Na górę
 Wyświetl profil  
 
 Tytuł:
Post: wtorek, 28 grudnia 2004, 19:49 
Offline
Użytkownik

Rejestracja: niedziela, 23 maja 2004, 22:03
Posty: 128
Lokalizacja: Radom
Witam...


Wiem że był ten temat ale on dotyczył TCP

Nie wiem czemu ale kolesi nieźle zasysa na UDP ma po 2000 ponad połączeń na IP np. ( na początek później mu wzrasta do 6000 )

netstat-nat -n | cat -b
7860 udp 192.168.11.38:11989 194.117.64.39:14877 UNREPLIED
7861 udp 192.168.11.38:11989 82.10.58.23:6532 ASSURED
7862 udp 192.168.11.38:11989 80.191.57.101:6484 ASSURED
7863 udp 192.168.11.38:11989 220.123.4.26:6408 ASSURED
7864 udp 192.168.11.38:11989 24.79.229.211:6496 ASSURED
7865 udp 192.168.11.38:11989 69.193.8.56:10093 ASSURED



9954 udp 192.168.11.38:11989 84.10.6.239:5243 UNREPLIED
9955 udp 192.168.11.38:11989 82.13.158.179:15981 ASSURED
9956 udp 192.168.11.38:11989 80.219.177.117:4835 ASSURED
9957 udp 192.168.11.38:11989 211.41.227.143:18934 ASSURED
9958 udp 192.168.11.38:11989 84.121.200.156:3189 ASSURED
9959 udp 192.168.11.38:11989 65.69.52.107:10688 ASSURED

komenda
iptables -I FORWARD -s $IP -p tcp -m connlimit --connlimit-above 300 -j DROP
jest do tcp i nie wiem jak kolesiowi wyciąć te połączenia

bo w logach ponownie ukazały się błędy typu
kernel: NET: 123 messages suppressed.
kernel: Neighbour table overflow.
kernel: NET: 156 messages suppressed.
kernel: Neighbour table overflow.
kernel: NET: 179 messages suppressed.
Czy też ten błąd dotyczy tylko i wyłącznie połączeń DLA TCP : ? i mam szukać dalej : ?

dZIEKi...
[/list]


Na górę
 Wyświetl profil  
 
 Tytuł:
Post: sobota, 14 maja 2005, 01:17 
Offline
Użytkownik

Rejestracja: niedziela, 27 czerwca 2004, 11:45
Posty: 317
NetroM... udało Ci sie rozwiązać może ten problem? Ja ostatnio mam podpobną sytuację jak Twoja, tzn. na TCP pewna osoba ma 200-300 połączeń, natomiast na UDP w kółko rośnie :evil:


Na górę
 Wyświetl profil  
 
Wyświetl posty nie starsze niż:  Sortuj wg  
Nowy temat Odpowiedz w temacie  [ Posty: 20 ] 

Strefa czasowa UTC+2godz.


Kto jest online

Użytkownicy przeglądający to forum: Obecnie na forum nie ma żadnego zarejestrowanego użytkownika i 6 gości


Nie możesz tworzyć nowych tematów
Nie możesz odpowiadać w tematach
Nie możesz zmieniać swoich postów
Nie możesz usuwać swoich postów
Nie możesz dodawać załączników

Szukaj:
Przejdź do:  
cron
Technologię dostarcza phpBB® Forum Software © phpBB Group
Hosting: Compus-Net
RobertKonik.pl