Konfiguration des Proxyservers Squid

(8696 Worte insgesamt im Text)
(31891 mal aufgerufen)  Druckerfreundliche Ansicht [1]

Letzte Änderung: 23.09.2013

Inhalt

Die Konfigurationsdatei von Squid [2] ist mit rund 125 Einträgen wohl neben der des Apache eine der längsten Konfigurationsdateien, die es bei einem Server gibt. Aus diesem Grund habe ich die einzelnen Sektionen zum Anlass genommen, die Darstellung hier ein wenig zu untergliedern. Wer den gesamten Artikel haben möchte, der kann ja immer noch auf das Drucker-Symbol [3] klicken.

Wichtig: Als Grundlage für die hier gemachten Einstellungen dient Squid Version 2.5 - frühere Versionen haben unter Umständen andere Konfigurationseinstellungen!

Installation von Squid

Sollte Interesse bestehen, kann sicherlich auch noch ein wenig über die Installation von Squid geredet werden - aber dies sollte heute eigentlich in allen Distributionen problemlos mit den entsprechenden Tools funktionieren.

Interessant dürfte allerdings manchmal die einkompilierte Funktionalität sein. Hier hilft der Aufruf von:

squid -v

als root. Damit werden die Optionen angezeigt, mit welchen Squid kompiliert wurde. Sollte da z.B. kein diskd angezeigt werden, dann muss man wohl oder übel doch neu kompilieren. Dann helfen aber die sogenannten "Source"-Pakete der Distribution weiter. Nach deren Installation findet man bei RPM basierten Systemen unter /usr/src/packages/SPECS eine Datei squid.spec, welche mit einem beliebigen Editor bearbeitet werden kann. Dort müssen dann ggfs. bei den "configure-Optionen" noch weitere Einstellungen gemacht und das Paket dann mit:

rpmbuild -ba squid.spec

neu gebaut werden. Fehlende Pakete werden gemeldet - die fehlenden Dateien bzw. Pakete findet man bei SUSE [16] LINUX am einfachsten, indem man auf der DVD mit dem Befehl zgrep in der Datei ARCHIVES.gz danach sucht.

Ein Beispiel:

zgrep /usr/lib/libjpeg.so ARCHIVES.gz

Nun sollten die Pakete angezeigt werden, die die fehlende Datei /usr/lib/libjpeg.so enthalten. Diese Pakete einfach nachinstallieren und wieder neu anfangen.


NETWORK OPTIONS

In diesem Abschnitt finden Sie alle Parameter, die für den Betrieb von Squid in einem Netzwerk erforderlich sind. So muss Squid u.a. wissen:

Squid benutzt für die Kommunikation mit anderen Rechnern die Protokolle TCP, UDP und ICP auf speziellen Ports.

TCP und UDP werden zur Kommunikation mit Webservern und Clients verwendet, ICP zur Kommunikation mit anderen Proxies. Für jede Verbindung benötigt Squid Angaben, über welche Ports und IP-Adressen diese Verbindungen aufgebaut werden sollen.

Im Normalfall brauchen Sie hier aber nichts zu ändern und können mit den Vorgaben arbeiten.

http_port

Über
http_port 3128

legen Sie den Port fest, auf welchem Squid Anfragen entgegen nehmen soll. Sie können hier aber auch weitere Angaben machen:
http_port 192.168.0.5:8080

Diese Anweisung lässt Squid nur auf der Netzwerkkarte mit der IP-Adresse 192.168.0.5 und dort auf dem Port 8080 auf Anfragen lauschen. Wenn Sie Squid auf mehreren Adressen und/ oder mehreren Ports lauschen lassen möchten, dann verwenden Sie die Direktive http_port mehrfach:

http_port 192.168.0.5:8080
http_port 192.168.0.5:3128

ssl_unclean_shutdown

Einige Browser (z.B. der Internet Explorer) unterstützen SSL nicht vollständig. Um hier Fehler zu vermeiden, bietet Squid hier einen Workaround an. Normalerweise reicht die Voreinstellung:

ssl_unclean_shutdown off

Wenn Sie aber Probleme beim Surfen auf SSL-gesicherten Seiten haben, dann versuchen Sie einmal hier den Wert auf:

ssl_unclean_shutdown on

zu ändern.

icp_port

Um Anfragen von Nachbar-Caches anzunehmen, lauscht Squid normalerweise auf dem ICP-Port 3130. Wenn Sie keine Anfragen von Nachbar-Caches akzeptieren möchten, dann können Sie hier den Wert auf:

icp_port 0

ändern.

htcp_port

Auch über den HTCP-Port empfängt Squid Anfragen von Nachbar-Caches. Auch dies können Sie abstellen, indem Sie hier den Wert '0' einstellen:

htcp_port 0

OPTIONS WHICH AFFECT THE NEIGHBOR SELECTION ALGORITHM

Hier wird es schon etwas interessanter. Wenn Sie z.B. einen Provider haben, der eigene Proxy-Server für Sie bereitstellt, dann können Sie durch die zusätzliche Nutzung dieser externen Server einen enormen Geschwindigkeitsgewinn erreichen:

cache_peer

Mit der Anweisung:

cache_peer www-proxy.t-online.de parent 80 0 no-query no-digest default no-netdb-exchange

verwenden wir z.B. den Proxy-Server von T-Online (Achtung: dieser ist nur über T-Online-Accounts erreichbar).


Alle Optionen, die hier möglich sind:
OptionErklärung
proxy-onlyDaten von diesem Cache sollen nicht zusätzlich noch einmal lokal gespeichert werden (etwa, weil dieser Cache schnell genug erreichbar ist).
weight=nWerden mehrere Caches angegeben, kann hiermit eine Gewichtung zwischen den unterschiedlichen Caches herbeigeführt werden. Die Zahl muss eine Ganzzahl sein. Höhere Werte führen zu einer höhren Gewichtung. Also wird ein Cache mit der Gewichtung 2 öfter befragt als einer mit der Standard-Gewichtung 1.
ttl=nNur sinnvoll, wenn die anderen Caches sich in einer Multicast-Gruppe befinden. Hiermit kann die TTL (Lebenszeit) von ICP-Anfragen an diese Hosts festgelegt werden. Damit lässt sich in Zusammenhang mit den anderen Werten hier eine schnelle Kaskadierung erreichen, da bei Hosts, die nicht schnell genug antworten einfach auf den nächsten Cache ausgewichen wird.
no-queryHiermit sollen keine ICP-Anfragen an diesen Host (Cache) gesendet werden. Nötig bei einigen Caches, die z.B. ICP-Anfragen gar nicht annehmen.
defaultDieser Cache soll die letzte Möglichkeit für Squid sein, eine Anfrage nicht direkt an die angeforderte Adresse zu senden. Wenn also andere Caches nicht erreicht werden können, wird dieser Cache befragt, bevor eine Anfrage an die vom Browser angeforderte Adresse gesendet wird. 'default' setzt auch ein 'no-query' für diesen Cache voraus.
round-robinHier werden mehrere Caches zusammengefasst und eine Anfrage an all die hier angegebenen Caches gleichzeitig versendet. ICP-Anfragen werden hierfür nicht benötigt.
multicast-responderDieser Cache ist ein Mitglied einer Multicast-Gruppe. Es werden zwar keine ICP-Anfragen an diesen Host gesendet - ICP-Anfragen von diesem Cache werden aber akzeptiert.
closest-onlyHier wird der Nachbar-Cache genutzt, welcher die kürzeste RTT (Round Trip Time - Antwortzeit) zum Originalserver hat.
no-digestVon diesem Cache werden keine Übersichten über dessen Cache angefordert. Damit kann Squid dann aber diesen Host nicht geziehlt aufgrund der vorhandenen Informationen ansprechen.
no-netdb-exchangeKeine Anfragen an die ICMP-RTT Datenbank des Nachbarcaches. In dieser Datenbank werden normalerweise Informationen über die auf anderen Servern vorgehaltenen Seiten gespeichert. Damit kann Squid nicht den Server anfragen, welcher die angeforderte Seite schon in seinem Cache hat.
no-delayNormalerweise werden Anfragen von anderen Caches so wie Anfragen von normalen Clients behandelt. Wenn dann ein Delay-Pool eingerichtet ist, der z.B. den Download bestimmter Seiten begrenzt, wird auch der anfragende Cache nur mit der entsprechenden Geschwindigkeit bedient. Mit dieser Option werden Anfragen dieses Caches nicht durch Delay-Pools beeinflusst: der Cache bekommt die volle Geschwindigkeit.
login=user:passwordWenn der andere Cache eine Authentifizierung verlangt, dann gibt man hier den Nutzernamen und das Passwort ein, welches an den Nachbar-Cache für die Authentifizierung gesendet werden soll.
login=PASSWenn die lokalen Nutzer sich am Nachbar-Cache anmelden sollen, dann führt diese Option zum Ziel: damit werden die Authentifizierungsdaten der Nutzer an den anderen Cache weitergeleitet. Dies funktioniert aber nur mit der Basic-Authentifizierung am lokalen Proxy. Um die Nutzer zu authentifizieren muss der Nachbar-Cache über diese Nutzer-Datenbank verfügen. Die Nutzerdaten (Name und Passwort) werden direkt an den anderen Cache weitergeleitet - man sollte diese Option also mit Vorsicht einsetzen.
login=*:passwordUm die Sache ein wenig sicherer zu machen und dem anderen Cache zwar nicht das Passwort aber den Nutzernamen zu übermitteln, können Sie auch ein 'default-Passwort' an den Nachbar-Cache übergeben. Sie können hinter dem '*' noch ein paar Informationen übermitteln, die dem Nachbar-Cache z.B. die Information darüber geben, welcher Proxy oder aus welcher Domain die Anfrage kam. Ansonsten gilt hier dasselbe wie für die "login=user:password" Nutzung.
connect-timeout=nnNach dieser Zeit wird der Nachbar-Cache als "Down" angesehen und die Anfrage an einen anderen Cache gestellt oder direkt geholt.
digest-URL=urlWenn Cache-Digests zugelassen sind, wird der Cach-Digest von diesem Nachbar-Proxy über die hier angegebene URL anstelle des Standardverfahrens angefordert.
allow-missNormalerweise schaut Squid zuerst in der Cache-Digest-Datenbank des Nachbar-Caches nach, ob dieser eine angeforderte Seite schon im Cache hat und stellt nur dann eine Anfrage an diesen Cache. Mit dieser Option wird dieses Verhalten abgeschaltet und Squid fragt den Nachbar-Cache auch dann, wenn dieser die Seite nicht in seinem Cache hat.
max-connDiese Angabe begrenzt die gleichzeitigen Verbindungen zu diesem Nachbar-Proxy.
htcpSquid sendet normalerweise nur ICP-Anfragen an Nachbar-Caches. Mit dieser Option wird Squid angewiesen statt dessen HTCP-Anfragen zu senden. Dazu sollte auch der icp_port auf 4827 gesetzt werden.
carp-load-factor=fSquid unterstützt Teile von CARP (Cache Array Routing Protocol) einem Protokoll, welches eine Erweiterung von ICP (Internet Cache Protocol) darstellt. Damit lassen sich ganze Cache-Farmen bilden und Client können mehrere Caches und deren Routing-Informationen in einem Array inkl. der Information der in ihrem Cache gespeicherten Daten sammeln. Wenn in einem Netzwerk mehr als 20MB an Traffic anfällt, dann sollte CARP anstelle von ICP (und entsprechend viele Caches) eingesetzt werden. Mit dieser Option teilt man Squid dann mit, dass der angegebene Cache Mitglied in einem solchen CARP-Verband ist.
Eine weitere Möglichkeit stellt die zusätzliche Verwendung des kommerziellen Programms "Webwasher [17]" dar, welches an Schulen und Bildungseinrichtungen kostenlos eingesetzt werden darf. Wählen Sie bitte die Linux-Version und befolgen Sie anschliessend die ausführliche Anleitung zur Installation.

