Re: [squid-users] Re: Three questions about Squid configuration

Sorry, I forgot to add: curl -I http://www.google.com run from the...

Client side:

     HTTP/1.1 403 Forbidden
     Server: squid/3.3.8
     Mime-Version: 1.0
     Date: Thu, 17 Jul 2014 19:26:15 GMT
     Content-Type: text/html
     Content-Length: 3402
     X-Squid-Error: ERR_ACCESS_DENIED 0
     Vary: Accept-Language
     Content-Language: en
     X-Cache: MISS from homeSecureProxy
     X-Cache-Lookup: MISS from homeSecureProxy:3127
     X-Cache: MISS from homeSecureProxy
     X-Cache-Lookup: MISS from homeSecureProxy:3127
     Via: 1.1 homeSecureProxy (squid/3.3.8), 1.1 homeSecureProxy
(squid/3.3.8)
     Connection: keep-alive

Server side:

     HTTP/1.1 302 Found
     Cache-Control: private
     Content-Type: text/html; charset=UTF-8
     Location: http://www.google.es/?gfe_rd=cr&ei=JyPIU6btLsPl-garw4DQCw
     Content-Length: 258
     Date: Thu, 17 Jul 2014 19:25:27 GMT
     Server: GFE/2.0
     Alternate-Protocol: 80:quic

El 17/07/2014 20:25, Nicolás escribió:
> 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:28:37 MDT