Re: [squid-users] Re: Squid: how to link inbound IPv4 + multiple port connections to unique outbound IPv6's

On 23/05/2013 9:38 p.m., bilderberger wrote:
> Thank you for the update advice everyone, and for the squid.repo suggestion,
> that worked very nicely to update squid using yum.
>
> I'm now using the latest version (3.3.5) however it seems a few of the lines
> in the rest of my squid.conf are obsolete - so although squid starts with
> the current squid.conf it no longer seems to permit connections.
>
> I've tried commenting out the obsolete lines (noted below) - here is my full
> squid.conf any observations, please?
>
> logfile_rotate 5
>
> ## this line is obsolete in 3.3.5
> ##emulate_httpd_log yes
>
> server_persistent_connections off

The above is no longer necessary with squid-3.2 and later. You can
safely enable server persistence now without getting any of the
connection crossover bugs which were so annoying in older Squid.

> forwarded_for off
>
> ## declare an acl that is true for all ipv6 destinations
> acl to_ipv6 dst ipv6
>
> ## deny ipv4 access
> http_access deny !to_ipv6

This is probably the cause of your non-connectivity problem. IPv4 and
not-IPv6 are two different things, all of IPv4 space maps inside IPv6.
Also, just about all IPv6-enabled sites also have IPv4 addresses.

What exactly are you trying to achieve here?
   ensuring that your clients get to IPv6 version of sites?
or, ensuring that they get rejection pages if they go to IPv4-only sites?
or, preventing access to IPv4 side of dual-stacked sites?

> ##tell Squid to listen on sequential ports and to designate a name for each
> inbound connection.
> http_port 109.xxx.xxx101:3128 name=3128
> http_port 109.xxx.xxx101:3129 name=3129
> http_port 109.xxx.xxx101:3130 name=3130
> http_port 109.xxx.xxx101:3131 name=3131
> http_port 109.xxx.xxx101:3132 name=3132
>
> ## proxy server client access - this is YOUR originating IP, repeat the line
> for multiple IPs
> acl mynetworks src xxx.my.ip.here
> http_access deny !mynetworks
>
> ## designate acl based on inbound connection name
> acl user1 myportname 3128
> acl user2 myportname 3129
> acl user3 myportname 3130
> acl user4 myportname 3131
> acl user5 myportname 3132
>
>
> ## define outgoing IPv6 per user
> tcp_outgoing_address [2001:::::::ipv61] user1
> tcp_outgoing_address [2001:::::::ipv62] user2
> tcp_outgoing_address [2001:::::::ipv63] user3
> tcp_outgoing_address [2001:::::::ipv64] user4
> tcp_outgoing_address [2001:::::::ipv65] user5
>
> ## disable caching
> cache deny all
>
> ## this line is obsolete in 3.3.5
> ##acl manager proto cache_object
>
> request_header_access Allow allow all
> request_header_access Authorization allow all
<snip...>
> request_header_access Cookie allow all
> request_header_access All deny all

A bunch of these are not request headers. The documentation has been
updated recently to list which are request header and which are reply
headers.

http://www.squid-cache.org/Doc/config/request_header_access/
http://www.squid-cache.org/Doc/config/reply_header_access/

FWIW: The example is documenting how Squid can perform behaviour of some
long-ago anonymising feature. There are many HTTP/1.1 and later headers
(most noticeablyTransfer-Encoding reply header) whih are missing from
that list.

Amos
Received on Fri May 24 2013 - 08:42:18 MDT