On 06/07/07 04:18, Ian Moyce wrote:
I am trying to combine a load of ip rules, but I am having problems
fathoming it out.
I run a VPS with openVPN. I have the following rules:
iptables -t nat -A POSTROUTING -s 192.168.2.3 -j SNAT --to 85.234.144.236
iptables -t nat -A POSTROUTING -s 192.168.2.4 -j SNAT --to 85.234.144.236
iptables -t nat -A POSTROUTING -s 192.168.2.5 -j SNAT --to 85.234.144.236
iptables -t nat -A POSTROUTING -s 192.168.2.6 -j SNAT --to 85.234.144.236
iptables -t nat -A POSTROUTING -s 192.168.2.7 -j SNAT --to 85.234.144.236
iptables -t nat -A POSTROUTING -s 192.168.2.8 -j SNAT --to 85.234.144.236
iptables -t nat -A POSTROUTING -s 192.168.2.9 -j SNAT --to 85.234.144.236
iptables -t nat -A POSTROUTING -s 192.168.2.10 -j SNAT --to 85.234.144.236
I'm not sure why you would be wanting to SNAT 8 systems to the same IP, but
hey, it's your script. The rules them selves look good enough.
Which works great. However, I am wanting to pass any IP traffic from
the 192.168.2.x range to be passed through a socks proxy on a specific
port, which I have been told can work with:
(Comments in line below)
#!/bin/sh
LOCAL_NET=192.168.2.0/24
/sbin/iptables -F
/sbin/iptables -t nat -F
/sbin/iptables -P INPUT ACCEPT
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT DROP
A default of DROP in the OUTPUT can catch you on a LOT of things.
/sbin/iptables -t nat -P OUTPUT ACCEPT
/sbin/iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to-destination
127.0.0.1:5353
/sbin/iptables -t nat -A OUTPUT -o lo -j RETURN
/sbin/iptables -t nat -A OUTPUT -d 127.0.0.1 -j RETURN
/sbin/iptables -t nat -A OUTPUT -d $LOCAL_NET -j RETURN
/sbin/iptables -t nat -A OUTPUT -m owner --uid-owner 103 -j RETURN
/sbin/iptables -t nat -A OUTPUT -p tcp --syn -j DNAT --to-destination
127.0.0.1:1211
So you are wanting to block all outbound traffic except for the following
conditions:
- Loop back traffic
- Local host network traffic
- Local network traffic
- Any thing sent by uid 103
Is this really what you are wanting to do?
Loop back and local host network are really about the same unless you have
other subnets bound to your loop back interface or for some strange reason the
127.0.0.0/8 subnet bound to something other than loop back.
It looks like you are using a local DNS (proxy?) server and redirecting any DNS
queries to it.
Then there is the main critter where you are redirecting any new TCP traffic to
a service on the local host. I'm not quite sure what will happen to the
destination IP and port of the request traffic. I'm afraid that they will be
translated to be the local host and port you are DNATing to, not the original
destination. If the original destination is lost, how is your proxy going to
work? I guess I should as, are you trying to transparent proxy or are you
really telling your client systems that they are using a proxy?
/sbin/iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -j ACCEPT
/sbin/iptables -A OUTPUT -d 127.0.0.1 -j ACCEPT
/sbin/iptables -A OUTPUT -d $LOCAL_NET -j ACCEPT
/sbin/iptables -A OUTPUT -m owner --uid-owner 103 -j ACCEPT
/sbin/iptables -A OUTPUT -j LOG
/sbin/iptables -A OUTPUT -j REJECT
Again, you are wanting to block all outbound traffic except for the following
conditions:
- Loop back traffic
- Local host network traffic
- Local network traffic
- Any thing sent by uid 103
Any thing that is not allowed out is logged and rejected.
The state rule is the normal short cut to by pass the rules for previously seen
traffic.
As an aside: Why are you filtering in your nat table? Filtering really is
better done in the filter table.
If someone is able to help me figure this out, I am offering a
reward of £50 (about $100) as it is driving me insane!!!
I don't see any thing to out standing other than the fact, which may be my
unfamiliarity with Socks, that any traffic not explicitly allowed TCP traffic
is being redirected in to one port on the system. I'm not sure that this will
work. However like I have said, I do not use Socks so I am not familiar with
it. To me, when you are DNATing to the local port, you are going to loose your
destination IP and port. Thus, how will your service know where to send the
traffic to unless there is some sort of indicator in what is coming in to the
service. If there is data coming in to the service telling it where to connect
to, then you have obviously configured the clients to talk to the service. If
you have configured the client to talk to the service, why are you having to
redirect the traffic? Why did you not configure the client to talk directly to
the correct port of the service?
It almost sounds like you are wanting to do transparent proxy with Squid.
Squid is an entirely different prosy than Socks. Socks (to my knowledge) is a
system for a client to request that an intermediary (bastion) host make the
connection on the client's behalf. With Socks, the client passes information
on where it wants to connect to the Socks proxy.
Squid transparent proxy on the other hand is entirely different. Squid is
primarily used to proxy HTTP / HTTPS requests on behalf of clients. Part of
the HTTP protocol is the information that you are trying to request. I.e. you
pass what host (name) and item that you want. Squid can interpret these
requests and make the appropriate connection on your behalf. Or, you can do
the standard thing and configure Squid as a standard proxy and just point the
clients to it and it will behave more like a Socks proxy where the client tells
Squid what it wants and Squid then goes and gets it.
Incidentally, setting Squid up as a transparent proxy and redirecting any and
all HTTP traffic in to it is not difficult and can be done in a very similar
manner (as far as the redirects on the router).
Digest this and let me know if you have any more questions.
Grant. . . .
|