nachdem ich die Probleme mit meinen ROOM_DEFAULTS lösen konnte, stehe ich heute vor dem folgenden Problem: Beim Ausführen von apt-get update werden ausschließlich Fehlschläge beim Holen der Repositories gemeldet.
Ich konnte das Problem schon auf den WebProxy eingrenzen. Deaktiviere ich diesen hat der Server Zugriff auf die Updates. In der Firewall ist der Server für allen Ports nach außen freigegeben (Regel aktiviert, Firewall nochmal neugestartet). Im Squid ist der Server unter Uneingeschränkte IP-Adressen eingetragen.
Der Port 80 taucht bei zulässige Standardports nicht auf, was aber richtig ist, da dieser ja über den Proxy geleitet wird, oder?
nachdem ich die Probleme mit meinen |ROOM_DEFAULTS| lösen konnte, stehe
ich heute vor dem folgenden Problem: Beim Ausführen von apt-get update
werden ausschließlich Fehlschläge beim Holen der Repositories gemeldet.
Ich konnte das Problem schon auf den WebProxy eingrenzen. Deaktiviere
ich diesen hat der Server Zugriff auf die Updates. In der Firewall ist
der Server für allen Ports nach außen freigegeben (Regel aktiviert,
Firewall nochmal neugestartet). Im Squid ist der Server unter
Uneingeschränkte IP-Adressen eingetragen.
Der Port 80 taucht bei zulässige Standardports nicht auf, was aber
richtig ist, da dieser ja über den Proxy geleitet wird, oder?
Wo kann ich noch weitersuchen?
der Web Proxy im IPFire ist die richtige Adresse.
Da muss
10.16.1.1
in den uneingeschränkten IP Adressen drin stehen.
Wenn es dann trotzdem nicht geht, dann sollte man prüfen ob im Web Proxy
die „Web Browser prüfung“ eingeschlatet ist.
Falls ja: den haken bei apt-get setzen.
Nach Änderungen an dieser Stelle ganz unten speichern + neustarten nicht
vergessen.
vielen Dank für eure Antworten.
Ich hatte in der ursprünglichen Nachricht schon geschrieben, dass der Server bei den uneingeschränkten IP-Adressen steht (bzw. seine IP) und es eine Firewall-Regel 10.16.1.1 -> Alle gibt.
vielen Dank für eure Antworten.
Ich hatte in der ursprünglichen Nachricht schon geschrieben, dass der
Server bei den uneingeschränkten IP-Adressen steht (bzw. seine IP) und
es eine Firewall-Regel 10.16.1.1 → Alle gibt.
Die Browser-Prüfung ist deaktiviert.
Neustart von Firewall und Proxy habe ich schon versucht.
OK. das sieht eigentlich gut aus.
Bitte beschreib mal eure Außenanbindung genauer.
DSL? Kabel? IPv4? IPv6? DSLite?
Habt ihr einen vorgelagerten Proxy?
Was hast dud en vor dem IPFire stehen? FritzBox?
Hat es schon funktioniert?
Kommen derzeit alle, außer dem Server, ins Netz?
Bei mir steht der Port 80 im WebProxy in den Zulässigen Standardports drin.
Schau mal nach , ob die MAC Adresse des Servers nciht ausversehen im
Proxy bei „verbotene MAC Adressen“ steht.
wir sind per Glasfaser an das Rechenzentrum der TU Darmstadt angegliedert. Wir haben keinen vorgelagerten Proxy.
Es hat schon funktioniert und alle Rechner außer dem Server kommen problemlos raus.
Wenn ich Port 80 in die zulässige Standardports aufnehme, kommt der Server raus. Dann funktioniert jedoch die Internetsperre nicht mehr.
Wie lautet die IP-Adresse auf der roten Schnittstelle. Die müsste
192.168.xy.254 lauten. xy ist die letzte Zahl der öffentlichen IP Eurer Schule sie beginnt mit 130…
Dann Ping mal auf dem IPFIRE auf 192.168.xy.1
ergibt das eine Antwort?
Soweit ich das mit verfolgt habe scheint alles zu stimmen. Ggf. setzt Dich mit der TU in Verbindung. Dort bekommst Du sehr schnell Support. Es ist schon vor gekommen, dass dort eine Einstellung nicht richtig war und deshalb der Internetzugang nicht funktionierte.
ich habe jetzt an drei Schulen nachgesehen.Unter Ziel-Ports auf dem IPFIRE Proxy steht überall 80 # http drin nur bei Euch nicht. http eingetragen und schon funktionierts.
Wenn die Internet-Sperre dann nicht mehr funktioniert, dann muss ein anderer Fehler vor liegen.
Der Clamav bekommt nach wie vor keine Aktualisierungen. Auf dem Server meiner Schule habe ich den freshclam Daemon gestoppt und dann freshclam von Hand ausgeführt. Die Aktualisierungen wurden geladen. Bei Euch funktioniert das nicht.
Am 28.09. taucht zum ersten Mal die Meldung auf (Horde) dass die Virensignaturen nicht geladen werden können. Kannst Du Dich erinnern was Du davor geändert hast?
Einige Deiner Geräte versuchen einen Zeitserver im Internet zu erreichen. Das gelingt aber nicht, weil der Port 123 nicht frei gegeben ist. Bei Euch holt der IPFIRE die Zeit und ist zugleich Zeitserver. Du solltest also die Geräte darauf einstellen die Zeit vom IPFIRE zu holen.
wow, vielen, vielen Dank für Deine Hilfe.
Zu dieser Zeit habe ich das Problem mit der Internetsperre angegangen und über die Wegnahme von Port 80 in den zulässigen Standard-Ports “gelöst”. Ich hatte gedacht (und ich meine auch gelesen), dass der Port 80 über den Proxy ausgeliefert wird.
Dann muss ich mich mal näher mit der Internetsperre auseinandersetzen. Nehme ich den Port 80 aus den Standard-Ports raus, erscheint bei Internetsperre die IP-Fire-Meldung bei den Clients wie gewünscht. Ohne den Port (wie jetzt wieder) haben die Clients dauerhaft Zugriff auf das Internet. Morgen schaue ich mir es mal vor Ort an.
melde Dich als Administrator in der Schulkonsole an und schau Dir die Einstellungen unter
Einstellungen\Räume
an.
Nur die Räume, welche als Computerräume deklariert sind (Haken gesetzt) können via Schulkonsole geschaltet werden. Alle anderen benutzen die Einstellung in der room_defaults
default on on off
Deshalb hast Du auch so viele ungefilterte Rechner.
Derzeit ist nur ein Raum als Computerraum definiert.
das Problem war auf eine falsche Konfiguration des Proxies zurückzuführen. Zunächst gehört Port 80 zu den Standard-Ports und sollte dort vermerkt sein.
Des Weitern stand bei uns aber im Proxy unter “Erlaubte Subnetze” das gesamte grüne Netz drin. Dadurch wurde die gesamte Internetsperre ausgehebelt und Einstellungen in der Schulkonsole wurden nicht umgesetzt.
Das ist richtig so, dass das 10.16.0.0er Netz dort drin steht. Es steht bei allen anderen Schulen die ich betreue auch dort und alles funktioniert.
Es muss dort
10.16.0.0/12
stehen.
Was Du noch nicht gemacht hast. Du hast noch nicht die Computerräume als solche in der Schulkonsole deklariert (siehe weiter oben). Oder habt Ihr nur noch einen Computerraum? Auch die Geräte die im grünen Netz im WLAN hängen sollten m.E. wie ein Raum behandelt werden.
das ist ungünstig, denn ohne diese Einstellung funktioniert alles problemlos. Ich hatte die Konfiguration des IP-Fire über linuxmuster-ipfire --setup --first zurückgesetzt. Dabei wurde nur das blaue Netz als erlaubtes Subnetz eingetragen und alles lief ohne Probleme. Wenn ich das Subnetz eintrage, funktioniert die Sperre nicht mehr.
Da das Problem nicht mehr mit der aktuellen Thread-Überschrift zusammenpasst, erstelle ich einen neuen Thread über die Internetsperre.