Gilt für SUSE Linux Enterprise Server 15 SP6

44 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 Proxyserver zugreifen
Zulassen oder Verweigern des Zugriffs auf bestimmte Webseiten mithilfe anderer Anwendungen
Erstellen von Statistiken zu häufig besuchten Webseiten für die Bewertung der Internetgewohnheiten

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.

44.1 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.

44.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 Abschnitt 44.6, „Konfigurieren eines transparenten Proxys“ 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.

44.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 wichtig, da es nicht erstrebenswert ist, das Gesamtaufkommen an Datenverkehr im Netzwerk zu erhöhen. Bei 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 zufrieden stellenden Antworten eingehen, wird die Anforderung an den übergeordneten Cache gesendet.

Anmerkung: 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.

44.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.

44.2 Systemanforderungen #

Die Systemanforderungen hängen 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

44.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 wichtig, dass genügend Arbeitsspeicher für den Squid-Vorgang zur Verfügung steht, da die Systemleistung erheblich reduziert wird, 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.

44.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.

44.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.

44.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.

In den meisten Fällen ist die Auswahl des Betriebssystems unerheblich. 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.

44.3 Grundlegende Verwendung von Squid #

squid wird nicht standardmäßig auf SUSE® Linux Enterprise Server installiert. Vergewissern Sie sich daher, dass das Paket auf Ihrem System installiert ist.

Da Squid in SUSE Linux Enterprise Server vorkonfiguriert ist, können Sie das Programm unmittelbar nach der Installation starten. Um Probleme beim Starten zu vermeiden, stellen Sie sicher, dass das Netzwerk mit dem Internet verbunden ist und über mindestens einen Nameserver verfügt. Eine Einwahlverbindung mit dynamischer DNS-Konfiguration kann möglicherweise Probleme verursachen. In diesem Fall geben Sie zumindest den Nameserver an, da Squid nicht startet, wenn kein DNS-Server in /var/run/netconfig/resolv.conf gefunden wird.

44.3.1 Starten von Squid #

Starten Sie Squid mit dem folgenden Befehl:

> sudo systemctl start squid

Soll Squid beim Booten des Systems gestartet werden, aktivieren Sie den Dienst mit systemctl enable squid.

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

Es stehen mehrere Möglichkeiten zur Auswahl, wie Sie überprüfen, ob Squid ausgeführt wird:

Wenn Sie systemctl:
```
> systemctl status squid
```
Die Ausgabe sollte anzeigen, dass Squid loaded und active (running) ist.
Mithilfe von Squid:
```
> sudo squid -k check | echo $?
```
Die Ausgabe sollte 0 sein, kann jedoch auch zusätzliche Meldungen umfassen, z. B. Warnungen.

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

Verwenden Sie squidclient, ein Befehlszeilenwerkzeug, das die Antwort auf eine Webanforderung ausgibt, ähnlich wie wget oder curl.

Im Gegensatz zu wget oder curl baut squidclient automatisch eine Verbindung zum standardmäßig eingerichteten Proxy für Squid auf (localhost:3128). Wenn Sie jedoch die Konfiguration von Squid Bericht haben, müssen Sie squidclient entsprechend konfigurieren. Weitere Informationen finden Sie im squidclient --help.

Beispiel 44.1: Eine Anforderung mit squidclient #

> 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 Beispiel 44.1, „Eine Anforderung mit squidclient“ abgebildete Ausgabe besteht aus zwei Teilen:

den Protokoll-Headern der Antwort( die Zeilen vor der leeren Zeile)
dem eigentlichen 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. Der erste X-Cache-Header kann bedenkenlos ignoriert werden, da er von der internen Caching-Software des ursprünglichen Webservers stammt.

Der Wert Via im Header zeigt 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. Laden Sie dann eine Seite und überprüfen Sie die Antwort-Header in der Kontrollleiste Netzwerk des Inspektors oder der Entwicklertools des Browsers. Die Header sollten ähnlich wie in Beispiel 44.1, „Eine Anforderung mit squidclient“ reproduziert werden.

Damit Benutzer aus dem lokalen System und anderen Systemen auf Squid und das Internet zugreifen können, ändern Sie den Eintrag in den /etc/squid/squid.conf-Konfigurationsdateien von http_access deny all in http_access allow all. Denken Sie jedoch daran, dass damit alle Benutzer den uneingeschränkten Zugriff auf Squid erhalten. 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 Abschnitt 44.5.2, „Optionen für die Zugriffssteuerung“.