Hier müssen allerdings einige zusätzliche Regeln definiert werden, welche Squid anweisen, nur für Webseiten und nicht für FTP-Dateien bei Webwasher anzufragen. Die zugehörende Konfiguration lautet insgesamt (kann so in die squid.conf eingetragen werden):

cache_peer localhost parent 9090 7 proxy-only no-query default no-digest no-delay
acl ftp url_regex -i ftp://*
always_direct allow ftp

Wenn Sie den Webwasher laut Anleitung installiert haben, dann verhindert er je nach Einstellung zukünftig u.a Pop-Ups und Werbeeinblendungen.

cache_host_domain

Mit
cache_host_domain www-proxy.t-online.de .de

beschränken wir die Domains, nach denen der Proxy-Server von T-Online befragt wird, auf Domains aus Deutschland.

cache_stoplist

Die Anweisung
cache_stoplist cgi-bin ?

sagt man Squid, dass er URL's, die ein "cgi-bin" oder ein "?" enthalten direkt holen und nicht über andere Caches holen soll. Da es sich hierbei meist um Suchanfragen (z.B. in google) und damit um dynamisch generierte Webseiten handelt ist das auch in Ordnung.

no_cache

Um zu verhindern, dass Squid bestimmte Anfragen oder Webseiten überhaupt in seinem Cache zwischenspeichert, kann man hier eine oder mehrere ACLs setzen und mit der Direktive:

no_cache deny ACL-NAME
das Zwischenspeichern abschalten. Ein Beispiel, welches verhindert, dass Squid
a) dynamische Seiten und
b) die eigene Homepage
zwischenspeichert wollen wir hier einmal angeben:
acl QUERY urlpath_regex cgi-bin \?
acl HOMEPAGE dstdomain www.linux-schulserver.de
no_cache deny QUERY
no_cache deny HOMEPAGE

icp_query_timeout

Normalerweise setzt Squid automatisch einen Timeout von 2000 Milisekunden für ICP-Anfragen an einen Nachbar-Cache. Wenn Sie dieses Verhalten abschalten wollen, dann setzen Sie hier eine '0'.

icp_query_timeout 0

dead_peer_timeout

Hier geben Sie an, nach welcher Zeitspanne Squid einen Nachbar-Cache als "Down" ansehen und künftig keine Anfragen mehr an ihn stellen soll.

dead_peer_timeout 10 seconds

Dies ist der default-Wert. Squid sendet weiterhin Anfragen an diesen Host - wartet aber nicht mehr auf Antworten. Wenn dennoch eine Antwort kommt, nimmt Squid diesen Host wieder in die Anfrageliste auf und der Timeout wird wieder gesetzt.


OPTIONS WHICH AFFECT THE CACHE SIZE

Hier lässt sich wohl am ehesten am Proxy-Server tunen. Immerhin handelt es sich hierbei um Einstellungen, welche die Speichernutzung - sowohl im RAM als auch auf der Festplatte - betreffen.

cache_mem

Gleich der erste Eintrag ist ein Volltreffer - normalerweise nutzt Squid nur 8 MB RAM. Man kann zwar von einer gewissen Kompensation reden, wenn man bedenkt, dass Linux von sich aus oft benötigte Dateien von der Festplatte im RAM cached aber mit einer höheren Einstellung lassen sich hier mehr Objekte direkt von Squid im Speicher halten, ohne dass zusätzliche Mechanismen benötigt werden.

Hier eine kleine Tabelle mit Werten, die sich in der Praxis bewährt haben:

RAM im System
RAM für Squid
bis 32 MB
8 MB
32 MB
16 MB
64 MB
24 MB
128 MB
96 MB
256 MB
96 MB

Darüber hinaus sollte man für Squid ungefähr ein Viertel des vorhandenen RAMs reservieren.

Bitte beachten Sie, dass Sie (laut Handbuch [18]) immer ein Vielfaches von 4 MB verwenden sollten und der gesammte von Squid verwendete Speicherplatz durchaus höher sein kann! (Dies ist hier aber noch nie vorgekommen...)

Wenn Sie über ein System mit ausreichend RAM (>=128 MB) verfügen und auch die weiter unten eingestellten delay_pools vernünftig nutzen möchten, sollten Sie hier mindestens 32 MB vorsehen. Ich habe mich bei meinem Beispiel sogar für 128 MB entschieden:

cache_mem 128 MB

maximum_object_size

Dateien über die hier angegebene Grösse werden NICHT vom Proxy zwischengespeichert. Eine HTML-Datei erreicht selten die vorgegebene 4 MB Grenze - wenn Sie aber mit ihren Schülern einmal ein Video ansehen wollen oder als Administrator ein Updatepaket für mehrere Rechner aus dem Internet laden müssen, sollten Sie hier höhere Werte einstellen. (Unter Webmin [19] lautet der passende Eintrag hier "Maximale Grösse zwischengespeicherter Objekte".)

maximum_object_size 65536 kB

maximum_object_size_in_memory

Das, was die Übersetzung schon sagt:
Dateien, welche grösser sind als hier angegeben werden NICHT im RAM gehalten. Standard sind 8 KB.

maximum_object_size_in_memory 4 KB

cache_replacement_policy

Wann sollen Dateien aus dem Cache entfernt werden? Seit der Version 2.5 von Squid stehen dafür mehrere Möglichkeiten zur Verfügung:

