Applies to SUSE Linux Enterprise Server 15 SP2

39 Caching-Proxyserver Squid #

Squid ist ein häufig verwendeter Caching-Proxyserver für Linux- und UNIX-Plattformen. Das bedeutet, dass er angeforderte Internetobjekte, wie beispielsweise Daten auf einem Web- oder FTP-Server, auf einem Computer speichert, der sich näher an der Arbeitsstation befindet, die die Anforderung ausgegeben hat, als der Server. Er kann in mehreren Hierarchien eingerichtet werden. So werden optimale Reaktionszeiten und die Nutzung einer niedrigen Bandbreite garantiert – auch bei Modi, die für den Endbenutzer transparent sind.

Squid fungiert als Caching-Proxyserver. Er leitet Objektanforderungen von Clients (in diesem Fall: von Webbrowsern) an den Server weiter. Wenn die angeforderten Objekte vom Server eintreffen, stellt er die Objekte dem Client zu und behält eine Kopie davon im Festplatten-Cache. Ein Vorteil des Cachings besteht darin, dass mehrere Clients, die dasselbe Objekt anfordern, aus dem Festplatten-Cache versorgt werden können. Dadurch können die Clients die Daten wesentlich schneller erhalten als aus dem Internet. Durch dieses Verfahren wird außerdem der Datenverkehr im Netzwerk reduziert.

Neben dem eigentlichen Caching bietet Squid eine breite Palette von Funktionen:

Verteilung der Last auf mehrere miteinander kommunizierende Hierarchien von Proxyservern
Definition strenger Zugriffssteuerungslisten für alle Clients, die auf den Proxy zugreifen server
Zulassen oder Verweigern des Zugriffs auf bestimmte Webseiten mithilfe anderer Anwendungen
Erstellen von Statistiken zu häufig besuchten Webseiten zur Bewertung der Internetgewohnheiten des Benutzers

Squid ist kein generischer Proxyserver. Er fungiert normalerweise nur bei HTTP-Verbindungen als Proxy. Außerdem unterstützt er die Protokolle FTP, Gopher, SSL und WAIS, nicht jedoch andere Internetprotokolle, wie das News-Protokoll oder Video-Konferenzen-Protokolle. Da Squid nur das UDP-Protokoll für die Bereitstellung von Kommunikation zwischen verschiedenen Caches unterstützt, werden zahlreiche Multimedia-Programme nicht unterstützt.

39.1 Einige Tatsachen zu Proxyservern #

Als Proxyserver für Caching-Aufgaben kann Squid auf verschiedene Weise verwendet werden. In Kombination mit einer Firewall kann er die Sicherheit unterstützen. Mehrere Proxies können gemeinsam verwendet werden. Außerdem kann er ermitteln, welche Objekttypen für wie lange im Cache gespeichert werden sollen.

39.1.1 Squid und Sicherheit #

Squid kann zusammen mit einer Firewall verwendet werden, um interne Netzwerke gegen Zugriffe von außen zu schützen. Die Firewall verweigert allen Clients Zugriff auf externe Dienste mit Ausnahme von Squid. Alle Webverbindungen müssen vom Proxyserver erstellt werden. Bei dieser Konfiguration steuert Squid den gesamten Webzugriff.

Wenn die Firewall-Konfiguration eine entmilitarisierte Zone (demilitarized zone, DMZ) enthält, sollte der Proxyserver in dieser Zone betrieben werden. Unter Section 39.6, “Konfigurieren eines transparenten Proxy” wird beschrieben, wie Sie einen transparenten Proxy implementieren. Dadurch wird die Konfiguration der Clients erleichtert, da sie in diesem Fall keine Informationen zum Proxyserver benötigen.

39.1.2 Mehrere Caches #

Mehrere Instanzen von Squid können für den Austausch von Objekten konfiguriert werden. Dadurch verringert sich die Gesamtlast im System und die Wahrscheinlichkeit erhöht sich, ein Objekt aus dem lokalen Netzwerk abrufen zu können. Außerdem können Cache-Hierarchien konfiguriert werden, sodass ein Cache Objektanforderungen an gleichgeordnete Caches oder einen übergeordneten Cache weiterleiten kann, sodass er Objekte aus einem anderen Cache im lokalen Netzwerk oder direkt von der Quelle anfordern kann.

Die Auswahl einer geeigneten Topologie für die Cache-Hierarchie ist von entscheidender Bedeutung, da es nicht erstrebenswert ist, das Gesamtaufkommen an Datenverkehr im Netzwerk zu erhöhen. Bei sehr großen Netzwerken ist es sinnvoll, einen Proxyserver für jedes Subnetz zu konfigurieren und mit einem übergeordneten Proxyserver zu verbinden, der wiederum mit dem Caching-Proxyserver des ISP verbunden ist.

Diese gesamte Kommunikation wird über das ICP (Internet Cache Protocol) abgewickelt, das über dem UDP-Protokoll ausgeführt wird. Die Übertragungen zwischen den Caches erfolgen über HTTP (Hypertext Transmission Protocol) auf der Grundlage von TCP.

Um den geeignetsten Server zum Anfordern der Objekte zu finden, sendet ein Cache eine ICP-Anforderung an alle gleichgeordneten Proxys. Die gleichgeordneten Proxys beantworten diese Anforderungen über ICP-Antworten. Wenn das Objekt erkannt wurde, verwenden sie einen HIT-Code, wenn nicht, einen MISS-Code.

Wenn mehrere HIT-Antworten gefunden wurden, legt der Proxyserver fest, von welchem Server heruntergeladen werden soll. Diese Entscheidung ist unter anderem davon abhängig, welcher Cache die schnellste Antwort gesendet hat bzw. welcher näher ist. Wenn keine zufriedenstellenden Antworten eingehen, wird die Anforderung an den übergeordneten Cache gesendet.

Note: Wie vermeidet Squid die Verdoppelung von Objekten?

Um eine Verdopplung der Objekte in verschiedenen Caches im Netzwerk zu vermeiden, werden andere ICP-Protokolle verwendet, wie beispielsweise CARP (Cache Array Routing Protocol) oder HTCP (Hypertext Cache Protocol). Je mehr Objekte sich im Netzwerk befinden, desto größer ist die Wahrscheinlichkeit, das gewünschte Objekt zu finden.

39.1.3 Caching von Internetobjekten #

Viele im Netzwerk verfügbaren Objekte sind nicht statisch, wie beispielsweise dynamisch generierte Seiten und TLS/SSL-verschlüsselte Inhalte. Derartige Objekte werden nicht im Cache gespeichert, da sie sich bei jedem Zugriff ändern.

Um zu bestimmen, wie lange Objekte im Cache gespeichert werden sollen, wird Objekten einer von mehreren Status zugewiesen. Web- und Proxyserver ermitteln den Status eines Objekts, indem sie Header zu diesen Objekten hinzufügen, beispielsweise “Zuletzt geändert” oder “Läuft ab”, und das entsprechende Datum. Andere Header, die angeben, dass Objekte nicht im Cache gespeichert werden dürfen, können ebenfalls verwendet werden.

Objekte im Cache werden in der Regel aufgrund mangelnden Speicherplatzes ersetzt. Dazu werden Algorithmen wie LRU (last recently used) verwendet. Dies bedeutet, dass der Proxy die Objekte löscht, die am längsten nicht mehr angefordert wurden.

39.2 Systemanforderungen #

Die Systemanforderungen hängen weitgehend von der maximalen Netzwerkauslastung ab, die das System tragen muss. Prüfen Sie daher die Belastungsspitzen, da diese mehr als das Vierfache des Tagesdurchschnitts betragen können. Im Zweifelsfall ist es vorzuziehen, die Systemanforderungen zu hoch einzuschätzen. Wenn Squid an der Grenze seiner Leistungsfähigkeit arbeitet, kann es zu erheblichen Einbußen in der Qualität des Diensts führen. Die folgenden Abschnitte widmen sich den einzelnen Systemfaktoren in der Reihenfolge ihrer Wichtigkeit:

RAM-Größe
CPU-Geschwindigkeit/physische CPU-Cores
Größe des Festplatten-Cache
Festplatten/SSDs und ihre Architektur

39.2.1 RAM #

Der von Squid benötigte Arbeitsspeicher (RAM) steht in direktem Verhältnis zur Anzahl der Objekte im Cache. RAM ist wesentlich schneller als eine Festplatte/SSD. Daher ist es sehr wichtig, dass genügend Arbeitsspeicher für den Squid-Vorgang zur Verfügung steht, da die Systemleistung erheblich eingeschränkt ist, wenn die Swap-Festplatte verwendet wird.

Außerdem speichert Squid Cache-Objekt-Bezüge und häufig angeforderte Objekte im Hauptspeicher, um das Abrufen dieser Daten zu beschleunigen. Außerdem gibt es andere Daten, die Squid im Arbeitsspeicher benötigt, beispielsweise eine Tabelle mit allen IP-Adressen, einen exakten Domänennamen-Cache, die am häufigsten angeforderten Objekte, Zugriffssteuerungslisten, Puffer usw.

39.2.2 Prozessor #

Squid ist so eingestellt, dass es am besten mit niedrigeren Prozessor-Core-Zahlen arbeitet (4–8 physische Cores), wobei jeder höchste Leistung bietet. Technologien, die virtuelle Cores bereitstellen, wie Hyperthreading, können sich negativ auf die Leistung auswirken.

Um mehrere CPU-Cores am besten zu nutzen, ist es notwendig, mehrere Worker-Threads einzurichten, die in verschiedene Caching-Geräte schreiben. Standardmäßig ist die Unterstützung mehrerer Cores deaktiviert.

39.2.3 Größe des Festplatten-Cache #

Bei einem kleinen Cache ist die Wahrscheinlichkeit eines HIT (Auffinden des angeforderten Objekts, das sich bereits dort befindet) gering, da der Cache schnell voll ist und die weniger häufig angeforderten Objekte durch neuere ersetzt werden. Wenn beispielsweise 1 GB für den Cache zur Verfügung steht und die Benutzer nur Datenverkehr im Umfang von 10 MB pro Tag in Anspruch nehmen, dauert es mehr als hundert Tage, um den Cache zu füllen.

Die einfachste Methode zur Ermittlung der benötigten Cache-Größe geht von der maximalen Übertragungsrate der Verbindung aus. Bei einer Verbindung mit 1 Mbit/s beträgt die maximale Übertragungsrate 128 KB/s. Wenn dieser Datenverkehr vollständig im Cache gespeichert wird, ergeben sich in einer Stunde 460 MB. Bei der Annahme, dass dieser Datenverkehr in nur 8 Arbeitsstunden generiert wird, würden 3,6 GB an einem einzigen Tag erreicht werden. Da in der Regel nicht das gesamte Volumen der Verbindung ausgeschöpft wird, kann angenommen werden, dass das Gesamtdatenvolumen, das auf den Cache zukommt, bei etwa 2 GB liegt. Daher sind bei diesem Beispiel 2 GB Festplattenspeicher erforderlich, damit Squid die durchsuchten Daten eines Tags im Cache speichern kann.

39.2.4 Festplatten-/SSD-Architektur #

Da Geschwindigkeit beim Caching eine wichtige Rolle spielt, muss diesem Faktor besondere Aufmerksamkeit gewidmet werden. Bei Festplatten wird dieser Parameter als random seek time (Zufallszugriffszeit) oder random read performance (Zufallsleseleistung) beschrieben – gemessen in Millisekunden. Da die Datenblöcke, die Squid von der Festplatte/SSD liest oder auf die Festplatte/SSD schreibt, tendenziell eher klein sind, ist die Zugriffszeit/Leseleistung der Festplatte/SSD entscheidender als ihr Datendurchsatz.

Für die Verwendung als Proxyserver sind Festplatten mit hoher Rotationsgeschwindigkeit oder SSDs die beste Wahl. Bei der Verwendung von Festplatten kann es besser sein, mehrere kleinere Festplatten zu verwenden. Dabei sollte jede ein einzelnes Cache-Verzeichnis aufweisen, um übermäßige Lesezeiten zu vermeiden.

Die Verwendung von RAID-Systemen bietet eine erhöhte Zuverlässigkeit, bedeutet jedoch Einschränkungen bei der Geschwindigkeit. Vermeiden Sie jedoch aus Leistungsgründen (Software-)RAID5 und ähnliche Einstellungen.

Die Wahl des Dateisystems ist in der Regel nicht entscheidend. Jedoch kann mit der Einhängeoption noatime die Leistung verbessert werden. Squid stellt eigene Zeitstempel bereit und erfordert daher nicht, dass das Dateisystem die Zugriffszeiten überwacht.

39.3 Grundlegende Verwendung von Squid #

Installieren Sie das Paket, falls es nicht bereits installiert ist squid bereitgestellt. squid gehört nicht zu den Paketen, die standardmäßig auf SUSE Linux Enterprise Server installiert werden.

Squid ist in SUSE Linux Enterprise Server bereits vorkonfiguriert. Sie können das Programm unmittelbar nach der Installation starten. Um einen reibungslosen Start zu gewährleisten, sollte das Netzwerk so konfiguriert werden, dass mindestens ein Namenserver und das Internet erreicht werden können. Es können Probleme auftreten, wenn eine Einwahlverbindung zusammen mit einer dynamischen DNS-Konfiguration verwendet wird. In diesem Fall sollte zumindest der Nameserver angegeben werden, da Squid nicht startet, wenn kein DNS-Server in /var/run/netconfig/resolv.conf gefunden wird.

39.3.1 Starten von Squid #

Verwenden Sie zum Starten von Squid Folgendes:

tux > sudo systemctl start squid

Wenn Sie möchten, dass Squid beim Booten des Systems gestartet wird, aktivieren Sie den Dienst mit systemctl enable squid.

39.3.2 Überprüfen, ob Squid ausgeführt wird #

Wählen Sie zum Überprüfen, ob Squid ausgeführt wird, eine der folgenden Optionen:

Mithilfe von systemctl:
```
tux > systemctl status squid
```
Die Ausgabe dieses Kommandos sollte Folgendes für Squid anzeigen: loaded (geladen) und active (running) (aktiv (wird ausgeführt)).
Mithilfe von Squid:
```
tux > sudo squid -k check | echo $?
```
Die Ausgabe dieses Befehls sollte 0 lauten, kann jedoch zusätzliche Warnungen oder Meldungen umfassen.

Um die Funktionsfähigkeit von Squid im lokalen System zu testen, wählen Sie eine der folgenden Optionen:

Zum Testen können Sie squidclient verwenden, ein Kommandozeilenwerkzeug, das die Antwort auf eine Webanforderung ausgeben kann, ähnlich wie wget oder curl.

Anders als diese Werkzeuge verbindet squidclient sich automatisch mit dem Standard-Proxy-Setup von Squid, localhost:3128. Wenn Sie jedoch die Konfiguration von Squid geändert haben, müssen Sie squidclient mithilfe von Kommandozeilenoptionen so konfigurieren, dass es andere Einstellungen verwendet. Weitere Informationen erhalten Sie mit squidclient --help.

Example 39.1: Eine Anforderung mit squidclient #

tux > squidclient http://www.example.org
HTTP/1.1 200 OK
Cache-Control: max-age=604800
Content-Type: text/html
Date: Fri, 22 Jun 2016 12:00:00 GMT
Expires: Fri, 29 Jun 2016 12:00:00 GMT
Last-Modified: Fri, 09 Aug 2013 23:54:35 GMT
Server: ECS (iad/182A)
Vary: Accept-Encoding
X-Cache: HIT
x-ec-custom-error: 1
Content-Length: 1270
X-Cache: MISS from moon1
X-Cache-Lookup: MISS from moon:3128
Via: 1.1 moon (squid/3.5.16)2
Connection: close

<!doctype html>
<html>
<head>
    <title>Example Domain</title>
[...]
</body>
</html>

Die in Example 39.1, “Eine Anforderung mit squidclient” angezeigte Ausgabe kann in zwei Teile aufgeteilt werden:

Die Protokoll-Header der Antwort: die Zeilen vor der leeren Zeile.
Der eigentliche Inhalt der Antwort: die Zeilen nach der leeren Zeile.

Um zu überprüfen, ob Squid verwendet wird, sehen Sie sich im Header die ausgewählten Zeilen an:

Der Wert X-Cache im Header gibt an, dass das angeforderte Dokument nicht im Squid-Cache (MISS) des Computers moon gespeichert war.

Das Beispiel oben enthält zwei X-Cache-Zeilen. Sie können den ersten X-Cache-Header ignorieren. Er wird von der internen Caching-Software erstellt, die vom Webserver stammt.

Der Wert Via im Header gibt die HTTP-Version, den Namen des Computers und die verwendete Squid-Version an.

Mithilfe eines Browsers: Richten Sie localhost als Proxy und 3128 als Port ein. Sie können dann eine Seite laden und die Antwort-Header in der Kontrollleiste Netzwerk des Inspektors oder der Entwicklertools des Browsers überprüfen. Die Header sollten ähnlich wie in Example 39.1, “Eine Anforderung mit squidclient” reproduziert werden.

Um Benutzern aus dem lokalen System und anderen Systemen den Zugriff auf Squid und das Internet zu ermöglichen, müssen Sie den Eintrag in den Konfigurationsdateien /etc/squid/squid.conf von http_access deny all in http_access allow all ändern. Beachten Sie dabei jedoch, dass dadurch jedem der vollständige Zugriff auf Squid ermöglicht wird. Legen Sie daher ACLs (Access Control Lists = Zugriffssteuerungslisten) fest, die den Zugriff auf den Proxyserver steuern. Nach Bearbeiten der Konfigurationsdatei muss Squid neu geladen oder neu gestartet werden. Weitere Informationen zu ACLs finden Sie in Section 39.5.2, “Optionen für die Zugriffssteuerung”.

Wenn Squid nach kurzer Zeit nicht mehr funktioniert, obwohl das Programm erfolgreich gestartet wurde, überprüfen Sie, ob ein fehlerhafter Nameservereintrag vorliegt oder ob die Datei /var/run/netconfig/resolv.conf fehlt. Squid protokolliert die Ursache eines Startfehlers in der Datei /var/log/squid/cache.log.

39.3.3 Stoppen, Neuladen und Neustarten von Squid #

Zum Neuladen von Squid stehen die folgenden Verfahren zur Auswahl:

Mithilfe von systemctl:

tux > sudo systemctl reload squid

