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

Hi Eliezer,

El 18/07/2014 15:03, Eliezer Croitoru escribió:
> Hey Nicolas,
>
> Can we change the way we are looking at the subject?
> You first need to figure out the right way to send packets between the
> "client" and the "server".
> After this connection will be intact you will be able to configure the
> other things such as interception the right way.
>
> As a starter since the "server" has a public IP and the "client" has a
> public IP it will be pretty easy to use a simple tunnel such as
> ipip,sit,gre between the client and the server.
> Then on the client side mark and then route traffic from the client to
> the server without any DNAT\REDIRECT rules which is the best way to
> handle this situation.
> In your case TPROXY is not an option since the server cannot use the
> client IP address for public use (probably due to routing policies
> around the globe).
>
> A good place to start is at:
> http://www.linuxfoundation.org/collaborate/workgroups/networking/tunneling
>
> http://tier.cs.berkeley.edu/drupal/howto/ip-tunnel-using-gre-on-linux
>
> The above doesn't give you enough on basic routing which could be very
> simple using "ip rule" and connection marking.
> If you do not have a clue about it I will try to give you a real life
> example I have used in the past to do this trick.
>
> One of the examples I have used gre tunnel is for wccp interception
> which should be similar to your setup but with a public IP addresses
> classes mixed with local ones.
> http://wiki.squid-cache.org/ConfigExamples/UbuntuTproxy4Wccp2
>
> If you want I will be next evening(19 Jul) in the squid irc channel at
> freenode:
> http://webchat.freenode.net/?channels=squid
>
> Eliezer
>

Thanks for the hints! I'm not sure whether I'll be able to try it before
you'll be on the Squid channel, but I'll let you know the results via
the list if not. I certainly have no experience with this subject, but
I'll check the documentation you provided and try to research over the
not detailed things.

However, I've made a much simpler experiment today. I setup a squid box
with the same characteristics as the remote, but inside the same network
as the client, so using private networking, and the result is exactly
the same... a forwarding loop. So having this, I guess I should
partially discard some public ip/different network/different
country/packet modifying issue by now and center on something much
simpler. This is for sure some overlooked detail making it enter the
loop, but I'm stuck at it for several days! I'll keep trying.

Thanks for the help!

> On 07/18/2014 02:02 PM, Nicolás wrote:
>> 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) guid=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 - 16:46:06 MDT