Standard So, wie bislang... Siehe auch lru [20]
heap LFUDA (Heap least frequently used with dynamic aging) Häufig angefragte Objekte werden im Cache gehalten, selten angefragte werden freigegeben, unabhängig von deren Grösse. Damit wird ein häufiger angefragtes grosses Objekt ggf. auf Kosten vieler kleiner Objekte im Cache gehalten. Damit steigt die Trefferrate für grosse Objekte auf Kosten kleinerer. Die "Byte"-Trefferrate liegt hier also höher, da nur ein Treffer für eine grosse Datei schon viele Treffer für kleinere Dateien ausgleichen kann.
lru (Last Recently Used) Behält die zuletzt angefragten Objekte im Cache, unabhängig von Grösse und Alter der Objekte. Also werden grosse Objekte genauso behandelt, wie kleine. Wenn neue Objekte angefragt werden, werden ältere Dateien aus dem Cache gelöscht.
heap GDSF (Greedy-Dual-Size Frequency) Kleine, häufig angefragte Objekte werden auf Kosten grosser weniger häufig angefragter Objekte im Cache gehalten. Damit wird die Warscheinlichkeit eines Treffers für kleinere Objekte gesteigert.
heap LRU (Heap Last frequently used) Erweitertes lru Verfahren. Hier wird zusätzlich noch das Alter der zwischengespeicherten Seiten berücksichtigt.

Jetzt stehen wir natürlich vor einem Dilemma: Lieber kurze Antwortzeiten (damit GDSF) oder weniger Traffic-Volumen (damit LFUDA)?

Wenn eine Schule ihren Internetanschluss nach Volumen abrechnet empfielt sich in jedem Fall die Verwendung von "heap least frequently used with dynamic aging LFUDA".

Unter Webmin lautet die entsprechende Einstellung "Dynamic least frequently used". Damit einher geht allerdings auch ein grösserer Wert bei der maximum_objekt_size [21]!

Damit lohnt sich die Umstellung also nur, wenn gleichzeitig auch der Wert für cache_mem erhöht wird. So ab 32 MB RAM für Squid sollte sich die Umstellung bemerkbar machen - darunter fahren Sie mit den alten Werten auf jeden Fall besser.
cache_replacement_policy heap LFUDA
Eine andere Möglichkeit wäre noch ein goldener Mittelweg durch Kombination beider Verfahren: Squid kann den Cache-Bereich im Hauptspeicher und denjenigen auf der Festplatte unterschiedlich verwalten. Also kann man im RAM mit "GSDF" möglichst viele kleine Objekte zwischenspeichern und auf der Festplatte die "grossen Brocken" auslagern, indem man dort LFUDA nutzt. In diesem Fall sähe die Konfiguration so aus:
cache_replacement_policy heap LFUDA
memory_replacement_policy heap GDSF

Zur letzten Zeile erfahren Sie mehr im nächsten [22] Abschnitt.

memory_replacement_policy

Genauso, wie die Dateien auf der Festplatte verwaltet werden, so funktioniert das auch im RAM. icon_wink

memory_replacement_policy heap LFUDA

LOGFILE PATHNAMES AND CACHE DIRECTORIES

cache_dir

Hier stellen Sie u.a. die Grösse des verwendeten Festplatten-Caches ein. Bitte achten Sie darauf, dass Sie auch genügend Platz auf der entsprechenden Partition haben. Abhilfe könnte hier das Anlegen eines Unterverzeichnisses auf einer anderen Partition (z.B. im Homeverzeichnis - ungünstig, geht aber) bringen.

Hier haben Sie zusätzlich die Möglichkeit, neben dem normalen UFS-Cache-Dateisystem auch das neue DISKD- oder AUFS-Dateisystem zu verwenden. Dieses soll einen entscheidenden Geschwindigkeitsgewinn bringen, wie auf der Hauptseite von Squid [23] zu lesen ist.

Die drei Zahlen hinter der Verzeichnisangabe betreffen die Gesamtgrösse des Caches und die Anzahl an Verzeichnissen und Unterverzeichnissen in welchen die gecachten Seiten gespeichert werden.

Die vielen Verzeichnisse und Unterverzeichnisse müssen sein, da ansonsten zu viele Dateien innerhalb eines einzelnen Verzeichnisses gespeichert werden. Sie sollten die Standardangabe von 16 Verzeichnissen mit 256 Unterverzeichnissen nur bei "ausufernden" Platzangebot (mehrere GB) für Squids Cache verändern müssen.

Eine Kalkulationsmöglichkeit für optimale Performance gibt Gert Brits:

x=Grösse des Cache-Verzeichnisses in KB (d.h. 6GB ~ 6,000,000KB);
y=Durchschnittliche Objektgrösse (im Schnitt meist ~ 13KB)

(((x / y) / 256) / 256) * 2 = Anzahl der Verzeichnisse im ersten Verzeichnisbaum
Bei einer Cache-Dir Grösse von 6GB sähe das dann ungefähr so aus:
6,000,000 / 13 = 461538.5 / 256 = 1802.9 / 256 = 7 * 2 = 14
Damit sähe die cache_dir Zeile dann so aus:
cache_dir /var/squid/cache 6000 14 256

Auch bei der Zugriffsart auf das Cache-Verzeichnis haben Sie wieder die Qual der Wahl:

UFS (Standard) Die Standard-Einstellung von Squid (wird auch genommen, wenn nichts weiter angegeben wird). Sollte bei der normalen Installation auch so gelassen werden. Erst ab 1-2 GB lohnt sich eine Umstellung wirklich.
DISKD Die "neueste" Errungenschaft. DISKD ist kompatibel zu UFS und kann mit UFS eingerichtete Cache-Verzeichnisse direkt übernehmen. Hier soll - ähnlich dem Async. UFS - ein "Blockieren" von Squid bei Plattenzugriffen verhindert werden.
Dafür wird ein separates Programm "diskd" gestartet, welches die Plattenzugriffe von Squid verwaltet. Besonders bei der Verwendung von mehreren Cache-Verzeichnissen auf verschiedenen Platten kann es zu nachweisbaren Geschwindigkeitsgewinnen kommen. Beachten Sie aber, dass "diskd" auch wieder Platz im RAM und einige Ressourcen des Prozessors benötigt.
Async UFS Asyncrones UFS - um zu verhindern, dass Squid allzu lange Pausen beim Zugriff auf die Festplatte macht. Hier werden keine Rückmeldungen vom System verlangt, wenn Dateien gespeichert werden. Das ist schnell, führt aber zu Fehlverhalten von Squid, wenn einmal das System nicht nachkommt und Daten nicht schnell genug speichern kann. Sie sollten hier also durchaus mit Datenverlust oder Programmabstürzen (von Squid) rechnen. Wenn es allerdings funktioniert... icon_smile

Ein Beispiel gefällig?

cache_dir aufs /var/squid/cache 6000 14 256

Wenn Sie den Server neu installieren oder eine weitere, kleine Platte "übrig" haben, dann sollten Sie diese speziell für Squid einbinden. Um die Zugriffe auf die Cache-Dateien noch weiter zu optimieren, kann dann die Partition oder Platte mit der Option "noatime" in der Datei /etc/fstab eingebunden werden. Damit wird bei einem Zugriff auf die Cache-Dateien nicht gleichzeitig jedesmal die Zugriffszeit geändert.

...und wo wir gerade bei der Datei /etc/fstab und der separaten Partition von Squid's Cache sind: mit "noexec" und "nosuid" schliessen Sie vorsorglich Sicherheitslücken. Ein Beispieleintrag in der Datei /etc/fstab könnte also so aussehen:

# Device Mountpoint FStype Options Dump Pass#
... /... ... defaults 1 2
/dev/hdd2 /var/squid reiserfs rw,noatime,noexec,nosuid 0 3
# /dev/hdc2 /var/squid/logs reiserfs rw,noatime,noexec,nosuid 0 3

(Achtung: bei diesem Beispiel werden auch die Logbücher von Squid unter /var/squid/logs auf dem entsprechend eingebunden Filesystem abgelegt. Damit wird die eine Festplatte natürlich wieder mehr belastet, weil Sie einerseits ja die heruntergeladenen Dateien wegspeichern muss, andererseits aber auch die entsprechenden Logbücher.

In der letzten Spalte ist deshalb noch eine weitere Platte im System (derzeit mit einem '#' auskommentiert), die nur für die Logbücher zuständig ist.

Wenn Sie die "Performance" Ihres Systems auf die Spitze treiben wollen, sollten Sie sowieso über ein RAID-System nachdenken. Es ist auch immer eine gute Idee, wenn alle Logbücher des Systems auf einem anderen System (der Syslog-Daemon lässt auch das Schreiben über ein Netzwerk zu) oder einer anderen Platte gespeichert werden. Jetzt noch alle ausführbaren Programme auf einer Platte und Partition, welche Read-Only gemountet wird, alle spool- und cache-Verzeichnisse auf einer weiteren Platte, ...

...und irgendwann sollte man über ein Leben ohne Computer und Backups nachdenken...

BTW: Wenn man einmal eine bestimmte Datei sucht, die mal im Web vorhanden aber nun gelöscht ist, kann man unter Umständen noch sein Glück im Cache von Squid versuchen. Dazu benötigt man die Datei store.log. Dort wird vom Squid festgehalten, welche Dateien sich gerade im Cache befinden und welchen Status diese haben. Schauen wir mal kurz auf eine Zeile in dieser Datei:

1109331307.457 Release -1 FFFFFFFF D6A9EAFAD972F9389675C5B8AB2AD5BF 302 1109331307 -1 -1 text/html -1/204 GET http://www.google.com/

Die Einträge sind wie folgt zu verstehen:

Anhand dieser Angaben sollten Sie die benötigte Datei nun schnell im Cache-Speicher finden können - sofern Sie dort gespeichert wurde...

emulate_httpd_log

Squid speichert seine Logfiles normalerweise in einem eigenen Format, welches auch von entsprechenden Analyse-Tools gelesen werden kann. Wenn Sie - um etwa bei der Verwendung von "Logviewer" - Squid mit diesem Schalter anweisen ein "lesbareres" Logfile-Format zu verwenden, müssen Sie auch die entsprechenden Analyse-Tools (wie z.B. calamaris und webalizer) entsprechend umstellen.

emulate_httpd_log on

Damit speichert Squid besonders die Datei access.log, welche die Anforderungen der Clients enthält, in einem benutzerfreundlichen Format. So wird u.a. die Zeit in einem lesbaren Format gespeichert und auch der Rest der Einträge lassen sich mit nur wenig Fantasie richtig deuten.

log_fqdn

Hier können Sie Squid anweisen, die Hostnamen der anfragenden Clients aufzulösen und diese Namen ins Logbuch zu schreiben. Aber Achtung! Zur Auflösung dieser Namen führt Squid einen DNS-Lookup durch, er fragt also zunächst einmal den eigenen Rechner (der diese Daten hoffentlich in der Datei /etc/hosts hat oder über einen eigenen Nameserver verfügt) und wendet sich bei einem Misserfolg an den nächsten DNS-Server. Wenn es sich dabei um einen öffentlichen DNS-Server (etwa den der Telekom) handelt, dann wird Squid die anfragenden IP-Nummern kaum zu Namen auflösen können.

Mit dieser Option kann man also einerseits ein "schöneres" Logbuch produzieren, andererseits aber Squid auch enorm ausbremsen, weil er für jede Anfrage eines Clients dessen IP-Adresse in einen zugehörigen Namen auflösen soll. Die Standardeinstellung von "no" sollten Sie also nur bei der Verwendung eines eigenen Nameservers oder einer gut gefüllten hosts-Datei auf dem Server ändern.

log_fqdn on


OPTIONS FOR EXTERNAL SUPPORT PROGRAMS

Hier werden externe Hilfsprogramme aufgeführt, die von Squid während des laufenden Betriebs genutzt werden. Etwa Filter- oder Authentifizierungsprogramme.

ftp_user

Gleich der erste Eintrag scheint nicht so richtig zu passen, allerdings meldet sich Squid mit dem hier eingetragenen Namen bei einer Datenübertragung mit FTP am entsprechenden Server an. Wenn sie also einerseits den Serveradmins etwas genauere Daten für ihre Statistik liefern wollen und auch nicht gleich wieder hinausgeschmissen werden möchten, wenn ein FTP-Server nur dem Nutzer "anonymous" mit einer echten Email-Adresse Zugriff gewährt, dann sollten Sie hier einen 'vernünftigen' Eintrag in der Form:

nutzer@domain.de

machen. Aber Achtung: manchmal werden die so übermittelten Email-Adressen auch für die Versendung von SPAM genutzt.

Unter Webmin können Sie hier einen Eintrag hinter "Anon. FTP-Anmeldung" machen.

ftp_user anonymous@schule.de

ftp_passive

Normalerweise verwendet Squid sowieso passives FTP. Wenn Sie das nicht möchten, können Sie es hier aber abstellen:

ftp_passive off

ftp_list_width

Gibt die Anzahl der Zeichen an, die Squid pro Spalte bei der Verwendung des FTP-Protokolls an den Client zurückgibt. Dies ist besonders bei der Verwendung eines Browsers hilfreich, um in FTP-Verzeichnissen etwas mehr von den eigentlichen Dateinamen zu sehen.

ftp_list_width 45

redirect_program

Hier können externe "Weiterleitungs-"Programme eingebunden werden. Diese Programme bekommen vom Squid sämtliche Anfragen vom Client durchgereicht, überprüfen diese intern und geben dann an Squid entweder die Anfragen zurück, damit dieser diese holt oder Sie reagieren auf die Anfragen und leiten Sie um.

Ein solches Programm ist z.B. das Programm SquidGuard [24], welches in einem anderen Artikel [25] besprochen wird.

Weitere Filterprogramme gibt es wie "Sand am Meer" - suchen Sie doch einfach mal in einer Suchmaschine Ihrer Wahl nach den Begriffen "redirect program squid download"...

Dort werden Sie dann auch so nützliche Programme wie "Adware-Blocker" und ähnliches finden.

Beispielhaft aktivieren wir nun einmal SquidGuard [26] (beachten Sie bitte die komplette Pfadangabe zum Programm!):

redirect_program /usr/bin/squidGuard

Sie können übrigens mehrere "Redirector"-Programme hintereinander angeben. Squid reicht die URLs dann der Reihe nach von einem Redirector zum anderen weiter. D.h. wenn Sie z.B. zuerst einen AddBlocker als Redirector eingestellt haben, so liefert diese ja eine andere URL an Squid zurück. Der nachfolgende Redirector wird dann diese URL prüfen.

redirect_children

Der Parameter redirect_children weist Squid an, eine bestimmte Anzahl von Redirect-Programmen [27] im Voraus zu starten, damit Anfragen von mehreren Clients zügig beantwortet werden können. Der Defaultwert von fünf hat sich bewährt und sollte nur in begründeten Ausnahmefällen geändert werden. Keine Angst: surfen mehr als Clients über Squid, werden auch eine entsprechende Anzahl an Redirect-Programmen gestartet - Plus 5 zusätzlichen, die schnell einspringen, wenn plötzlich weitere Clients auftauchen.

redirect_children 5

auth_param

Der neue Squid arbeitet nicht mehr mit den bisherigen Parametern authenticate_program" und "authenticate_children".

Sollten Sie diese Parameter noch in Ihrer squid.conf eingetragen haben, werden Sie diesbezüglich Fehlermeldungen beim Starten von Squid bekommen und die Nutzerauthentifizierung findet nicht mehr statt!

Geben Sie - um eine Nutzeranmeldung über die Datei /etc/shadow im Browser zu verlangen - folgende 4 Zeilen in die squid.conf ein:

auth_param basic program /usr/sbin/ncsa_auth /etc/shadow Zur Authentifizierung greift Squid hier auf das Programm ncsa_auth zurück. Das ist das Standardprogramm von Squid. Andere Programme sind z.B. smb_auth, yp_auth oder squid_ldap_auth. (ein Hinweis an dieser Stelle: das Programm ldap_auth hat dieselbe Funktion, wird aber nicht mehr weiter Entwickelt und ist von squid_ldap_auth abgelöst worden). All diese Programme können Nutzer authentifizieren:
  • ncsa_auth authentifiziert die Nutzer über eine shadow-Datei, wie Sie Linux z.B. in /etc/shadow verwendet. Dort sind normalerweise alle Nutzer des Systems eingetragen. Da diese Datei aber auch für andere Authentifizierungen (z.B. der Benutzeranmeldung) genutzt wird, sollten Sie hier vorsichtig bei Veränderungen sein.
    Achtung: Bitte löschen Sie also keine Nutzer aus der Datei /etc/shadow, wenn Sie Ihnen nur das Surfen im Internet verbieten wollen!
  • smb_auth authentifiziert die Nutzer über Ihre Samba-Passwörter in der Datei smbpasswd. Diese k�nnen u.U. von denjenigen in /etc/passwd abweichen: nicht jeder Nutzer, der sich an einem Windows-Client anmelden k�nnen soll, soll sich ja auch am Server selbst anmelden k�nnen.
    Ansonsten gilt hier dasselbe wie f�r ncsa_auth: beachten Sie, dass die Datei smbpasswd durchaus auch f�r andere Authentifizierungen genutzt wird!
  • yp_auth Hier werden Nutzer �ber einen NIS-Server identifiziert. Dabei reicht das Modul normalerweise nur Benutzername und Passwort an den NIS-Server weiter und erh�lt von diesem entweder ein "ok" oder eine Fehlermeldung zur�ck. Hier liegen die M�glichkeiten ganz und gar bei der Konfiguration der NIS-Datenbank. So k�nnte hier einzelnen Nutzern z.B. eine normale Anmeldung, nicht aber das Surfen im Internet erlaubt werden...
  • squid_ldap_auth Auch hier reicht das Modul die Daten nur an einen anderen Server weiter, der die eigentlich Authentifizierung vornimmt und eine entsprechende Antwort an das Modul zur�cksendet. Da heute immer mehr Administratoren auf LDAP [28] umsatteln, wird diese Art der Authentifizierung zuk�nftig wohl eine gr��ere Bedeutung gewinnen, da sich hier - �hnlich wie bei der Authentifizierung �ber einen NIS-Server - gezielt Unterscheidungen vornehmen lassen.
    So s�he eine g�litge Zeile mit Zusatzattributen hier wie folgt aus:
    authenticate_program /usr/sbin/squid_ldap_auth -b dc=Schule,dc=de -f (&(!(internetDisabled=true))(!(gidNumber=103))(uid=%s)) -u uid ldap
    D.h. im LDAP gibt es f�r jeden Nutzer einen Eintrag "internetDisabled". Sollte dieser nicht auf "true" stehen oder der anmeldende Nutzer die Gruppen-ID 103 besitzen, dann die Anmeldung verweigern - sonst zulassen.
auth_param basic children 5 Squid startet - um Anfragen m�glichst schnell beantworten zu k�nnen - das Authentifizierungsprogramm gleich 3 mal im voraus. Diese Einstellung sollte f�r ~150 Rechner ausreichen. Bitte erh�hen Sie sie also nur, wenn die Anmeldung wirklich zu lange dauert, da ansonsten unn�tig Speicherplatz verbraucht wird.
auth_param basic realm Internetzugang Das Wort hinter "realm" wird im Dialogfenster bei der Anmeldung angezeigt.
auth_param basic credentialsttl 2 hour Die Authentifizierung wird die eingestellte Zeit lang aufrecht erhalten. Danach muss sich ein Nutzer erneut anmelden. Sollte der Nutzer zwischenzeitlich den Browser schlie�en, mu� er sich allerdings sowieso erneut anmelden. Eine k�rzere Zeitspanne d�rfte also kaum jemanden auffallen.

OPTIONS FOR TUNING THE CACHE

Nachdem wir nun schon im Vorfeld so viel an "Tuning-M�glichkeiten" kennen gelernt haben, bietet uns die Konfigurationsdatei nun sogar noch einen eigenen Abschnitt daf�r.

request_header_max_size

Hiermit wird die maximale Gr��e eines HTTP-Headers einer Anfrage festgelegt. Diese Header stehen am Anfang einer HTML-Seite und werden nicht vom Browser angezeigt. Normalerweise haben Header eine Gr��e von einigen hundert Byte. Diese Option dient dazu fehlerhafte Anfragen, z.B. durch fehlerhafte Client-Software oder einen DoS-Angriff abzufangen. Die Standardeinstellung von 10 KB ist ein wenig �bertrieben: 3 KB reichen da normalerweise aus. Achten Sie aber darauf, dass dies bei den immer mehr in Mode kommenden Groupware-L�sungen durchaus zu Problemen f�hren kann, wenn Nutzer Dateien von Ihrem Arbeitsplatz auf den Server hochladen wollen.

request_header_max_size 3 KB

refresh_pattern

Mit den Refresh-Pattern kann das Verhalten von Squid bei Anfragen eines Clients massiv beeinflu�t werden. So k�nnen regelwidrige Refresh Pattern auch zur Auslieferung l�ngst veralteter Webseiten oder FTP-Dateien f�hren. Allerdings ergibt sich hier auch eine optimale M�glichkeit zum Cache-Tuning.

Anweisung Option Regul�rer Ausdruck Mindestzeit Prozentsatz Maximalzeit weitere Optionen
Die "refresh_pattern" Zeilen werden der Reihe nach durchlaufen. Es gilt die erste Zeile, deren regul�rer Ausdruck zutrifft. Normalerweise wird zwischen Gro�- und Kleinschreibung unterschieden. Mit der Option -i wird das nicht ber�cksichtigt. Der regul�rer Ausdruck bestimmt, f�r welche URLs die Anweisung gilt. Die bei min angegebene Mindestzeit gibt (in Minuten) die Zeit an, die Objekte ohne ausdr�ckliches Verfallsdatum mindestens als aktuell (fresh) betrachtet werden.
43200 bedeutet also 30 Tage.
percent ist der Prozentsatz des Objektalters (Zeit seit der letzten �nderung) die Objekte ohne ausdr�ckliches Verfallsdatum mindestens als aktuell (fresh) betrachtet werden. max ist der maximale Zeitraum, den Objekte ohne ausdr�ckliches Verfallsdatum als aktuell (fresh) betrachtet werden. options beinhaltet eine oder mehrere Optionen, durch Lerraum getrennt:
  • override-expire [29]
  • override-lastmode [30]
  • reload-into-ims [31]
  • ignore-reload [32]
refresh_pattern ^ftp: 43200 20% 43200 reload-into-ims
refresh_pattern ^gopher: 43200 0% 43200 reload-into-ims
refresh_pattern -i \.jpg 43200 100% 43200 reload-into-ims
refresh_pattern -i \.gif 43200 100% 43200 reload-into-ims
refresh_pattern -i \.tif 43200 100% 43200 reload-into-ims
refresh_pattern -i \.bmp 43200 100% 43200 reload-into-ims
refresh_pattern -i \.png 43200 100% 43200 reload-into-ims
refresh_pattern windowsupdate.com/.*\.(cab|exe) 43200 100% 43200 reload-into-ims
refresh_pattern download.microsoft.com/.*\.(cab|exe) 43200 100% 43200 reload-into-ims
refresh_pattern . 20160 50% 43200



override-expire erzwingt die unter "min" angegeben ``Mindesthaltbarkeit'', auch wenn vom Webserver ein "Expires:" im Header gesendet wurde.
override-lastmode erzwingt die unter "min" angegeben "Mindesthaltbarkeit", auch wenn das Objekt häuft geändert wird.
reload-into-ims Ändert eine "no-cache" oder "reload" Anfrage in ein "If-Modified-Since" - das sollte die sinnvollste Voreinstellung sein, da Squid so zwar eine Anfrage ins Internet aussendet - oft aber die Seite aus seinem eigenen Cache holen kann.
ignore-reload ignoriert ein "no-cache" oder "reload" in einer Anfrage.

Bitte beachten Sie, dass Squid bei einigen Einstellungen gegen die w3d-Konventionen verstößt. Mit den oben gemachten Einstellungen werden aber vorwiegend Grafiken besser zwischengespeichert, die sich - wie die Erfahrung zeigt - kaum verändern.

Die beiden vorletzten refresh-pattern sorgen (als Beispiel für komplexere Ausdrücke) dafür, dass Windows-Updates im Cache zwischengespeichert werden. Damit gelingt dann das Updaten der Windows-Rechner ein wenig schneller.

Der letzte Eintrag sorgt mit dem "." (Punkt) dafür, dass alle angeforderten Seiten, Grafiken, etc. für mindestens 14 Tage zwischengespeichert werden, solange sie sich nicht ausdrücklich geändert haben.

quick_abort_min

Wenn nach einer Anfrage eines Benutzers die �bertragung des Objekts vom Benutzer abgebrochen wird (z.B. durch ``Klick'' auf eine andere Seite bevor die aktuelle zu ende geladen ist), wird das Objekt vom Proxy trotzdem vollst�ndig in den Cache geladen, wenn weniger als "quick_abort_min" noch zu laden sind.

Empfehlung: 0 KB einstellen. Damit bricht Squid das Laden wirklich ab und kann sich um andere Sachen k�mmern. Das bringt bei Klickw�tigen Sch�lern schon eine ganze Menge!

quick_abort_min 0 KB

quick_abort_max

Wenn nach einem Abbruch durch den Benutzer noch mehr als "quick_abort_max" zu laden sind, wird auch der Proxyserver das laden des Objekts abbrechen.

Empfehlung: 0 KB. Auch hier sollte Squid nicht zum Laden einer Seite gezwungen werden, die ein Sch�ler vielleicht nur versehentlich ansurfen wollte.

quick_abort_max 0 KB

quick_abort_pct

Wenn nach einem Abbruch durch den Benutzer bereits mehr als "quick_abort_pct" Prozent des Objekts bereits geladen sind, wird der Proxyserver das Objekt vollst�ndig laden.

Empfehlung: 100. Also soll Squid das Laden nur dann fortsetzen, wenn die Seite schon zu 100 Prozent geladen ist... (Erkl�rung s.o.)

quick_abort_pct 100

Mit diesen Werten f�r quick_abort wird das Laden eines Objektes grunds�tzlich sofort abgebrochen, wenn der Surfer "weiter klickt" oder das Laden abbricht.

negative_ttl

Fehlermeldungen wie z.B. "connection refused" oder "404 Not Found" werden die hier angegebene Zeit (in Minuten) im Cache gehalten, d.h. von Proxyserver bei erneuten Anfragen mit dem gleichen Fehler beantwortet. Sollte zum Zeitpunkt einer Anfrage keine Internetverbindung bestehen, gibt es folglich eine Fehlermeldung, die auch dann noch f�r die hier eingestellte Zeit erhalten bleibt wenn eine Online-Verbindung aufgebaut wurde.

In Schulsituationen eine unangenehme Situation, wenn die Sch�ler zuerst "mal wieder schneller als der Lehrer" waren und dann - trotz Verbindungsaufbau - weiterhin nur eine Fehlerseite erscheint. Setzen Sie deshalb hier bitte die voreingestellte Zeit von 5 Minuten auf die k�rzeste Zeitspanne von 5 Sekunden herunter!

negative_ttl 5 second

negative_dns_ttl

�hnlich wie die negative_ttl - hier allerdings nur f�r Anfragen an einen Nameserver g�ltig. Auch hier sollten Sie die Zeit auf das Minimum reduzieren:

negative_dns_ttl 5 second

TIMEOUTS

Hier werden Zeitbegrenzungen f�r unterschiedliche Prozesse definiert. Vor allem das Verhalten von Squid gegen�ber den eingesetzten Clients spielt dabei f�r uns eine Rolle.

connect_timeout

Diese Option bestimmt, wie lange Squid auf einen vollst�ndigen TCP-Verbindungsaufbau zu einem Server wartet. Innerhalb dieser Zeit (Standard 2 Minuten) muss die Verbindung zum Server aufgebaut sein - ansonsten gibt Squid eine Fehlermeldung aus.

connect_timeout 90 second

request_timeout

Bestimmt, wie lange nach einem erfolgreichen TCP-Verbindungsaufbau eines Clients auf eine HTTP-Anfrage gewartet wird (Standard: 5 Minuten).

request_timeout 2 minute

half_closed_clients

Einige Clients beenden die sendende Seite einer TCP-Verbindung, lassen jedoch die empfangende Seite offen. Squid kann dies nicht von einer vollst�ndig geschlossenen Verbindung unterscheiden.

Mit "on" wird bestimmt, das Squid die Verbindung h�lt, bis beim Lesen oder Schreiben in dieser Verbindung ein Verbindungsfehler gemeldet wird.

"off" bestimmt, dass die Verbindung beendet wird, sowie beim Lesen ein "no more data to read" zur�ck gegeben wird.

half_closed_clients off

shutdown_lifetime

Wenn Squid die Aufforderung zum ``Shutdown'' erh�lt ("SIGTERM" oder "SIGHUP"), nimmt er keine neuen Verbindungen mehr an und wartet bis die vorhandenen Verbindungen abgebaut sind.

Diese Option bestimmt, wie lange Squid maximal warten soll, bis er die restlichen Verbindungen von sich aus unterbricht und herunter f�hrt.

Alle dann noch aktiven Clients bekommen eine "Timeout"-Fehlermeldung. Der Wert wird in Sekunden angegeben.

shutdown_lifetime 10 second

ACCESS CONTROL

Zitieren wir einmal das Squid-Handbuch [33]: "F�r das folgende Kapitel ben�tigen Sie einen starken Kaffee, ein paar billige Bleistifte (zu Ihrer Gesundheit m�glichst ungef�rbte) und Sie sollten alle scharfen Gegenst�nde aus Ihrer Umgebung entfernen. Mit Squid ACL's k�nnen Sie nahezu jede erdenkliche Zugriffsregel erstellen. Manche Firewall kann hier nicht mithalten. Diese Komplexit�t birgt jedoch auch einige Fallen, in die Sie stolpern k�nnen. Mancher Administrator soll daran schon verzweifelt sein icon_wink ."

Aber keine Angst, die meisten Einstellungen sind ja schon gemacht. Wir wollen hier nur noch zus�tzliche Eintr�ge f�r eine Bandbreitenbegrenzung und f�r die Absicherung des Proxys nach aussen einf�gen.

acl

ACLs sind Access-(Zugriffs-)Listen, die umst�ndlich ausgedr�ckt nur eine Definition von Regeln darstellen.

Die hier vorgenommenen Einstellungen gelten also normalerweise noch nicht!

Damit werden nur bestimmte Ausdr�cke mit einem "einfach" zu merkenden Namen verkn�pft. Diese Namen unterliegen wieder den normalen Restriktionen, wie man sie allgemein kennt (erlaubt sind nur Buchstaben, Nummern sowie '_' und '-').

Wir definieren hier - sofern noch nicht vorhanden - verschiedene Regeln und weisen diesen Regeln dann einen Namen zu. Da die Regeln hier noch nicht in Kraft treten, sondern nur definiert werden, ist die Reihenfolge hier nicht weiter wichtig. Sie sollten nur beachten: pro Regel nur eine Zeile. Sollte ihnen der Platz nicht ausreichen, k�nnen Sie die Regel auch in eine separate Datei auslagern (s.u.).

acl all src 0.0.0.0/0.0.0.0 Hiermit wird eine Regel definiert, die auf alle IP-Adressen trifft. Mit dem K�rzel "acl" teilen wir Squid mit, dass nun eine neue Regel definiert wird, deren Name direkt folgt und u.a. keine Leerzeichen beinhalten darf. Unsere Regel lautet also "all". Das Schl�sselwort "src" nach dem Namen weist Squid an, den nachfolgenden Wert als IP-Adresse oder IP-Netzwerkbereich zu behandeln. Weiter unten werde ich noch andere Schl�sselw�rter erl�utern. Zum Schluss kommt dann der eigentliche Inhalt der Regel - in diesem Fall ein IP-Adressbereich.
acl our_networks src 172.16.0.0/16

Mit "our_networks" definieren wir diejenigen Rechner, welche �berhaupt auf den Proxyserver zugreifen d�rfen. In unserem Beispiel sind das Rechner mit der IP 172.16.x.y und dem Subnetz 255.255.0.0 - die Zahl 16 ist nur eine andere Schreibweise f�r das Subnetz.

Wenn Sie also zus�tzlich noch Rechner im 192.168er Netz �ber den Proxy laufen lassen m�chten, m�ssen Sie - mit Leerzeichen getrennt - noch 192.168.0.0/16 anf�gen.
acl dateien urlpath_regex -i \.(zip|exe|cmd|rar|com|mp3|mp[e]g)($|\?) Die hier erstellte Zugriffsregel wird f�r beliebte "Download"-Dateien sp�ter nur eine bestimmte Bandbreite zulassen. Hier sieht man sehr sch�n, dass nach der Namensvergabe "dateien" ein anderes Schl�sselwort urlpath_regex folgt, welches zus�tzlich noch bestimmte "Optionen" erlaubt. In diesem Fall steht die "Option" -i f�r das Ignorieren von Gross- und Kleinschreibung.

Da gleich mehrere Dateiendungen in dieser Regel erfasst werden sollen, werden diese durch Leerzeichen voneinander getrennt.
acl authenticated proxy_auth REQUIRED Hiermit definieren wir eine ACL mit dem Inhalt "Proxy-Anmeldung erforderlich". Wenn diese ACL sp�ter aktiviert wird, dann m�ssen die Nutzer sich �ber die unter auth_param [34] eingestellte Authentifizierungsform anmelden. Ansonsten verweigert Squid die Nutzung.
acl sites_without_auth dstdomain *.foo.com

Angenommen, die Nutzer sollen einige Seiten im Internet ansurfen k�nnen ohne sich vorher authentifizieren zu m�ssen. Mit dieser ACL definieren Sie eine Regel "sites_without_auth" und dahinter geben Sie die Seiten an, welche sp�ter auch ohne Anmeldung am Squid angesurft werden k�nnen.

Beachten Sie bitte, dass sp�ter dann die Reihenfolge der http_access entscheidend ist! Nur wenn Sie diese Reihenfolge hier w�hlen:

http_access allow sites_without_auth
http_access allow authenticated
dann wird das sp�ter auch funktionieren...
acl winupdate dstdomain .update.microsoft.com .windowsupdate.microsoft.com Damit die Rechner ein Windows-Update fahren k�nnen, ohne dass eine Anmeldemaske "aufpoppt", nehmen wir diese Adressen noch in eine eigene ACL mit auf. Diese ACL kommt dann nat�rlich auch vor http_access allow authenticated.

Nun wollen wir noch eine "whitelist" und eine "blacklist" anlegen, welche URLs von Webseiten enthalten soll, die wir entweder sperren oder freigeben m�chten. Um nicht immer in der Konfiguration von Squid herumfuhrwerken zu m�ssen, um hier neue Seiten einzutragen, werden diese Listen in separate Dateien ausgelagert und in der Konfigurationsdatei wird nur der Speicherort der Dateien angegeben.
acl whitelist url_regex "/etc/squid/acl_whitelist" In der Datei /etc/squid/acl_whitelist werden dan einfach untereinander der einzelnen URLs der Seiten (ohne http://) aufgelistet.
acl blacklist url_regex "/etc/squid/acl_blacklist" In der Datei /etc/squid/acl_blacklist werden dan einfach untereinander der einzelnen URLs der Seiten (ohne http://) aufgelistet.

Tip: Diese Art der Sperrung von Internetseiten mag bei wenig Eintr�gen noch gut funktionieren. Wenn Sie aber mehr als 100 Eintr�ge haben, lohnt der Einsatz von speziellen Filterprogrammen wie SquidGuard [35].

Ab und zu kommt von Schulen die Frage: "K�nnen wir die Anmeldung am Squid �hnlich begrenzen, wie unter Samba [36]?" Also Squid so konfigurieren, dass ein Sch�ler sich nur einmal am Squid anmelden kann?

Die Antwort lautet: Ja.
Hierf�r definiert man eine spezielle ACL:
acl maxlogon max_user_ip -s 1
Der Parameter -s bewirkt sp�ter das "harte" Blocken, d.h. wenn sich der Sch�ler an einem anderen Rechner anmelden will, bekommt er sofort die rote Karte. Ohne -s l��t Squid ihn noch ab- und zu durch - in der Hoffnung, dass der Sch�ler den Fehler erkennt.

Wichtig hierbei: Squid speichert ja die Anmeldung (ansonsten w�rde der Sch�ler sein Passwort bei jeder neuen Seite erneut eingeben m�ssen) f�r eine gewisse Zeit. Wenn nun aber ein Raumwechsel ansteht, dann kann es passieren, dass Squid noch die Anmeldung unter der alten IP gespeichert hat und den Nutzer dann im neuen Raum nicht hineinl��t. Deshalb muss man zus�tzlich noch ein wenig mit dem Parameter:
authenticate_ip_ttl 2 minutes
herumspielen. In diesem Beispiel cached Squid das Passwort 2 Minuten - normalerweise ausreichend f�r eine Schulstunde in welcher die Sch�ler oft neue Seiten aufrufen.

Denken Sie daran, dass Sie f�r die ACL "maxlogon" noch eine http_access-Regel [37] definieren m�ssen.

http_access

Mit den http_acess-Anweisungen bestimmen wir nun, was mit den zuvor gemachten ACLs geschehen soll.

Hier kommt es auf die richtige Reihenfolge an!

Der erste zutreffende Ausdruck wird verwendet!
Deshalb sperren wir jetzt auch erst einmal den Rest der Welt aus unserem Proxy-Server aus, indem wir zun�chst nur nur unser lokales Netzwerk zulassen und anschlie�end die weite Welt aussperren:
http_access allow our_networks
http_access deny all

Mit diesen beiden Angaben am Ende der http_access-Regelliste erlauben ("allow") wir also grunds�tzlich unserem Netzwerk ("our_networks"), welches wir ja weiter oben genau definiert haben, den Zugriff auf den Proxy w�hrend der Rest der Welt ("all" s.o.) der Zugriff verboten ("deny") wird. Zu beachten: werden diese Regeln andersherum durchlaufen, bleibt auch das lokale Netzwerk draussen, da auch die lokalen Adressen von der allgemeinen Regel erfasst werden und damit die Abarbeitung der Regeln schon nach der ersten abgebrochen wird.

Wenn Sie also z.B. den Zugriff auf unsere "Dateien" verbieten wollen, muss eine entsprechende http_access-Regel VOR dem "allow our_networks" hinzugef�gt werden! Steht Sie dahinter, darf unser Netzwerk diese Dateien laden, weil Squid die weiter unten stehende Regel nicht mehr auswertet, sobald ein Rechner zu unserem Netzwerk geh�rt...

icp_access

Nachdem wir andere Clients ausgesperrt haben, verbieten wir in einem zweiten Schritt auch anderen Proxys den Zugriff auf unseren Server. Da die Proxys untereinander �ber sogenannte icp-queries miteinander kommunizieren, m�ssen wir daf�r eine andere Regel setzen: den icp_access. Wer bei http_access aufgepasst hat, der d�rfte die jetzt folgende Regelkette schon erraten.
icp_access allow our_networks
icp_access deny all


ADMINISTRATIVE PARAMETERS

cache_mgr

Gibt die Email-Adresse desjenigen armen Menschen an, der f�r die Konfiguration des Servers verantwortlich ist. Sie k�nnen diese Email-Adresse �ber die Variable %w auch in selbstgenerierten Fehlerseiten anzeigen lassen: setzen Sie dazu einfach eine Zeile: "Ihr Cache Administrator ist %w [38]." ein.
cache_mgr admin@localhost


MISCELLANEOUS

dns_testnames

Squid testet beim Start ob eine DNS-Aufl�sung m�glich ist - ansonsten wird der Start abgebrochen. Hier k�nnen mehrere Domains angegeben werden. Der Test wird nach der ersten erfolgreichen Aufl�sung eines Domainnamens beendet.
Um also den Start zu beschleunigen mogeln wir ein wenig und lassen Squid den Namen des eigenen Rechners zuerst aufl�sen:
dns_testnames localhost netscape.de denic.de microsoft.com

forwarded_for

Im Normalfall (on) wird Squid die IP-Adresse oder den Namen des Clients als "X-Forwarded-For:" in den Header der weitergeleiteten HTTP-Anfrage einf�gen.

Beispiel: X-Forwarded-For:192.168.20.10
Wird diese Option abgeschaltet (off) wird Squid den Client bei der Weiterleitung nicht nennen. Im Header wird dann ein "X-Forwarded-For: unknown" erscheinen. Damit erh�lt der jeweilige Server also keine Auskunft �ber die Organisation des internen Netzwerks - ein kleiner aber feiner Sicherheitsgewinn.

Problematisch wird es hier nur, wenn die Nutzer passwortgesch�tzte Seiten ansurfen, die nicht �ber Cookies oder andere Varianten die Authentizit�t des Nutzers �berpr�fen: im schlimmsten Fall d�rfen dann alle Nutzer unter dem Account eines anderen bei ebay Artikel ersteigern oder Mail lesen!
forwarded_for off
Sollte daher beibehalten werden, wenn man nicht �rger mit seinen Nutzern bekommen m�chte. Sollte eine entsprechende Regelung existieren und die Nutzer d�rfen Webseiten mit Authentifizierung nicht ansurfen, kann man mit dieser Option Squid allerdings sehr gut beschleunigen.

log_icp_queries

Eigentlich unn�tig, da wir ja Anfragen von anderen Servern sowieso nur aus dem internen Netz zulassen. Sollte aus irgend einem Grund allerdings einmal ein weiterer Server im Intranet dazukommen, dann wird Squid f�r Anfragen dieses Servers nicht noch ein zus�tzliches Logbuch anlegen.
log_icp_queries off

buffered_logs

Einen kleinen Geschwindigkeitsgewinn bringt die Zwischenpufferung der Logdatei "cache.log": Mit einer Pufferung (on), kann der Schreibvorgang geringf�gig beschleunigt werden, da gro�e Teile der Logdatei im RAM gehalten und nur sporadisch auf die Festplatte geschrieben werden. Bei einem Absturz f�hrt dies jedoch zum Verlust der letzten Loginformationen. Bei einem Problemlosen Betrieb verschmerzen wir das einmal f�r das "letzte Quentchen an Geschwindigkeitsrausch". Denken Sie aber daran, dass Sie diese Option wieder deaktivieren, wenn Sie Problemen auf den Grund gehen wollen.
buffered_logs on

snmp_port

Bestimmt den Port auf dem Squid\'s interner SNMP-Server lauscht.
�ber diesen Port k�nnen (wenn Squid mit der entsprechenden Option kompiliert wurde) SNMP Daten abgefragt werden. Dies dient in gr��eren Netzwerken zur �berwachung der einzelnen Server.

Soll Squid grunds�tzlich zun�chst einmal keine SNMP-Anfragen beantworten, mu� diser Port auf "0" gesetzt werden.
snmp_port 0

DELAY POOL PARAMETERS

Mit den "Delay-Pools" von Squid l��t sich eine Bandbreitenbegrenzung f�r bestimmte Clients oder URL-Teile erreichen. In Schulen mit "Medienecken", an welchen Sch�ler in Freistunden sitzen d�rfen, also eine gute M�glichkeit gen�gend "Reserven" f�r den normalen Unterricht vorzuhalten.

delay_pools

Zun�chst einmal m�ssen wir Squid mitteilen, wie viele Delay-Pools wir einrichten m�chten. Bei dem hier gezeigten Beispiel handelt es sich um zwei Delay-Pools, die - bei einer DSL-Verbindung - die normalen Surfer eindeutig bevorzugen und "Downloadfreaks" an den Rand der Verzweiflung treiben sollen.
delay_pools 2

delay_class

Squid kennt grunds�tzlich drei verschiedene Arten von Delay-Pools:
  1. In einem Pool der Klasse 1 wird die Download-Rate aller Verbindungen zusammengefasst und darf eine gewisse Bandbreite nicht �berschreiten. Also ein ideales Anwendungsgebiet um allen Nutzern (auf welche die betreffende acl zutrifft) einen D�mpfer zu verpassen. Wenn man es genau nimmt, dann arbeitet Squid in der Standardeinstellung also mit genau einem Delay-Pool der Klasse 1 - ohne Beschr�nkungen. icon_wink
  2. In einem Pool der Klasse 2 kann einerseits wieder die gesammte Bandbreite begrenzt werden (daf�r dient der erste Parameter) und andererseits die Bandbreite f�r einen mit einer acl festgelegten Bereich oder Benutzer.
  3. Ein Delay-Pool der Klasse 3 letzendlich erlaubt zus�tzlich zu den oberen noch eine Begrenzung f�r ein gesammtes Subnetz.

delay_class 1 2 Der erste Delay-Pool ist ein Pool der Klasse 2.
delay_class 2 1 Der zweite Delay-Pool ist ein Pool der Klasse 1.

delay_parameters

delay_parameters 1 -1/-1 102400/512000 Der erste Pool erh�lt einen kontinuierlichen Datenzuflu�. Es gibt keine Begrenzung (-1 schaltet die Begrenzung aus).
Bei Bedarf kann der Inhalt des Pools f�r einzelne Mitglieder mit einem Schwung von 512000 bytes/s ausgekippt werden - anschlie�end f�llt sich der Pool wieder langsam mit 102400 bytes/s. Dieses Verhalten ist f�r Surfer wohl am g�nstigsten: Eine neue Seite wird zun�chst mit voller Geschwindigkeit geladen - w�hrend der Surfer die Seite betrachtet, f�llt sich der Delay-Pool langsam wieder an.
delay_parameters 2 128000/128000 Der zweite Pool bekommt maximal 128000 byte/s. Nicht mehr und nicht weniger. Der maximale Durchsatz wird hier also massiv begrenzt. Da durch die eingesetzte acl hier alle als "Dateien" deklarierten Endungen betroffen sind, wird sich so mancher "Download-Freak" hier �ber "das lahme DSL" wundern icon_wink

delay_access

Bitte beachten Sie hier die Reihenfolge:
Es werden immer der Reihe nach alle Pools der Klasse 1, danach Pools der Klasse 2 und danach Pools der Klasse 3 abgearbeitet. Selbst wenn Sie in der folgenden Konfiguration einen Klasse 2 Pool vor einem Klasse 1 Pool setzen, wird zuerst der Klasse 1 Pool abgearbeitet.

Erst innerhalb ein und derselben Delay-Pool-Klasse kommt es auf die Reihenfolge innerhalb der Konfigurationsdatei an.

delay_access 2 allow Dateien Der zweite Pool wird auf alle in der acl "Dateien" definierten Dateiendungen angewendet.
delay_access 2 deny all ...und wieder geht den Rest der Welt dieser Pool nichts an. Die normalen Surfer aus dem internen Netzwerk werden auch nicht von diesem Pool bedient.
delay_access 1 allow our_networks Zum ersten Pool erh�lt das gesammte interne Netzwerk Zugriff. Da alle Anfragen, welche unsere "Dateien" beinhalten schon vorher abgefangen wurden (wie schon erw�hnt, bricht Squid die Bearbeitung einer Anfrage beim ersten Treffer ab), darf jetzt alles andere diesen Pool benutzen.
delay_access 1 deny all Der gesammte Rest der Welt darf den Pool nicht nutzen.

Delay Pools testen

Wenn Sie nicht wissen, ob Ihr eingesetzter Squid Delay-Pools unterst�tzt oder ob Ihre eingegebenen Werte bei den einzelnen Pools richtig sind, dann empfielt sich ein einfacher Test mit diesen Einstellungen:
acl all src 0.0.0.0/0.0.0.0
acl dateien urlpath_regex -i \\.(zip|exe|cmd|rar|com|mp3)($|\\?)
delay_pools 1
delay_class 1 1
delay_parameters 1 1024/1024
delay_access 1 allow Dateien
delay_access 1 deny all

Tragen Sie diese Werte in Ihre Datei "squid.conf" ein und laden Sie die Konfiguration des laufenden Squids erneut mit "rcsquid reload".

Jetzt m�ssen Sie den Server nur noch Online schalten und eine ca. 5-10 MB gro�e Datei mit der Endung ".exe", ".zip", ".rar", ".com" oder ".mp3" mit dem Browser aus dem Internet [39] herunterladen.

Egal, ob Sie mit einem Modem, ISDN oder DSL unterwegs sind: dieser Download d�rfte extrem langsam sein. Wenn Sie jetzt aber zeitgleich auf ganz normalen HTML-Seiten surfen, werden Sie kaum Geschwindigkeitseinbu�en im Vergleich zu Ihrer vorherigen Konfiguration feststellen k�nnen. Voila: die Delay-Pools funktionieren und Sie k�nnen sich durch schrittweises Erh�hen der delay_parameters [40] an den f�r Sie optimalen Wert herantasten.

Erh�hen Sie den Wert bitte jeweils um Vielfache von 1024 - ansonsten mu� Squid auf- bzw. abrunden.

In eigener Sache

So. Ich hoffe, der Text hat Ihnen ein wenig geholfen und Sie k�nnen Ihren Squid nun richtig an Ihre pers�nlichen Bed�rfnisse anpassen.

Ein Hinweis sei mir am Ende noch gestattet: ich �berarbeite diesen Text von Zeit zu Zeit, wenn mir eine Mail mal wieder ein wenig Motivation verschafft. Das kann eine Frage zur Konfiguration sein - oder einfach auch mal nur ein "ich habs gelesen". Schlie�lich kann ich nicht wie ein Buchautor anhand der verkauften St�ckzahl auf die Beliebtheit meines Werkes schlie�en - und einen Lohn bekomme ich derzeit leider auch noch nicht daf�r... icon_wink

Also los: schreiben Sie mir! [41]

Viele Gr��e,
Lars


  

[ zurück zu Serverprogramme [42] | Index [43] ]

Kommentare

Schultzi
13.09.06, 07:38
Super

Klasse

Andreas
24.11.06, 08:11
Spitzen Info´s

Hallo,

da ich gerade dabei bin, einen Squid zu installieren, haben mir die Infos sehr geholfen. Speziell die Delay Pools waren für mich ein wenig schwierig , aber mit der Erklärung hab ich es jetzt begriffen. :-) Auch die Tuning Tips sind sehr wertvoll .... Respekt !!!

Weiter so ...

Grüße

Andreas

Einen Kommentar hinzufügen


Links
  [1] http://www.linux-schulserver.de/index.php?name=Sections&req=viewarticle&artid=1&allpages=1&theme=Printer
  [2] http://www.squid-cache.org/
  [3] http://www.linux-schulserver.de/Sections-index-req-printpage-artid-1.phtml
  [4] http://www.linux-schulserver.de/Sections-article1-p1.phtml#instalation
  [5] http://www.linux-schulserver.de/Sections-article1-p2.phtml
  [6] http://www.linux-schulserver.de/Sections-article1-p3.phtml
  [7] http://www.linux-schulserver.de/Sections-article1-p4.phtml
  [8] http://www.linux-schulserver.de/Sections-article1-p5.phtml
  [9] http://www.linux-schulserver.de/Sections-article1-p6.phtml
  [10] http://www.linux-schulserver.de/Sections-article1-p7.phtml
  [11] http://www.linux-schulserver.de/Sections-article1-p8.phtml
  [12] http://www.linux-schulserver.de/Sections-article1-p9.phtml
  [13] http://www.linux-schulserver.de/Sections-article1-p10.phtml
  [14] http://www.linux-schulserver.de/Sections-article1-p11.phtml
  [15] http://www.linux-schulserver.de/Sections-article1-p12.phtml
  [16] http://www.novell.com/linux/suse/
  [17] http://www.webwasher.com/
  [18] http://www.squid-handbuch.de/hb/node31_ct.html
  [19] http://www.webmin.com/
  [20] http://www.linux-schulserver.de/#lru
  [21] http://www.linux-schulserver.de/Sections-article1-p4.phtml#maximum_object_size
  [22] http://www.linux-schulserver.de/Sections-article1-p4.phtml#memory_replacement_policy
  [23] http://www.squid-cache.org/
  [24] http://www.squidguard.org/
  [25] http://www.linux-schulserver.de/Sections-article2-p1.phtml
  [26] http://www.linux-schulserver.de/Sections-article2-p1.phtml
  [27] http://www.linux-schulserver.de/#redirect_program
  [28] http://de.wikipedia.org/wiki/LDAP
  [29] http://www.linux-schulserver.de/#override-expire
  [30] http://www.linux-schulserver.de/#override-lastmode
  [31] http://www.linux-schulserver.de/#reload-into-ims
  [32] http://www.linux-schulserver.de/#ignore-reload
  [33] http://www.squid-handbuch.de/hb/node44_ct.html
  [34] http://www.linux-schulserver.de/Sections-article1-p6.phtml#auth_param
  [35] http://www.linux-schulserver.de/Sections-article2-p1.phtml
  [36] http://www.linux-schulserver.de/Sections-article14-p4.phtml#lizenz
  [37] http://www.linux-schulserver.de/Sections-article1-p9.phtml#http_access
  [38] http://www.linux-schulserver.de/mailto:%w
  [39] http://www.freeware.de/Windows_98/Bildung_Wissen/
  [40] http://www.linux-schulserver.de/Sections-article1-p12.phtml#delay_parameters
  [41] http://www.linux-schulserver.de/mailto:l.rupp@web.de?Subject=Squid-Artikel
  [42] http://www.linux-schulserver.de/index.php?name=Sections&req=listarticles&secid=1
  [43] http://www.linux-schulserver.de/index.php?name=Sections