Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
| server:squid [2007/08/26 21:36] – st | server:squid [2011/05/24 16:36] (aktuell) – st | ||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| + | ====== SQUID ====== | ||
| + | {{: | ||
| + | |||
| + | Squid zeichnet sich vor allem durch seine gute Skalierbarkeit aus. Squid unterstützt die Netzwerkprotokolle HTTP/HTTPS, FTP über HTTP und Gopher. Er kann sowohl für sehr kleine Netze (5-10 User), als auch für sehr große Proxyverbünde in Weitverkehrsnetzen mit mehreren hunderttausend Benutzern eingesetzt werden (aus der [[wpde> | ||
| + | |||
| + | ===== Features ===== | ||
| + | * mehrere Cache-Partitionen | ||
| + | * Webverwaltung über cgi-Skript | ||
| + | * ... | ||
| + | |||
| + | ===== Installation ===== | ||
| + | |||
| + | Squid kann direkt aus den Paketquellen von Ubuntu über das Paket | ||
| + | |||
| + | * **squid** | ||
| + | |||
| + | installiert | ||
| + | |||
| + | * Restarting Squid HTTP proxy squid | ||
| + | * Creating squid spool directory structure | ||
| + | FATAL: Could not determine fully qualified hostname. | ||
| + | |||
| + | ausgegeben. Das ist normal, denn Squid muss erst konfiguriert werden. | ||
| + | |||
| + | ===== Konfiguration ===== | ||
| + | |||
| + | Wie schon in der Einleitung geschrieben ist Squid nicht nur ein Programm für kleine Netze Zuhause oder in der Firma. Squid kann so gut wie alle Einsatzzwecke abdecken. Dies hat leider zur Folge, dass die Konfiguration nicht sehr einfach ist. Allerdings sind die Grundfunktionen leicht zu konfigurieren, | ||
| + | |||
| + | Sämtliche Konfigurationen werden in der Datei **/ | ||
| + | |||
| + | ===== Blacklisten über Squidguard ===== | ||
| + | |||
| + | * [[http:// | ||
| + | * [[http:// | ||
| + | |||
| + | |||
| + | ==== Netzwerkport ==== | ||
| + | |||
| + | Üblicherweise wartet Squid auf dem Port 3128 auf Anfragen. Bei Bedarf lässt sich der Port über die Option | ||
| + | |||
| + | # TAG: http_port | ||
| + | http_port 3128 | ||
| + | |||
| + | frei setzen. | ||
| + | |||
| + | ==== Größe des Caches im Arbeitsspeicher ==== | ||
| + | |||
| + | Je nachdem wie viel RAM der Rechner zur Verfügung hat, kann man den Wert auf sein System anpassen. Zu beachten ist, das Squid bei hoher Auslastung auch über diesen Wert hinaus geht. Dient der Rechner als reiner http-Proxy, so kann man bis zu 20% des vorhanden Speichers angeben. | ||
| + | |||
| + | # TAG: cache_mem | ||
| + | cache_mem 32 MB | ||
| + | |||
| + | ==== Max. Größe gecachter Dateien ==== | ||
| + | |||
| + | Ein relativ kleiner Wert führt zu höheren Objekt-Hitraten und damit in der Regel zu etwas besserer Geschwindigkeit. Ein höherer Wert führt zu einer höheren Byte-Hitrate und reduziert die nötige Bandbreite. Der Standardwert sind 4096 KB. Je nach Bedarf kann dieser Wert variiert werden. | ||
| + | |||
| + | # TAG: maximum_object_size | ||
| + | maximum_object_size 10000 KB | ||
| + | |||
| + | ==== Max. Größe gecachter Dateien im RAM ==== | ||
| + | |||
| + | Da RAM meistens die begehrteste Ressource ist, gibt man an, bis zu welcher Größe Dateien im RAM gehalten werden dürfen. Ein größerer Wert verbessert natürlich die Performance des Cache, wenn immer wieder die selben Daten angefordert werden. Reduziert jedoch die Menge an Dateien, die im RAM vorgehalten werden können. | ||
| + | |||
| + | # TAG: maximum_object_size_in_memory | ||
| + | maximum_object_size_in_memory 32 KB | ||
| + | |||
| + | ==== Verfahren um Speicherplatz freizugeben ==== | ||
| + | |||
| + | Wenn der Cache voll ist, muss entschieden werden, welche Daten gelöscht werden sollen und welche nicht. Dafür gibt es 3 Verfahren: | ||
| + | |||
| + | * **LRU** behält die zuletzt angefragten Objekte im Cache, unabhängig von Größe und Alter der Objekte. (Wird als Standard verwendet, wenn man nichts angibt) | ||
| + | * **heap GDSF** optimiert die Objekt-Hitrate. Kleine, häufig angefragte Objekte werden auf Kosten großer, weniger häufig angefragter Objekte im Cache gehalten. Damit wird die Wahrscheinlichkeit eines Objekt-Hit gesteigert. | ||
| + | * **heap LFUDA** optimiert die Byte-Hitrate. Häufig angefragte Objekte werden im Cache gehalten, selten angefragte werden freigegeben, | ||
| + | |||
| + | Für kleinere Netzwerke ist //" | ||
| + | |||
| + | # TAG: cache_replacement_policy | ||
| + | cache_replacement_policy heap LFUDA | ||
| + | # TAG: memory_replacement_policy | ||
| + | memory_replacement_policy heap LFUDA | ||
| + | |||
| + | ==== Speicherort des Caches ==== | ||
| + | |||
| + | Bei Bedarf kann man noch definieren wo Squid die gecachten Daten ablegen soll. Standard ist dies das Verzeichnis **/ | ||
| + | |||
| + | # TAG: cache_dir | ||
| + | cache_dir ufs / | ||
| + | |||
| + | bestimmen | ||
| + | |||
| + | * **ufs** - Ist Das Speichersystem von squid | ||
| + | * **/ | ||
| + | * **2000** - Gibt die Cache-Größe in MB an. Dabei sollte man beachten, dass man diesen Eintrag nicht beliebig hoch setzen darf. Um so größer der Cache ist, um so mehr RAM braucht Squid. Also nicht einfach einen Cache von 40GB machen, weil man ausreichend Festplattenplatz hat. | ||
| + | * **16** - Gibt an, wie viele Unterordner für Level1 Domains erstellt werden sollen | ||
| + | * **256** - Gibt an, wie viele Unterordner für Level2 Domains erstellt werden sollen | ||
| + | |||
| + | ==== Cache löschen ==== | ||
| + | |||
| + | Sollte aus irgendeinem Grund der Cache von Squid gelöscht werden, muss dafür Squid angehalten, der Löschbefehl abgesetzt und anschließend wieder der Start erfolgen: | ||
| + | |||
| + | < | ||
| + | / | ||
| + | squid -z | ||
| + | / | ||
| + | </ | ||
| + | |||
| + | Die ersten Seitenaufrufe gehen dann langsam, da der Cache erst wieder aufgebaut wird. Wenn man das vermeiden möchte ruft man lokal schon einmal oft benutzte Seite ab. Dazu kann wget benutzt werden. | ||
| + | |||
| + | < | ||
| + | wget --cache=off -r http:// | ||
| + | </ | ||
| + | |||
| + | Anschließend können die lokal übertragenen Dateien gelöscht werden. | ||
| + | |||
| + | |||
| + | |||
| + | ==== Datenschutz ==== | ||
| + | |||
| + | Wenn die Privatsphäre der Clients bewahrt werden soll oder muss (z.B. Datenschutz in Unternehmen), | ||
| + | |||
| + | # TAG: client_netmask | ||
| + | client_netmask 255.255.255.0 | ||
| + | |||
| + | ==== IP Adresse verbergen ==== | ||
| + | |||
| + | Nach den Voreinstellungen von Squid, wird die wahre IP-Adresse des eigenen Rechners hinter dem Proxy-Server in den Header Daten mitgesendet. Dieses kann man unterdrücken, | ||
| + | |||
| + | # TAG: forwarded_for | ||
| + | forwarded_for off | ||
| + | |||
| + | Diese Einstellung bewirkt nicht dass man komplett anonym im Netz ist. Es wird lediglich die lokale IP Adresse hinter einem NAT-Router nicht mehr mitgesendet. Die eigentliche Internet-IP-Adresse sieht der Webserver nach wie vor. | ||
| + | |||
| + | ==== Squid VIA Header ausschalten ==== | ||
| + | |||
| + | Normalerweise sendet Squid im Header **HTTP_VIA** seinen Versions-String mit. Dies kann man mit folgenden Eintrag unterdrücken: | ||
| + | |||
| + | via off | ||
| + | |||
| + | ==== Authentifizierung ==== | ||
| + | |||
| + | Die Authentifizierung funktioniert nur mit einem Proxy, der normal angesprochen wird. Richtet man Squid als transparenten Proxy ein, so ist eine Authentifizierung nicht möglich, da der Proxy ja nicht direkt vom Client aus angesprochen wird. | ||
| + | |||
| + | Eventuell möchte man, dass sich Benutzer am Squid Proxy anmelden müssen, bevor sie über den Proxy auf das Internet zugreifen können. Dies ist sinnvoll, wenn z.B. unterschiedliche Nutzer verscheidene Rechte bekommen sollen. So ist es z.B. möglich, dass einzelne Benutzer über Blacklist definierte Webseiten nicht aufrufen können. Am einfachsten ist es, die vorhandenen Benutzer im System zur Authentifizierung am Squid-Proxy heranzuziehen. Dazu müssen die Zeilen | ||
| + | |||
| + | # TAG: auth_param | ||
| + | auth_param basic program / | ||
| + | auth_param basic children 5 | ||
| + | auth_param basic realm Squid proxy-caching web server | ||
| + | auth_param basic credentialsttl 2 hours | ||
| + | auth_param basic casesensitive off | ||
| + | |||
| + | aktiviert und **/ | ||
| + | |||
| + | # TAG: http_access | ||
| + | acl checkpw proxy_auth REQUIRED | ||
| + | http_access allow checkpw all | ||
| + | |||
| + | nötig. Danach können Benutzer sich mit ihren Daten einloggen, die sie nutzen um sich lokal am Rechner anzumelden. | ||
| + | |||
| + | ==== Zugriffslisten und -regeln (ACLs) ==== | ||
| + | |||
| + | Aus Sicherheitsgründen ist die Voreinstellung von Squid so, dass niemand Anfragen über den Proxy in das Internet schicken darf. Deshalb muss jeder Rechner bzw. jedes Netz explizit freigegeben werden (siehe Beispiele) indem man Zugriffsrechte erteilt. | ||
| + | |||
| + | Für die Rechtevergabe muss zunächst die Zugriffs-Kontroll-Liste (Access Control List, ACL) definiert werden. Anschließend wird über den Namen dieser ACL das Recht mit dem Schlüsselwort http_access zugewiesen. | ||
| + | |||
| + | Die Syntax einer ACL sieht allgemein so aus. | ||
| + | |||
| + | acl < | ||
| + | |||
| + | Hinweis: | ||
| + | |||
| + | Die Reihenfolge der Freigaben ist entscheidend! Wurde zuerst ein http_access deny all gesetzt, kann man darunter keinen Zugriff mehr einrichten. Der Einfachheit halber kannst du am besten deine Freigabe Regeln in der config Datei ganz oben einfügen. | ||
| + | |||
| + | Bei den Beispielen müssen natürlich die IP-Adressen an die eigenen Verhältnisse angepasst werden. | ||
| + | |||
| + | === Beispiele === | ||
| + | |||
| + | Als **Beispiel 1** wird hier die ACL-Regel " | ||
| + | |||
| + | < | ||
| + | # Beispiel 1: | ||
| + | acl freigegeben1 src 192.168.10.0/ | ||
| + | http_access allow freigegeben1 | ||
| + | </ | ||
| + | |||
| + | Möglich ist auch die Angabe einer Teilmenge von Rechnern aus einem Netz: Hier als **Beispiel 2** die ACL " | ||
| + | |||
| + | < | ||
| + | # Beispiel 2: | ||
| + | acl freigegeben2 src 192.168.20.1-192.168.20.99 | ||
| + | http_access allow freigegeben2 | ||
| + | </ | ||
| + | |||
| + | **Beispiel 3**: Lediglich einzelne Rechner freigeben: Eine einfache Erlaubnis-Regel für die IP 192.168.30.1 (Name ist hier " | ||
| + | |||
| + | < | ||
| + | # Beispiel 3: | ||
| + | acl testpc src 192.168.30.1 | ||
| + | http_access allow testpc | ||
| + | </ | ||
| + | |||
| + | |||
| + | ==== Hostname ==== | ||
| + | |||
| + | Besitzt der Rechner auf dem man Squid aufsetzt keinen ordentlichen Namen inklusive Domäne (also z.b. rechner.foo.bar), | ||
| + | |||
| + | # TAG: visible_hostname | ||
| + | visible_hostname meinproxy | ||
| + | |||
| + | einen Namen einsetzen. Diese Option ist besonders wichtig, wenn wie oben genannt, Squid aufgrund eines //"not fully qualified hostname"// | ||
| + | |||
| + | ==== Traffic über weiteren Proxy leiten ==== | ||
| + | |||
| + | Um den gesamten Traffic von Squid zu einem anderen Proxy, beispielsweise Privoxy oder Tor, zu leiten reicht folgender Eintrag: | ||
| + | |||
| + | # TAG: cache_peer | ||
| + | cache_peer localhost parent 8118 7 no-query default | ||
| + | |||
| + | Hierbei ist localhost durch den Hostnamen des Proxyservers zu ersetzen, 8118 durch den entsprechenden Port. Zusätzlich muss noch dieser Eintrag gemacht werden: | ||
| + | |||
| + | # TAG: never_direct | ||
| + | never_direct allow all | ||
| + | |||
| + | Um wirklich den gesamten Traffic weiterzuleiten. | ||
| + | |||
| + | Somit könnte folgendes Szenario entstehen: Browser des Benutzers -> Squid (Cache) -> Privoxy (Werbefilter) -> Tor (Anonymisierer) -> WWW. Aber dies bleibt natürlich jedem selber überlassen. | ||
| + | |||
| + | ==== Transparenter Proxy ==== | ||
| + | |||
| + | Diese Konfiguration ist optional. Sie ist nur nötig, wenn der gesamte http-Netzwerkverkehr über den Proxy geleitet werden soll, selbst wenn die Clients keinen Proxy eintragen. Aufgrund der nötigen Kenntnisse bezüglich [[http:// | ||
| + | |||
| + | Ein transparenten Proxy ist ein Proxyserver der vollkommen im Hintergrund arbeitet und der automatisch über eine iptables Regel alle Internetpakete, | ||
| + | |||
| + | === Konfiguration] === | ||
| + | |||
| + | == Ab Ubuntu Edgy Eft 6.10 == | ||
| + | |||
| + | Ab Ubuntu Edgy Eft 6.10 wird Squid als transparenter Proxy über die eine zusätzlichen Paramter an der Option //" | ||
| + | |||
| + | # Squid normally listens to port 3128 | ||
| + | http_port 3128 transparent | ||
| + | |||
| + | == Bis Ubuntu Dapper Drake 6.06 == | ||
| + | |||
| + | Bis Ubuntu Dapper Drake 6.06 müssen diese Optionen aktiviert werden. | ||
| + | |||
| + | # HTTPD-ACCELERATOR OPTIONS | ||
| + | ... | ||
| + | # TAG: httpd_accel_host | ||
| + | # TAG: httpd_accel_port | ||
| + | httpd_accel_host virtual | ||
| + | httpd_accel_port 80 | ||
| + | ... | ||
| + | # TAG: httpd_accel_with_proxy | ||
| + | httpd_accel_with_proxy on | ||
| + | ... | ||
| + | # TAG: httpd_accel_uses_host_header | ||
| + | httpd_accel_uses_host_header on | ||
| + | |||
| + | === Iptables-Regel === | ||
| + | |||
| + | Die dazu passende [[http:// | ||
| + | |||
| + | iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128 | ||
| + | |||
| + | ==== Delay Pools ==== | ||
| + | |||
| + | Delay Pools sind ein sehr komplexes Thema. Die Aufteilung in Klassen und die Arbeit mit regulären Ausdrücken überfordert sicherlich Einsteiger. | ||
| + | |||
| + | Anfragen können in verschiedene Klassen unterteilt, über Filter sortiert und schließlich priorisiert werden. So ist es Möglich gewissen IPs mehr Bandbreite zur Verfügung zu stellen, als anderen oder die Datenrate von Downloads z.B. komplett zu limitieren. | ||
| + | |||
| + | Als sehr einfaches Beispiel sei ein Delay Pool vorgegeben, der den kompletten Durchsatz auf 75kb/s ab einer Dateigröße von 32kb limitiert. | ||
| + | |||
| + | # DELAY POOL PARAMETERS | ||
| + | delay_pools 1 | ||
| + | delay_class 1 1 | ||
| + | delay_parameters 1 32000/75000 | ||
| + | delay_access 1 allow All | ||
| + | |||
| + | Weitere Funktionen bedürfen individuellen Anpassungen und meist ein ausführliches Studium der Squid Dokumentationen. | ||
| + | |||
| + | ===== Dienst steuern ===== | ||
| + | |||
| + | Squid lässt sich wie jeder andere Dienst auch über die init-Skripte steuern. In einem Terminal kann man über | ||
| + | |||
| + | # Allgemein | ||
| + | sudo / | ||
| + | # Beispiel | ||
| + | sudo / | ||
| + | |||
| + | den Dienst steuern. Mehr zu dem Thema Dienste findet man im Wiki [[http:// | ||
| + | |||
| + | |||
| + | |||
| + | ===== Überwachen ===== | ||
| + | |||
| + | |||
| + | :!: In Betrieben existieren normalerweise Datenschutzbestimmungen. So dürfen z.B. oftmals keine personenbezogenen Informationen aus Proxy-Logdateien gewonnen werden. Diese Datenschutzbestimmungen gelten auch für einen kleineren Rahmen. Setzt man zuhause für die Familie, für die Mitbewohner oder die Mitarbeiter einen Proxy auf, so hat man diese über die Logs zu informieren, | ||
| + | |||
| + | Squid kann umfangreiche Logdaten - in **/ | ||
| + | |||
| + | [[http:// | ||
| + | |||
| + | ==== squidview ==== | ||
| + | |||
| + | [[http:// | ||
| + | |||
| + | * **squidview** (// | ||
| + | |||
| + | installiert werden. Über Filter und Suchoptionen kann effektiv nach Informationen im Squidlog gesucht werden. Ebenso ist es möglich Berichte zu exportieren. Das Programm wird nach der Installation in einem Terminal mit dem Befehl | ||
| + | |||
| + | sudo squidview | ||
| + | |||
| + | aufgerufen. | ||
| + | |||
| + | [[http:// | ||
| + | |||
| + | ==== sarg ==== | ||
| + | |||
| + | [[http:// | ||
| + | |||
| + | * **sarg** (// | ||
| + | |||
| + | installiert werden und wird dann über ein Terminal mit dem Befehl | ||
| + | |||
| + | # Allgemein | ||
| + | sudo sarg -g e -o </ | ||
| + | |||
| + | ausgeführt werden. Gibt man keinen Pfad an, so wird die Ausgabe direkt nach **/ | ||
| + | |||
| + | [[http:// | ||
| + | |||
| + | ==== SRG ==== | ||
| + | |||
| + | [[http:// | ||
| + | |||
| + | * **srg** (// | ||
| + | |||
| + | installiert werden. Möchte man noch Konfigurationen vornehmen, so kann man dies in der **/ | ||
| + | |||
| + | ===== Links ===== | ||
| + | |||
| + | |||
| + | * [[http:// | ||
| + | * [[http:// | ||
| + | * [[http:// | ||
| + | * [[http:// | ||
| + | * [[http:// | ||
| + | * [[http:// | ||
| + | * http:// | ||
| + | * [[http:// | ||
| + | * [[http:// | ||
| + | * [[http:// | ||
| + | * [[http:// | ||
| + | * [[http:// | ||
| + | |||
| + | ==== Links für den Proxy-test ==== | ||
| + | |||
| + | Um zu überprüfen, | ||
| + | |||
| + | * [[http:// | ||
| + | * [[http:// | ||
| + | |||
| + | |||
| + | ===== Fehlerbehebung ===== | ||
| + | |||
| + | ==== Debug Modus ==== | ||
| + | |||
| + | Sollte der Squid Proxy nicht korrekt starten, kann Squid im Debug Modus gestartet werden. Fehlermeldungen werden so auf dem Terminal ausgegeben. | ||
| + | |||
| + | squid -NCd1 | ||
| + | |||
| + | |||
| + | Alternativ erteilt Squid mit der Konfigurationseinstellung | ||
| + | |||
| + | |||
| + | debug_options ALL,1 33,2 28,9 | ||
| + | |||
| + | |||
| + | eine detaillierte Fehlerauskunft. Im Protokoll steht welche Regel bei welchem Request angewandt wurde und warum es zum Scheitern/ | ||
| + | |||
| + | |||
| + | |||
| + | ==== FATAL: Could not determine fully qualified hostname ==== | ||
| + | Wenn man den Dienst startet bekommt man manchmal eine Fehlermeldung, | ||
| + | FATAL: Could not determine fully qualified hostname. | ||
| + | d.h. er kann seinen Hostnamen nicht bestimmen (Befehl '' | ||
| + | Also gibt man ihn vor: | ||
| + | visible_hostname NAME | ||
| + | NAME muss natürlich durch den richtigen Namen ersetzt sein. | ||
| + | |||
| + | Wenn der [[netzwerke: | ||