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

Hi again,

El 18/07/2014 9:32, Amos Jeffries escribió:
> On 18/07/2014 7:51 p.m., Nicolás wrote:
>> Hi Amos,
>>
>> El 18/07/2014 5:21, Amos Jeffries escribió:
>>> [...]
>> Unfortunately, this one neither seems to make a difference. On the squid
>> box, the squid daemon is run by user proxy so I got the UID and replaced
>> it in the rule you provided:
>>
>> # id proxy
>> uid=13(proxy) gid=13(proxy) groups=13(proxy)
>>
>> So on the client box:
>>
>> iptables -t nat -A OUTPUT --match owner --uid-owner 13 -p tcp
>> --dport 80 -j ACCEPT
>>
>> Then I appended the DNAT rule.
>>
>> However, I should have (re)mentioned it: Additionally to have different
>> public IP addresses, both the client box and the squid box are on
>> different networks (basically the squid box is located in a different
>> country than the client box). Should that make a difference?
> Depends on how the packets get from one country to another. These are
> the fundamental limits on packet handling:
>
> 1) There MUST NOT be any NAT manipulation of the packets destination IP
> prior to their arrival on the Squid machine.
> - However, source-IP:port manipulation as done by gateway machines
> NATing outbound traffic from internal private source-IP to public ranges
> is okay.
>
> 2) a network interface tunnel should not be producing OUTPUT chain
> packets. Traffic arriving through that type of tunnel should be dealt
> with as per packets arriving on a standard NIC.
> - Traffic arriving via application layer gateway (another proxy, or
> userland VPN client) *might* go through the OUTPUT chain and need
> handling as if sourced internally.
>
> 3) if the packets contain HTTP in port-80 syntax the "intercept" or
> "tproxy" option is mandatory which one depending on method of capture.
> - If the packets were destined *to another proxy* Squid does not
> require the "intercept" option to receive.
>
>> Also if you wish, I can run squid with the -N -d options and send you
>> the output log, so you probably will rapidly know what else could be
>> happening there.
> "debug_options 11,2" in squid.conf is going to provide you with a good
> trace to see what is happening. Better than access.log will in these
> circumstances.
>
> Amos
>

I've made a trace to see what's happening and this is the result. I've
removed the duplicate requests for better readability. I've also
obfuscated the IPs to make them match the example above (A.B.C.D ->
client's public IP, E.F.G.H -> server's public IP).

2014/07/18 12:33:05| Starting Squid Cache version 3.3.8 for
x86_64-pc-linux-gnu...
2014/07/18 12:33:27.900| client_side.cc(2316) parseHttpRequest: HTTP
Client local=E.F.G.H:3128 remote=A.B.C.D:54341 FD 8 flags=33
2014/07/18 12:33:27.901| client_side.cc(2317) parseHttpRequest: HTTP
Client REQUEST:
---------
GET / 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: 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:
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

----------
2014/07/18 12:33:27.902| http.cc(2204) sendRequest: HTTP Server
local=E.F.G.H:43140 remote=E.F.G.H:3128 FD 11 flags=1
2014/07/18 12:33:27.902| http.cc(2205) sendRequest: HTTP Server REQUEST:
---------
[Same request with this line added:
Via: 1.1 FQDN (squid/3.3.8)]

----------
2014/07/18 12:33:27.902| client_side.cc(2316) parseHttpRequest: HTTP
Client local=E.F.G.H:3128 remote=E.F.G.H:43140 FD 13 flags=33
2014/07/18 12:33:27.902| client_side.cc(2317) parseHttpRequest: HTTP
Client REQUEST:
---------
[Same request]

----------
2014/07/18 12:33:27.903| client_side.cc(1377) sendStartOfMessage: HTTP
Client local=E.F.G.H:3128 remote=E.F.G.H:43140 FD 13 flags=33
2014/07/18 12:33:27.903| client_side.cc(1378) sendStartOfMessage: HTTP
Client REPLY:
---------
HTTP/1.1 403 Forbidden
Server: squid/3.3.8
Mime-Version: 1.0
Date: Fri, 18 Jul 2014 10:33:27 GMT
Content-Type: text/html
Content-Length: 3932
X-Squid-Error: ERR_ACCESS_DENIED 0
Vary: Accept-Language
Content-Language: es-es
X-Cache: MISS from ovh.devels.es
X-Cache-Lookup: MISS from ovh.devels.es:3127
Via: 1.1 ovh.devels.es (squid/3.3.8)
Connection: keep-alive

----------
2014/07/18 12:33:27.903| ctx: enter level 0: 'http://www.google.es/'
2014/07/18 12:33:27.903| http.cc(761) processReplyHeader: HTTP Server
local=E.F.G.H:43140 remote=E.F.G.H:3128 FD 11 flags=1
2014/07/18 12:33:27.903| http.cc(762) processReplyHeader: HTTP Server
REPLY:
---------
[HTTP error page saying "Access denied"]

 From what I see, squid makes several times requests to itself instead
of redirecting the request outside. Shouldn't there be a rule
redirecting that traffic to the internet? On the server side I have no
such rule right now.
Received on Fri Jul 18 2014 - 11:02:35 MDT