Alternativ:

tux > sudo systemctl restart squid

Verwenden von YaST:
Klicken Sie im Squid-Modul auf die Schaltfläche Einstellungen jetzt speichern und Squid neu starten

Zum Anhalten von Squid stehen die folgenden Verfahren zur Auswahl:

Mithilfe von systemctl:
```
tux > sudo systemctl stop squid
```
Verwenden von YaST
Klicken Sie im Squid-Modul auf die Schaltfläche Squid jetzt stoppen Schaltfläche.

Das Herunterfahren von Squid kann einige Zeit dauern, da Squid bis zu eine halbe Minute wartet, bis die Verbindungen zu den Clients unterbrochen und die Daten auf die Festplatte geschrieben werden (siehe Option shutdown_lifetime in /etc/squid/squid.conf),

Warning: Beenden von Squid

Das Beenden von Squid mit kill oder killall kann den Cache beschädigen. Damit Squid neu gestartet werden kann, müssen beschädigte Caches gelöscht werden.

39.3.4 Entfernen von Squid #

Durch das Entfernen von Squid aus dem System werden die Cache-Hierarchie und die Protokolldateien nicht entfernt. Um diese zu entfernen, müssen Sie das Verzeichnis /var/cache/squid manuell löschen.

39.3.5 Lokaler DNS-Server #

Die Einrichtung eines lokalen DNS-Servers ist sinnvoll, selbst wenn er nicht seine eigene Domäne verwaltet. Er fungiert dann einfach als Nur-Cache-Namenserver und kann außerdem DNS-Anforderungen über die Root-Namenserver auflösen, ohne dass irgendeine spezielle Konfiguration erforderlich ist (siehe Section 31.4, “Starten des BIND-Nameservers”). Wie dies durchgeführt werden kann, hängt davon ab, ob Sie bei der Konfiguration der Internetverbindung dynamisches DNS auswählen.

Dynamisches DNS

Normalerweise wird bei dynamischem DNS der DNS-Server während des Aufbaus der Internetverbindung vom Anbieter festgelegt und die lokale Datei /var/run/netconfig/resolv.conf wird automatisch angepasst. Dieses Verhalten wird in der Datei /etc/sysconfig/network/config mit der sysconfig-Variablen NETCONFIG_DNS_POLICY gesteuert. Legen Sie NETCONFIG_DNS_POLICY mit dem YaST-sysconfig-Editor auf "" fest.

Fügen Sie anschließend den lokalen DNS-Server in der Datei /var/run/netconfig/resolv.conf hinzu. Verwenden Sie die IP-Adresse 127.0.0.1 für localhost. Auf diese Weise kann Squid immer den lokalen Nameserver finden, wenn er gestartet wird.

Um den Zugriff auf den Nameserver des Anbieters zu ermöglichen, geben Sie ihn zusammen mit seiner IP-Adresse in der Konfigurationsdatei /etc/named.conf unter forwarders an. Mit dynamischem DNS kann dies automatisch während des Verbindungsaufbaus erreicht werden. Setzen Sie hierzu die sysconfig-Variable NETCONFIG_DNS_POLICY mit dem YaST-sysconfig-Editor auf autobereitgestellt.

Statisches DNS

Beim statischen DNS finden beim Verbindunsgsaufbau keine automatischen DNS-Anpassungen statt, sodass auch keine sysconfig-Variablen geändert werden müssen. Sie müssen jedoch den lokalen DNS-Server in der Datei /var/run/netconfig/resolv.conf, wie unter Dynamisches DNS beschrieben, angeben. Außerdem muss der statische Nameserver des Anbieters zusammen mit seiner IP-Adresse manuell in der Datei /etc/named.conf unter Forwarders angegeben werden.

Tip: DNS und Firewall

Wenn eine Firewall ausgeführt wird, müssen Sie sicherstellen, dass DNS-Anforderungen durchgelassen werden.

39.4 Das YaST-Squid-Modul #

Das YaST-Squid-Modul enthält die folgenden Registerkarten:

Start: Gibt an, wie Squid gestartet wird und welcher Firewall-Port auf welchen Schnittstellen geöffnet ist.
HTTP-Ports: Definiert alle Ports, die Squid auf HTTP-Anforderungen von Clients überwacht.
Aktualisierungsschemata: Gibt an, wie Squid die Objekte im Cache behandelt.
Cache-Einstellungen: Definiert Einstellungen für den Cache-Speicher, die maximale und minimale Objektgröße und vieles mehr.
Cache-Verzeichnis: Definiert das übergeordnete Verzeichnis, in dem Squid alle Cache-Swap-Dateien speichert.
Zugriffssteuerung: Steuert den Zugriff auf den Squid-Server mithilfe von ACL-Gruppen.
Protokollierung und Zeitüberschreitung: Definiert die Pfade zu den Protokolldateien für Zugriff, Cache und Cache-Speicher sowie die Zeitüberschreitung für die Verbindungen und die Client-Lebensdauer.
Sonstige: Legt die Sprache und die Email-Adresse des Administrators fest.

39.5 Die Squid-Konfigurationsdatei #

Alle Einstellungen für den Squid-Proxyserver werden in der Datei /etc/squid/squid.conf vorgenommen. Beim ersten Start von Squid sind keine Änderungen in dieser Datei erforderlich, externen Clients wird jedoch ursprünglich der Zugriff verweigert. Der Proxy ist für localhost verfügbar. Der Standardport ist 3128. Die vorinstallierte Konfigurationsdatei /etc/squid/squid.conf bietet detaillierte Informationen zu den Optionen sowie zahlreiche Beispiele.

Viele Einträge sind kommentiert und beginnen deshalb mit dem Kommentarzeichen #. Die relevanten Spezifikationen finden Sie am Ende der Zeile. Die angegebenen Werte entsprechen in der Regel den Standardwerten, daher hat das Entfernen der Kommentarzeichen ohne Ändern der Parameter in der Regel keine Auswirkungen. Lassen Sie die kommentierten Zeilen nach Möglichkeit unverändert und geben Sie die Optionen zusammen mit den geänderten Werten in der Zeile darunter ein. Auf diese Weise können die Standardwerte problemlos wiederhergestellt und mit den Änderungen verglichen werden.

