[squid-users] RES: New Squid Server 3.5.20 on Centos 7 - Trying to redirect local web access to Port 80 on Linux Servers with iptables to Squid Server with http_port intercept
Amos Jeffries
squid3 at treenet.co.nz
Wed May 24 21:47:34 UTC 2017
On 25/05/17 08:16, Rogerio Coelho wrote:
> Using intercept mode with 3129 port :
>
> [root at prd-rbs-squid01-poa squid]# cat /etc/squid/squid.conf | egrep -v "^#|^$"
> acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
> acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
> acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
> acl localnet src fc00::/7 # RFC 4193 local private network range
> acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines
> acl SSL_ports port 443
> acl Safe_ports port 80 # http
> …
> acl Safe_ports port 21 # ftp
> acl Safe_ports port 443 # https
> acl Safe_ports port 70 # gopher
> acl Safe_ports port 210 # wais
> acl Safe_ports port 1025-65535 # unregistered ports
> acl Safe_ports port 280 # http-mgmt
> acl Safe_ports port 488 # gss-http
> acl Safe_ports port 591 # filemaker
> acl Safe_ports port 777 # multiling http
> acl CONNECT method CONNECT
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
> http_access allow localhost manager
> http_access deny manager
> http_access allow localnet
> http_access allow localhost
> http_port 3128
> http_port 3129 intercept
> cache_dir ufs /var/spool/squid 100 16 256
> coredump_dir /var/spool/squid
> refresh_pattern ^ftp: 1440 20% 10080
> refresh_pattern ^gopher: 1440 0% 1440
> refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
> refresh_pattern . 0 20% 4320
> [root at prd-rbs-squid01-poa squid]#
>
> [root at prd-rbs-squid01-poa ~]# systemctl restart squid
> [root at prd-rbs-squid01-poa squid]# systemctl start squid
> [root at prd-rbs-squid01-poa squid]# cat cache.log
> 2017/05/18 15:22:29 kid1| Accepting HTTP Socket connections at local=[::]:3128 remote=[::] FD 17 flags=9
> 2017/05/18 15:22:29 kid1| Accepting NAT intercepted HTTP Socket connections at local=[::]:3129 remote=[::] FD 18 flags=41
> …
> pkts bytes target prot opt in out source destination
> 0 0 PROXYSQUID tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
> 0 0 PROXYSQUID tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
>
> Chain POSTROUTING (policy ACCEPT 1 packets, 76 bytes)
> …
> pkts bytes target prot opt in out source destination
>
> Chain PROXYSQUID (2 references)
> pkts bytes target prot opt in out source destination
> 0 0 RETURN all -- * * 0.0.0.0/0 192.168.0.0/16
> 0 0 RETURN all -- * * 0.0.0.0/0 189.76.144.0/20
> 0 0 RETURN all -- * * 0.0.0.0/0 189.76.156.190
> 0 0 RETURN all -- * * 0.0.0.0/0 172.16.0.0/12
> 0 0 RETURN all -- * * 0.0.0.0/0 10.0.0.0/8
> 0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 to:10.240.64.11:3129
Two problems visible.
* One you have not yet encountered is that these iptables rules are
directing port 80 and 443 to the same Squid receiving port. These two
ports also have very different traffic from each other, more so than
port 3128 vs 80 and Squid again requires separate receiving port for the
intercepted port 443 traffic.
To fix this it needs an "http_port ... intercept" line for port-80, and
a "https_port ... intercept cert=..." line for port-443. Note the extra "s".
* The second is your current problem; the NAT rules are on a different
machine to Squid.
Squid uses the kernel NAT state directly to ensure that the traffic is
going where it was intended to by the client (the ORIGINAL_DST). So it
cannot work if that needed piece of kernel memory is on another machine.
To fix this you need to use routing to get the TCP packets to the
relevant Squid machine and do the iptables DNAT (or REDIRECT target) there.
Amos
More information about the squid-users
mailing list