| Freesco, NND, CDN, EOS http://forum.freesco.pl/ |
|
| ip_conntrack_max i bledy w logach z kernela http://forum.freesco.pl/viewtopic.php?f=22&t=5626 |
Strona 1 z 1 |
| Autor: | NertoM [ poniedziałek, 18 października 2004, 01:54 ] |
| Tytuł: | ip_conntrack_max i bledy w logach z kernela |
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... |
|
| Autor: | NertoM [ poniedziałek, 18 października 2004, 05:22 ] |
| Tytuł: | |
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... |
|
| Autor: | zciech [ poniedziałek, 18 października 2004, 05:53 ] |
| Tytuł: | |
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. 
|
|
| Autor: | NertoM [ wtorek, 19 października 2004, 01:16 ] |
| Tytuł: | |
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 
|
|
| Autor: | zciech [ wtorek, 19 października 2004, 10:40 ] |
| Tytuł: | |
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> |
|
| Autor: | Koriolan [ wtorek, 19 października 2004, 12:20 ] |
| Tytuł: | |
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! |
|
| Autor: | fishu [ niedziela, 31 października 2004, 11:04 ] |
| Tytuł: | |
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/  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 ? |
|
| Autor: | prg080 [ niedziela, 31 października 2004, 23:42 ] |
| Tytuł: | |
Daj connlimit'a na iptables i bedzie spokoj. Problem byl juz na forum. |
|
| Autor: | fishu [ poniedziałek, 1 listopada 2004, 13:28 ] |
| Tytuł: | |
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?
|
|
| Autor: | prg080 [ poniedziałek, 1 listopada 2004, 18:19 ] |
| Tytuł: | |
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. |
|
| Autor: | jarekjarek [ poniedziałek, 1 listopada 2004, 23:16 ] |
| Tytuł: | |
limit limitem ale powiedzcie dlaczego NND utrzymuje tą uzyskana ilość połączeń nawet po wyłączeniu torenta w statystykach MRTG |
|
| Autor: | fishu [ poniedziałek, 1 listopada 2004, 23:44 ] |
| Tytuł: | |
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 /
|
|
| Autor: | jarekjarek [ poniedziałek, 1 listopada 2004, 23:54 ] |
| Tytuł: | |
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" |
|
| Autor: | fishu [ wtorek, 2 listopada 2004, 00:18 ] |
| Tytuł: | |
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? |
|
| Autor: | jarekjarek [ wtorek, 2 listopada 2004, 00:21 ] |
| Tytuł: | |
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 |
|
| Autor: | fishu [ piątek, 5 listopada 2004, 13:37 ] |
| Tytuł: | |
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
|
|
| Autor: | fishu [ niedziela, 14 listopada 2004, 13:16 ] |
| Tytuł: | |
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? |
|
| Autor: | fishu [ niedziela, 14 listopada 2004, 14:09 ] |
| Tytuł: | |
Mam dobrą wiadomość /a przynajmniej wstępnie dobrze rokuje  /
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
|
|
| Autor: | NertoM [ wtorek, 28 grudnia 2004, 19:49 ] |
| Tytuł: | |
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] |
|
| Autor: | fishu [ sobota, 14 maja 2005, 01:17 ] |
| Tytuł: | |
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 
|
|
| Strona 1 z 1 | Strefa czasowa UTC+2godz. |
| Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |
|