Forum Debian Users Gang

Tak, jeśli chcesz by przepuścił wszystko co zmierza do portów 80,21,22,53,443 TCP/UDP, oraz wszystko inne co nie przekracza ilości połączeń 50 per IP

iptables -L -vn

-n wyłacza rozwiązywanie nazw DNS
-v włącza wyświetlanie licznika

po -L możesz podać nazwę łańcucha, np. iptables -L FORWARD -vn.

Możesz to zrobić jedynie tworząc osobną regułkę dla tego IP.

Pytanie do siarka2107

Na jakim jajku smiga ci niceshaper 0.6 jakie łatki ver. squida, iptables, iproute etc. linki mile widziane

Od kilku ładnych dni walcze z nice0.6 bez powodzenia - efekt ---wszystko działa ok "tylko" ping do bramki podczas ściągania 2000-3000 ms (testy na biurku) - i nie jest to wysycenie łacza etc. na 10000000% - może jakieś pomysły gdzie robię bład - config nice standard - jajko najnowsze wg. linuxbox.pl ......

config.ns

<global>
run squid download upload
mark-on-ifaces eth0 eth1
log syslog true
log terminal true
lang pl
</>

<squid>
iface eth0 match dstip 192.168.2.0/24
#iface eth1 match srcip 192.168.2.1/24
default imq autoredirect false
section speed 2048kb/s
section shape 1900kb/s
default low 8kB/s
default ceil 1500kb/s
default htb prio 5
default hold 600s
default htb scheduler esfq
default esfq hash dst
debug iptables iproute
iptables insert-hook POSTROUTING
reload 1s
</>

<download>
iface imq0 match dstip 192.168.2.0/24
#iface eth1 match dstip 192.168.2.0/24
default imq autoredirect true
section speed 1024kb/s
section shape 900kb/s
default low 8kb/s
default ceil 512kb/s
default htb prio 4
default hold 600s
default htb scheduler esfq
default esfq hash dst
debug iptables iproute
iptables insert-hook POSTROUTING
reload 4s
</>

<upload>
iface imq1 match srcip 192.168.2.0/24
#iface eth0 match srcip 192.168.2.0/24
default imq autoredirect true
section speed 128kb/s
section shape 100kb/s
default low 1kb/s
default ceil 80kb/s
default htb prio 4
default hold 600s
default htb scheduler esfq
default esfq hash src
debug iptables iproute
iptables insert-hook PREROUTING
reload 2s
</>


class.ns

class squid eth0 98
match from localhost srcip 192.168.2.1 dstip 192.168.2.98/24 proto tcp tos 0x8

class download imq0 98
match dstip 192.168.2.98
ceil 512kb/s
class upload imq1 98
match srcip 192.168.2.98
ceil 64kb/s

spróbuj zachaszować

#log syslog true
#log terminal true
#debug iptables iproute

jak ci pingi strasznie skaczą to może wina leży po stronie twojego isp, możesz też dodać do class.ns coś takiego

class download imq0 ssh_www_ping
     match srcip 192.168.2.1 srcport 22 proto tcp dstip 192.168.2.0/24
     match srcip 192.168.2.1 srcport 80 proto tcp dstip 192.168.2.0/24
     match srcip 192.168.2.1 proto icmp dstip 192.168.2.0/24
     rate 512kbit
     wrapper
class upload imq1 ssh_www_ping
     match dstip 192.168.2.1 dstport 22 proto tcp srcip 192.168.2.0/24
     match dstip 192.168.2.1 dstport 80 proto tcp srcip 192.168.2.0/24
     match dstip 192.168.2.1 proto icmp srcip 192.168.2.0/24
     rate 70kbit
     wrapper
#przyjmuje, że 192.168.2.1 to twoja brama

jaka wersja ns dokładnie? grzebałeś coś w źródłach przed kompilacją, mi ns dobrze chodził na każdej wersji jądra (23-26) iptables i iproute

---edit---
jakos 2 razy weszło wykasujcie tego posta jak można, żeby nie zaśmiecał

Ostatnio edytowany przez siarka2107 (2008-09-02 17:35:16)

zastosowałem twoją wskazówkę (+ różne prędkości ) efekt:


Badanie 192.168.2.1 z 32 bajtami danych:
Odpowiedź z 192.168.2.1: bajtów=32 czas=180ms TTL=64
Odpowiedź z 192.168.2.1: bajtów=32 czas=378ms TTL=64
Odpowiedź z 192.168.2.1: bajtów=32 czas=474ms TTL=64
Odpowiedź z 192.168.2.1: bajtów=32 czas=834ms TTL=64
Odpowiedź z 192.168.2.1: bajtów=32 czas=1142ms TTL=64
Odpowiedź z 192.168.2.1: bajtów=32 czas=1734ms TTL=64
Odpowiedź z 192.168.2.1: bajtów=32 czas=1965ms TTL=64
Upłynął limit czasu żądania.
Odpowiedź z 192.168.2.1: bajtów=32 czas=375ms TTL=64
Odpowiedź z 192.168.2.1: bajtów=32 czas=375ms TTL=64
Odpowiedź z 192.168.2.1: bajtów=32 czas=199ms TTL=64
Odpowiedź z 192.168.2.1: bajtów=32 czas=534ms TTL=64
Odpowiedź z 192.168.2.1: bajtów=32 czas=1060ms TTL=64
Odpowiedź z 192.168.2.1: bajtów=32 czas=2169ms TTL=64
Odpowiedź z 192.168.2.1: bajtów=32 czas=1630ms TTL=64
Odpowiedź z 192.168.2.1: bajtów=32 czas=2144ms TTL=64
Odpowiedź z 192.168.2.1: bajtów=32 czas=2018ms TTL=64

Po wczorajszym dniu zmagań z moim serwerkiem dochodze do wniosku, że wina będzie leżeć po stronie squida - bez przekierowania na squida pingi są ok - z przekierowaniem tak jak wyżej - tragedia

Co do wskazówki że LMS gryzie sie z niceshaperem (jak to wybadać) - w LMS generuję skrypty do maskarady+limity połaczeń+kontrola ip-mac+przekierowanie na squida - jeśli ktoś zechce rzucić na to okiem moge powrzucać konfigi !?

Witam. Wiem, ze o tym już było, ale problemu niestety nie rozwiązałem - iptables 1.4 , kernel 2.6.24 + p-o-m . Wszystkie łaty nałożone niestety iptables -m ipp2p -h zwraca : iptables v1.4.0: Couldn't load match `ipp2p':(null) . Kernel przekompilowany ( ipt_ipp2p zaladowany bez problemu). Google niestety nie rozwiązało mojego problemu. Z góry dzięki za pomoc.

Dzieki za szybka odpowiedz. Troche jeszcze posiedzialem nad p-o-m'em i wyglada na to ,ze niestety w moim przypadku patch ipp2p zaimplementowana dzieki niemu nie spisuje sie tak jak powinien. Zadzialala dopiero taka konfiguracja - zrodla ipp2p + patch zaczerpniety stad (
wget http://sources.gentoo.org/viewcvs.py/*checkout*/gen … -2.6.22.patch oraz wget http://sources.gentoo.org/viewcvs.py/*checkout*/gen … s-1.4.0.patch
- moze komus jeszcze sie przyda ) i wszystko dziala . Jeszcze raz dzieki i pozdrawiam