Ipfire hängt ständig

jojocw · 8. Juni 2018 um 10:27

Hallo,

wir haben seit einiger Zeit Probleme mit dem Internet über den IPFIre.

Ubuntu 12.4 mit Linuxmuster 6.1.

Nach dem Hochfahren des IPFire-Rechners funktioniert das Internet und der Zugriff auf den IPFIre.

Manchmal läuft er dann einige Minuten, einige Stunden, manchmal auch einen ganzen Tag.

Dass funktioniert das Internet nicht mehr, und man hat keinen Zugriff mehr auf die Weboberfläche des IPFIre. Kann ihn also auch nicht neu starten.

Wenn man den dann per Knopfdruck oder reboot herutnerfährt und wieder neu startet, dann funktioniert alles wieder … bis zum nächsten Aussetzer.

Habe dann den IPFire neu installeirt, Core 105 weil dananch das Problem mit dem DNSSec nicht gelöst ist.

Genau das gleich Problem. linuxmuster-IPfire setup --first durchgeführt, workstations-import ebenso, hilft nichts.

Ein PRoblem beim Hochfahren

jojocw · 8. Juni 2018 um 10:31

Zu früh weggeschickt.

Ein Problem beim Hochfahren zeigt er an:
Starting Squid Proxy server
Bad Argument ´tcp´
Try íptable -h …

Wir wissen nicht, ob es am IPfire direkt liegt, oder am Netz, vielleicht hat einer eine Schleife gesteckt?
Keine Ahnung.

MFG J

baumhof · 8. Juni 2018 um 11:04

Hallo J,

zuerst würde ich mal mittels
ssh -p 222 ipfire
vom Server aus auf den IPFire gehen und folgende Ausgaben prüfen:

df -h
df -i

um zu checken, ob die Platte oder die Inoes voll sind.

Dann würde ich mal in den logs des IPFire schauen, ob da was erhellendes
drin steht.

LG

Holger

jojocw · 20. Juni 2018 um 11:10

Hallo,

df -i max 15% auf sde3
df -h max 36% auf sde3

top ergibt überwiegend 0 %
bei MEM 0 - 2%

einziger Fehler ist beim Hochfahren des IPFire, dass er Probleme mit den IPtables hat

Letzte Woche konnte man die ganze Woche ins Internet bzw. auf den IPFire zugreifen.
Gestern musst man neustarten.
Heute auch schon wieder.

Das heißt kein Zugriff auf das Internet, und kein Zugriff auf den IPFire. Auch nicht mit Putty.

MFG JH

jojocw · 20. Juni 2018 um 11:20

Was noch nicht stimmt:

Ein paar PCs sind mit PXE in der Schulkonsole eingetragen, obwohl sie gar nicht über Netz booten.

Bei Import:workstations kommt die Meldung, dass Räume multiple IP-Ranges haben.

MFG JH

jojocw · 20. Juni 2018 um 11:25

Bei Firewall-Optionen habe ich bei outgoing auf zulassen gestellt,
da ich keine Regel hinkriege, die z.Bsp Thunderbird freischaltet.

Außerdem haben wir eine Verbindung auf die Stadtbibliothek, (habs schon geschrieben, Thema Firewall-Regel) )
bei der ich ebenfalls nicht konkret weiß, wie ich die in einer Regel freischalten kann.
Zu viele Optionen beim Regel-Erstellen).Ich bräuchte dafür einen Screenschot)

Outgoing habe ich auch zugelassen.

MFG JH

baumhof · 20. Juni 2018 um 12:18

Hallo JH,

bei den Problemen, wie du sie beschreibst, liegt wohl der Hund beim
ZUsammenspiel von virtualisierer und IPFire begraben.
Deswegen würde ich folgendes machen:

IPFire updaten auf den neusten Core.
auch den Kernel vom IPFire auf den aktuellsten updaten.
Virtualisierer updaten

alles neu booten und dann beobachten.

Zusätzlich würde ich mal schauen, ob man bei virtualisierer etwas
einstellen kann wie: welcher Prozessor wird dem Gast gemeldet? Mit
welchem Befehlssatz?
Stimmen die Angaben?

Dass der IPFire hängen bleibt und nicht mehr ansprechbar ist, ist sehr
ungewöhnlich: deswegen bin ich bei „virtualisierer“.
Direkt danach käme bei mir die Hardware (Netzteil und Speicher zuerst).

Bei Firewall-Optionen habe ich bei outgoing auf zulassen gestellt,
da ich keine Regel hinkriege, die z.Bsp Thunderbird freischaltet.

… da würde ich noch mal drüber nachdenken: immerhin haben hier bestimmt
20 Einrichtungen es hinbekommen, dass man aus dem internen Netz Mails
abrufen (IMAPs und POP3s) und Abschicken kann (SMTPs)

