Search squid archive

Re: Re: Squid: how to link inbound IPv4 + multiple port connections to unique outbound IPv6's

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux