On 2013-06-01 2:51, Amos Jeffries wrote:
On 1/06/2013 6:13 p.m., Rob Sheldon wrote:
Can you explain a little more about "non-intercept traffic" vs.
"intercept traffic"? I thought the only difference was whether the
browser sent an absolute URL in the GET request ("non-intercept") or a
pathname + "Host:" header in the GET request ("intercept"). Am I
missing something?
That is pretty much the HTTP level difference. However the TCP/IP
level also has its own differences. When acccept() happens PF hands
Squid its own listening IP:port details on direct traffic, and the
clients original IP:port details on intercepted traffic.
That difference affects the Squid security systems which for
intercept ports check those IP:port against the HTTP level Host:
header detail of the clients destination. If they match Squid can use
DNS to try and locate better origin servers. If they dont match Squid
does the safe things and transparently relays it to that same IP:port
the client was apparently contacting. So if you configure a browser to
use a intercept port directly the IP:port received will be Squid's
ones, the security checks guaranteed to fail, and a loop begins as
Squid contacts itself.
OK, that makes sense, thanks.
Hmmm ... but, I'm pretty sure that rdr-to rewrites the destination
address in the packet. From http://www.openbsd.org/faq/pf/rdr.html: "The
redirection rule does apply and the destination address gets replaced
with that of the internal server."
So an rdr-to rule should cause Squid to be seeing itself as the
destination address...
If you set debug_options 11,2 you can get IP:port details on each
connection Squid is using to correlate with those traces and see if
anything unexpected is showing up.
Thanks! This is something I've been looking for. (I did find
http://wiki.squid-cache.org/KnowledgeBase/DebugSections but couldn't
quickly make heads or tails out of it.)
Here's where the loop is happening (192.168.10.164 is the test
machine):
2013/06/01 03:02:20.447| src/client_side.cc(2298) parseHttpRequest:
HTTP Client local=192.168.0.1:3129 remote=192.168.10.164:36365 FD 9
flags=33
2013/06/01 03:02:20.447| src/client_side.cc(2299) parseHttpRequest:
HTTP Client REQUEST:
---------
GET / HTTP/1.0^M
Host: www.associatedtechs.com^M
^M
----------
2013/06/01 03:02:22.586| src/http.cc(2177) sendRequest: HTTP Server
local=192.168.0.1:25276 remote=192.168.0.1:3129 FD 12 flags=1
...That sort of does look to me like Squid's confused about the
destination address.
Here's the rest of that log up until the forwarding loop warning:
2013/06/01 03:02:22.587| src/http.cc(2178) sendRequest: HTTP Server
REQUEST:
---------
GET / HTTP/1.1^M
Host: www.associatedtechs.com^M
Via: 1.0 firewall.local (squid/3.2.7)^M
X-Forwarded-For: 192.168.10.164^M
Cache-Control: max-age=259200^M
Connection: keep-alive^M
^M
----------
2013/06/01 03:02:22.587| src/client_side.cc(2298) parseHttpRequest:
HTTP Client local=192.168.0.1:3129 remote=192.168.0.1:25276 FD 13
flags=33
2013/06/01 03:02:22.587| src/client_side.cc(2299) parseHttpRequest:
HTTP Client REQUEST:
---------
GET / HTTP/1.1^M
Host: www.associatedtechs.com^M
Via: 1.0 firewall.local (squid/3.2.7)^M
X-Forwarded-For: 192.168.10.164^M
Cache-Control: max-age=259200^M
Connection: keep-alive^M
^M
----------
2013/06/01 03:02:22.587| WARNING: Forwarding loop detected for:...
- R.
--
[__ Robert Sheldon
[__ No Problem
[__ Information technology support and services
[__ (530) 575-0278
