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
