On 17/05/2013 1:04 a.m., jimmah6786 wrote:
I've tried adding
http_port 8080 intercept
http_port 8080 transparent
http_port 8080 tproxy
http_port 8080
I don't understand how squid will ever get the Datagram, because the
packets arrive with a destination IP that is not Squid's...so the upper
layers will never be passed up to Squid.
Ah via the magic of NAT.
You said you have this:
"
Squid IPTABLE
iptables -A PREROUTING -s $SQUID_DMZ_IP -p tcp -m tcp --dport 80 -j ACCEPT
iptables -A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080
iptables -A POSTROUTING -j MASQUERADE
"
The above is all in the "-t nat" table on the Squid box iptables right?
In which case:
... the packets going to 8.8.8.8:80 when they hit the Squid box will
be re-written by NAT REDIRECT rule to point at the Squid box IP and port
8080,
... iptables will then pass the packet to the Squid process (or
whatever is on the port set by REDIRECT),
... Squid using "intercept" option receive them and looks up the NAT
system to find the original 8.8.8.8:80 which is then used inside Squid
as the destination, ignoring whatever the REDIRECT did to the packet.
* response packets from Squid to the client:
... leave Squid with the port 8080 and IP selected by REDIRECT as
source and cleint IP as destination,
... hit the MASQUERADE rule and teh changes done by REDIRECT get reversed,
... making the packet which leaves the box a source 8.8.8.8:80 and
destination of client IP:port.
voila, magic!
When its working correctly you will not see port 8080 or the IP Squid is
listening on (if any). What you will see is details of some client
connecting to 8.8.8.8:80 being handled as if Squid was that 8.8.8.8:80.
And Squid contacting the real 8.8.8.8:80 for any MISS traffic. For this
reason the http_port with "intercept" flags can (and should!) be 100%
blocked by the firewall in the iptables "raw" table to prevent external
traffic sliding into that Squid receiving port without going through
REDIRECT.
Amos
