crotchmaster
happy BSD user
Moin Jungs,
ich habe z.Z. ein Problem mit einem FreeBSD Server, der bei einem Provider steht. Der Provider betreibt Switches, die einen Port abschalten, wenn von dem Server eine Verbindung mit einer MAC-Adresse rausgeht, die nicht zu dem Port gehört. Der Server ist danach netzwerktechnisch nicht mehr erreichbar, läuft aber sonst 1a.
Etwas zur Konfiguration. Das System läuft noch mit FreeBSD 6.2. Darauf läuft ein Jail mit einer privaten IP-Adresse (192.168.0.1/32). Die IP-Adresse ist an das Interface lo1 gebunden. Über pf werden Anfragen an die öffentl. IP-Adresse auf den Ports 22, 80 und 443 über redirects an die entsprechenden Ports im Jail weitergeleitet. DNS-Requests und ausgehende Mails gelangen via NAT in die große weite Welt, DNS-Requests nur zu den Nameservern des Providers, SMTP uneingeschränkt. Das gesamte Netzwerkgedöns wird nur auf dem Hostsystem konfiguriert und ist über das Jail nicht veränderbar.
Meine Frage ist nun. Wie ist es möglich, das Ethernet-Frames mit einer verkehrten MAC-Adresse das System verlassen, wodurch die Portsperre ausgelöst wird?
Der Support meint, das taucht auf, wenn eine virtuelle Maschine versucht, mit einer anderen MAC-Adresse eine Verbindung auf zubauen. Das kann ich mir angesicht der o.g. Konfiguration nicht vorstellen.
Ich habe die Logfiles trotzdem durchforstet und finde keine Hinweise auf Veränderungen. Da ich nun mit meinem Latein am Ende bin, habe ich als Akt der Verzweiflung pflog abgeschaltet, wodurch das Interface nicht mehr im promiscous-Mode arbeitet. Ich glaube aber nicht, dass das etwas bewirkt, zumal ich es auch bei anderen System aktiviert habe. Wir haben bei dem gleichen Provider ein identisches System laufen, was die Hardware, die Software und die Konfiguration betrifft, welches keinerlei Probleme bereitet. Bei dem fehlerhaften System hatte ich das Problem schoneinmal vor ca. 8 Wochen.
Ist es denkbar, das es auch ein Hardwareproblem der Netzwerkkarte ist?
Ich wäre für Lösungsvorschläge sehr dankbar, auch für Tipps, wie ich das Problem weiter eingrenzen kann. Wenn Ihr weitere Angaben benötigt, dann lasst es mich wissen.
Danke und Gruß c.
ich habe z.Z. ein Problem mit einem FreeBSD Server, der bei einem Provider steht. Der Provider betreibt Switches, die einen Port abschalten, wenn von dem Server eine Verbindung mit einer MAC-Adresse rausgeht, die nicht zu dem Port gehört. Der Server ist danach netzwerktechnisch nicht mehr erreichbar, läuft aber sonst 1a.
Etwas zur Konfiguration. Das System läuft noch mit FreeBSD 6.2. Darauf läuft ein Jail mit einer privaten IP-Adresse (192.168.0.1/32). Die IP-Adresse ist an das Interface lo1 gebunden. Über pf werden Anfragen an die öffentl. IP-Adresse auf den Ports 22, 80 und 443 über redirects an die entsprechenden Ports im Jail weitergeleitet. DNS-Requests und ausgehende Mails gelangen via NAT in die große weite Welt, DNS-Requests nur zu den Nameservern des Providers, SMTP uneingeschränkt. Das gesamte Netzwerkgedöns wird nur auf dem Hostsystem konfiguriert und ist über das Jail nicht veränderbar.
Meine Frage ist nun. Wie ist es möglich, das Ethernet-Frames mit einer verkehrten MAC-Adresse das System verlassen, wodurch die Portsperre ausgelöst wird?
Der Support meint, das taucht auf, wenn eine virtuelle Maschine versucht, mit einer anderen MAC-Adresse eine Verbindung auf zubauen. Das kann ich mir angesicht der o.g. Konfiguration nicht vorstellen.
Ich habe die Logfiles trotzdem durchforstet und finde keine Hinweise auf Veränderungen. Da ich nun mit meinem Latein am Ende bin, habe ich als Akt der Verzweiflung pflog abgeschaltet, wodurch das Interface nicht mehr im promiscous-Mode arbeitet. Ich glaube aber nicht, dass das etwas bewirkt, zumal ich es auch bei anderen System aktiviert habe. Wir haben bei dem gleichen Provider ein identisches System laufen, was die Hardware, die Software und die Konfiguration betrifft, welches keinerlei Probleme bereitet. Bei dem fehlerhaften System hatte ich das Problem schoneinmal vor ca. 8 Wochen.
Ist es denkbar, das es auch ein Hardwareproblem der Netzwerkkarte ist?
Ich wäre für Lösungsvorschläge sehr dankbar, auch für Tipps, wie ich das Problem weiter eingrenzen kann. Wenn Ihr weitere Angaben benötigt, dann lasst es mich wissen.
Danke und Gruß c.