El 16/07/2014 12:31, Amos Jeffries escribió:
On 16/07/2014 9:23 a.m., Nicolás wrote:
Thanks! That would indeed cover the first issue :-) I initially used
redirect because somewhere I read that it's not a good idea forwarding
the traffic directly to the port where squid listens and it should be
pointed to another port instead and then redirected.
Sounds like you read one of my explanations and did not quite get it.
Hope this helps clarfy:
That is all true regarding *intercepted* port 80 traffic. The traffic
which is actually destined to a webserver directly.
For traffic such as your testing with (CONNECT etc) on non-80 ports the
traffic is destined to a proxy. So the NAT IP addressing does not matter
and the security checks on the interception do more harm than good.
This is why you should keep the ports separate. Because the traffic on
port 80 and the traffic destined to a proxy are quite different beasts.
Ok, now it's crystal clear. However, trying to reproduce the
configuration on the link that babajaga proposed, I get a loop on the
squid side on any link opened from the client side. On the client side,
I just added the OUTPUT DNAT iptables rule to make it match the 3128 IP
and port of the remote server. On the server side there are not iptables
rules, just the -j ACCEPT policy for the 3128 port, which is the
intercept port.
2014/07/15 23:09:46| WARNING: Forwarding loop detected for:
GET /favicon.ico HTTP/1.1
Host: www.google.es
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
Firefox/24.0
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Cookie:
PREF=ID=119a6e25e6eccb3b:U=95e37afd611b606e:FF=0:TM=1404500940:LM=1404513627:S=r7E-Xed2muOOp-ay;
NID=67=M5geOtyDtp5evLidOfam1uzfhl6likehxjXo7KcamK8c5jXptfx9zJc-5L7jhvYvnfTvtXYJ3yza7cE8fRq2x0iyVEHN9Pn2hz9urrC_Qt_xNH6IQCoT-3-eXTwb2h4f;
OGPC=5-25:
Via: 1.1 homeSecureProxy (squid/3.3.8)
X-Forwarded-For: 77.231.176.236
Cache-Control: max-age=259200
Connection: keep-alive
1405462555.918 0 SERVER-IP TCP_MISS/403 4285 GET http://google.es/
- HIER_NONE/- text/html
1405462555.918 1 CLIENT-IP TCP_MISS/403 4404 GET http://google.es/
- HIER_DIRECT/CLIENT-IP text/html
I just replaced the "SERVER-IP" and "CLIENT-IP" IPs.
Is there any extra rules necessary on the server side to make the
intercept mechanism work? I tried debugging it with tcpdump but I can't
see anything strange.
Thanks.
However, working as
this, it would be enough to set a firewall policy to permit just the
client range of IPs. Let's see whether I can solve the second issue too...
Yes, if I am understanding you that firewall policy should be needed
regardless of whether you are dealing with explicitly configured clients
or intercepting the port 80 traffic.
Amos