Wenn Squid nach kurzer Zeit nicht mehr funktioniert, prüfen Sie, ob ein falscher Nameserver-Eintrag 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.

44.3.3 Stoppen, Neuladen und Neustarten von Squid #

Squid kann auf zweierlei Weise neu geladen werden:

Wenn Sie systemctl:

> sudo systemctl reload squid

oder

> sudo systemctl restart squid

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

Um Squid zu stoppen, verwenden Sie eine der folgenden Optionen:

Wenn Sie systemctl:
```
> 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),

Warnung: 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.

44.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.

44.3.5 Lokaler DNS-Server #

Die Einrichtung eines lokalen DNS-Servers ist sinnvoll, selbst wenn er nicht seine eigene Domäne verwaltet. In diesem Fall fungiert er als reiner Caching-Nameserver und kann DNS-Anforderungen auch über die Root-Nameserver auflösen, ohne dass eine spezielle Konfiguration erforderlich ist (siehe Abschnitt 39.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 beim Herstellen 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 festgelegt. 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 durchgeführt werden, indem die sysconfig-Variable NETCONFIG_DNS_POLICY auf auto festgelegt wird.

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 angeben, wie unter Dynamisches DNS beschrieben. Außerdem muss der statische Nameserver des Anbieters zusammen mit seiner IP-Adresse manuell in der Datei /etc/named.conf unter forwarders angegeben werden.

Tipp: DNS und Firewall

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

44.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 Verzeichnis auf oberster Ebene, in dem Squid die Cache-Auslagerungsdateien 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: Gibt die Sprache und die Email-Adresse des Administrators an.

44.5 Die Squid-Konfigurationsdatei #

Einstellungen für den Squid-Proxyserver werden in der Datei /etc/squid/squid.conf gespeichert. Obwohl die Datei für den ersten Start von Squid nicht geändert werden muss, wird externen Clients zunächst 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.

Zahlreiche Einträge sind mit dem Kommentarzeichen # deaktiviert. 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.

Tipp: 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.

44.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 HOST_NAME TYPE 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 TYPE angegeben. Der Typ kann entweder parent oder sibling sein.

Geben Sie für HOST_NAME 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 sich Squid wie ein Webbrowser und nicht wie ein Proxyserver verhält, deaktivieren Sie die Verwendung des ICP-Protokolls, indem Sie die Optionen default und no-query anhängen.

cache_mem SIZE

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

cache_dir STORAGE_TYPE CACHE_DIRECTORY CACHE_SIZE LEVEL_1_DIRECTORIES LEVEL_2_DIRECTORIES

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 STORAGE_TYPE 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 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 hat unterschiedliche Parameter.

Der Parameter CACHE_DIRECTORY steht für das Verzeichnis des Festplatten-Caches. Standardmäßig ist dies auf /var/cache/squid festgelegt. CACHE_SIZE gibt die maximale Größe dieses Verzeichnisses in Megabyte an. Der festgelegte Standardwert ist 100 MB. Legen Sie eine Größe zwischen 50 % und maximal 80 % des verfügbaren Speicherplatzes fest.

Die Werte LEVEL_1_DIRECTORIES und LEVEL_2_DIRECTORIES geben an, wie viele Unterverzeichnisse im CACHE_DIRECTORY erstellt werden. Standardmäßig werden 16 Unterverzeichnisse auf der ersten Ebene unter CACHE_DIRECTORY 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 LOG_FILE, cache_log LOG_FILE, cache_store_log LOG_FILE

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 NETMASK

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 Email-Adresse ein, da FTP-Server diese auf Gültigkeit überprüfen.

cache_mgr E-MAIL

Wenn Squid abstürzt, wird eine Meldung an die angegebene Email-Adresse gesendet. Der Standardwert ist webmaster.

logfile_rotate VALUE

Bei Verwendung mit squid -k rotate werden Protokolldateien in squid rotiert. Die Dateien werden 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 DOMAIN

Verwenden Sie append_domain, um anzugeben, welche Domäne automatisch angefügt wird, wenn keine angegeben wurde. In der Regel wird hier Ihre eigene Domäne angegeben. Die Eingabe von www in den Browser navigiert also zu Ihrem eigenen Webserver.

forwarded_for STATE

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 TIME, negative_dns_ttl TIME

Wenn diese Optionen konfiguriert sind, speichert Squid bestimmte Fehlerarten im Cache, z. B. 404-Antworten. Die Ausgabe neuer Anforderungen wird danach abgelehnt, selbst wenn die Ressource verfügbar ist.

Standardmäßig ist negative_ttl auf 0 festgelegt und negative_dns_ttl auf 1 minutes. 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 annimmt, 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.

44.5.2 Optionen für die Zugriffssteuerung #

Squid kann den Zugriff auf den Proxyserver über Zugriffssteuerungslisten (Access Control Lists, ACL) steuern, wobei die Regeln in diesen Listen sequenziell verarbeitet werden. Die ACLs müssen zuerst definiert werden, bevor sie verwendet werden können. Squid enthält Standard-ACLs wie all und localhost. Eine ACL wird jedoch erst dann wirksam, wenn sie eine entsprechende Regel http_access enthält.

Die Syntax für die Option acl lautet:

acl ACL_NAME TYPE DATA

Die Platzhalter innerhalb dieser Syntax stehen für Folgendes:

ACL_NAME kann ein beliebiger Name sein.
Für TYPE wählen Sie eine der verfügbaren Optionen im Abschnitt ACCESS CONTROLS der Datei /etc/squid/squid.conf.
Die Angabe für DATA ist vom jeweiligen ACL-Typ abhängig, z. B. Hostnamen, IP-Adressen oder URLs.

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 https://www.squid-cache.org/Versions/v3/3.5/cfgman/acl.html.

Beispiel 44.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).
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. Hierzu müssen Sie ACLs definieren. Die ACLs localhost und all wurden bereits oben definiert und Sie können den Zugriff auf sie über deny oder allow ablehnen oder zulassen. Eine Liste mit einer beliebigen Anzahl von http_access-Einträgen kann erstellt werden, die dann von oben nach unten verarbeitet wird. Je nachdem, welcher Eintrag zuerst auftritt, wird der Zugriff auf die entsprechende URL erlaubt 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 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

Zur besseren Lesbarkeit geben Sie alle Optionen für http_access als Block in der Konfigurationsdatei /etc/squid/squid.conf an.

url_rewrite_program PATH

Mit dieser Option geben Sie einen URL-Rewriter an.

auth_param basic program PATH

Wenn Benutzer auf dem Proxyserver authentifiziert werden müssen, geben Sie ein geeignetes Programm an, beispielsweise /usr/sbin/pam_auth. Beim ersten Zugriff auf pam_auth wird der Benutzer aufgefordert, einen Benutzernamen und ein Passwort einzugeben. 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

Damit wird eine ident-Anforderung für alle Clients aktiviert, die mit einer ACL des Typs src festgelegt sind, um die Identität der einzelnen Benutzer zu ermitteln. Um dies für alle Clients zu aktivieren, können Sie die vordefinierte ACL all als ACL_NAME anwenden.

Auf allen Clients, die durch ident_lookup_access angegeben sind, muss ein ident-Daemon ausgeführt werden. Unter Linux können Sie pidentd (package pidentd) als ident-Daemon verwenden. 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 die Option acl identhosts ident auf den Wert REQUIRED festgelegt, werden alle gültigen Benutzernamen akzeptiert. 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.

44.6 Konfigurieren eines transparenten Proxys #

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 den folgenden Fällen ist die Verwendung des transparenten Proxy-Modus von Squid empfehlenswert:

Wenn alle Clients aus Sicherheitsgründen über einen Proxyserver auf das Internet zugreifen sollen.
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.

Vorgehen 44.1: Squid als transparenter Proxyserver (Befehlszeile) #

Fügen Sie in der Datei /etc/squid/squid.conf den Parameter transparent zur Zeile http_port hinzu. Damit sollten Sie zwei Zeilen erhalten:
```
http_port 3128⎄
http_port 3128 transparent
```
Starten Sie Squid neu:
```
> sudo systemctl restart squid
```
Richten Sie die Firewall so ein, dass HTTP-Datenverkehr an den in http_proxy angegebenen Port umgeleitet wird (im Beispiel oben ist dies Port 3128). Laden Sie dann die Firewall-Konfiguration neu. Hierbei wird vorausgesetzt, dass die Zone internal der LAN-Schnittstelle zugewiesen ist.
```
> sudo firewall-cmd --permanent --zone=internal \
    --add-forward-port=port=80:proto=tcp:toport=3128:toaddr=LAN_IP
