On 10/06/11 21:20, errno wrote:
On Friday, June 10, 2011 12:07:49 AM Amos Jeffries wrote:
On 10/06/11 09:34, errno wrote:
I've got squid conf that looks a bit like the following snippet:
# ...
acl ip-192.168.1.2 myip 192.168.1.2
http_port 192.168.1.2:80 name=ip-192.168.1.2
http_port 192.168.1.2:8080 name=ip-192.168.1.2
tcp_outgoing_address 192.168.1.2 ip-192.168.1
# ...
Question: do those http_port directives need to have
unique 'name=' entries?
unique.
I stand corrected on this. They MAY bet set with matching names.
Or can they all share the
same name? Also - and perhaps more importantly,
is there any similar(ish) problems with the way I've
named the 'myip' acl the same as the http_port names?
myip is at the mercy of the interception lookups.
myportname only depends on what you put in squid.conf and which actual
listening port the traffic arrives on.
Well one thing that occurred is that I at first was using
myportname rather than myip for the acl in question -
but when doing so, all traffic appeared to be comming
from the server's primary ip addr (in this case, 192.168.1.1)
rather than what I intended as specified by tcp_outgoing_address -
in other words, the following (with a bit more config added for
context):
# ...
# 192.168.1.2
acl ip-192.168.1.2 myportname ip-192.168.1.2
http_port 192.168.1.2:80 name=ip-192.168.1.2
http_port 192.168.1.2:8080 name=ip-192.168.1.2
tcp_outgoing_address 192.168.1.2 ip-192.168.1.2
# 192.168.2.2
acl ip-192.168.2.2 myportname ip-192.168.2.2
http_port 192.168.2.2:80 name=ip-192.168.2.2
http_port 192.168.2.2:8080 name=ip-192.168.2.2
tcp_outgoing_address 192.168.2.2 ip-192.168.2.2
# ...
Using the above, tcp_outgoing_address did not work as
expected/intended: using a tool such as http://www.whatismyip.com/ ,
showed 192.168.1.1 in all cases, regardless of which
http_port/myportname the client originated from.
whatismyip.com uses far more than the TCP/IP address to determine what
the IP is.
To accurately judge whether the packet IP is correct you need to check
the packets as they flow. "tcpdump -s 0 -w file" and wireshark to read
the resulting packet dump is the easiest.
Failing that a netstat dump of the TCP connections.
Failing that a cache.log ALL,5 trace has the details buried in it somewhere.
Switching from the above, to:
# ...
# 192.168.1.2
acl ip-192.168.1.2 myip 192.168.1.2
http_port 192.168.1.2:80 name=ip-192.168.1.2
http_port 192.168.1.2:8080 name=ip-192.168.1.2
tcp_outgoing_address 192.168.1.2 ip-192.168.1.2
# 192.168.2.2
acl ip-192.168.2.2 myip 192.168.2.2
http_port 192.168.2.2:80 name=ip-192.168.2.2
http_port 192.168.2.2:8080 name=ip-192.168.2.2
tcp_outgoing_address 192.168.2.2 ip-192.168.2.2
# ...
... behaved as intended: when clients went through
the http_port listener 192.168.2.2:80, the tcp_outgoing_address
worked as expected, wherein http://www.whatismyip.com
displayed 192.168.2.2 rather than 192.168.1.1.
* whatismyip.com is a global website outside on The Internet
* 192.168.* is a rfc1918 IP space
* rfc1918 IP are not used on The Internet
Ergo the Squid outgoing IP address is not what is being displayed by
that website.
There are 3 layers of protocols above IP where the address can be found.
I think whatismyip uses only the HTTP layer ones. The X-Forwarded-For
and Via: headers added by Squid to provide UID and looping detection.
When the proxy is working properly whatismyip.com should display the
nicely anonymous rfc1918 (192.168.1.250) or whatever the client browser
has been assigned by your LAN.
Hope that makes sense; to rephrase/summarize:
* squid server's main/primary IP: 192.168.1.1
* one instance of squid running;
* the single instance listening on multiple<ip>:<port> http_ports:
192.168.1.2:80, 192.168.1.2:8080, 192.168.1.2:80 and
192.168.1.2:8080
results:
~ first example, using:
acl ip-192.168.1.2 myportname ip-192.168.1.2
and:
acl ip-192.168.2.2 myportname 192.168.2.2
... all cache traffic was detected as originating from server's
main/primary ip: 192.168.1.1 - and not from the specified
tcp_outgoing_address
~ BUT, second example, using:
acl ip-192.168.1.2 myip 192.168.1.2
and:
acl ip-192.168.2.2 myip 192.168.2.2
... all cache traffic was this time detected as originating
from the specified tcp_outgoing_address, as intended,
rather than from the squid server instances primary
ip addr (192.168.1.1).
<snip duplicate of the same results>
# ...
#
# don't work:
#acl ip-192.168.1.2 myportname ip-192.168.1.2
#
# works as expected/intended:
acl ip-192.168.1.2 myip 192.168.1.2
#
http_port 192.168.1.2:80 name=ip-192.168.1.2
http_port 192.168.1.2:8080 name=ip-192.168.1.2
tcp_outgoing_address 192.168.1.2 ip-192.168.1.2
#...
I'd like to understand what's going on, but the docs
I've read are not supplying any real information on
the matter.
Squid stores the local-endpoint IP address as local_ip and the http_port
name= as myportname next to each other in an object recording the
request details.
Those details are then passed to the ACL as needed.
NP: The details gets copied a few times as it moves through Squid. We do
sometimes find problems caused by people omitting bits from the copy and
myportname is fairly new. The lastest was missing myportname copy when
doing URL re-writing. You will need the latest 3.1 or 3.2 to avoid that
(only if you are re-writing URLs though).
I think your definition of works/fails is a little confused by a common
mistake interpreting the whatismyip.com display.
But at the very least myip and myportname should show identical
behaviour for your test config when a browser is directly pointed at the
proxy IP:port.
The behaviour you describe, with the 192.168.1.1 showing up indicates
that NAT (iptables REDIRECT) may be involved. Or that something else is
looping things through Squids primary IP on its way *into* Squid just
before going to the website.
( and as an additional piece of info; with the second
working-as-intended example, I did not need to set
server_persistent_connections to 'off', like the default
squid conf suggests:
# TAG: tcp_outgoing_address
# Allows you to map requests to different outgoing IP addresses
# based on the username or source address of the user making
# the request.
#
# tcp_outgoing_address ipaddr [[!]aclname] ...
# [ ... ]
# Note: The use of this directive using client dependent ACLs is
# incompatible with the use of server side persistent connections. To
# ensure correct results it is best to set server_persistent_connections
# to off when using this directive in such configurations.
Server-facing connection the current Squid is looked up by domain name.
An idle persistent connection to domain example.com can be picked up and
used by any client at any time.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.12
Beta testers wanted for 3.2.0.8 and 3.1.12.2
