Re: [squid-users] Re: server failover/backup

On 21/08/2014 5:33 a.m., nuhll wrote:
> Some Logs:

These logs are showing a problem...

> ==> /var/log/squid3/cache.log <==
> 2014/08/20 19:33:19.809 kid1| client_side.cc(777) swanSong:
> local=192.168.0.1:3128 remote=192.168.0.125:62595 flags=1
> 2014/08/20 19:33:20.227 kid1| client_side.cc(777) swanSong:
> local=192.168.0.1:3128 remote=192.168.0.125:62378 flags=1
> 2014/08/20 19:33:20.232 kid1| client_side.cc(900) deferRecipientForLater:
> clientSocketRecipient: Deferring request
> http://llnw.blizzard.com/hs-pod/beta/EU/4944.direct/Updates/hs-6187-6284-Win_deDE-final.MPQ
> 2014/08/20 19:33:20.232 kid1| client_side.cc(1518)
> ClientSocketContextPushDeferredIfNeeded: local=192.168.0.1:3128
> remote=192.168.0.125:62611 FD 29 flags=1 Sending next

This appears to be a client (192.168.0.125) connecting to what it thinks
is a regular forward-proxy port:
  http_port 3128
or
  http_port 192.168.0.1:3128

> 2014/08/20 19:33:20.235 kid1| client_side.cc(777) swanSong:
> local=192.168.0.1:3128 remote=192.168.0.125:62611 flags=1
> 2014/08/20 19:33:20.638 kid1| client_side.cc(777) swanSong:
> local=192.168.0.1:3128 remote=192.168.0.125:62669 flags=1
>
> ==> /var/log/squid3/access.log <==
> 1408555999.808 10552 192.168.0.125 TCP_MISS/503 3899 GET
> http://dist.blizzard.com.edgesuite.net/hs-pod/beta/EU/4944.direct/Updates/hs-6187-6284-Win-final.MPQ
> - HIER_DIRECT/192.168.0.4 text/html
> 1408556000.232 9976 192.168.0.125 TCP_MISS/503 3844 GET
> http://llnw.blizzard.com/hs-pod/beta/EU/4944.direct/Updates/hs-6187-6284-Win-final.MPQ
> - HIER_DIRECT/192.168.0.4 text/html
> 1408556000.232 9975 192.168.0.125 TCP_MISS/503 3803 GET
> http://llnw.blizzard.com/hs-pod/beta/EU/4944.direct/Updates/hs-6187-6284-Win_deDE-final.MPQ
> - HIER_DIRECT/192.168.0.4 text/html

This above shows Squid receiving various requests for blizzard.com
domains and relaying them to the web server at 192.168.0.4.

Do you actually have a blizzard.com web server running at 192.168.0.4 ?
 I dont think so.

> 1408556000.638 406 192.168.0.125 TCP_MISS/200 1642 CONNECT
> dws1.etoro.com:443 - HIER_DIRECT/149.126.77.194 -
>

It seems to me that you are mixing the HTTP traffic modes up.

Squid accepts traffic with two very different on-wire syntax formats,
and also with possibly mangled TCP packet details. These combine into 3
perutatiosn we call traffic "modes".

1) forward-proxy (aka manual or auto-configured explicit proxy)
  - port 3128 traffic syntax designed for proxy communication. Nothing
special needed to service the traffic.

2) reverse-proxy (aka accelerator / CDN gateway)
  - port 80 traffic syntax designed for web server communication.
Message URLs need reconstructing and an origin cache_peer server is
expected to be explicitly configured.

3) interception proxy (aka transparent proxy)
  - port 80 traffic syntax and also possible TCP/IP mangling of the
packet IPs. Any mangling needs to be detected and undone, input
validation security checks applied, then the reverse-proxy URL
manipulations performed.
  NP: if the security checks fail caching will be disabled for request,
but it will still be serviced as a transparent MISS.
  NP2: if the security checks fail and the TCP packet details are broken
you will get 503 exactly as logged above.

What you need to do for a properly working proxy is ensure that:
* each mode of traffic is sent to a separate http_port opened by Squid.
 - you may use multiple port directives as long as each has a unique
port number.
* each http_port directive is flagged as appropriate to indicate the
traffic mode being received there.

From the logs above it looks to me like you are possibly intercepting
the blizzard traffic and NAT'ing it to a forward-proxy port 3128.

You probably need to actually configure this to get rid of the 503s:

 http_port 3128
 http_port 3129 intercept

and change your NAT rules to -j REDIRECT packets to port 3129. Leave
your DHCP rules sending traffic to port 3128.

Amos
Received on Wed Aug 20 2014 - 22:23:46 MDT