Außerdem haben wir eine Verbindung auf die Stadtbibliothek, (habs schon
geschrieben, Thema Firewall-Regel) )
bei der ich ebenfalls nicht konkret weiß, wie ich die in einer Regel
freischalten kann.

… man trägt die Regel unter „Firewall“ als Regel:
Von:
Nach:
Protokoll:
Port:
Beschreibung:

ein und drückt nach dem Speichern auf „Änderungen übernehmen“

Zu viele Optionen beim Regel-Erstellen).Ich bräuchte dafür einen
Screenschot)

ich schick dir einen für Thunderbird (bei mir gibt es nur verschlüsselte
Ports).

Outgoing habe ich auch zugelassen.

… funktioniert dann die INternet Sperre noch?

Viele Grüße

Holger

jojocw · 20. Juni 2018 um 20:36

Hallo Holger,
Bei mir ist nichts virtualisiert.
Eine Maschine mit Linuxmuster 6.1
Eine Maschine mit Ipfire 105

Lief bis vor einigen Wochen gut.
Dann die Hänger,
Hab deshalb eine neue Maschine mit Ipfire
aufgesetzt,mit Core 105.
Aber das gleiche Problem.
Mal gehts ne Woche gut,
Mal blos ein paar Stunden.
Ich denke dass es nicht am Ipfire liegt,sondern an irgendwelchen PC die irgendwie stören.
Mfg j

baumhof · 20. Juni 2018 um 21:10

Hallo j,

Lief bis vor einigen Wochen gut.
Dann die Hänger,
Hab deshalb eine neue Maschine mit Ipfire
aufgesetzt,mit Core 105.
Aber das gleiche Problem.
Mal gehts ne Woche gut,
Mal blos ein paar Stunden.
Ich denke dass es nicht am Ipfire liegt,sondern an irgendwelchen PC die
irgendwie stören.

kannst du dich, wenn er hängt, noch am IPFire anmelden?

LG

Holger

jojocw · 21. Juni 2018 um 07:48

Hallo Holger,

