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

From: bilderberger <marketquant_at_googlemail.com>
Date: Fri, 24 May 2013 02:03:17 -0700 (PDT)

Amos Jeffries-2 wrote
>> 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.

Thank you, that is very helpful.

Amos Jeffries-2 wrote
>> 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?

The purpose in this instance was to force IPv6 connection, or no connection
at all. The sites to be accessed in this case should be dual-stacked and as
far as I can see (at least, when testing my previous partially working
script with 3.1.1) IPv6 was taking priority. What I wanted to ensure was no
leakage of the IPv4 address of the proxy on dual stack sites. Would this
accomplish this?

When I tested this on 3.1.1 it seemed to work for that purpose - I went to
http://ipv6-test.com/ and without this line, the test was showing both IPv6
and IPv4 address. With the line enable, the test only showed IPv6. Is there
a better way to approach this?

Amos Jeffries-2 wrote
>> ## 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

Thank you - I hadn't seen the updated documentation - time for some digging,
and yes, you are correct those lines were supposed to be anonymising - would
any of these contribute to the connectivity issue?

Also, are the obsolete lines not needed anymore?

## this line is obsolete in 3.3.5
##acl manager proto cache_object

## this line is obsolete in 3.3.5
##emulate_httpd_log yes

Thanks again for your comments.

--
View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-how-to-link-inbound-IPv4-multiple-port-connections-to-unique-outbound-IPv6-s-tp4660190p4660230.html
Sent from the Squid - Users mailing list archive at Nabble.com.
Received on Fri May 24 2013 - 09:21:54 MDT

This archive was generated by hypermail 2.2.0 : Fri May 24 2013 - 12:00:48 MDT