|
Julian ecrit:
> Don't forget the ICMP traffic related to the allowed TCP connections,
> you have to pass it too (in FORWARD).
oooh, OK. Thanks
Roberto Nibali wrote:
> Correct me if I'm wrong but do you mean a request through the director
> onto the RS initiates a connection from the RS back to the Internet to a
> squid server who then replies to the RS which in turn replies with the
> final response packet to the DGW?
client makes http request to the director, which passes it to the realserver
which is actually a squid. The squid will make connections from RIP to httpds
out
on the internet.
> If my statement above is ok, why would you ever want to set up such a
> strange thing?
that's the way squids work?
As well other clients (eg DNS) on the realservers may need connection
to the internet. I want to have a line in the configure file
which lists the IP:port pairs (eg 0/0:80, x.x.x.x:53)
that clients on the realservers are allowed to connect to.
> Why don't you set the policy for the chains to DROP and simply accept
> the packets you need?
functionally that's what I want to do. Maybe I'm not doing it the
usual way. What I'm now doing is
-A OUTPUT -t mangle mark packet to some IP:port
-A OUTPUT -t mangle mark packet to another IP:port
-A OUTPUT if packet is marked -j RETURN
-A OUTPUT -j DROP
> Why do you need an extra chain? Isn't it enough to simply mark the
> packets or do you have multiple different destinations?
I figured a way not to have an extra chain, but for my first attempt,
I thought I'd send all the packets I wanted to mark to another chain
and mark everything that arrived in the other chain. This way I could
put the rules into the OUTPUT chain without other changes to the OUTPUT
chain and I could have the -j DROP in the other chain.
> > #here packets to 0/0:23 and 0/0:80 are sent to a new chain
> > iptables -A OUTPUT -p tcp -s ${RIP}/32 -d 0/0 --dport telnet -j 3_tier
> > iptables -A OUTPUT -p tcp -s ${RIP}/32 -d 0/0 --dport http -j 3_tier
>
> What about packets that come back? I'm really confused. Don't you need a
> --state RELATED,ESTABLISHED or at least an INPUT chain rule? Or is your
> packetfilter (RS in this case) completely open?
For testing, INPUT is open. I don't know how to do RELATED, ESTABLISHED.
If I can't figure it out from the docs, I'll be posting again ;-)
Joe
--
Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
contractor to the National Environmental Supercomputer Center,
mailto:mack.joseph@xxxxxxx ph# 919-541-0007, RTP, NC, USA
|
