Ok, I'll try to explain the scenario again and more detailed (I remark
that I'm using this guide which states that it should work for public IP
addresses: http://wiki.squid-cache.org/ConfigExamples/Intercept/AtSource):
Client side: Has public IP address A.B.C.D
Server side: Has public IP address E.F.G.H
On the client side, I added the following iptables rule:
iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT
--to-destination E.F.G.H:3128
On the server side, I just opened up the port 3128, this is the only one
rule:
iptables -I INPUT -s eth0 --dport 3128 -j ACCEPT
On the server side, there's a squid3 running with the default package
configuration, just two lines changing (though the 3127 port has nothing
to do with this example):
http_port 3128 intercept
http_port 0.0.0.0:3127
So, when I do a HTTP connection attempt on the client side, it is indeed
successfully redirected to E.F.G.H but the loop occours with these two
events in the log:
cache.log:
2014/07/17 21:05:02| WARNING: Forwarding loop detected for:
GET / HTTP/1.1
Host: google.es
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
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:
Pragma: no-cache
Via: 1.1 homeSecureProxy (squid/3.3.8)
X-Forwarded-For: A.B.C.D
Cache-Control: no-cache
Connection: keep-alive
access.log:
1405623902.957 0 A.B.C.D TCP_MISS/403 4300 GET
http://google.es/ - HIER_NONE/- text/html
1405623902.958 1 A.B.C.D TCP_MISS/403 4419 GET
http://google.es/ - HIER_DIRECT/E.F.G.H text/html
I also tried using a VPN connection between both the client and the
server, the result is exactly the same (just the public IPs change by
the VPN's private, obviously).
I hope I explained it better now, hope someone can help because this is
really driving me nuts :-(
Thanks.
El 17/07/2014 14:45, Eliezer Croitoru escribió:
> On 07/17/2014 08:47 AM, Nicolás wrote:
>> Hi Eliezer,
>>
>> This would be the output of your script. This is not CentOS so some
>> things have failed... and I just obscurated the public IP related data.
>> I tried adding the rule you proposed (as you may see in the output), but
>> unfortunately it made no difference, I'm still having the redirect loop.
> I am yet not able to understand how do you use the proxy and how do
> you connect to it.
> The only way you can connect to your server is but I assume it will be
> a tunnel\vpn connection.
>
> How do you want to use your proxy?
> It will be much simpler to understand the circumstances to the loop
> rather then the loop itself (for me).
>
> I think that we are missing something important in everything.
> Can you just run "curl -I http://www.google.com" from command line?
> (and couple other addresses you are having issues with).
>
> Eliezer
Received on Thu Jul 17 2014 - 19:25:01 MDT
This archive was generated by hypermail 2.2.0 : Fri Jul 18 2014 - 12:00:04 MDT