Freesco, NND, CDN, EOS

czy komus po zainstalowaniu squida wysiadlo zliczanie ruchu dla bałwan jestem w mrtg? co sie moze gryzc?
niceshaper dziala poprawnie ale w statystykach pokazuje download na zero, upload jest ok.

a moze ktos ma jakies sugestie co do kolejnosci instalowania pakietow?
i kolejnowsci ich uruchamiania przy starcie systemu

winna jest bałwan jestem przekierowujaca pakiety z portu 80 na 8080

przynajmiej w przypadku niceshapera i mrtg chyba tez

iptables -t nat -A PREROUTING -p tcp -i eth1 --dport 80 -j REDIRECT --to-port 8080

Winny jest zazwyczaj skrypt zliczajacy ruch, ktory liczy tylko na forwardzie trzeba dodac tez na input, output.

dzieki za podpowiedz

mam rozumiec ze w pliku /etc/rc.d/mrtg w linii 46 wpis
iptables -I FORWARD -j mrtg_traffic
kieruje pakiety do zliczania ruchu i za
ta linia nalezy dodac

iptables -I INPUT -j mrtg_traffic
iptables -I OUTPUT -j mrtg_traffic

narazie nie tesuje bo nie mam czasu, ale wieczorem sprawdze

nie podwoi to wynikow?

ja mam ten sam problem mrtg nie nie pokazuje mi statystyk jak komputer bałwan jestem ze squida dopisałem do pliku /etc/rc.d/mrtg wpis
iptables -I FORWARD -j mrtg_traffic
iptables -I INPUT -j mrtg_traffic
iptables -I OUTPUT -j mrtg_traffic
i pokuzeju mi tylko łaczne bałwan jestem szystkich użytkowników na wykresach ip serwera a na klijenckich nic nie ma chyba że nie bałwan jestem z proxy

ja dodale tylko w INPUT i OUTPUT bo w FORWARD juz jest
i to zadzialalo.
Ruch jest liczony dla IP ale tylko ten faktyczny z netu i do netu,jesli pobierane sa dane juz z cechowane to nie uwzglednia ruchu.

Jesli przegladarka jest skonfigurowana dla proxy to niceshaper nie ogranicza transferow pomiedzy hostem a routerem, a jesli pozostawimy ja nie skonfigurowana to wowczas niceshaper tnie rowniez dane pobierane z proxy - ale to juz kazdy wykozysta na swoj uzytek.

posiadam łacze satelitarne i u mnie cały ruch idzie przez squida da się coś takiego zrobić żeby mrtg uwzględniał ruch z niego pochodzący ??

no i nie moge pogodzic niceshapera ze squidem.
przekierowanie polaczenia z portu 80 na 8080 powoduje ze niceshaper
nie wyswietla donload'u, caly czas stoi 0 chociaz upload pokazuje ok.
samo przycinanie lacza zdaje sie dzialac prawidlowo, lecz nie jest tak dokladne jak przy wylaczonym proxy, faworyzuje niektorych bałwan jestem (raz jednych raz drugich).
ma ktos jakis pomysl?

To nie jest problem squida - w nice jest wpis
do not shape local 192.168.1.1 with 192.168.1.0/24
i to on jest temu winny - nice całkowicie pomija lokalne połączenia - a po zainstalowaniu squida - wszystko idzie przez niego czyli eth0->eth1 więc nie ma shape'u i tu jest problem - sam nad tym pracuję

pieprzone #

jesze raz ponowie pytanie bo nie uzyskałem nna nie odpowiedzi czy da się tak skonfigurować mrtg aby zliczał ruch pochodzący od squida a jezeli mrtg tego nie potrafi to może jakieś onne statystyki

a u mnie to dziala i to idealnie.
na wykresie interfejsu zewnetrznego odklada sie caly ruch do netu, na wewnetrznego do netu + squid
indywidualnie terz pokazuje userow.

dodalem w pliku mrtg powyzsze wpisy i linie do usuwania bałwan jestem przy stopie i restarcie mrtg.

ale w niceshapetrze trzeba zaplotkowac linie zezwalajace na nieblokowany ruch z routera do sieci wewnetrznej.

#do not shape......
#do not shape......

l dlatego pewnie nie liczy ruchu hostow ( a moze sie myle)
ja mialem tak problemy

nic nie pomaga mrtg liczy ruch ze squida tylko na IP serwera a na IP klijenta wykazuje tylko ten ruch ktory nie idzie przez squida może jakaś reguła iptables żeby liczyła ruch na porcie squida 3128 może to pomoże
pomużcie bo już nie mam sił

witam,
u mnie jest podobnie, squid + transparent proxy i zadna z powyzszych metod nie skutkuje...

Dołączam sie do prośby, znalazł ktoś z Was skuteczne rozwiązanie?

_________________
intel D201GLY2A, nano-ITX, celeron220 1,2GHz, load average: 0.25, 0.21, 0.21, 2GB DDR2, 320HDD SATA

Cześć

Miałem ten sam problem. Mam squid transparent + niceshaper +mrtg. W nsstat.txt zmieniał mi się tylko upload, a download stał ja wryty na 0. Reguły (z wcześniejszych postów) INPUT i OUTPUT nic nie dają. Tak jak mówi -MW- należy "zahaszować" w configu nieceshapera linijkę:

do not shape local 192.168.1.1 with 192.168.1.0/24

Wtedy wszystko będzie ok. I hope:)

Za to mam inny problem i proszę o pomoc. Mrtg nie zlicza mi ruchu userów. Wszystkie pozostałe są, a wykresy z IP userów cały czas świecą pustką. (mrtg odpalone jest raz i wpisane na końcu daemonów).

Pozdrawiam.

U mnie rowniez nie zlicza dobrze ruchu dla konkretnego IP - po wylaczeniu przekierowania ruchu na port squida mrtg dziala dobrze. NND z lipca W /etc/rc.d/mrtg mam juz wpisy :

iptables -I FORWARD -j mrtg_traffic 2>/dev/null
iptables -I INPUT -j mrtg_traffic 2>/dev/null
iptables -I OUTPUT -j mrtg_traffic 2>/dev/null

Byly tam od poczatku - nic nie dodawalem

_________________
.:: Każdy zaczynał od lamera ::.

_________________
Nie jestem NEKROMANTĄ, nie wróżę z flaków!
Alkohol pity z umiarem nie szkodzi nawet w największych ilościach!
Przeczytaj nim zapytasz

[root@S3_Porabka scyhe]# iptables -L INPUT -nv
Chain INPUT (policy DROP 7197 packets, 625K bytes)
pkts bytes target prot opt in out source destination
3108K 2692M mrtg_traffic all -- * * 0.0.0.0/0 0.0.0.0/0
2988 770K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
1030 50368 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 135,445
9 540 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:113 reject-with icmp-port-unreachable
56 3136 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1080 reject-with icmp-port-unreachable
19531 2202K ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
7193 649K ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8283
3 152 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:21
0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:20
9816 787K ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8 limit: avg 1/sec burst 5
3323K 201M ACCEPT all -- !eth0 * 0.0.0.0/0 0.0.0.0/0
5013K 7024M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED

----------------------------------------
iptables -L FORWARD -nv
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
175K 24M mrtg_traffic all -- * * 0.0.0.0/0 0.0.0.0/0
181K 80M DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ipp2p v0.8.0 --ipp2p
0 0 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 135,445
805K 75M ACCEPT all -- !eth0 * 0.0.0.0/0 0.0.0.0/0
512K 209M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 REJECT tcp -- * eth0 10.0.0.0/8 0.0.0.0/0 #conn/32 > 100 reject-with tcp-reset
0 0 ACCEPT tcp -- * * 0.0.0.0/0 10.0.100.16 tcp dpt:50016
0 0 ACCEPT udp -- * * 0.0.0.0/0 10.0.100.16 udp dpt:60016
0 0 ACCEPT tcp -- * * 0.0.0.0/0 10.0.100.1 tcp dpt:50001
0 0 ACCEPT udp -- * * 0.0.0.0/0 10.0.100.1 udp dpt:60001

------------------------------------------

iptables -L OUTPUT -nv
Chain OUTPUT (policy ACCEPT 8777K packets, 7243M bytes)
pkts bytes target prot opt in out source destination
3370K 2712M mrtg_traffic all -- * * 0.0.0.0/0 0.0.0.0/0

-------------------------------------------
iptables -L mrtg_traffic -nv
Chain mrtg_traffic (3 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- * * 0.0.0.0/0 127.0.0.1
0 0 RETURN all -- * * 127.0.0.1 0.0.0.0/0
1237K 82M RETURN all -- * * 0.0.0.0/0 10.0.0.1
1884K 2605M RETURN all -- * * 10.0.0.1 0.0.0.0/0
0 0 RETURN all -- * * 0.0.0.0/0 10.0.100.16
0 0 RETURN all -- * * 10.0.100.16 0.0.0.0/0

bylo tego wiecej w lancuchu ale mysle ze dalej to nie istotne...
Troche sie rozni od tego co podal Zciech ale dalej nie wiem co z tym jest

_________________
.:: Każdy zaczynał od lamera ::.