From: "Edmund Turner" <eturner@monash.edu.my>
To: lartc@vger.kernel.org
Subject: RE: [LARTC] New member
Date: Tue, 04 Nov 2003 03:54:34 +0000 [thread overview]
Message-ID: <marc-lartc-106791907104251@msgid-missing> (raw)
In-Reply-To: <marc-lartc-106784862220876@msgid-missing>
Cillie, take this setup for example:
Web server IP = 192.168.1.2
1MB access to the internet.
Etho -LAN
Eth2 - External --1MB access to the internet.
tc qdisc add dev eth2 root handle 3: htb default 10
tc class add dev eth2 parent 3: classid 3:1 htb rate 1mbit
tc class add dev eth2 parent 3:1 classid 3:12 htb rate 400kbit ceil
400kbit prio 4
tc filter add dev eth2 parent 3:0 protocol ip prio 4 u32 match ip src
192.168.1.2 classid 3:12
I manage to limit all outbound traffic from 192.168.1.2 by putting a
filter for the src address of the web server on the external NIC. This
seems to work for me.
Regards
edmund
-----Original Message-----
From: ph4ke [mailto:deff@sadomain.co.za]
Sent: Monday, November 03, 2003 9:14 PM
To: eturner@monash.edu.my
Cc: lartc@mailman.ds9a.nl
Subject: Re: [LARTC] New member
Hi Edmund
OK, sorry 'bout that.
Say for example that I have a webserver and I only want that thing to
push
512kbit out. The only way that I see that I would be able to limit this
kind
of outbound traffic with the tc classifier is if I knew which ip's will
be
visiting web-pages. If this was the situation I would be able to have a
long
list of rules that all look something like
.. u32 match ip src xxx.xxx.xxx.xx flowid 1:1
or something
Unfortunately there is about a few million possible ipv4 addresses that
can
access the box if they really felt like it.
This could problem could possibly be solved by having a rule like this :
.. u32 match ip sport 80 match ip src (webserver) flowid
whatever
But the real problem lies in limiting ftp, since ftp (at least the way i
thought it works. could be wrong. probably am)
just does the whole auth section on sport 20/21 and
the data transfer actually take place on a random 1024+ source port
and a random 1024+ destination port.
This would be perfectly solved with iptables marking because one
should be able to do something like
--append PREROUTING -m state --state ESTABLISHED, RELATED --jump MARK
--set mark 1 { please excuse the line wrapping }
thanks a lot for your time
cilliè
On Monday 03 November 2003 10:35, you wrote:
> Cillie,
> I might be missing something here, but I do use this filter setup for
> limiting outbound http and ftp traffic.
>
>
> Regards
> edmund
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
prev parent reply other threads:[~2003-11-04 3:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-03 8:37 [LARTC] New member ph4ke
2003-11-03 10:29 ` ph4ke
2003-11-03 10:35 ` Edmund Turner
2003-11-03 11:17 ` ph4ke
2003-11-04 3:54 ` Edmund Turner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-lartc-106791907104251@msgid-missing \
--to=eturner@monash.edu.my \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox