Proxy-Cache

7.1	Proxy-Grundlagen

Eines der größten Probleme im Internet ist die begrenzte Kapazität der Datenleitungen. Je beliebter das Netz der Netze wird, desto öfter herrscht Stau auf der „Daten-Autobahn“. Der Ausbau der nationalen und internationalen Leitungsstrecken bleibt weit hinter den Anforderungen durch immer neue Internetnutzer und Dienste zurück. Die Folgen für den einzelnen Benutzer sind lange Wartezeiten und somit höhere Kosten für ein einzelnes Dokument oder eine Information.
Der Einsatz von Zwischenspeichern (Caches) kann die Zeit zwischen der Anforderimg und dem Eintreffen einer Information („Document-Latency-Time“) erheblich verkürzen. Ein Cache profitiert von der Tatsache, daß bestimmte Dokumente innerhalb eines Zeitraumes mehrfach angefordert werden. Die einfachste Form des Caches ist in jedem Standard-Browser eingebaut: der lokale Plattencache. Von jeder HTML-Seite, die geholt wird, legt der Browser eine Kopie auf der Festplatte des eigenen Rechners an. Wird ein Dokument ein zweites Mal aufgerufen, zum Beispiel weil der Benutzer auf den „Zurück“ -Knopf geklickt hat, dann wird die betreffende Seite nicht noch einmal vom entfernten Webserver, sondern direkt von der Festplatte geholt.
Einen Schritt weiter geht der Proxy-Cache (Proxy = „Stellvertreter“). Dabei handelt es sich um ein Programm, das auf einem im lokalen Netz zugänglichen Rechner läuft und, genauso wie der lokale Browser, von jeder im Netz angeforderten Web-Seite eine Kopie auf seiner Festplatte anlegt. Wird die Seite ein zweites Malvon einer Station im Netz angefordert dann liefert der Proxy seine Kopie aus, statt die Seite noch einmal vom entfernten Server zu holen. Dazu ein Beispiel: Station A in Bild 7.2 möchte die Seite index.html vom Server www.veryfar.com laden. Dazu baut Station A zunächst eine Verbindung zum lokalen Proxy-Rechner auf. Der sucht die geforderte Datei in seinem CacheSpeicher. Ist sie dort noch nicht vorhanden, dann fordert der Proxy die Seite von www.veiyfar.com an, speichert sie im Cache und liefert sie anschließend an Station A aus. Die Wartezeit für Benutzer A ist nahezu die gleiche, als hätte er ohne Proxy auf den entfernten WWW-Rechner zugegriffen. Interessant wird es aber, wenn zu einem späteren Zeitpunkt der Benutzer an Station B die selbe Seite anfordert, dann ist sie bereits im Cache des Proxies. Da der Proxy-Rechner im Jntranet steht, fällt der Zugriff für Benutzer B wesentlich rascher aus als vorher für A.
Neben der Verkürzung der Anforderungzeit von Dokumenten sorgt der ProxyRechner auch für eine Trennung zwischen dem lokalen Rechner und einem Server im Internet. Die lokale Station fragt immer nur den Proxy nach Dokumenten, nur der Proxy baut Verbindungen zu externen Rechnern auf. Wegen dieses Konzeptes werden Proxies auch in Firewalls integriert. Stellvertretend für die lokalen Arbeitsstationen stellt die Firewall Anfragen nach HTML-Seiten an Server im Internet (Bild 7.3). Die lokalen Stationen können keine direkte Verbindung nach außen aufbauen.
Beim Einsatz von Cache-Speichern, egal ob im Browser oder auf einem ProxyRechner, ergibt sich immer ein Problem: Die Information der lokalen Kopie kann veraltet sein, weil sich das Original auf dem entfernten Server geändert hat. Handelt es sich bei dem gespeicherten Dokument beispielsweise um eine Seite mit Börsenkursen, dann kann der Inhalt bereits innerhalb weniger Minuten oder Stunden ungültig sein.
Ein Proxy muß also über eine Vorschrift bestimmmen, wann es sinnvoll ist, eine Seite als veraltet einzustufen. Der einfachste Fall liegt vor, wenn das „Verfallsdatum“ direkt im HTTP-Header der Seite angegeben wurde. (Expires: Sat, 08 Jan 2003 09:00:00) Der Cache wertet diese Zeile aus und kann nach Ablauf des angegebenen Datums die Seite als veraltet einstufen.
Schwieriger wird es, wenn kein Ablaufdatum angegeben wurde; dann muß der Proxy selbst berechnen, wann eine Aktualisierung der Seite sinnvoll ist. Das Proxy-Programm Squid teilt dazu die Dateien in seinem Cache in zwei Gruppen ein:
Ein Dokument ist entweder „frisch“ (fresh), dann wird es ohne weitere Aktualitätsprüfung an einen Klienten ausgeliefert, oder es ist „veraltet“ (stale), dann muß vor der Weitergabe beim Quellserver nachgefragt werden, ob es eine aktuellere Version gibt.
Die wichtigsten Daten zur Bewertung einer Datei als fresh oder stale sind:

Datum der letzten Modifikation (last modified): Dieser Wert wird von den meisten WWW-Servern im Kopf des Dokuments vermerkt.
Objekt-Datum (object_date): Zeitpunkt an dem die Datei geholt wurde. 
Aktuelles Datum (now)

Alter (age): Bisherige Verweildauer der Datei im Cache (age = now – object_date)

Alter beim Holen (lm_age): lm_age = object_date – last_modified

Altersfaktor (factor): Dient zum Vergleich mit dem in der Konfigurationsdatei einstellbaren Prozentwert (percent). Je höher der Faktor, desto höher die Wahrscheinlichkeit, daß das Dokument geändert wurde. factor = age / lm_age

Minimale Verweildauer (min_age): In der Konfigurationsdatei einstellbare minimale Lebensdauer eines Cache-Objektes.

Maximale Verweildauer (max): In der Konfigurationsdatei einstellbare maximale Lebensdauer eines Cache-Objektes.

client_max_age: Mit diesem optionalen Parameter kann der Klient ein Maximalalter für Dokumente festlegen. Dieser Wert hat oberste Priorität.

Mit diesen Werten berechnet squid den Zustand einer Datei nach den folgenden Regeln so lange, bis ein Ergebnis vorliegt:
if (client_max_age)
if (age > client_max_age)
return stale
if (age <= min_age)
return fresh
if (expires)
if (expires <= now)
return stale
else
return fresh
if (age > max_age)
return stale
if (lm_factor < percent)
return fresh
return stale

Mit dem Programm Squid steht ein Proxy-Cache zur Verfügung, der sich schon seit langem bewährt hat und von vielen Internet-Providern eingesetzt wird.

7.2	Installation und Konfiguration

Die Installation von Squid ist schnell erledigt. Besitzt man eine komplette LinuxDstribution wie SuS5E oder RedHat, muß lediglich das Squid-Paket installiert werden. Hat man die Quelltext-Variante vorliegen, muß zum Ubersetzten das Script configure aufgerufen werden, das automatisch alle Einstellungen vornimmt. Anschließend kann das Programm mit make all und make install compiliert und installiert werden.
Die Konfiguration des Caches wird über eine einzige Datei vorgenommen (squid.conf). In jedem Squid-Paket ist bereits eine Musterdatei enthalten, die nur noch editiert werden muß.
Die wichtigsten Parameter für die Grundfunktionen lauten:

http_port: TCP-Portnummer, auf der der Cache von Klienten angesprochen werden kann. Standardwert ist 3128, aber viele Proxybetreiber verwenden hier die Portnummer 8080.

http_port 8080

cache_mem: Mit diesem Wert kann der Hauptspeicherverbrauch des Caches in MByte eingestellt werden. Um auf den tatsächlichen Speicherbedarf des kompletten Squid-Prozesses zu kommen, muß man diese Zahl etwa mit dem Faktor 3 multiplizieren. Standard sind 8 MByte, damit belegt Squid circa 24 MB Hauptspeicher. Bei der Eintragung dieses Wertes sollte man nicht vergessen, genügend Speicher für Linux und alle anderen laufenden System-Prozesse übrigzulassen. Muß der Proxy im Betrieb aus Speichermangel auf die SwapPartition zugreifen, würde die Geschwindigkeit des Caches erheblich darunter leiden. Während der Testphase des Proxys sollte der Administrator mit dem free-Kommando gelegentlich kontrollieren, ob noch genügend Speicher zur Verfügung steht, oder ob schon geswappt wurde.

cache_dir: Die wichtigste Zeile der ganzen Konfigurationsdatei. Hier wird das Cacheverzeichnis und dessen Größe eingestellt. Die Syntax der Zeile ist:

cache_dir Verzeichnisname Größe Ebenel Ebene2

Die Verzeichnisstruktur des Caches ist in zwei Ebenen organisiert. Mit Ebene 1 und Ebene 2 wird die Anzahl der Unterverzeichnisse auf jeder Ebene eingestellt. Die Zeile

cache_dir /var/squid/cache 3000 16 256

legt in /var/squid/cache 16 Verzeichnisse zum Speichern von Objekten an. Jedes dieser Verzeichnisse enthält noch einmal 256 Unterverzeichnisse. Die Gesamtgröße des Caches beträgt 3000 MByte.

cache_access_log: In der hier angegebenen Datei werden alle Zugriffe der Klienten und aller anderen Server in einem Verbund auf den Proxy vermerkt. Insbesondere bei der Fehlersuche kann diese Datei sehr nützlich sein. Beispiel: 

cache_access_log /var/squid/logs/access.log

cache_log: Legt die Datei fest, in der das Verhalten des Caches protokolliert wird. Mit Hilfe von debug_options läßt sich einstellen, wie viele Informationen geschrieben werden. Auch diese Datei ist für die Fehlersuche sehr wichtig. Beispiel: 

cache_log /var/squid/log/cache.log

debug_options: Legt fest, wie ausführlich die Information in der Logdatei des Caches werden soll. Als Parameter müssen die Sektion (Standardwert: All) und ein Wert für die Menge der erzeugten Information angegeben werden. Dabei steht 1 für normale und 9 für maximale Menge. Im Normalfall sollte
Squid mit der Einstellung debug_options ALL‚ 1 betrieben werden.

log_fqdn: Wird dieser Schalter auf „ON“ gesetzt, dann wird in der Datei access.log, statt der IP-Nummer jedes zugreifenden Klienten, dessen „FullQualified-Domainname“ aufgezeichnet. Aus einer IP-Nummer wie 192.186.1.4 wird damit also pc5.netzmafia.de. Da Squid aber zum Feststellen des Namens extra eine Named-Server-Abfrage starten muß, wird mit dem Einschalten dieser Funktion die Gesamtgeschwindigkeit möglicherweise reduziert. Unser Tip: Schalten Sie diese Funktion im Normalbetrieb aus (log_fqdn 0FF). 

client_netmask: Mit Hilfe der hier angegebenen Maske können aus den Klienten-IP-Nummern in den Log-Dateien Stellen ausgeblendet werden, um sie zu anonymisieren. Mit der Zeile client_netmask 255.255.255.0 wird zum Beispiel die letzte Stelle der IP-Nummer in der Logdatei durch die Zahl 0 ersetzt. Statt 192.168.1.4 oder 192.168.1.6 erscheint in der Datei für alle Klienten im gleichen Subnetz einheitlich 192.168.1.0. Bei der Maske 255.255.0.0 werden die letzten beiden Zahlen der IP-Nummern ausmaskiert und nur noch 192.168.0.0 als Adresse gespeichert. Anhand der Logdatei festzustellen, welcher Rechner welche Seite aufgerufen hat, wird damit unmöglich. Unsere Empfehlung hierzu lautet: Setzen Sie im Sinne des Datenschutzes die Maske so, daß die letzte Zahl ausgeblendet wird, also client_netmask 255.255 • 255.0. Damit können Sie bei großen Installationen mit mehreren Subnetzen immer noch feststellen, aus welchem Netz ein Zugriff stammt und von welchen Bereichen aus häufiger auf den Proxy zugegriffen wird. Anhand dieser Daten können Sie zum Beispiel erkennen, welche Netze Bedarf für eigene Proxies haben oder wo es lohnt, die Plattengröße oder die Leistung der Proxies zu optimieren.

ftp_user: Diese Einstellung ist von Bedeutung, wenn Squid auch als Cache für FTP-Verbindungen verwendet werden soll. Bei einem anonymen FTP-Login gibt man als Benutzernamen „ftp“ und als Paßwort seine E-Mail-Adresse an. Mit einem Eintrag wie zum Beispiel ftp_user squid@netzmafia. de legen Sie fest, was Squid in diesem Fall überträgt. Verwenden Sie statt netzmafia.de im obigen Beispiel Ihren echten Domainnamen oder einen Rechnernamen innerhalb der Domain, da viele FTP-Server die Adressen auf Gültigkeit prüfen und im Fehlerfall den Login verweigern.

cache_mgr: Wenn der Cachevorgang durch einen Fehler beendet werden muß, kann Squid eine Mail an die hier eingetragene Adresse senden. Üblicherweise verwendet man einen Aliasnamen für einen Benutzer oder eine Gruppe. Zum Beispiel: cache_mgr proxyadmins. Die Zuweisung zur echten EMail-Adresse geschieht mit Hilfe der lokalen Alias-Datenbank des Rechners (/etc/aliases). Dort steht dann zum Beispiel eine Zeile mit

# Benachrichtigungsite fuer den Proxy-Cache-Server
proxyadmins mueller@netzmafia.de, maier@netzmafia.de

Wir raten Ihnen, bei allen Serverprogrammen so zu verfahren. Soll die Zuständigkeit geändert werden, weil zum Beispiel eine Urlaubsvertretung in die Liste eingetragen werden soll, oder weil ein Mitarbeiter ausgeschieden ist, muß immer nur die / etc / alias es editiert werden und nicht viele einzelne Dateien mit unterschiedlicher Konfigurationssyntax. Vergessen sie dabei nicht die einzelnen Zeilen zu kommentieren, damit die Zuordnung der Aliase zu den Funktionen und Programmen klar wird.

cache_effective_user: Benutzername und ID, unter welcher der Cache läuft. Aus Sicherheitsgründen sollte der Server nicht unter der der ID „root“ laufen. Standardwert ist: cache_effective_user nobody

cache_effective_group: Gruppenname, unter dem Squid läuft. Standard ist:
cache_effective_group nogroup

visible_hostname: Hier kann ein besonderer Rechnername angegeben werden, der in allen Meldungen an die Klienten erscheint. Wenn nichts angegeben ist, wird der Name verwendet, der bei Ausführen des Kommandos hostname erscheint. Beispiel: Der Proxy-Server „gremlin.netzmafia.de“ soll sich in Fehlermeldungen als „proxy.netzmafia.de“ melden um die Benutzer nicht zu verwirren. Die passende Zeile in der squid.conf lautet:

visible_hostname squid.netzmafia.de

logfile_rotate: Bei stark ausgelasteten Servern wachsen die einzelnen Logdateien schnell an und erreichen bald mehrere MByte. Da sie aber meist nur der unmittelbaren Fehlersuche dienen, lohnt es sich kaum, sehr alte Einträge aufzuheben. Interessant ist nur die unmittelbare Vergangenheit von einigen Tagen oder Wochen. Squid bietet zur Beschränkung der Größe und des Inhalts der access.log und cache.log einen Rotationsmechanismus. Immer wenn der Squid-Prozeß das Signal „USR1“ empfängt, wird von den aktuellen Logdateien eine Sicherheitskopie angelegt und mit einer neuen, leeren Datei weitergearbeitet. Die Zahl hinter logfilerotate bestimmt, wie viele Generationen von Sicherheitskopien aufgehoben werden. Die jeweils älteste wird bei jeder Rotation gelöscht. Ist zum Beispiel der Wert 5 eingestellt, werden die fünf letzten Logdateien aufgehoben. Squid hängt zur Kennzeichnung der Generationen Zahlen-Erweiterungen an die Dateinamen an. cache. 1 og. 0 ist die jüngste Kopie, cache.log. 1 die nächstältere, und so weiter. Wie viele Kopien Sie anlegen und wie oft Sie die Dateien rotieren, hängt natürlich von Ihrer Installation und insbesondere von der Anzahl der Zugriffe ab. Unsere Empfehlung: Die Logdateien sollten auch einen langen Urlaub oder Krankheit des Systemadministrators überdauern, damit dieser nach seiner Rückkehr Probleme analysieren kann. Ein typischer Praxiswert ist: Rotation jede Woche und fünf Generationen von Backups. Das Signal „USR1“ schickt man mit Hilfe des Kommandos squid -k rotate an den Server; am besten mit Hilfe eines Eintrags in der Datei crontab. Ein Eintrag, der jeden Sonntag um 2 Uhr nachts eine Rotation durchführt lautet:

	0	2 *  * 0 /usr/sbin/squid -k rotate

append_domain: Der hier angegebene Dateiname wird an alle vom Klienten angeforderten Adressen angehängt, die keinen Punkt enthalten. Tippt ein Benutzer zum Beispiel in seinem Browser nur www ein, um die Startseite des lokalen WVVW-Servers zu erreichen, dann erhält er ohne diesen Eintrag die Fehlermeldung, daß der Rechner www nicht gefunden werden kann. Trägt man aber append_domain netzmafia.de ein, dann wird www zu www.netzmafia.de ergänzt, und der Benutzer erhält das gewünschte Dokument.

Mit den obigen Konfigurations-Einträgen kann ein funktionierender Cache aufgebaut werden. Es bleibt nur noch zu klären, welche Hardware für eine Installation benötigt wird. Dazu zwei Beispiele:

7.2.1	Kleine Installation

Im ersten Beispiel besitzt eine Firma 15 Klienten-Rechner und ist über eine DSLLeitung an den Provider angebunden. Wie bei vielen kleinen Installationen soll für den Proxy-Service kein neuer Rechner gekauft werden, sondern es wird ein ausrangierter PC mit einer Pentium-I- oder 11-CPU verwendet. Der PC besitzt eine IDE-Platte mit 4 GByte. Er soll ausschließlich für Proxy-Dienste zur Verfügung stehen, also kann 3 GByte der Platte als Squid-Cache konfiguriert werden. Das setzt voraus, daß Linux als „schlanke“ Installation vorliegt und zum Beispiel XWindow gar nicht installiert wurde und Plattenplatz verschwenden kann. Da das interne Netz mit einer 10-MBit-Leitung ausgestattet ist, erhält auch der Proxy nur eine 10-MBit-Netzwerkkarte.
Den Speicherbedarf dieses Rechners kann man mit einer einfachen Faustformel bestimmen. Squid benötigt pro Gigabyte Cache circa 10 MByte RAM. Bei den 3 GByte im Beispiel oben kann man also von einem Gesamtspeicherbedarf von 30 MByte nur für die Cache-Verwaltung ausgehen. Hinzu kommt der Platz für Objekte, die Squid gerade im Arbeitsspeicher hält. Alle anderen Programme, darunter die von Squid benötigt werden, brauchen natürlich ebenfalls Speicher, so daß man den Rechner mit mindestens 80 MByte, besser mit 96 MByte ausstatten sollte. Mit diesen Daten ergibt sich folgende / etc / squid.conf:

# Squid.conf fuer kleinen Cache

# Proxy-Port
http_port 3128

# 11 MByte für Objekt-Cache reservieren. Echter Bedarf des
# Proxies ca. 3 x dieser Wert
cache_mem 11

# Verzeichnis fuer cache, Groesse 3GByte, 16 Verzeichnisse
# in Ebene 1, 256 in Ebene 2
cache_dir /var/squid/cache 3000 16 256

# Log-Datei mit allen Zugriffen
cache_access_log /var/squid/logs/access.log

# Log-Datei fuer alle Cache-Aktivitaeten
cache_log /var/squid/logs/cache. log

# Debug-Level niedrig halten, sonst zuviel Output
debug_level ALL,1

# Keine IP-Nummer -> Namens-Wandlung
log_fdqn off

7.2 Installation und Konfiguration 

# Letzte Stelle der IP-Nummer in der Logdatei  löschen
client_netmask 255.255.255.0

# zugriffsrechte fuer den Cache: alle duerfen! acl all src 0.0.0.0 / 0.0.0.0
http_access allow all

# Passwort fuer anonymes FTP
ftp_user squid@proxy . netzmafia. de

# E-Mail-Adresse der Verwalter, Festlegung in der /etc/aliases cache_mgr squidadmin@netzmafia.de

# UID unter der Squid laeuft. Hier wurde eine extra ID vergeben.
cache_effective_user squid

# Dito, Gruppe
cache_effective_group squid

# Hostname, der in Fehlermeldungen erscheint
visible_hostname proxy.netzmafia.de

# Logfiles fuenf Wochen aufheben
logfile_rotate 5

# Kein Punkt in der URL? Dann diesen Domainnamen anhaengen
append_domain netzmafia.de

7.2.2	Große Installation

In diesem Beispiel soll ein Cache konfiguriert werden, der einige zigtausend Zugriffe pro Tag verkraften kann. Dieser Typ von Proxy könnte in einer großen Firma oder bei einem mittleren Provider stehen. Bei dieser Größenordnung von Zugriffen ist der Server natürlich ausschließlich für die Cache-Dienste reserviert, und das interne Netz läuft mit einer Übertragungsgeschwindigkeit von 100 MBit/s. In den Proxy-Rechner sind neben der Betriebssystem-Platte mit 10 GByte je zwei 20 GByte Ultra-Wide-SCSI-Platten eingebaut, die als Cache konfiguriert werden sollen.
Der Speicherbedarf kann wieder mit der Faustformel berechnet werden: 40 GByte Cache benötigen 400 MByte Speicher. Hinzu kommt Speicher für Objekte und Betriebssystem-Prozesse. 512 MByte Speicher sind in diesem Fall also eine gute Wahl.
Die squid.conf aus dem letzten Beispiel kann hier komplett übertragen werden, mit Ausnahme der Zeilen, die Cache-Größe und Speicherbedarf bestimmen. Statt dessen müssen sie in diesem Beispiel durch folgende Zeilen ersetzt werden:

# cache auf der ersten Platte, gemountet unter  /var/squid/diskl
cache_dir /var/squid/diskl 20000 16 128

# 2. Platte, gemauntet unter /var/squid/disk2 
cache_dir /var/squid/disk2 20000 16 128

# Speicherbedarf 128 x 3 MB
cache_mem 128

Beachten Sie bei diesem Beispiel, daß die Zeile cache_dir mehrmals in der Konfigurationsdatei auftauchen darf. So ist es möglich, viele, auch verschieden große Platten in den Proxy einzubauen und alle zusammen als Cache zu nutzen. Die Aufteilung auf mehrere Platten ergibt sogar einen Performancevorteil, wie später noch gezeigt wird.

7.2.3	Squid als transparenter Proxy

Nachdem heutzutage kaum noch ein Netzwerk direkt, das heißt ohne Firewall, mit dem Internet verbunden ist, wird squid häufig als sogenannter „transparenter Proxy“ eingesetzt. Das bedeutet ein Firewallkonzept leitet alle Zugriffe der lokalen Client-PCs über einen Proxyserver um. Diese Umleitung geschieht ohne ein Umkonfigurieren der Webbrowser auf den Anwender-PCs, eben „transparent“.
Um Squid das Arbeiten in solchen Umgebungen zu ermöglichen, muß die Konfigurationsdatei squid.conf angepaßt werden. Wichtig sind die folgenden fünf Einträge.

http_port 3128
httpd_accel_host virtual 
httpd_accel_port 80
httpd_accel_with_proxy  on
httpd_accel_uses_host_header  on

Wird auf dem Firewallrechner das Programm iptables eingesetzt, dann lauten die Zeilen zum Aktivieren des transparenten Proxies:

#! /bin/bash
IPTABLES= /usr/ sbin/ iptables

#Ethernet-Interfaces
# offizielle Adressen
EXT=eth0
# intern (192er-Netz)
INT=ethl

# Definition internes Netz
INTERN=l92 .168.110.0/255.255.255.0

# Proxy-Server: Port
SQUIDSERVER=l92 .168.110.1:3128

# Parts
P_HIGH=l024:65535 # User-Ports

# Tranparentes HTTP-Proxying einschalten
echo „configuring transparent proxy $SQUIDSERVER“
$IPTABLES -t nat -A PREROUTING -i $INT -p TCP -sport $P_HIGH  \

7.3 Konfiguration der Webbrowser

	--dport 80 -j DNAT --to-destination $SQUIDSERVER