Tip: Anpassen der Konfigurationsdatei nach einer Aktualisierung

Wenn Sie eine Aktualisierung einer früheren Squid-Version durchgeführt haben, sollten Sie die neue Datei /etc/squid/squid.conf bearbeiten und nur die in der vorherigen Datei vorgenommenen Änderungen übernehmen.

Manchmal werden Squid-Optionen hinzugefügt, entfernt oder geändert. Daher kann Squid möglicherweise aufhören, ordnungsgemäß zu funktionieren, wenn Sie die alte squid.conf-Datei verwenden.

39.5.1 Allgemeine Konfigurationsoptionen #

Nachfolgend finden Sie eine Liste mit einer Auswahl an Konfigurationsoptionen für Squid. Die Liste ist nicht vollständig. Das Squid-Paket enthält eine vollständige Liste mit einfacher Veranschaulichung in der Datei /etc/squid/squid.conf.documented.

http_port PORT

Dies ist der Port, den Squid auf Client-Anforderungen überwacht. Der Standardport ist 3128, 8080 wird jedoch ebenfalls häufig verwendet.

cache_peer HOSTNAME TYP PROXY-PORT ICP-PORT

Mit dieser Option kann ein Netzwerk mit Caches erstellt werden, die zusammen arbeiten. Der Cache-Peer ist ein Computer, der auch ein Netzwerk-Cache hostet und in einer Beziehung zu Ihrem eigenen steht. Der Typ der Beziehung wird als TYP angegeben. Der Typ kann entweder parent oder sibling sein.

Geben Sie als HOSTNAME den Namen oder die IP-Adresse des verwendeten Proxyservers an. Geben Sie für PROXY-PORT die Portnummer zur Verwendung in einem Browser an (in der Regel 8080). Legen Sie für ICP-PORT den Wert 7 oder, wenn der ICP-Port des übergeordneten Proxy nicht bekannt ist und seine Verwendung für den Anbieter nicht wichtig ist, den Wert 0 fest.

Damit Squid sich wie ein Webbrowser verhält und nicht wie ein Proxyserver, unterbinden Sie die Verwendung des ICP-Protokolls. Hängen Sie dazu die Optionen default und no-query an.

cache_mem GRÖSSE

Diese Option legt fest, wie viel Arbeitsspeicher Squid für besonders beliebte Antworten verwenden kann. Der Standardwert ist 8 MB. Dieser Wert gibt nicht die Arbeitsspeichernutzung von Squid an und kann überschritten werden.

cache_dir SPEICHERTYP CACHE-VERZEICHNIS CACHE-GRÖSSE EBENE-1-VERZEICHNISSE EBENE-2-VERZEICHNISSE

Die Option cache_dir legt das Verzeichnis für den Festplatten-Cache fest. In der Standardkonfiguration auf SUSE Linux Enterprise Server erstellt Squid keinen Festplatten-Cache.

Der Platzhalter SPEICHERTYP kann einen der folgenden Werte haben:

Verzeichnisbasierte Speichertypen: ufs, aufs (Standard), diskd. Alle drei Typen sind Variationen des Speicherformats ufs. Dabei wird ufs als Teil des Squid-Core-Threads ausgeführt, aufs wird in einem separaten Thread ausgeführt und diskd verwendet einen separaten Prozess. Dies bedeutet, dass die letzten beiden Typen das Blockieren von Squid aufgrund von Datenträger-E/A vermeiden.
Datenbankbasierte Speichersysteme: rock. Dieses Speicherformat basiert auf einer einzelnen Datenbankdatei, in der jedes Objekt eine oder mehrere Arbeitsspeichereinheiten einer festen Größe (“Slots”) einnimmt.

Im Folgenden werden nur die Parameter für Speichertypen beschrieben, die auf ufs basieren. rock weist etwas andere Parameter auf.

Der Parameter CACHE-VERZEICHNIS steht für das Verzeichnis des Festplatten-Cache. Standardmäßig lautet dieses /var/cache/squid. CACHE-GRÖSSE ist die maximale Größe dieses Verzeichnisses in Megabyte. Der festgelegte Standardwert ist 100 MB. Legen Sie eine Größe zwischen 50 % und maximal 80 % des verfügbaren Speicherplatzes fest.

Die letzten zwei Werte EBENE-1-VERZEICHNISSE und EBENE-2-VERZEICHNISSE geben an, wie viele Unterverzeichnisse im CACHE-VERZEICHNIS erstellt werden. Standardmäßig werden 16 Unterverzeichnisse auf der ersten Ebene unter CACHE-VERZEICHNIS und 256 jeweils innerhalb dieser Ebenen erstellt. Diese Werte sollten nur nach reiflicher Überlegung erhöht werden, da zu viele Verzeichnisse zu Leistungsproblemen führen können.

Wenn ein Cache von mehreren Datenträgern gemeinsam verwendet wird, müssen Sie mehrere cache_dir-Zeilen angeben.

cache_access_log PROTOKOLLDATEI, cache_log PROTOKOLLDATEI, cache_store_log PROTOKOLLDATEI

Diese drei Optionen geben die Pfade an, in denen Squid alle Aktionen protokolliert. In der Regel muss hier nichts geändert werden. Bei hoher Auslastung von Squid kann es sinnvoll sein, Cache und Protokolldateien auf mehrere Datenträger zu verteilen.

client_netmask NETZMASKE

Diese Option ermöglicht die Maskierung von IP-Adressen des Client in der Protokolldatei, indem eine Teilnetzmaske angewendet wird. Um beispielsweise für die letzte Zahl der IP-Adresse 0 festzulegen, geben Sie 255.255.255.0 an.

ftp_user E-MAIL

Diese Option ermöglicht die Einstellung des Passworts, das Squid für die anonyme FTP-Anmeldung verwenden soll. Geben Sie hier eine gültige E-Mail-Adresse ein, da manche FTP-Server diese auf Gültigkeit überprüfen.

cache_mgr E-MAIL

Bei unerwartetem Absturz sendet Squid eine Nachricht an diese E-Mail-Adresse. Der Standardwert ist webmaster.

logfile_rotate WERT

