44.11. Connecting to Other Proxies
Instead of retrieving requested web pages directly, Squid can be configured to connect to another proxy server instead and forward some or all requests to it. This feature is useful if your organization has one proxy for each department and a master cache for the entire network, and you want to have all department proxies query the master for requests that they cannot serve from their own caches. It may also be necessary if your ISP runs a proxy server and you want to set up Squid for your home network as well, yet still make use of the ISP's cache.
By making use of ACLs to categorize requests, you can set up Squid to forward only some requests to another proxy while handling the rest normally. For example, your proxy could always handle requests for web pages on your local LAN, but still forward everything else to a master proxy cache system.
To set up your server to make use of another proxy for requests except those to a certain network or domain, follow these steps:
1. | On the module's main page, click on the Access Control icon. |
2. | Create a Web Server Hostname or Web Server Address
ACL that matches the web servers that your proxy should fetch directly. Call the ACL
direct, for example. |
3. | Go back to the main page and click on the Other Caches icon to bring up a page containing a list of other known proxy servers (if any) and a form for setting options that control when they are used. |
4. | Click on Add another cache to go to the cache host creation form. |
5. | In the Hostname field, enter the fully qualified hostname of the master cache server, such as bigproxy.example.com. Do not just enter bigproxy, as Squid sometimes has trouble resolving non-canonical DNS names. |
6. | From the Type menu, select parent, which tells Squid that this other proxy is at a higher level (and thus has more cached pages) than yours. |
7. | |
8. | |
9. | Hit the Save button at the bottom of the page to return to the list of other caches. |
10. | In the form at the bottom of that page is a section entitled ACLs to fetch directly, which is actually an ACL table similar to the Proxy restrictions table explained in Section 44.8 “Creating and Editing Proxy Restrictions”. Instead of allowing or denying requests, however, it determines which ones are fetched directly and which are forwarded to another cache. Use the Add ACLs to fetch directly link to first add an entry to allow your direct ACL, and then add one to deny the all ACL. This tells Squid to directly fetch pages from local web servers, but pass all other requests on to the chosen proxy. |
11. | Finally, click on Apply Changes at the top of the page to have Squid start using the other proxy server. |
If you just want to have your proxy forward all requests to another proxy server, regardless of their destination, Step 10 in the previous instructions can be skipped completely. This works because Squid will use the other configured proxy by default if no ACLs have been set up to force direct fetching for certain requests.
On a large network with many clients, one single system running Squid may not be able to keep up with the volume of client requests. For example, a big company with hundreds of employees all running web browsers, or an ISP that has set up a proxy for customers, could put an enormous load on a single Squid server. One solution would be to upgrade to a more powerful machine. Another would be to install Squid on multiple systems and spread the proxying load between them.
This is typically done by creating one DNS address record for each proxy system, all with the same name (such as proxy.example.com) but with different IP addresses. Then, when a client looks up the IP address for proxy.example.com, it will get back all the addresses and pick one effectively at random to which to connect. Another alternative is to install a layer four switch that can redirect traffic to the same IP address to different destinations, such as multiple proxy servers. This is more expensive (layer four switches don't come cheap), but more reliable because a server that is down can be detected and not used. If you are unfamiliar with the term, a layer four switch is one that can reroute network traffic depending on its protocol, port, and destination. In the case of HTTP requests, it can transparently redirect them to another server while leaving other types of data to be routed normally.
There is one problem with using multiple servers, however—each maintains its own cache, so if two different clients request the same web page from two different proxies it will be downloaded twice! This negates most of the benefit of running a caching proxy server.
Fortunately, Squid has features that solve this problem. It can be configured to contact other caches in the same cluster for each request, and ask them if they already have the page cached. If so, it is retrieved from the other proxy instead of from the originating web server. Because all the proxies in an organization are typically connected via a fast network, this is far more efficient. The protocol used for this inter-cache communication is called ICP and is only used by Squid.
On the module's main page, click on the Other Caches icon. To set up two or more proxies to talk to each other with ICP, follow these steps on each system:
1. | Click on Add another cache to bring up the cache host creation form. |
2. | In the Hostname field enter the full hostname of one of the other caches. |
3. | From the Type menu, select sibling, indicating that the other cache is at the same level as this one. |
4. | |
5. | In the ICP port field, enter the port number that the other proxy uses for ICP (usually 3130). |
6. | Hit the Save button to add the other proxy and return to the other caches list. |
7. | Repeat Steps 2 through 7 for each of the other hosts in the cluster. |
8. | Finally, click on Apply Changes at the top of the page. |
The end result should be that each proxy in the cluster has entries for all the other proxies, so that it knows to contact them for requests not in its own cache. You can, however, set up ACLs to avoid the use of ICP and force the direct fetching of certain requests, just as you can when forwarding requests to a master cache.