Die Variablen am Anfang des Skriptes sind als Konfigurationserleichterung gedacht. Man braucht sie in aller Regel mehrmals und kann so ein universelles Firewallskript erzeugen, das nur noch über ein paar Angaben angepaßt werden muß. [m obigen Beispiel ist das interne Netzwerkinterface der Firewall ethl und das externe ethO. Intern wird das private Netz 192.168.112.0 verwendet und der SquidProxy hat die Adresse 192.168.112.1. Die Umleitung auf den Proxy findet in den letzten beiden Zeilen statt. Sie bedeuten übersetzt etwa:
Leite alle empfangenen Pakete, die auf dem internen Interface eintreffen, zum TCP-Protokoll gehören, von einer Portnummer größer als 1024 kommen (den sogenannten Userports) und an den Empfängerport 80 (http) gehen, an den Rechner 192.168.112.1 weiter. Mit -j DNAT wird festgelegt, daß es sich bei diesem Vorgang um „Destination-Network-Adress-Translation“ handelt. Das bedeutet lediglich, daß die Empfängeradresse eines Paketes geändert wird. -A PREROUTING legt fest, das die Umwandlung gleich nach dem Empfang des Paketes geschieht und bevor es durch etwaige andere Firewallregeln modifiziert wird.

7.3	Konfiguration der Webbrowser

Bevor der einzelne Benutzer an seinem Computer vom Proxy profitieren kann, muß der lokale Webbrowser für die Benutzung des Caches umkonfiguriert werden; sofern man keinen transparenten Proxy einsetzt. Stellvertretend für die vielen Browser auf dem Markt werden die Einstellungen für den Netscape-Navigator (oder Mozilla) und den Internet-Explorer beschrieben.

Im Fenster Kategorien werden durch einen Mausklick auf das Dreieck neben Erweitert links zwei neue Aste in der Baumdarstellving sichtbar (Bild 7.5). Durch einen Klick auf Proxies wird rechts das Fenster Proxies für den Internetzugrzffkonfigurieren geöffnet. Dort wählt man Manuelle Proxy-Konfiguration aus.

In den Feldern unter Manuelle Proxy-Konfiguration kann der Name des Proxies eingegeben werden. Handelt es sich bei dem Proxy lediglich um einen Cache für Webseiten, ist nur die Zeile http auszufüllen. Ist der Proxy auch für FTP-Verbindungen zuständig, muß die Zeile FTP den gleichen Inhalt wie http aufweisen.
Im Fall der Netzmafia lautet der Eintrag für die Adresse des Proxies proxy.netzmafia.de. Als Fort ist der Wert einzustellen, der in der Datei squid.conf unter http_port eingestellt wurde. In unserem Fall war dies der Fort 3128. Mit dem Feld „Kein Proxy für“ kann angegeben werden, für welche Domänennamen sich der Weg über den Proxy nicht lohnt, weil die Direktverbindung zu deren Webservern schneller wäre als der Zugriff über den Cache. In der Regel ist das die eigene Domäne und damit das interne Netz.

7.3.2	Internet-Explorer
Beim Internet-Explorer sind folgende Schritte nötig: Im Menü Extras des Hauptfensters wählt man Internetoptionen aus (Bild 7.7). Im Fenster Internetoptionen muß man die Karteikarte „Verbindungen“ und anschließend den Knopf „LAN-Einstellungen“ im Abschnitt „Einstellungen für lokales Netzwerk (LAN)“ anklicken (Bild 7.8). Im folgenden Fenster wählt man die Schaltfläche Proxyserver verwenden aus und klickt auf den Knopf Erweitert (Bild 7.9). Analog zur Konfiguration von Netscape muß auf dem folgenden Fenster der Name des Proxyservers unter http sowie, wenn der Server auch FTP-Zugriffe zwischenspeichert, unter FTP eingetragen werden. Als Fort ist der unter http_port eingestellte Wert aus der scquid.conf einzutragen. In allen Beispielen in diesem Buch wurde 3128 als Fortadresse verwendet. Auch im Internet-Explorer können bestimmte Subnetze angegeben werden, für die der Zugriff auf den Proxy nicht lohnt, weil sie direkt schneller erreicht werden können. Zumindest das lokale Netz sollte man unter Ausnahmen eintragen. 

7.4	Zugriffsrechte

7.4.1	Grundlagen

Mit Hilfe sogenannter Access-Lists innerhalb der squid.conf läßt sich der Zugriff auf den Cache einschränken. Damit kann der Proxy vor unberechtigter Nutzung geschützt werden.
Dazu wird zunächst ein Bereich von Elementen unter einem symbolischen Namen in einer eigenen Zeile zusammengefaßt, die mit dem Schlüsselwort acl beginnt. Ein solcher Bereich kann zum Beispiel eine Gruppe von IP-Nummern, eine Zeitspanne oder sogar ein bestimmter Browsertyp sein. Die generelle Schreibweise lautet:
acl <symbolischer Name> <Typ> <Definition>

Soll der Zugriff auf den Cache nur im lokalen Netzwerk möglich sein, miissen das eigene Netz und alle anderen Netze in je einer ACL-Zeile aufgeführt werden.

acl intranet src 192.168.1.0/255.255.255.0
acl all src 0.0.0.0/0.0.0.0

Die erste Zeile definiert unter dem Namen „intranet“ das komplette lokale Subnetz. Der Typ sr-c legt fest, daß es sich bei der Definition um eine Zugriffsbeschränkung für Klienten handelt. Es folgt die Angabe des IP-Nummern-Bereichs mit Netzmaske, für den die Definition gilt. Mit Hilfe einer Null an der jeweils letzten Stelle von IP-Nummer und Netzmaske wird ein ganzes Klasse-C-Subnetz, im Beispiel der Bereich von 192.168.1.1 bis 192.168.1.254, definiert.
Um nun das lokale Netz von allen anderen zu unterscheiden, muß ein symbolischer Name für alle Netze (hier: all) vergeben werden. Dies geschieht mit Hilfe der Adresse 0.0.0.0 und der Maske 0.0.0.0.
Um den Proxy-Zugriff zu beschränken, kann nun auf die oben definierten Namen zugegriffen werden. Mit den folgenden Zeilen wird der Zugriff für das lokale Netz erlaubt und für alle anderen verboten.

http_access allow intranet
http_access deny all

7.4.2	ACL-Anweisungen

Die wichtigsten Typ-Anweisungen aus der squid.conf sind:

src: Syntax: acl Name src IP-Adresse/Netzmaske
Definiert Klienten-IP-Adressen. Dabei kann eine einzige Adresse, bestimmte
Adreßbereiche, oder ein komplettes Subnetz angegeben werden. Dazu einige
Beispiele:

acl meinpc src 192.168.2.34/255.255.255.255
acl kleinesnetz src 192.l68.3,l—192.168.3.3l/255.255.255.255 
acl meinclassc src 192.168.1.0/255.255.255.0
acl meinclassb src 192.168.0.0/255.255.0.0

Die erste Zeile definiert lediglich einen Klienten-Rechner mit der IP-Adresse
192.168.2.34. In der zweiten wird ein Bereich von IP-Nummern (hier: alle
Adressen zwischen 192.168.3.1 und 192.168.3.31) angegeben. Dazu ist einfach
ein Minuszeichen zwischen die höchste und die niedrigste Nummer zu setzen.
Beachten Sie dabei, daß bei den beiden oberen Zeilen die Netzmaske immer
255.255.255.255 ist.

Anders bei den letzten beiden, definiert Zeile drei den Zugriff von Klienten aus einem kompletten Klasse-C-Netz: 192.168.1.1 — 192.168.1.254. Die zugehörige Netzmaske ist 255.255.255.0 Die letzte Zeile legt sogar ein ganzes Klasse-BNetz fest. Damit sind alle Rechner mit einer IP-Adresse zwischen 192.168.1.1 und 192.168.255.254 unter dem Namen meinclassb zusammengefaßt. Zu einem B-Netz gehört die Maske 255.255.0.0.

~	dst: Syntax: acl Name dst IP-Adresse/Netzmaske

Analog zu src kann man damit angeben, auf welche Server zugegriffen werden kann. Mit Hilfe dieses Typs lassen sich einschlägige Server sperren. Beispiele:

acl dst boeserserver dst 192.168.99.97/255.255.255.255 
acl dst boesesnetz dst 192.168,69.0/255.255.255.0

Die erste Zeile beschreibt einen Rechner, die zweite ein ganzes Klasse-CSubnetz. Mit den beiden Zeilen

http_access deny boeserserver
http_access deny boesesnetz

kann anschließend der Zugriff aller Klienten auf die angegebenen IPNummern verhindert werden.

~	srcdomain: Syntax: acl Name srcdomain Domänenname
Dieser Typ entspricht src, mit dem Unterschied, daß hier statt IP-Nummern Domänennamen angegeben werden müssen. Beispiel:

acl intranet srcdomain netzmafia.de

Hier werden alle Rechner in der Domäne netzmafia.de unter dem Namen intranet zusammengefaßt. Beachten Sie dabei, daß Squid zum Überprüfen der Domänenzugehörigkeit einen DNS-Reverse-Lookup vornimmt. Das heißt, er versucht, mit einer Named-Server-Abfrage die IP-Nummer des Klienten, den Rechnernamen und Domänennamen zu holen. Das funktioniert natürlich nur, wenn es überhaupt einen DNS-Server für die lokale Domäne gibt und der entsprechende Rechner auch in dessen Tabellen eingetragen ist. Für viele kleine Netze ist das nicht der Fall. Entweder gibt es keinen DNS, oder nicht alle Rechner sind im DNS eingetragen. Daher sollte man in solch einem Fall den Typ src statt srcdomain verwenden, um sicher alle Rechner im lokalen Netz angeben zu können.

dstdomain: Syntax: acl Name dstdomain Domänenname

Dieser Typ entspricht dst, mit dem Unterschied, daß hier statt IP-Nummern Domänennamen angegeben werden müssen. Diesen Typ können Sie besonders gut zum Sperren des Klienten-Zugriffs auf einschlägige Server verwenden. Ist Ihr Proxy in eine Firewall integriert und damit kein Direktzugriff der lokalen Rechner auf das Internet möglich, kann damit jeglicher Zugang zu der angegebenen Domäne verhindert werden. Viele Administratoren großer Firmenproxies führen lange Listen von Domänen-Namen in dieser Form auf, um damit insbesondere an Freitagnachmittagen die Netzlast wesentlich zu minimieren. Beispiel:

acl boesesnetz dstdomain einschlaegig.com

Alle Server der Domäne einschlaegig.com werden unter dem Namen boesesnetz zusammengefaßt. Mit der Zeile

http_access deny boesesnetz

wird der Zugriff aller Klienten auf einen Rechner innerhalb vom einschlaegig.com gesperrt. Tippt ein Benutzer zum Beispiel in seinem Browser den URL http: / /www.einschlaegig.com, dann erhält er vom Proxy eine Fehlermeldung.

srcdom_regex: Syntax: acl Name [-II src_regex Ausdruck

Statt eines Domänennamens kann hier zur Identifikation der Klienten ein regulärer Ausdruck benutzt werden. Zum Beispiel:

acl programmierer srcdom_regex -i prog.netzmafia.de

Im obigen Beispiel gehen wir davon aus, daß in der Domäne netzmafia.de nur für die Rechner der Programmierabteilung der Proxy-Zugriff erlaubt werden soll. Alle PCs dieser Abteilung haben die Zeichenkette prog in ihrem Namen:
Sie heißen zum Beispiel pcl-prog.netzmafia.de oder pc5-prog.netzmafia.de. Der optionale Schalter -1 sorgt dafür, daß die Groß- und Kleinschreibung nicht überprüft wird.

Wie schon bei srcdom erwähnt, wird dabei vorausgesetzt, daß es einen DNS für die lokalen Domäne gibt und alle gewünschten Rechner darin eingetragen sind.

dstdom_regex: Syntax: acl Name [-1] dst_regex Ausdruck

Analog zu srcdom_regex kann hierbei ein regulärer Ausdruck für den Namen eines Servers angegeben werden. Zum Beispiel:

acl boesenetze dstdom_regex -i micro

Das obige Beispiel filtert alle Server aus, die die Zeichenkette micro in ihrem Domänen-Namen haben. Damit können Zugriffe auf Domänen wie abmicroc.com, microabc.com oder abcmicro.com verhindert werden. Viele Proxyverwalter in Firmen und Instituten verwenden hier Zeichenketten wie hardcore.

Beachten Sie dabei, daß kurze Zeichenketten immer das Risiko in sich bergen, daß damit auch andere Domains als die unerwünschten ausgeblendet werden. Wenn Sie zum Beispiel die Zeile

acl boese dstdom_regex -i sex

verwenden, können Sie nicht mehr auf die Homepage der Stadt Essex in Connecticut (www.essex.com) zugreifen.

~	time: Syntax: acl Name time [Tag] [stdl:minl-std2-min2]

Mit diesem Befehl läßt sich die Benutzungszeit des Proxies einschränken. Tag ist das Kürzel des gewünschten Wochentages (S~Sonntag, M=Montag, T=Dienstag, W=Mittwoch, H=Donnerstag, F=Freitag, A=Samstag), std lind min sind Stunde und Minute. Im Beispiel

acl geschaeftszeit time 07:00-19:00
http_access allow geschaeftszeit

wird die Proxy-Benutzung auf die Zeit von 7 Uhr bis 19 Uhr festgelegt.

7.4.3	Fehlersuche

Insbesondere wenn Sie, mit Hilfe von regulären Ausdrücken, bestimmte Zugriffs-regeln für Ihren Cache-Server eintragen, schleichen sich schnell Fehler ein. Deshalb ist ein Test der neu eigeführten Filterregeln sehr wichtig. Squid gibt im Normalbetrieb keine Information zu den ACL-Regeln aus, die er gerade verarbeitet. Mit dem Befehl
debug_options ALL,1 28,9

in der squid.conf läßt er sich aber in einen Modus umschalten, in dem er alle verarbeiteten ACL-Anweisungen in die Datei cache.log schreibt. In der squid.conf eines Caches steht beispielsweise:

acl all src 0.0.0.0 / 0.0.0.0
acl boese dstdom_regex -i sex

7.5 	Proxy-Verbünde

acl intern src 192.168.1.0/255.255.255.0 
http_access deny boese
http_access allow intern 
http_access deny all

Es wird also ein Netz namens intern definiert, von dem aus ein Zugriff auf den Cache möglich ist. Die Adresse jeder angeforderten Datei wird mit dem Kommando dstdom_regex auf die Zeichenkette sex untersucht. Im Erfolgsfall wird der Zugriff darauf gesperrt (http_access deny boese). In diesem Beispiel gehen wir davon aus, daß ein Klient in seinem Browser die Adresse www.essex.com eingibt. Sein Rechner hat die IP-Nummer 192.168.1.15.
Mit dem Kommando tail -f /var/squid/logs/cache.log können Sie nun mitverfolgen, wie die Auflösung der einzelnen Zugriffsregeln erfolgt.

2002/04/15 14:04:441 aclCheckFast: list: 0x8207e58
2002/04/15 14:04:441 aclMatchAclList: checking all
2002/04/15 14:04:441 aclMatchAcl: checking ‘acl all src 0.0~0.0/0.0.0.0‘
2002/04/15 14:04:441 aclMatchlp: ‘192.168.1.15‘ found
2002/04/15 14:04:441 aclMatchAclList: returning 1
2002/04/15 14:04:441 aclCheck: checking ‘httpaccess deny boese‘
2002/04/15 14:04:441 aclMatchAcliist: checking boese
2002/04/15 14:04:441 aclMatchAcl: checking ‘acl boese dstdom_regex -i sex‘
2002/04/15 14:04:441 aclMatchRegex: checking ‘www.essex.com
2002/04/15 14:04:441 aclMatchRegex: looking for ‘sex‘
2002/04/15 14:04:441 aclMatchAclList: returning 1
2002/04/15 14:04:441 aclCheck: match found, returning 0
2002/04/15 14:04:441 aclCheckCallback: answer=0

Wie Sie sehen, wird zunächst geprüft, ob der Klient mit seiner IP-Nummer in den Bereich von all fällt. Das trifft natürlich zu. Anschließend wird der Ausdruck sex mit der eingegebenen Adresse www.essex.com verglichen. Nachdem auch das zutrifft und über http_access deny boese der Zugriff auf solche Seiten gesperrt ist, liefert Squid mit answer=0 das Ergebnis: „Der Klient darf die Seite nicht holen.“ Und der Benutzer erhält die Fehlermeldung:

While trying to retrieve the URL: http://www.essex.oom/ The following error was enoountered:

Access Denied.

Access control confiquratiori prevents your request
from being allowed at this time. Please contact your
service provider if you feel this is incorrect.

Die nächsthöhere Stufe nach dem Einsatz eines einzelnen Proxy-Servers besteht darin, mehrere Caches zu einem Verbund zusammenzufassen. Die Theorie, die dahinter steckt, ist dieselbe wie bei einzelnen Servern: Kann ein Froxy in seinem Cache eine angeforderte Datei nicht finden, muß er sie vom Ursprungserver holen. Befindet sich in der Nähe noch ein weiterer Proxy, lohnt es sich, ihn nach der Datei zu fragen. Liegt sie in dessen Cache, ergibt sich ein erheblicher Geschwindigkeitsvorteil beim Holen des Dokuments.
Die Beziehung, die die Caches miteinander in einer Hirarchie haben können, wird in zwei Kategorien eingeteilt: Siblings/Neighbours (=Nachbarn) oder Parents (=E1tern).
Unterhalten zwei Proxies eine Sibling-Beziehung, befinden sie sich hierarchisch auf einer Ebene. 

Der Cache A erhält eine Anfrage nach der Seite abc.html auf dem Server www.veryfar.com. Da sich die Datei nicht auf seiner Festplatte befindet, fragt er seinen Nachbarn oder Sibling (Cache B) nach dem Dokument. Ist sie dort vorhanden, wird sie zunächst an Cache A und dann an den anfragenden Benutzer weitergegeben. Ist sie aber auch im Cache B nicht vorrätig, dann fordert A und nicht etwa B sie vom Ursprungsserver an.
Auf eine einfache Formel gebracht, bedeutet das: Ein Nachbar-Proxy kann nur Dokumente liefern, die bereits in seinem Cache vorhanden sind.
Eltern- oder Parent-Caches stehen in der Hierarchie höher. In Bild 7.12 ist der Weg der einzelnen Abfragen dargestellt. Cache C ist ein Parent des Proxies A.
Der Klient fragt nun wiederum Cache A nach abc . html. Wenn die Datei nicht auf der Festplatte von A liegt, wird die Frage an den Parent weitergegeben. Der Unterschied zur Sibling-Beziehung ergibt sich, wenn C die Datei auch nicht vorrätig hat. C überläßt das Abholen der Datei von veryfar.com nicht dem Cache A, sondern der Parent holt die Datei selbst. Mit anderen Worten: Ein ParentCache liefert immer eine Datei, wenn er gefragt wird.
Wann Proxies zueinander in Sibling- oder Parent-Beziehung stehen sollten, läßt sich am besten anhand eines konkreten Beispieles nachvollziehen:
In einem großen Unternehmen besitzen die einzelnen Abteilungen eigene ProxyServer. Vor der Leitung zum Provider sitzt ein weiterer Proxy, der unnötigen Datenverkehr von der teuren Leitung ins Internet fernhalten soll 

In dieser Situation ist es sinnvoll, die einzelnen Abteilungs-Caches so zu konfigurieren, daß sie zueinander in Sibling-Beziehung stehen. Fragt ein Klient seinen Abteilungscache nach einem Dokument, das nicht im Speicher vorhanden ist, dann werden zunächst alle anderen Abteilungsserver nach der Datei gefragt. Konnte keiner das Dokument liefern, wird zuletzt der Parent kontaktiert. Diese Position ist für den Proxy vor der Providerleitung sinnvoll. Er wird zuletzt angesprochen, und, wenn er die Datei liefern kann, ist kein einziges Bit über die Providerleitung übertragen worden.
Die Kommunikation der Proxies untereinander wird über ein eigenes Protokoll namens ICP („Internet-Cache-Protokoll“) realisiert. Das Verfahren und der Einsatz werden in den RFCs 2186 und 2187 beschrieben. ICP befindet sich im ISO/OSI-Schichtenmodell auf Ebene 5 und setzt auf das Protokoll UDP auf.
Um den Zugriff auf andere Caches innerhalb einer Hirarchie freizuschalten, muß zunächst in der squid.conf ein Port für die Ubertragung von ICP-Nachrichten freigeschaltet werden. Dies geschieht über die Zeile

icp_port 3130

Die Definition der Parents und Siblings geschieht über die Konfigurationszeile:
cache_peer Name oder IP-Nummer Typ Proxy-Port ICP-Port [Optionen] Dabei haben die einzelnen Parameter folgende Bedeutungen:

~	Typ: parent oder sibling. Legt die Position in der Hierarchie fest.

~	Proxy-Port: Portnummer, auf der der jeweilige Cache von seinen Klienten angesprochen wird. Hier ist die Nummer einzusetzen, die in seiner squid.conf unter http_port angegeben ist. Standardwert ist 3128, aber viele Betreiber verwenden 8080.

ICP-Port: Portnummer, auf der der jeweilige Cache ICP-Meldungen empfangen kann. Hier ist die Nummer einzusetzten, die in seiner squid.conf unter icp_port angegeben ist. Standardwert ist: 3130.

Optionen: Hiermit können diverse Einstellungen vorgenommen werden, die die Kommunikation der Caches untereinander beeinflussen. Die wohl wichtigste Option ist proxy-only. Sie sorgt dafür, daß Dokumente des angegebenen Proxies nicht noch einmal im lokalen Cache abgespeichert werden.

Zusätzlich kann in der Konfiguration mit dem Befehl cachepeerAomain angegeben werden, für welche Domain ein Cache zuständig sein soll. Die Zeile

cache_peer_domain parent .meinprovider. com .com

bewirkt, daß der Parent-Cache parent.meinprovider.com nur nach Dokumenten gefragt wird, deren Adressen innerhalb der COM-Domäne liegen.
Setzt man vor den Domänennamen ein Ausrufezeichen, wird das als Verneinung interpretiert. !. com legt also fest, daß der Proxy für alle anderen, aber nicht für die Domäne . com zuständig ist.
Mit dem Befehl neighbor_type_domain läßt sich die Hierarchieebene eines anderen Caches für bestimmte Domänen ändern. Die Zeilen

cache_peer parent parent .meinprovider .com 3128 3130 
neighbor_type_domain parent .meinprovider .com sibling .de

definieren den Cache parent.meinprovider.com als Parent. Für alle Dokumente aus der Domäne .de ist er aber ein Sibling.
Mit verschiedenen weiteren Befehlen läßt sich das Zeitverhalten der ICPAbfragen steuern. Die wichtigsten davon sind:

icp_query_timeout: Zeit in Millisekunden, die nach Absenden eines ICPPaketes auf Antwort gewartet werden soll. Mit dem Standardwert 0 bestimmt squid selbst einen geeigneten Wert anhand der letzten empfangenen Pakete.

dead_peer_timeout: Zeit in Sekunden, nach der ein Cache für „tot“ erklärt wird, wenn er auf keine ICP-Anfrage geantwortet hat. Ein als tot eingestufter Cache wird zukünftig nicht mehr nach Dokumenten gefragt. Sein Status wird aber automatisch wieder zurück in „lebend“ geändert, wenn ein erstes ICP-Paket von ihm empfangen wird.

hirarchy_stoplist Muster: Legt fest, daß für alle Dokumente, deren Adressen das angegebene Muster enthalten, die komplette Cache-Hierarchie übergangen und das Dokument direkt geholt wird. Üblicherweise gibt man hier cgi -bin und ? an. Mit cgi -bin werden die dynamisch generierten Seiten von CGI-Programmen und mit? alle Parameterübergaben erkannt. Diese Parameter können zum Beispiel die Begriffe sein, die Sie in das Eingabefeld einer Suchmaschine eingegeben haben. Die Wahrscheinlichkeit, daß ein Sibling oder Parent ein Dokument mit gleichem Inhalt auf seiner Festplatte hat, ist sehr gering; es lohnt sich darum nicht, ihn danach zu fragen.

no_cache: Mit diesem Befehl wird festgelegt, welche Gruppe von Dokumenten nach dem Holen sofort von der Festplatte entfernt werden sollen. Für diese Dateien ist es sehr unwahrscheinlich, daß sie ein zweites Mal von einem Klienten angefordert werden. Ahnlich wie bei hierarchy_stoplist sollte man hier Muster definieren, die individuelle Dateien, wie zum Beispiel die Ergebnisseiten von Suchmaschienen oder Eingabeformulare, kennzeichnen. Die beiden Zeilen

acl NichtCachen urlpath_regexp cgi-bin \?
no_cache deny NichtCachen

bewirken folgendes: Die erste Zeile faßt alle URLs, die die Zeichenketten cgi -bin oder ein Fragezeichen enthalten, in der Gruppe mit dem Namen NichtCachen zusammen. Die zweite Zeile verbietet dann das Speichern solcher Seiten. Das obige Beispiel sollten Sie auf jeden Fall bei Ihren Installationen verwenden, da es keinen Standardwert gibt.

Ein Beispiel für Proxy-Verbünde:
An einer Hochschule sollen Proxies miteinander zu einer Hierarchie verbunden werden. Jeder Fachbereich besitzt einen eigenen, kleinen Proxy-Server innerhalb des eigenen Subnetzes. Alle diese Server stehen hierarchisch auf derselben Stufe und sollen in einer Sibling-Beziehung miteinander verbunden werden. Zusätzlich sind auf dem Campus zwei große Proxy-Server vor der Leitung zum Provider installiert. Einer davon soll ausschließlich Dokumente aus der Domäne .com speichern und der andere alle restlichen. Die Hochschule besitzt das Klasse-B-Netz 123.123.0.0. Bild 7.14 zeigt die Konfiguration.
Die squid.conf des Servers squid. bwl. campus. edu enthält folgende Zeilen:

# Festlegung der Ports
http_port 3128
icp_port 3130

# Hierarchie definieren
cache_peer proxyl.campus.edu parent 3128 3130

7.14: Proxies auf dem Campus

cache_peer proxy2.campus.edu parent 3128 3130
cache_peer proxy.e-technik.carnpus.edu sibling 3128 3130
cache_peer proxy. informatik.campus.edu sibling 3128 3130

# Proxyl bearbeitet nur die Domaene .COM
cache_peer_domain proxyl . campus . edu com
# Proxy2 den Rest
cache_peer_domain proxy2 . campus . edu . com

dead_peer_timeout 10 seconds

# Dynamische Dokumente nicht cachen hierarchy_stoplist cgi-bin ?
acl LohntNicht urlpath_regex cgi-bin \? 
no_cache deny LohntNicht

# Speicher
cache_mem 12 MB

# Verzeichnisse und Log-Dateien 
cache_dir /var/squid/cache 3000 16 256
cache_access_log /var/squid/logs/access.log 
cache_log /var/squid/logs/cache.log 
cache_store_log /var/squid/logs/store.log

# Diverse Optionen
debug_options ALL, 1
log_fgdn off
# IP-Nurmmer anonymisieren
client_netmask 255.255.255.0

# Zugriffsrechte
a-l all src 0.0.0.0/0.0.0.0
a-l campus src 123.123.0.0/255.255.0.0
# Zugriff nur vom Campusnetz erlaubt
http_access allow campus
http_access deny all
icp_access allow campus 
icp_access deny all

# Mail, UID und GID 
cache_mgr proxyadmin 
cache_effective_user squid 
cache_effective_group nogroup
logfile_rotate 5
append domain .bwl.campus.edu

Die squid. conf des Parent-Servers squidl . campus . edu lautet:

# Festlegung der Ports
http_port 3128
icp_port 3130

# Dynamische Dokumente nicht cachen 
hierarchy_stoplist cgi-bin ? 
acl LohntNicht urlpath_regex cgi-bin \? 
no_cache deny LohntNicht

# Speicher
cachemem 150 MB

# Verzeichnisse und Log-Dateien 
# 30 Giga-Byte fuer COM-Domain
cache_dir /var/squid/cache 30000 16 256 
cache_access_log /var/squid/logs/access. log 
cache_log /var/squid/logs/cache.log
cache_store_log /var/squid/logs/store.log

# Diverse Optionen
debug_options ALL, 1 
log_fqdn off 

# IP-Nummer anonymisieren client_netmask 255.255.255.0

# Zugriffsrechte 
acl all src 0.0.0.0/0.0.0.0 
acl campus src 123.123.0.0/255.255.0.0 

# Zugriff nur vom Campusnatz erlaubt 
http_access allow campus 
http_access deny all
icp_access allow campus
icp_access deny all

# Mail, UID und GID 
cache_mgr proxyadmin 
cache_effective_user squid 
cache_effective group nogroup

logfilerotate 5
append domain .campus.edu

7.6	Performance-Aspekte

Während die Standardkonfiguration von Squid in den meisten kleinen Installationen recht ordentlich arbeitet, muß man sich bei großen Servern mit vielen Hunderttausend oder gar Millionen Zugriffen pro Tag Gedanken über die Optimierung des Cache-Rechners machen.
Beim Neuaufbau eines Caches steht natürlich die Auswahl der geeigneten Hardware als erstes auf dem Plan. Es liegt in der Natur der Sache, daß für den Betrieb von Squid die reine Prozessorleistung weniger ausschlaggebend ist. Deshalb muß nicht unbedingt ein brandaktuelles Rechriersystem eingesetzt werden: Die letzte oder vorletzte Prozessorgeneration tut es auch. Wichtig ist allerdings, wieviel Speicher das System aufnehmen kann. Die Proxy-Performance steht und fällt mit der Anzahl der Objekte die gleichzeitig im RAM gehalten werden können. Beim Kauf des Motherboards sollte man nicht nur auf die Maximalspeichergröße achten, die verwaltet werden kann, sondern immer auch prüfen, ob der Speicher auch noch komplett cachebar ist. Wird diese Grenze überschritten, dann sinkt die Gesamtperformance des Systems gewaltig. Altere Pentium-I-Systeme lassen zum Beispiel oft einen Speicherausbau auf 128 MB zu, können aber nur 64 MB cachen. Auch bei neueren Motherboards mit maximal einem Gigabyte Speicher können manchmal nur 128 MB über den Second-Level-Cache verwaltet werden. Im Zweifelsfall hilft hier ein Blick ins Handbuch oder auf die Webseite des Herstellers.
Auch die Anzahl der Sockel für Speichermodule ist wichtig, damit das System bei Engpässen problemlos erweitert werden kann.
Natürlich hat auch die Netzwerkanbindung des Servers einen großen Anteil an der Reaktionszeit des Proxies. Nach heutigen Maßstäben sollte es also auf jeden Fall ein 100 MBit-Netzwerk sein, das zum Einsatz kommt. Hat man ein komplexes Netz mit hierarchisch verbundenen Caches, dann lohnt es sich, bei einer entsprechenden Anzahl von Anfragen pro Tag, wie sie zum Beispiel bei Campus-Installationen vorkommen, die Proxies sogar mit einem eigenen Netzwerk über einen gemeinsamen Switch zu verbinden.
Ein weiterer, kritischer Punkt ist die Festplatte des Servers. Statistische Messungen an Proxy-Installationen haben ergeben, daß die durchschnittliche Größe eines Dokuments im Cache nur circa 12 KByte beträgt. Daher ist es weniger wichtig, welche Datenrate die eingesetzte Festplatte hat. Da aber im laufenden Betrieb viele Dateien geschrieben und viele alte Objekte aus dem Cache entfernt werden müssen, läßt sich die gesamte Arbeitsgeschwindigkeit am besten steigern, indem man mehrere Festplatten verwendet, die über getrennte Controller parallel angesteuert werden können. Dabei sollte man nicht vergessen, daß auch die LogDateien bei jedem Zugriff erweitert werden. Daher ist es zweckmäßig, auch die access . log, store. log und cache. lcg auf getrennte Platten zu verlagern. Dazu ein Auszug aus der squid. conf eines Systems mit drei getrennten 10-
Gigabyte-Cache-Festplatten:

# Cache-Groesse und Lage
cache dir /squid/cachel 10000 16 128
cache dir /squid/cache2 10000 16 128
cache dir /squid/cache3 10000 16 128

#Log-Files
cache_access_log /squid/cachel/access.log 
cache_log /squid/cache2/cache.log
cache_store_log /squid/cache3 /store.log

Unix-Dateisysteme haben für schnelle Zwischenspeicher die unangenehme Eigenschaft, für jede Datei das Datum des letzten Zugriffs, die sogenannte AccessTime, abzuspeichern. Diese Operation kostet natürlich Zeit und kann die Gesamt-geschwindigkeit von ausgelasteten Proxies erheblich verringern. Daher empfiehlt es sich, dieses Verhalten beim Mounten der Cache-Platten abzuschalten. Dies geschieht mit der Option noatime. Für das obige Beispiel mit drei Cacheplatten lautet der Auszug aus der /etc/ fstab:
/dev/hdbl /squid/cache1	ext2 noatime 1 2
/dev/hdcl /squid/ cache2	ext2 noatime 1 2
/dev/hddl /squid/ cache3	  ext2 noatime 1 2

Ein weiterer Ansatzpunkt für Optimierungen sind die zahlreichen Parameter in der sciuid. conf. Bevor man sie jedoch verändert, sollte man den Zustand des Caches im laufenden Betrieb über einen gewissen Zeitraum beobachten. Zu diesem Zweck stellt Squid eine Schnittstelle zur Verfügung: den Cache-Manager. Er liefert eine ganze Reihe interner Daten über den Cache-Prozeß. Dazu gehören:

•	Belegter Speicher

•	Anzahl der belegten Datei-Deskriptoren

•	Auslastung des Caches