Wenn Sie squid -k rotate ausführen, kann Squid ein Rotationssystem für Protokolldateien einführen. Bei diesem Prozess werden die Dateien nummeriert und nach dem Erreichen des angegebenen Werts wird die älteste Datei überschrieben. Der Standardwert ist 10. Hierdurch werden Protokolldateien mit den Nummern 0 bis 9 rotiert.

Auf SUSE Linux Enterprise Server erfolgt die Rotation der Protokolldateien jedoch mithilfe von logrotate und der Konfigurationsdatei /etc/logrotate.d/squid automatisch.

append_domain DOMÄNE

Verwenden Sie append_domain, um anzugeben, welche Domäne automatisch angefügt wird, wenn keine angegeben wurde. In der Regel wird hier die eigene Domäne angegeben, sodass bei der Angabe von www im Browser ein Zugriff auf Ihren eigenen Webserver erfolgt.

forwarded_for STATUS

Ist für diese Option on festgelegt, wird eine Zeile wie die folgende zum Header hinzugefügt:

X-Forwarded-For: 192.168.0.1

Wenn Sie für diese Option off festlegen, entfernt Squid die IP-Adresse und den Systemnamen des Client aus den HTTP-Anforderungen.

negative_ttl ZEIT, negative_dns_ttl ZEIT

Sind diese Optionen festgelegt, speichert Squid manche Fehlertypen im Cache, wie beispielsweise 404-Antworten. Squid lässt dann keine neuen Anforderungen mehr zu, selbst wenn die Ressource verfügbar wäre.

Standardmäßig sind für negative_ttl der Wert 0 und für negative_dns_ttl der Wert 1 minutes festgelegt. Dies bedeutet, dass negative Antworten auf Webanforderungen standardmäßig nicht im Cache gespeichert werden und negative Antworten auf DNS-Anforderungen für eine Minute im Cache gespeichert werden.

never_direct allow ACL-NAME

Um zu verhindern, dass Squid Anforderungen direkt aus dem Internet entgegennimmt, müssen Sie mit der Option never_direct die Verbindung mit einem anderen Proxyserver erzwingen. Dieser muss zuvor unter cache_peer angegeben worden sein. Wenn all als ACL-NAME angegeben ist, werden alle Anforderungen direkt an den übergeordneten Proxy (parent) weitergeleitet. Dies kann beispielsweise dann erforderlich sein, wenn Sie einen Anbieter verwenden, der die Verwendung der eigenen Proxys vorschreibt oder der durch seine Firewall direkten Internetzugriff verweigert.

39.5.2 Optionen für die Zugriffssteuerung #

Squid bietet ein detailliertes System für die Steuerung des Zugriffs auf den Proxyserver. Diese ACLs (Access Control Lists = Zugriffssteuerungslisten) sind Listen mit Regeln, die nacheinander verarbeitet werden. Die ACLs müssen zuerst definiert werden, bevor sie verwendet werden können. Einige Standard-ACLs, wie beispielsweise all und localhost, sind bereits vorhanden. Die bloße Definition einer ACL bedeutet jedoch noch nicht, dass sie tatsächlich angewendet wird. Dies passiert nur dann, wenn eine entsprechende http_access-Regel vorhanden ist.

Die Syntax für die Option acl lautet:

acl ACL_NAME TYPE DATA

Die Platzhalter innerhalb dieser Syntax stehen für Folgendes:

Der Name ACL-NAME kann frei gewählt werden.
Als TYP können Sie aus einer Vielzahl verschiedener Optionen wählen, die Sie im Abschnitt ACCESS CONTROLS in der Datei /etc/squid/squid.conf finden.
Die Angabe für DATA hängt vom jeweiligen ACL-Typ ab, beispielsweise Hostnamen, IP-Adressen oder URLs, und kann auch von einer Datei gelesen werden.

Sollen Regeln in das YaST-Squid-Modul eingefügt werden, öffnen Sie das Modul und klicken Sie auf die Registerkarte Zugriffssteuerung. Klicken Sie unter der Liste der ACL-Gruppen auf Hinzufügen und geben Sie den Namen Ihrer Regel, den Typ und die zugehörigen Parameter ein.

Weitere Informationen zu den Typen von ACL-Regeln finden Sie in der Squid-Dokumentation unter http://www.squid-cache.org/Versions/v3/3.5/cfgman/acl.html.

Example 39.2: Definieren von ACL-Regeln #

acl mysurfers srcdomain .example.com 1
acl teachers src 192.168.1.0/255.255.255.0 2
acl students src 192.168.7.0-192.168.9.0/255.255.255.0 3
acl lunch time MTWHF 12:00-15:00 4

1	Diese ACL definiert `mysurfers` als alle Benutzer, die von `.example.com` kommen (wie durch Reverse-Lookup für die IP bestimmt wurde).
2	Diese ACL definiert `teachers` als die Benutzer von Computern, deren IP-Adressen mit `192.168.1.` beginnen.
3	Diese ACL definiert `students` als die Benutzer von Computern, deren IP-Adressen mit `192.168.7.`, `192.168.8.` oder `192.168.9.` beginnen.
4	Diese ACL definiert `lunch` als eine Uhrzeit an den Tagen Montag bis Freitag zwischen 12 und 15 Uhr.

http_access allow ACL-NAME

http_access definiert, wer den Proxyserver verwenden darf und wer auf welche Seiten im Internet zugreifen kann. Hierfür müssen ACLs festgelegt werden. localhost und all wurden bereits oben festgelegt. Sie können den Zugriff dafür verweigern oder erlauben mit deny bzw. allow. Es können Listen mit einer beliebigen Anzahl von http_access -Einträgen erstellt und von oben nach unten verarbeitet werden. Je nachdem, was zuerst vorkommt, wird der Zugriff auf die betreffende URL gestattet oder verweigert. Der letzte Eintrag muss immer http_access deny all sein. Im folgenden Beispiel hat localhost freien Zugriff auf alle Elemente, während allen anderen Hosts der Zugriff vollständig verweigert wird:

http_access allow localhost
http_access deny all

In einem anderen Beispiel, bei dem diese Regeln verwendet werden, hat die Gruppe teachers immer Zugriff auf das Internet. Die Gruppe students erhält nur montags bis freitags während der Mittagspause Zugriff:

http_access deny localhost
http_access allow teachers
http_access allow students lunch time
http_access deny all

