Proxy Server How To

Start by installing Arch Linux (or your chosen distribution) onto the hardware you selected. If you are in need of a little assistance with the installation, I recommend using this wiki guide and then set up yaourt. Once you have completed your standard Linux installation you need to ensure your network is configured properly. In the case of my transparent proxy, I plugged one network port directly into my cable router and allowed it to grab and IP address via DHCP. The second adapter is then given an IP address of your choice (I chose 10.4.20.1; other common IP addresses would be 192.168.x.x).

At this point you will want to test your network configuration. Start with trying to get out to the internet. If this works, plug your secondary network adapter into whatever switch/router you have available. Take your desktop or laptop that's plugged into the same switch and assign it an IP address in your 10.4.20.x range. (For DHCP setups, see below.) You should now be able to ping your new proxy server (10.4.20.1) from your desktop/laptop. As a quick note for the users who only have a wireless cable modem, it is okay to have both interfaces of your proxy server and desktop plugged into the same cable modem hub.

Now that we have the configuration of the network cards complete, we just need to do a quick installation and configuration of Shorewall/Squid. That may sound like a daunting task to the Linux initiate, but this is actually very simple. First go ahead and install both Squid and Shorewall. Arch has both readily available in the package repository (from a command prompt: yaourt –S shorewall squid). If you are not utilizing Arch, you can download the packages manually from www.shorewall.net and www.squid-cache.org.

