Re: [squid-users] multiple http_port names
On Friday, June 10, 2011 07:33:07 AM Amos Jeffries wrote: > > ... 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. > Sorry for making things difficult with my example - I completely failed to make it understood that the IPs in the config examples were dummy values. All the actual IPs in question under the real config are indeed within the publicly routable, non-reserved address space. So, to simplify, I found that using: acl myportname http_port name= tcp_outgoing_address ... failed to cause the tcp_outgoing_address to work as expected/intended, while: acl myip http_port name= tcp_outgoing_address ... worked as intended. .. the only change being that I used the 'myip' acl rather than the 'myportname' acl.
Re: [squid-users] multiple http_port names
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: 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). # ... # # 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 th
Re: [squid-users] multiple http_port names
On Friday, June 10, 2011 02:20:49 AM errno wrote: > * the single instance listening on multiple : http_ports: > 192.168.1.2:80, 192.168.1.2:8080, 192.168.1.2:80 and > 192.168.1.2:8080 > Damn, that should have said: * the single instance listening on multiple : http_ports: 192.168.1.2:80, 192.168.1.2:8080, 192.168.2.2:80 and 192.168.2.2:8080 ... e.g. 192.168.1.2 and 192.168.2.2
Re: [squid-users] multiple http_port names
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. > > > 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. 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. 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 : 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). So, something in the difference between: # ... 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 #... and: # ... # # 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. ( 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. Basically, I have one instance of squid that is listening on multiple ip:port http_port directives, and I want the tcp_outgoing_address for each ip to properly reflect the ip that the cache request came in on.
Re: [squid-users] multiple http_port names
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. 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. The ACL values can of course list several port name= values if you want several ports grouped to be handled the same. I tested the above and things _appear_ to be working as expected, but... I'm still wondering whether there might be subtle issues with the above config. The only subtle problem I have been able to think of is that wildcard listening ports are neutral/agnostic of the packets arriving on them. The name is fixed with the actual receiving port on Squid, not the client visible IP. This is by design, but can be confusing to some who don't realize how wildcard ports work. Particularly when dealing with multiple IPs spread over multiple protocols. 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
[squid-users] multiple http_port names
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? 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? I tested the above and things _appear_ to be working as expected, but... I'm still wondering whether there might be subtle issues with the above config. Thanks!