> sudo firewall-cmd --permanent --zone=internal --add-port=3128/tcp
> 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-Protokolldateien unter /var/log/squid/access.log an, um zu überprüfen, ob alles ordnungsgemäß funktioniert.

44.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.

Vorgehen 44.2: Einrichten cachemgr.cgi #

Stellen Sie sicher, dass der Apache-Webserver auf Ihrem System ausgeführt wird. Konfigurieren Sie Apache, wie in Kapitel 42, Der HTTP-Server Apache beschrieben. Lesen Sie insbesondere Abschnitt 42.5, „Aktivieren von CGI-Skripten“. Um zu überprüfen, ob Apache bereits ausgeführt wird, verwenden Sie:
```
> sudo systemctl status apache2
```
Wenn der Status inactive vorliegt, starten Sie Apache mit den Standardeinstellungen für SUSE Linux Enterprise Server:
```
> 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 benennen Sie sie cachemgr.conf. Fügen Sie der Datei Folgendes 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 HOST_NAME 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 der Apache-Webserver auf demselben Computer ausgeführt werden, muss die Konfigurationsdatei /etc/squid/squid.conf nicht geändert werden. Überprüfen Sie jedoch, ob die Datei die folgenden Zeilen enthält:
```
http_access allow manager localhost
http_access deny manager
```
  Hiermit können Sie ausschließlich über Ihren Computer (localhost) auf die Manager-Schnittstelle zugreifen.
- Wenn Squid und der 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 den Server an (ersetzen Sie WEB_SERVER_IP durch die IP-Adresse des Webservers):
```
acl webserver src WEB_SERVER_IP/255.255.255.255
```
  Stellen Sie sicher, dass die folgenden Regeln in der Konfigurationsdatei enthalten sind. Denken Sie daran, dass die Reihenfolge wichtig ist.
```
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 eröffnet Ihnen auch den Zugriff auf weitere Aktionen, wie das Schließen des Caches per Fernzugriff oder das Anzeigen weiterer Informationen zum Cache. Um den Zugriff zu aktivieren, konfigurieren Sie die Optionen cache_mgr und cachemgr_passwd mit einem oder mehreren Passwörtern für den Manager und einer Liste der zulässigen Aktionen.
Die folgende Beispielkonfiguration ermöglicht die Anzeige der Indexseite, des Menüs und des 60-minütigen Durchschnitts der Zähler ohne Authentifizierung. Die Konfiguration ermöglicht es auch, mit dem Passwort secretpassword in den Offline-Modus umzuschalten und alles andere zu deaktivieren.
```
cache_mgr user
cachemgr_passwd none index menu 60min
cachemgr_passwd secretpassword offline_toggle
cachemgr_passwd disable all
```
cache_mgr definiert einen Benutzernamen. cache_mgr legt fest, welche Aktionen mit welchen Passwort erlaubt sind.
Die Schlüsselwörter none und disable sind speziell: none entfernt die Notwendigkeit eines Passworts, disable deaktiviert die Funktionalität vollständig.
Die vollständige Liste der Aktionen finden Sie nach der Anmeldung bei cachemgr.cgi. Wie der Vorgang 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, um die Änderungen zu aktivieren:
```
> 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 aus. Wenn ein Benutzername und ein Passwort konfiguriert sind, geben Sie sie an. Klicken Sie auf Fortsetzen und blättern Sie durch die verfügbaren Statistiken.

44.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. Es arbeitet mit Squid-Zugriffsprotokolldateien. Dieses Werkzeug gehört nicht zum standardmäßigen Installationsumfang von SUSE Linux Enterprise Server. Zum Verwenden installieren Sie das Paket calamaris. Weitere Informationen zu Calamaris finden Sie unter https://cord.de/calamaris-english.

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

# 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. Hierzu können Sie die Dateien eine nach der anderen wie im Beispiel oben auflisten oder alternativ access{1..3}.log verwenden.

calamaris akzeptiert 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 Optionen finden Sie auf der Manpage des Programms (man calamaris).

Typisches Beispiel:

# 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.

44.9 Weitere Informationen #

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

Squid-Mailinglisten finden Sie unter https://www.squid-cache.org/Support/mailing-lists.html.