Whether you installed Arch Linux or another distribution as your base OS, Shorewall has one simple command to get it set up: cp /usr/share/shorewall/Samples/two-interfaces/* /etc/shorewall. (This copies the base two-NIC example to your live Shorewall directory, which saves a lot of manual work.) Make a quick edit to /etc/shorewall/shorewall.conf and change the Startup_Enabled to yes and you now have a functioning Shorewall. The only thing you need to do for Shorewall at this point is add the following rule into the /etc/shorewall/rules file: REDIRECT loc 3128 tcp www. Start Shorewall by typing: shorewall start from the command line, and add it to your boot process by putting shorewall into the DAEMONS section of /etc/rc.conf.

Now that Shorewall is fully functional and configured, we need to configure Squid. I found a short wiki guide that will assist with the initial set up of Squid. Once you have completed the configuration in the wiki guide, you need to pay close attention to a few configuration settings located in /etc/squid/squid.conf. The cache_memline should be set to half of your installed ram on your proxy server. In my case I have 512MB of total memory so I configured cache_mem to 256. The other setting that you need to pay attention to is maximum_object_size. This setting is the maximum file size your proxy will retain. I set my maximum size to 2048MB in order to retain everything up to a CD ISO. Be cautious of using 2048 if you have anything less than a 120gb drive as your storage space could be gone in the matter of a few days. To get the caching proxy in place and running, the most important line to add is http_port 3128 transparent. The key here is the addition of "transparent", which turns squid into a caching proxy that won't require any additional configuration on your client PCs.

If you followed all of the directions correctly, you're now ready to configure all the machines on your network with a 10.4.20.x IP address with the gateway set as 10.4.20.1. Don't forget to configure your DNS as well (in /etc/resolve.conf). Now that you have everything fired up give your new proxy a spin around the internet. If you would like to do a good test, download a decent size file (i.e. larger than 1MB). Once the download is complete, you should be able to download it again a second time and get LAN speeds on the download. If you have multiple computers, use another machine on your network and attempt to download the same file and you should again see LAN download speeds.

Proxy Server with DHCP

Although I wanted to keep this short and to the point, a common question inevitably comes up: what if you still want to use DHCP? There are a few ways to tackle this issue. If you're lucky enough to have a router/cable modem that will allow you to change what IP addresses it assigns to the network, simply change it over to your new 10.4.20.x subnet and have it assign the gateway of 10.4.20.1. If this is not the case, you will need to disable DHCP on your router and install the DHCP server package (in Arch: pacman –S dhcp). The configuration can be a bit of a hassle, so here's my /etc/dhcpd.conf.

Start the DHCP service on your proxy (/etc/rc.d/dhcpd start) and test DHCP on your desktop/laptop. Assuming all goes well, add dhcpd to your DAEMONS in /etc/rc.conf. If you happen to reboot your Linux box, after a minute or so your proxy should be back up and running.

Introduction to Proxy Servers Linux Neophyte Troubleshooting
POST A COMMENT

97 Comments

View All Comments

  • ChrisRice - Tuesday, May 11, 2010 - link

    Freebsd would certainly be my second choice in home firewall systems "First in the corporate scene". That being said I've always been a fan of having the newer packages of Arch compared to Deb order to get many new features that you would be without in a Deb environment. As far as bugs/security holes because its a rolling compared to the bugs/security holes on a Distro with a slow moving release system, I think they both have their own downsides. Reply
  • mfenn - Tuesday, May 11, 2010 - link

    I agree with dezza that Arch should *not* be used in a "set it and forget it" box. The great thing about Debian or Red Hat is that you can choose to only receive security updates. The maintainers also backport security fixes for the supported life of the release (which for RHEL is 7 years!). Arch only provides the upstream package versions, so if you want the latest security fixes, you also get the latest functionality-killing bugs. Also, for somebody who isn't religiously running "pacman -Syu" every week or so, Arch will quickly fall into the dist. upgrade hell that you get with other distros. You've got to realize that rolling release doesn't eliminate the dist. upgrade problem, it just allows the user to spread the problems across a longer span of time (e.g. I can update every month for a year and encounter 1 problem each time, or I can upgrade every year and encounter 12 problems). For an infrequently updated system (i.e. one build by any reader of this article because let's face it, if they were Linux geeks, they would have one already) you *will* have upgrade problems. In summary, a growing trend in the Linux community is to treat Arch as a panacea, which it most certainly is not. It's great for some things (desktops for tinkerers, development with the latest and greatest, supporting oddball hardware), but a server distro it isn't. Reply
  • KaarlisK - Tuesday, May 11, 2010 - link

    About x1 in x16 slots:
    Could you please test that? :D You have the motherboard.

    And why is cache_memline always half the RAM? Even if you have, for example, 8GB?
    Reply
  • JarredWalton - Tuesday, May 11, 2010 - link

    I think Chris assumes you don't have that much RAM. You probably only need to use half the RAM or leave 1GB free, or you can get by with just caching 512MB in RAM. I have my proxy set as 2GB RAM, and so most of the data comes across from the proxy at GbE speeds. If it goes to HDD than the speed will drop to around 50MB/s, which is still plenty fast. Reply
  • KaarlisK - Tuesday, May 11, 2010 - link

    Thanx for the explanation!
    So basically my usage pattern can determine the cache size, and there IS use from a large cache, as your 2GB example shows.
    Reply
  • ChrisRice - Tuesday, May 11, 2010 - link

    I would recommend starting with a smaller cache then tweaking up. I run a 256MB ram cache and that works just fine for me. That being said if I had more ram on the hardware I am using, I would run at least 1GB. Reply
  • KaarlisK - Wednesday, May 12, 2010 - link

    Thanks for the reply.
    And thanks again for the article! This might finally be the way to sneak... a kind-of replacement for WSUS on a certain network. I know it's horrible, but I do not really have a choice.
    Reply
  • enterco - Tuesday, May 11, 2010 - link

    Hi!

    I would like to make few observations:
    - many owners of an old PC suitable for a caching proxy are using ATX motherboards and enclosures, making the proxy a 'big noisy box', just good to keep in the basement, if you have one.
    - an old P4 computer will add enough bucks to the electricity bill
    - a typical computer user is not familiar with the requirements of configuring a Linux box, and will avoid this kind of setup.
    - the most bandwidth hungry applications in a home is not a HTTP download, but P2P transfers.

    I, personally, don't have the basement, and I don't want the noise made by such a box, neither to waste space or money in electricity in my home. So, instead of bringing back to life an old machine, I would prefer to configure QOS on a wireless router.
    Reply
  • pkoi - Sunday, May 16, 2010 - link

    Go the VMware way. Reply
  • medys - Tuesday, May 11, 2010 - link

    These days virtualisation is the answer :)

    I know that most of people do not need so much as I do and a lot of them do not care about backups, but in case you do, there is a great way to have everything you need in one box :)

    Get some semi old PC with at least 2GB of RAM (4GB is recomended).
    Install a distribution of linux on it that can run virtualisation software (VirtualBOX, vmware server, KVM).
    Configure the linux as NAS server.
    Install virtualisation software.
    Create virtual machines for anything you want :) router, proxy, LAMP, application server etc....
    Reply

Log in

Don't have an account? Sign up now