Geben Sie für eine bessere Lesbarkeit in der Konfigurationsdatei /etc/squid/squid.conf alle http_access-Optionen in einem Block an.

url_rewrite_program PFAD

Geben Sie mit dieser Optionen einen URL-Rewriter an.

auth_param basic program PFAD

Wenn Benutzer auf dem Proxyserver authentifiziert werden müssen, geben Sie ein geeignetes Programm an, beispielsweise /usr/sbin/pam_auth. Beim ersten Ausführen von pam_auth wird ein Anmeldefenster geöffnet, in dem der Benutzer den Benutzernamen und das Passwort eingeben muss. Außerdem ist eine ACL erforderlich, sodass nur Clients mit einer gültigen Anmeldung das Internet benutzen können:

acl password proxy_auth REQUIRED

http_access allow password
http_access deny all

Wird in der Option acl proxy_auth der Wert REQUIRED verwendet, bedeutet dies, dass alle gültigen Benutzernamen akzeptiert werden. REQUIRED kann auch durch eine Liste mit erlaubten Benutzernamen ersetzt werden.

ident_lookup_access allow ACL-NAME

Lassen Sie damit eine ident-Anforderung für alle Clients, die mit einer ACL des Typs src festgelegt sind, ausführen, um die Identität der einzelnen Benutzer zu ermitteln. Alternativ dazu (verwenden Sie dies für alle Clients) können Sie die vordefinierte ACL all als ACL-NAME anwenden.

Auf allen Clients, die durch ident_lookup_access abgedeckt sind, muss ein ident-Daemon ausgeführt werden. Unter Linux können Sie pidentd (package pidentd ) als ident-Daemon verwenden. Für andere Betriebssysteme ist in der Regel kostenlose Software verfügbar. Um sicherzustellen, dass nur Clients mit einem erfolgreichen ident-Lookup zulässig sind, definieren Sie eine entsprechende ACL:

acl identhosts ident REQUIRED

http_access allow identhosts
http_access deny all

Wird in der Option acl identhosts ident der Wert REQUIRED verwendet, bedeutet dies, dass alle gültigen Benutzernamen akzeptiert werden. REQUIRED kann auch durch eine Liste mit erlaubten Benutzernamen ersetzt werden.

Durch die Verwendung von ident kann die Zugriffszeit erheblich reduziert werden, da die ident-Lookups für jede Anforderung wiederholt werden.

39.6 Konfigurieren eines transparenten Proxy #

Ein transparenter Proxy fängt die Anforderungen des Webbrowsers ab und beantwortet sie, sodass der Webbrowser die angeforderten Seiten erhält, ohne dass bekannt ist, woher sie kommen. Wie der Name bereits andeutet, verläuft der gesamte Prozess für den Benutzer transparent.

In der Regel arbeiten Sie folgendermaßen mit Proxyservern: Der Webbrowser sendet Anforderungen an einen bestimmten Port des Proxyservers und der Proxy liefert immer diese erforderlichen Objekte, unabhängig davon, ob sie sich im Cache befinden oder nicht. In manchen Fällen ist die Verwendung des transparenten Proxy-Modus von Squid empfehlenswert:

Wenn aus Sicherheitsgründen alle Clients einen Proxyserver für den Zugriff auf das Internet verwenden sollten.
Wenn alle Clients einen Proxyserver verwenden müssen, unabhängig davon, ob sie sich dessen bewusst sind.
Wenn der Proxyserver in einem Netzwerk verschoben wird, die vorhandenen Clients jedoch ihre alte Konfiguration beibehalten müssen.

Procedure 39.1: Squid als transparenter Proxyserver (Kommandozeile) #

Fügen Sie in der Datei /etc/squid/squid.conf in der Zeile mit der Option http_port den Parameter transparent hinzu. Damit sollten Sie zwei Zeilen erhalten:
```
http_port 3128
http_port 3128 transparent
```
Starten Sie Squid neu:
```
tux > sudo systemctl restart squid
```
Richten Sie die Firewall so ein, dass der HTTP-Datenverkehr an den unter http_proxy angegebenen Port umgeleitet wird. Im obigen Beispiel ist dies der Port 3128. Laden Sie dann die Firewall-Konfiguration neu. Hierbei wird vorausgesetzt, dass die Zone internal der LAN-Schnittstelle zugewiesen ist.
```
tux > sudo firewall-cmd --permanent --zone=internal \
    --add-forward-port=port=80:proto=tcp:toport=3128:toaddr=LAN_IP
tux > sudo firewall-cmd --permanent --zone=internal --add-port=3128/tcp
tux > sudo firewall-cmd --reload
```
Ersetzen Sie LAN_IP durch die IP-Adresse Ihrer LAN-Schnittstelle oder der Schnittstelle, die durch Squid überwacht wird.
Sehen Sie sich die Squid-Protokolle unter /var/log/squid/access.log an, um zu überprüfen, ob alles ordnungsgemäß funktioniert.

39.7 Verwenden der Cache-Manager-CGI von Squid (`cachemgr.cgi`) #

Die Cache-Manager-CGI (Common Gateway Interface; cachemgr.cgi) ist ein CGI-Dienstprogramm für die Anzeige der Statistiken zur Arbeitsspeichernutzung eines laufenden Squid-Prozesses. Außerdem bietet er eine bequeme Methode zur Verwaltung des Cache und zur Anzeige der Statistiken ohne Anmeldung beim Server.

Procedure 39.2: Einrichten von cachemgr.cgi #

