Being a networking geek, I often try to figure out every aspect I can about different network technologies being used, how to configure them, and what benefits they have to provide when implemented. My home network/lab is a great place to test these technologies in a non-crucial environment. One such networking aspect I haven’t researched much is proxies. Sure, I’ve run into it with application installation that needs a connection configured, and had setup a CGI proxy in the past on a windows machine after my frustrations with my high school’s network blocking my once favorite social new site digg.com, but overall I hadn’t had much knowledge about why else proxies were implemented on a network, so I decided to play with Squid3 to educate myself.
Squid3 works as a web-cache proxy which means that while you browse, the content you are retrieving can also be cached for faster retrieval on the machine running the proxy – based on a set of rules in the proxy’s configuration files. This is not to say that ALL content gets cached, due to the fact that most content you are retrieving is dynamic, and it wouldn’t make sense to cache it due to the fact that you would quickly be viewing outdated material. In fact, in most environments only a small amount of content gets cached – which is why a web-cache proxy becomes more effective with more users working behind it. With a one-user environment the speed increase given by the cached content may not even offset the costs of running the proxy. With a multiple user environment there is most likely a significant amount of overlap in the viewed content and leads to the web-cache loading more of the local cached content versus retrieving new material each time. Although the amount of users on such proxies are not limitless as, due to the nature of a web-cache proxy, it will have to perform many reads/writes to its drives to receive and deliver cached content – and without adequate hardware to handle these read/writes, the network will actually suffer in performance as it will be bottlenecked by the proxy’s speed. If you have more questions about what exactly squid is and how it works checkout Squid’s site.
With all of this being said, the decision to implement a proxy on your network will need to be carefully examined by the needs and amount of throughput of the network. Keep in mind that Squid can be majorly tweaked to fit the needs of the network – so looking at the configuration options available is not something to be ignored.
Okay, enough with the explanations, on to the fun part – installation and configuration!
There are many ways to setup Squid. The most simple is re-directing all traffic to a Squid box on the local network through your software. This requires simply adding the Squid box to the network and directing the web applications on the clients as needed. But those of us administering larger networks know that redirecting client browsers is a pain, and look toward a more automated solution. This was the reason I chose to setup this Squid box as transparent. It is transparent in the sense that no changes will be needed on the client-side for any network settings or re-direction in order for the proxy to be implemented. The diagram below illustrates this setup:
Diagram created using Gliffy
For clients, they have the following settings:
IP Address: DHCP (in the 192.168.2.0 subnet)
DNS: whatever you want, doesn’t affect this setup as long as they are working DNS servers.
The running Squid3 box will simply pass all traffic on eth0 to eth1 and vis versa, but will intercept all traffic on port 80 and re-direct it to the port that Squid is running on. From here, Squid will work its magic in either delivering the cached content to the client or retrieving it and then caching as needed. The client will have no idea where the content is being delivered from, and should ideally only notice it is being received quickly.
I completed the following steps on a machine running Ubuntu 10.04 with 2 NICs installed (eth0, eth1). We will assume eth0 will be the incoming line from the gateway, and eth1 is the outgoing line to switch which the clients access (demonstrated in diagram).
sudo apt-get install squid3
That was simple enough… Most of the work is completed in the configuration.
We need to first add a few lines to the squid configuration file to make the proxy transparent.
sudo nano /etc/squid3/squid.conf
Add the lines below to the configuration:
http_port 3128 transparent acl localnet src 192.168.2.0/24 acl localhost src 127.0.0.1/255.255.255.255 http_access allow localnet http_access allow localhost
This next line is optional – it changes the default size for Squid’s cache to 5000MB to be stored in /var/spool/squid3.
cache_dir ufs /var/spool/squid3 5000 16 256
After making the changes above, save the configuration file and restart squid3. If there are errors Squid should fail to start.
sudo /etc/init.d/squid3 restart
I found ebtables easier to configure the bridge to pass traffic accordingly than iptables. You can use whichever you’d like.
Install ebtables and enter the lines below to pass traffic through accordingly. The port at which Squid is set to run by default is 3128, but if you have changed this in the squid configuration make sure and make the change in the rule accordingly.
sudo apt-get install ebtables sudo ebtables -t broute -A BROUTING -p IPv4 --ip-protocol 6 --ip-destination-port 80 -j redirect --redirect-target ACCEPT sudo iptables -t nat -A PREROUTING -i br0 -p tcp --dport 80 -j REDIRECT --to-port 3128
Also, enable traffic to be passed through both IPv4 and IPv6 on the local machine by uncommenting the following lines in /etc/sysctl.conf
sudo nano /etc/sysctl.conf (uncomment the following) net.ipv4.ip_forward=1 net.ipv6.conf.all.forwarding=1
You will need to install the bridge-utils to configure the bridge within your /etc/network/interfaces file.
sudo apt-get install bridge-utils
After configured my /etc/network/interfaces filled looked like this:
auto lo iface lo inet loopback auto eth1 iface eth1 inet static address 192.168.2.199 netmask 255.255.255.0 network 192.168.2.0 broadcast 192.168.2.255 gateway 192.168.2.1 auto br0 iface br0 inet static address 192.168.2.200 netmask 255.255.255.0 network 192.168.2.0 broadcast 192.168.2.255 gateway 192.168.2.1 bridge-ports eth0 eth1
Save this file and either reboot the system or restart networking and squid3.
sudo /etc/init.d/networking restart sudo /etc/init.d/squid3 restart
After this go to one of your client machines and browse the web for a few seconds. You can then tell if squid3 is working correctly by checking the logs:
This should show you the requests as they are received by squid3. Make sure and check traffic on other ports as well to ensure that it is being passed through correctly.
If traffic is not being passed correctly or squid is not logging any requests a good step to take would be to set the client machine’s browser proxy settings to direct right to the proxy. See if browsing is now working correctly. If so, squid3 is working correctly but there is most likely an issue with the traffic passing rules on the machine the proxy is running on.
These were all the steps I completed to get my transparent proxy running successfully. Obviously you can tweak to fit your needs. The other added benefit of running the proxy in the “transparent” mode is that if the box fails you can simply disconnect the cable from the gateway to the proxy and plug directly into the client switch and the network will continue to function (obviously without local caching enabled).
Hopefully this helps others out there attempting to complete a similar setup. If you notice any errors with this tutorial please let me know. Thanks for reading.