The advantage of using OpenVZ to virtualize a squid proxy is that it provides better use of your hardware as you can set up other servers on the box. It also provides a very easy way to backup and create redundancy.
The illustration may look complex but it actually took less than 20 minutes to create the Squid Proxy and have it working with a backup of the whole configuration.
There are four points of control in this illustration. 1. Browser on Workstation On the web browser of each client set the client to connect to the Squid Proxy at 216.15.226.130 on port 3128. The gateway setting on the client(A) will send the packets to the gateway(B) at 192.168.0.1 where they will be NATed and changed to the IP Address 12.32.34.32(C). 2. Gateway Doing NAT The gateway must have iptables settings to drop all network connections from the internal network except on port 3128. Otherwise users could adjust their browser to avoid the proxy server. Be sure to create the order represented below as you must accept on port 3128 and then drop everything else.
iptables -A FORWARD -p tcp -s 192.168.0.0/24 --dport 3128 -j ACCEPT iptables -A FORWARD -p tcp -s 192.168.0.0.24 -j DROP iptables -A FORWARD -p udp -s 192.168.0.0.24 -j DROP
3. OpenVZ Server The OpenVZ server does not accept any connections on the INPUT chain from the gateway, it will only FORWARD(D) traffic to the Squid Proxy(E). However, this still allows you to completely control all traffic from the Gateway(C) by managing the FORWARD chain. Note that the rules should be written on one line without the return.
iptables -A FORWARD -p tcp -s 12.32.34.32 --sport 1024:65535 --dport 3128 -m state --state NEW -j ACCEPT iptables -A FORWARD -p tcp -s 12.32.34.32 --dport 3128 -m state --state NEW -j ACCEPT iptables -A FORWARD -p tcp -s 12.32.34.32 --dport 3128 -j ACCEPT
This allows you to set connections from various subnets that can connect to your proxy and keep everyone else away from the proxy. Once the traffic goes to the Squid Server(E) you will again need to manage the FORWARD chain to allow traffic to be passed from Squid Server(E) to the OpenVZ Server(F).
Then you must allow the traffic to return to the Gateway(C) and into the internal subnet(A).
iptables -A FORWARD -s 216.15.226.130 -d 12.32.34.32 -j ACCEPT
4. Squid Server At the Squid Server(E) you will also have a firewall that controls connections from the IP Addresses you will accept and the ports you will accept connections on.
You will need to set up your Squid Proxy to accept connections from each IP Address that will use the proxy. Here you can see an acl to accept connections from 12.32.34.32(C) and the http_access line that goes with it.
acl all src 0.0.0.0/0.0.0.0 acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 acl to_localhost dst 127.0.0.0/8 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 local src 12.32.34.32 acl CONNECT method CONNECT
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
# Example rule allowing access from your local networks. Adapt # to list your (internal) IP networks from where browsing should # be allowed #acl our_networks src 192.168.1.0/24 192.168.2.0/24 #http_access allow our_networks http_access allow local # And finally deny all other access to this proxy http_access allow localhost http_access deny all
Multiple Gateways At this point multiple gateways that use the Squid Proxy are easily added by duplicating the process as many times as you needed. You can use the same Squid Proxy or create multiple proxies on the OpenVZ Server.