Stellen Sie sicher, dass der Apache-Webserver auf Ihrem System ausgeführt wird. Konfigurieren Sie Apache, wie in Chapter 37, Der HTTP-Server Apache beschrieben. Lesen Sie insbesondere Section 37.5, “Aktivieren von CGI-Skripten”. Um zu überprüfen, ob Apache bereits ausgeführt wird, verwenden Sie:
```
tux > sudo systemctl status apache2
```
Wenn inactive angezeigt wird, können Sie Apache mit den Standardeinstellungen von SUSE Linux Enterprise Server starten:
```
tux > sudo systemctl start apache2
```
Aktivieren Sie nun cachemgr.cgi in Apache. Erstellen Sie hierzu eine Konfigurationsdatei für ein ScriptAlias.
Erstellen Sie die Datei im Verzeichnis /etc/apache2/conf.d und nennen Sie sie cachemgr.conf. Fügen Sie Folgendes in der Datei hinzu:
```
ScriptAlias /squid/cgi-bin/ /usr/lib64/squid/

<Directory "/usr/lib64/squid/">
Options +ExecCGI
AddHandler cgi-script .cgi
Require host HOST_NAME
</Directory>
```
Ersetzen Sie HOSTNAME durch den Hostnamen des Computers, über den Sie auf cachemgr.cgi zugreifen möchten. Dies erlaubt es nur Ihrem Computer, auf cachemgr.cgi zuzugreifen. Um den Zugriff von allen Computern zu erlauben, verwenden Sie stattdessen Require all granted.
- Wenn Squid und Ihr Apache-Webserver auf demselben Computer ausgeführt werden, sollten keine Änderungen an /etc/squid/squid.conf notwendig sein. Überprüfen Sie jedoch, ob /etc/squid/squid.conf die folgenden Zeilen enthält:
```
http_access allow manager localhost
http_access deny manager
```
  Diese Zeilen erlauben Ihnen den Zugriff auf die Manager-Schnittstelle über Ihren eigenen Computer (localhost), jedoch nicht über andere Computer.
- Wenn Squid und Ihr Apache-Webserver auf verschiedenen Computern ausgeführt werden, müssen Sie zusätzliche Regeln hinzufügen, um den Zugriff über das CGI-Skript auf Squid zu erlauben. Geben Sie eine ACL für Ihren Server an (ersetzen Sie WEBSERVER-IP durch die IP-Adresse Ihres Webservers):
```
acl webserver src WEB_SERVER_IP/255.255.255.255
```
  Stellen Sie sicher, dass die folgenden Regeln in der Konfigurationsdatei enthalten sind. Verglichen mit der Standardkonfiguration ist nur die Regel in der Mitte neu. Jedoch ist die Sequenz wichtig.
```
http_access allow manager localhost
http_access allow manager webserver
http_access deny manager
```
(Optional) Optional können Sie ein oder mehrere Passwörter für cachemgr.cgi konfigurieren. Dies erlaubt auch den Zugriff auf weitere Aktionen, wie das Schließen des Cache per Fernzugriff oder das Anzeigen weiterer Informationen zum Cache. Konfigurieren Sie hierfür die Optionen cache_mgr und cachemgr_passwd mit einem oder mehreren Passwörtern für den Manager und einer Liste der erlaubten Aktionen.
Beispiel: Verwenden Sie die folgende Konfiguration, um explizit das Anzeigen der Indexseite, des Menüs und des 60-minütigen Durchschnitts der Zähler ohne Authentifizierung zu aktivieren, das Umschalten des Offline-Modus mithilfe des Passworts secretpassword zu aktivieren und alles andere vollständig zu deaktivieren:
```
cache_mgr user
cachemgr_passwd none index menu 60min
cachemgr_passwd secretpassword offline_toggle
cachemgr_passwd disable all
```
cache_mgr legt einen Benutzernamen fest. cache_mgr legt fest, welche Aktionen mit welchen Passwort erlaubt sind.
Die Schlüsselwörter none und disable haben besondere Eigenschaften: none entfernt die Notwendigkeit eines Passworts, disable inaktiviert die Funktion vollständig.
Die vollständige Liste der Aktionen finden Sie nach der Anmeldung bei cachemgr.cgi. Wie die Operation in der Konfigurationsdatei zu referenzieren ist, sehen Sie in der Zeichenkette nach &operation= in der URL der Aktionsseite. all ist ein besonderes Schlüsselwort und steht für alle Aktionen.
Laden Sie Squid und Apache neu, nachdem die Konfigurationsdatei geändert wurde:
```
tux > sudo systemctl reload squid
```
Um die Statistiken anzuzeigen, rufen Sie die Seite cachemgr.cgi auf, die Sie zuvor eingerichtet haben. Diese könnte beispielsweise http://webserver.example.org/squid/cgi-bin/cachemgr.cgi lauten.
Wählen Sie den richtigen Server und geben Sie, falls dies festgelegt wurde, den Benutzernamen und das Passwort ein. Klicken Sie dann auf Fortsetzen und blättern Sie durch die verschiedenen Statistiken.

39.8 Erstellung von Cache-Berichten mit Calamaris #

Calamaris ist ein Perl-Skript, mit dem Berichte über die Cache-Aktivität im ASCII- oder HTML-Format erstellt werden können. Es arbeitet mit nativen Squid-Zugriffsprotokolldateien. Die Calamaris-Homepage befindet sich unter http://cord.de/calamaris-english. Dieses Werkzeug gehört nicht zum standardmäßigen Installationsumfang von SUSE Linux Enterprise Server. Zum Verwenden installieren Sie das Paket calamaris.

Melden Sie sich als root an und geben Sie Folgendes ein:

root # cat access1.log [access2.log access3.log] | calamaris OPTIONS > reportfile

Wenn Sie mehr als eine Protokolldatei verwenden, stellen Sie sicher, dass sie chronologisch geordnet sind, wobei ältere Dateien zuerst aufgelistet werden. Dies können Sie erreichen, indem Sie die Dateien eine nach der anderen wie im Beispiel oben auflisten oder indem Sie access{1..3}.log verwenden.

calamaris erfordert die folgenden Optionen:

-a: Ausgabe aller verfügbaren Berichte
-w: Ausgabe als HTML-Bericht
-l: Einschließen einer Meldung oder eines Logos in den Berichtsheader

Weitere Informationen zu den verschiedenen Optionen finden Sie auf der man-Seite des Programms (mancalamaris.

Typisches Beispiel:

root # cat access.log.{10..1} access.log | calamaris -a -w \
> /usr/local/httpd/htdocs/Squid/squidreport.html

Dadurch wird der Bericht im Verzeichnis des Webservers gespeichert. Zur Anzeige des Berichts ist Apache erforderlich.

39.9 Weiterführende Informationen #

Besuchen Sie die Squid-Homepage unter http://www.squid-cache.org/. Hier finden Sie das “Squid-Benutzerhandbuch” und eine umfassende Sammlung mit FAQ zu Squid.

Außerdem sind Mailinglisten für Squid unter http://www.squid-cache.org/Support/mailing-lists.html verfügbar.