PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : squid.conf reagiert nicht wie gewünscht



Hakam
09.02.11, 07:52
Guten Morgen an Alle!
Ich benutze Linux Suse 11.3 als Internet-Verbindungsserver. Unter anderem läuft darauf Squid. In der Squid.conf habe ich einen Verweis auf eine Bannliste notiert. Diese Liste enthält Seiten, die man nicht per Browser aufrufen soll.
Außerdem habe ich eine Bash-Datei namens “transproxy” eingerichtet, die den Datenverkehr, der vom Intranet kommt, über den Port 3128 (Squid) umleiten soll (Transparenter Proxy).
Inhalt: “/usr/bin/iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 80 -j REDIRECT –to -port 3128"
Nun habe ich festgestellt, dass nach dem Booten des Rechners die Bannliste nicht berücksichtigt wird - sprich, die Benutzer können Seiten aufrufen, die in der Bannliste als gesperrte Seiten aufgelistet sind.
Wenn ich Squid nach dem Booten einmal stoppe und wieder neu starte, dann wirkt die Bannliste.
Ich vermute nun, dass im Ordner /etc/init.d/rc5,d die Datei sxxtransproxy (xx für eine Nummer) oder die Datei sxxsquid eine falsche (zu kleine) Nummer trägt und somit vielleicht die Wirkung quasi verpufft. Also habe ich beide Nummern - ohne Erfolg - erhöht.
Was kann die Ursache dafür sein, dass die squid.conf beim Booten nicht komplett, vielleicht auch gar nicht, wirkt?
Für zielführende Antworten bin ich sehr dankbar.
Gruß Hakam

muell200
09.02.11, 09:53
Nun habe ich festgestellt, dass nach dem Booten des Rechners die Bannliste nicht berücksichtigt wird - sprich, die Benutzer können Seiten aufrufen, die in der Bannliste als gesperrte Seiten aufgelistet sind.


es geht nicht - ist keine fehlermeldung

poste config, log, genaue beschreibung...

Hakam
10.02.11, 07:39
Hier die squid.conf. Ich habe sie schon bereinigt (keine #-Zeilen mehr).


# WELCOME TO SQUID 3.0.STABLE25

#Default:
# acl all src all
#
#Recommended minimum configuration:
acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32
acl localnet src 10.1.0.0/16 # RFC1918 possible internal network
acl ban dstdomain -i "/srv/www/dateien/banlist.txt"
#
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT

# TAG: http_access

http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access deny ban
http_access allow localnet

http_access allow localhost

http_access deny all

icp_access allow localnet
icp_access deny all

# TAG: htcp_access
htcp_access allow localnet
htcp_access deny all


# Squid normally listens to port 3128
http_port 10.1.1.254:3128 transparent


Ich hoffe, ich habe keine Nutzzeile gelöscht.
Anmerkung:
Wie gesagt: squid funktioniert tadellos, wenn ich den Dienst einmal manuell stopppe ((mit Yast natürlich) und danach wieder starte. Die Bannliste wird dann angesprochen und die Seiten sind dann gesperrt. Das sagt mir, dass in der Squid.conf eigentlich kein Fehler sein kann.
Die Eintragungen in der Bannliste haben die Form ".partyface.de" usw...
Log-Dateien werden auf diesem Server in's Nirwana geschickt, weshalb ich momentan damit nicht dienen kann. Übrigens: Welche Log-Datei soll es denn sein?
Soweit dazu. Und vielen Dank im Voraus für Deine (Euere) Bemühungen.
Gruß Hakam

[oETTi]
11.02.11, 17:50
Logfiles werden ins Nirvana geschickt??? :confused: Was ist das denn?
Wie willst du denn rauskriegen, ob überhaupt Verbindungen über deinen Squid laufen oder vllt. doch daran "vorbei", weil deine iptables-Regel vllt. nicht wirksam ist?

nopes
12.02.11, 01:33
hi,

keine Ahnung was da nun genau in die Grütze geht, aber der Weg des kleinsten Widerstands ist wohl: starte es einfach neu.

Log: /var/log - heißer Kandidat... ;)

ähm ansonsten hilft evt. ein "#iptables -nvL"; ggf. mal posten