On 31/08/2012 11:57 p.m., Pawel Mojski wrote:
W dniu 31-Aug-12 03:41, Amos Jeffries pisze:
[...]
Pawl started his problem description with "on the gateway". Which is
a phrase usually only used by people with separate gateway and Squid
devices. Meaning he very probably is doing NAT on packets outdside of
the Squid box - the #1 side effect of doing things that way is the
SYN packet problem he described.
NAT creates a lie in the packet headers. The gateway box is lying to
Squid box about where the packets are destined. Squid now operates
transparently (when possible) "believes" that lie and sends the
request there, just like any bridge or switch would if the proxy were
turned off.
Thanks Amos for detailed answer.
Because I want to make my squid public avaible over internet (with
auth ofcourse) I have to allow other users to create:
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to
my.public.ip.address:8081 on their own routers, I have no other
way then proxy chaining squid3.1->squid3.2.
So you want to create what the security industry calls an "open proxy"?
That is what NAT on external devices does. Anybody anywhere in the world
can NAT packets into your proxy and Squid will log that they are coming
from inside your Squid-3.1 box, you have zero control and zero protection.
You can use tunnels (VPN, GRE, IP-over-IP tunnels) to pass the packets
from the remote routers to yours without loosing the IP details. If they
are doing it for privacy SNAT is acceptible to hide the client details,
all that Squid requires is accurate destination details.
Amos