nein, man kann den IPfire nicht mehr über (https://10.16.1.254:444) weder über die PCs (Browser), noch über den Server, auf dem ich ein kleines Lubuntu mit Firefox laufen hab.
(Die Schulkonsole kann aber noch erreicht werden.)

Über Putty kommt man dann auch nicht mehr ran.
Ob man direkt auf dem IPFIre was machen kann, weiß ich nicht, weil ich dann erst einen Bildschirm ranhängen muss.

MFG JH

jrichter · 21. Juni 2018 um 08:38

Hallo JH,

der erste Punkt ist unkritisch, aber den zweiten würde ich angehen. Die
IP-Bereiche sollten bei den Räumen konsistent sein.

Ob das nun mit dem IPFire-Problem zu tun hat - kann durchaus sein
(Probleme beim Sperren/Freigeben des Internets?), vielleicht aber auch
nicht.

Viele Grüße

Jörg

baumhof · 21. Juni 2018 um 09:49

Hallo Jörg,

der erste Punkt ist unkritisch, aber den zweiten würde ich angehen. Die
IP-Bereiche sollten bei den Räumen konsistent sein.

das ist einfach „Reinlichkeit“: es kann einem auf die Füße fallen: z.B.
bei Druckersperre/freigabe

Hintergrund: man weist Drucker in der SchuKo z.B. Räumen zu.
Aber in der /etc/cups/access.conf stehen IP Adressen bzw. Bereich.
Welche die SchuKo da einträgt errechnet sie aus der ersten IP die sie in
der workstation für den Raum findet.
Also sagen wir wir haben zwei Rechner im Raum:
10.16.5.1
10.16.6.2

Dann gibt die SchuKo den Drucker für 10.16.5.0/24 frei: damit wäre er
für den zweiten Rechner, obwohl er physikalisch und logisch im Raum
steht, nicht freigegeben.
Deswegen ist es gut, dass import_workstations das anmahnt.

Ob das nun mit dem IPFire-Problem zu tun hat - kann durchaus sein> (Probleme beim Sperren/Freigeben des Internets?), vielleicht aber auch
nicht.

ich denke nein, da die Sperre per MAC Adresse funktioniert, es sei den,
man hat subnetting aktiviert: dann läuft es auf IP Adresse.

LG

Holger

baumhof · 21. Juni 2018 um 09:50

Hallo JH,

nein, man kann den IPfire nicht mehr über (https://10.16.1.254:444)
weder über die PCs (Browser), noch über den Server, auf dem ich ein
kleines Lubuntu mit Firefox laufen hab.
(Die Schulkonsole kann aber noch erreicht werden.)

Über Putty kommt man dann auch nicht mehr ran.
Ob man direkt auf dem IPFIre was machen kann, weiß ich nicht, weil ich
dann erst einen Bildschirm ranhängen muss.

genau das solltest du mal testen: und sei es nur, ob das NUM Lock
Lichtchen an der Tastatur noch an/aus geht.
Ist der Rechner nicht mehr ansprechbar, dann ist der IPFire abgeschmiert
und dann hast du ein Hardwareproblem.

LG

Holger

thoschi · 21. Juni 2018 um 12:06

Hallo zusammen,

Wir hatten das mal vor ein paar Wochen. IPFire nicht mehr oder nur noch
sporadisch zu erreichen. Das ganze Netz langsam. Server war per SSH
erreichbar, IPFire nicht mehr (zuverlässig).

Ich habe ca. 3 Stundne probiert und gesucht. Netzwerksegmente abkoppeln
und mich dem Ziel so langsam nähern. Im letztlich in Frage kommenden
Raum ein Rechner. Der Monitor war ausgestöpselt, so dass er “aus”
wirkte. Darauf lief LOIC.exe - und flutete unseren IPFire mit Anfragen.

Der Schüler hatte versucht, die Datei zu entfernen, so dass sie nur im
Hintergrund noch lief. Allerdings zeigte z.B. das Log des
Windows-Virenscanners die Datei und ihren Besitzer noch.

Sync+Start und das Problem war weg. Für unser Netz. Für den Schüler
nicht, das war aber tatsächlich nicht mehr Sache der Schule

Auf jeden Fall eine lehrreiche Geschichte - nächstes Mal gehts dann
hoffentlich etwas schneller.

Viele Grüße,

Thomas

jojocw · 22. Juni 2018 um 06:30

Erst mal vielen Dank an die Mitarbeiter hier.

Hardware-Probleme schliesse ich aus, da es ja jetzt eine andere Maschine ist,
und bei der vorherigen einige Wochen lang die gleichen Probleme auftraten.

Ich vermute auch so was wie thoschi schildert, dass irgendein Gerät dauernd feuert.
Schwierig wird nur, das Gerät zu identifizieren, mal schauen wie weit ich komme.

MFG JH

jojocw · 22. Juni 2018 um 06:31

Nachtrag: Vor Jahren hatten wir mal so was ähnliches, da hatte ein Schüler an 2 Lan-Dosen eine Schleife gesteckt.
Aber heute ist unser Netz deutlich größer, vor allem mit vielen Handys im Pool.

MFG JH

jojocw · 24. Juni 2018 um 07:21

Hallo,

hab gestern mal einen Monitor an den IPFIre (eigene Maschine) gehängt, (nachdem er wohl hängt,
kein internet, kein Zugriff über die Website des IPFire).

man kann auf die Konsole,
df -h und df -i gibt nur geringe Auslastung, (wie oben schon beschrieben)
top ebenfalls nicht,

ping vom Server auf den IPFire geht nicht,
ping vom IPFire auf den Server geht auch nicht,

ping vom IPFIre auf sich selbst (ping 10.16.1.254) geht.

Nach Neustart geht wieder alles.

MFG JH

jojocw · 24. Juni 2018 um 07:31

network restart über die Konsole bringt auch nichts.

Wie kann man auf der Konsole abfragen, welcher Dienst ev. gestoppt wurde, oder hängt?

MFG JH

alois · 24. Juni 2018 um 07:57

Hallo,

wir hatten mal ein ähnliches Problem. Da war es ein Virenscanner der nach Hause telefoniert hat. Ich habe das wie folgt in Erfahrung gebracht:

tail -f /var/log/squid/access.log

Man konnte sehen dass es massenhaft Anfragen gab. Man konnt auch die IP-Adressen sehen die anfragten. Nachdem ich die IP-Adressen gesperrt hatte lief alles wieder wie gehabt.

Ein weiterer Grund für Probleme mit dem IPFIRE können Netzwerkadressen z.B. in grün und rot sein die eigentlich im gleichen Netz sind.

Bsp.: 192.168.1.3/16 und 192.168.5.4/16

Bei solchen Konstellationen macht der IPFIRE zu.

Gruß

Alois

irrlicht · 24. Juni 2018 um 08:30

Wenn ich mit einem tail -f /var/log/syslog nichts finde, dann “taile” ich per wildcard, quasi ein tail -f /var/log/*.log oder sogar hardcore tail -f /var/log/* , falls vorhanden dann auch Unterordner mit tail -f /var/log/**/*
Da fliegen einem erstmal die Zeichen um die Ohren, das beruhigt sich dann aber - vorausgesetzt das Terminal ueberlebt die Anfangsflut. Ein reset sollte falls es den Zeichensatz crasht das Terminal wieder funktionsfaehig machen.

Ich weiss nicht wo ipfire seine Logs ablaedt, also muss gegebenenfalls der Pfad angepasst werden.

Das (umfangreiche) iptables-Regelwerk laesst sich ueber iptables -L bzw. fuer die NAT-Tabelle ueber iptables -t nat -L abfragen, bevorzugt ueber ein |less seitenweise ausgeben.