22
Kein Zugriff auf Linux Server nach Neustart - Alle Ports zu
Guten Abend zusammen,
ich habe folgendes Problem. Auf meinem Linux Root Server (Debian Jessie) läuft Proxmox, sowie darauf unter anderem eine Maschiene mit einem Webserver.
Auf den Webserver (Plesk) hatte ich Zugriff, allerdings nicht mehr auf das Grundsystem auf dem dieser Virtualisiert lief. Weder Ping noch SSH lieferten ein Ergebnis. Auch ein Portscan mit nmap zeigt nur host down und mit parameter -Pn zwar das der Host "up" ist, aber alle Ports filtered, was ja auf "geschluckte" TCP-Pakete hindeutet.
Nach einem Neustart des Servers war natürlich der webhost auch down, ein Portscan zeigte dass immernoch alle Ports auf dem Rootie gefiltert werden.
Das Startupskript für iptables habe ich bereits gelöscht, obwohl vorher nie Probleme aufgetreten waren, und auch die entsprechenden Ports in der Kunfiguration freigegeben sind. in /etc/network/interfaces ist auch kein Hinweis auf iptables.
Mein letzter Verdacht fiel auf fail2ban, aber im entsprechenden log (/var/log/fail2ban.log) findet sich kein Hinweis auf eine geblockte IP-Adresse, auch nach einem generellen freigeben meiner statischen IP zu Testzwecken in der fail2ban-config, konnte ich nicht auf das System zugreifen; nmap immer noch alles gefiltert.
Zur Info: Ich kann über ein Webinterface in ein Recoverysystem booten, wodurch ich nach mounten der Raid-Platten auch Zugriff auf die logs bekam / bekommen kann.
Für alle Vorschläge wäre ich euch echt dankbar
VG
Christian
ich habe folgendes Problem. Auf meinem Linux Root Server (Debian Jessie) läuft Proxmox, sowie darauf unter anderem eine Maschiene mit einem Webserver.
Auf den Webserver (Plesk) hatte ich Zugriff, allerdings nicht mehr auf das Grundsystem auf dem dieser Virtualisiert lief. Weder Ping noch SSH lieferten ein Ergebnis. Auch ein Portscan mit nmap zeigt nur host down und mit parameter -Pn zwar das der Host "up" ist, aber alle Ports filtered, was ja auf "geschluckte" TCP-Pakete hindeutet.
Nach einem Neustart des Servers war natürlich der webhost auch down, ein Portscan zeigte dass immernoch alle Ports auf dem Rootie gefiltert werden.
Das Startupskript für iptables habe ich bereits gelöscht, obwohl vorher nie Probleme aufgetreten waren, und auch die entsprechenden Ports in der Kunfiguration freigegeben sind. in /etc/network/interfaces ist auch kein Hinweis auf iptables.
Mein letzter Verdacht fiel auf fail2ban, aber im entsprechenden log (/var/log/fail2ban.log) findet sich kein Hinweis auf eine geblockte IP-Adresse, auch nach einem generellen freigeben meiner statischen IP zu Testzwecken in der fail2ban-config, konnte ich nicht auf das System zugreifen; nmap immer noch alles gefiltert.
Zur Info: Ich kann über ein Webinterface in ein Recoverysystem booten, wodurch ich nach mounten der Raid-Platten auch Zugriff auf die logs bekam / bekommen kann.
Für alle Vorschläge wäre ich euch echt dankbar
VG
Christian
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 305685
Url: https://administrator.de/forum/kein-zugriff-auf-linux-server-nach-neustart-alle-ports-zu-305685.html
Ausgedruckt am: 27.12.2024 um 19:12 Uhr
22 Kommentare
Neuester Kommentar
die logs bekam / bekommen kann.
Die Logs sind durchaus Hilfreich. Aber wenn wir die nicht sehen..Hast du eine Möglichkeit dich mit dem vServer zu verbinden? VNC?
LG PPR
Hi,
seit dem ersten Neustart komme logischer Weise nicht mehr auf das Proxmox Webinterface und der vServer wird nicht automatisch gestartet. Ich habe also lediglich Zugriff auf den Rootie (SSH) via Rescuesystem. Da wiederrum kann ich folgende Logs anbieten (siehe Bildanhang).
VG
Christian
seit dem ersten Neustart komme logischer Weise nicht mehr auf das Proxmox Webinterface und der vServer wird nicht automatisch gestartet. Ich habe also lediglich Zugriff auf den Rootie (SSH) via Rescuesystem. Da wiederrum kann ich folgende Logs anbieten (siehe Bildanhang).
VG
Christian
Nun du kannst ja in syslog ma schauen ob da was ungewöhnliches steht bzw was der Grund dort ist das Netzwerk bzw SSH nicht erreichbar ist.
Aber da dies ja schon als gelöst Makiert wurde hast du de Fehler ja schon gefunden...
Aber da dies ja schon als gelöst Makiert wurde hast du de Fehler ja schon gefunden...
Zitat von @kaiand1:
Aber da dies ja schon als gelöst Makiert wurde hast du de Fehler ja schon gefunden...
Aber da dies ja schon als gelöst Makiert wurde hast du de Fehler ja schon gefunden...
Also das Gelöst wurde anscheinend wieder entfernt also gibt es noch ein Problem...
Ne, ist noch nicht gelöst :/ wie das da hingekommen ist weiss ich auch nicht.
Folgendes habe ich zu iptables gefunden:
Ist ja jetzt nicht ungewöhnlich.
Ich versuch mal eth0 auf statisch zu setzen und´s dann nochmal zu versuchen...
Im Anhang ist die Syslog (hier), vlt. findet ihr ja etwas. Danke schonmal
Folgendes habe ich zu iptables gefunden:
May 29 17:26:18 server65 kernel: [ 24.821470] ip_tables: (C) 2000-2006 Netfilter Core TeamIch versuch mal eth0 auf statisch zu setzen und´s dann nochmal zu versuchen...
Im Anhang ist die Syslog (hier), vlt. findet ihr ja etwas. Danke schonmal
Moin,
ich würde mal darauf schätzen das du dich selbst geblockt hast - deine ganzen Proxmox usw. gehen ja auch auf iptables. Rein persönlich würde ich jetzt mal gucken ob es iptables sein kann indem ich den Befehl kurz umbenenne. Nicht die elegante Version aber ggf. hilfreich. Ebenfalls würde ich den ganzen Proxmox, ip2ban usw. einfach rauswerfen aus /etc/init.d (wenns noch nen initd is) und dann stück für stück hochfahren.
Und gleichzeitig drauf achten das MEINE ip immer in der whitelist is ...
ich würde mal darauf schätzen das du dich selbst geblockt hast - deine ganzen Proxmox usw. gehen ja auch auf iptables. Rein persönlich würde ich jetzt mal gucken ob es iptables sein kann indem ich den Befehl kurz umbenenne. Nicht die elegante Version aber ggf. hilfreich. Ebenfalls würde ich den ganzen Proxmox, ip2ban usw. einfach rauswerfen aus /etc/init.d (wenns noch nen initd is) und dann stück für stück hochfahren.
Und gleichzeitig drauf achten das MEINE ip immer in der whitelist is ...
Hallo,
Und dann kannst Du darüber arbeiten wie bei einer lokalen Anmeldung.
Hast Du auch Dein IP-Tables Script aus der /etc/network/interfaces geworfen (auskommentiert)
Wenn im Netztwerkblock was drin steht, das fehlerhaft ist, kann es sein, das dass Netzwerk NICHT geladen wird und dann sind alle draußen.
Gruß
Chonta
Linux Root Server
wenn das ein echter dedezierter Rootserver ist, sollte der auch einen KVM Zugang haben, mit dem Du Dich direkt auf den Bildschirm schalten kannst, den das gebootete System zeigt.Und dann kannst Du darüber arbeiten wie bei einer lokalen Anmeldung.
Hast Du auch Dein IP-Tables Script aus der /etc/network/interfaces geworfen (auskommentiert)
Wenn im Netztwerkblock was drin steht, das fehlerhaft ist, kann es sein, das dass Netzwerk NICHT geladen wird und dann sind alle draußen.
Gruß
Chonta
Hallo und danke schonmal für die Vorschläge
Was vlt. noch wichtig zu wissen ist: Der erste Fehler (sorry fällt mir auch grade erst auf), geschah ohne (wissentlichen) Neustart. D.h. ich habe das System noch nutzen können, selbst aber keinen Neustart ausgeführt, und einige Tage später hatte ich eben nurnoch Zugriff auf den vServer. DANN nach einem Neustart auf diesen logischerweise auch nicht mehr da ich diesen ja wg. fehlendem Zugriff auf Proxmox nicht mehr starten kann.
Dankeschön schonmal
Christian
Zitat von @Chonta:
wenn das ein echter dedezierter Rootserver ist, sollte der auch einen KVM Zugang haben,
Das ist in der Tat ein echter dedezierter Rootserver, mit dem kleinen Manko dass das RZ eine Gebühr für die Buchung von KVM-Zeit erhebt, die ich gerne vermeiden möchte :/wenn das ein echter dedezierter Rootserver ist, sollte der auch einen KVM Zugang haben,
Zitat von @Chonta:
Hast Du auch Dein IP-Tables Script aus der /etc/network/interfaces geworfen (auskommentiert)
In der Interfacesdatei war von Anfang an kein Verweis auf iptables, diese wurden durch ein Startupskript von mir definiert, und dieses habe ich bereits gelöscht.Hast Du auch Dein IP-Tables Script aus der /etc/network/interfaces geworfen (auskommentiert)
Zitat von maretz:
deine ganzen Proxmox usw. gehen ja auch auf iptables.
Ja, aber dort habe ich nichts verändert, und Proxmox sperrt doch auch nicht den Port auf sein eigenes Interface.deine ganzen Proxmox usw. gehen ja auch auf iptables.
Zitat von maretz:
Rein persönlich würde ich jetzt mal gucken ob es iptables sein kann indem ich den Befehl kurz umbenenne.
Und über einen klitzekleinen Tipp wie ich das über ein Rettungssystem bewerkstellige wäre ich dir überaus dankbar ;) (chroot?! - wie?)Rein persönlich würde ich jetzt mal gucken ob es iptables sein kann indem ich den Befehl kurz umbenenne.
Was vlt. noch wichtig zu wissen ist: Der erste Fehler (sorry fällt mir auch grade erst auf), geschah ohne (wissentlichen) Neustart. D.h. ich habe das System noch nutzen können, selbst aber keinen Neustart ausgeführt, und einige Tage später hatte ich eben nurnoch Zugriff auf den vServer. DANN nach einem Neustart auf diesen logischerweise auch nicht mehr da ich diesen ja wg. fehlendem Zugriff auf Proxmox nicht mehr starten kann.
Dankeschön schonmal
Christian
Zitat von @bmitsol:
Hallo und danke schonmal für die Vorschläge
Hallo und danke schonmal für die Vorschläge
Zitat von @Chonta:
wenn das ein echter dedezierter Rootserver ist, sollte der auch einen KVM Zugang haben,
Das ist in der Tat ein echter dedezierter Rootserver, mit dem kleinen Manko dass das RZ eine Gebühr für die Buchung von KVM-Zeit erhebt, die ich gerne vermeiden möchte :/wenn das ein echter dedezierter Rootserver ist, sollte der auch einen KVM Zugang haben,
Ist das wieer so ein Sparhoster, der um billig zu sein alle Extras auslagert? Dann soltlest Du dich nach einem Hoster umschauen, bei dem das inklusive ist.
Zitat von maretz:
Rein persönlich würde ich jetzt mal gucken ob es iptables sein kann indem ich den Befehl kurz umbenenne.
Und über einen klitzekleinen Tipp wie ich das über ein Rettungssystem bewerkstellige wäre ich dir überaus dankbar ;) (chroot?! - wie?)Rein persönlich würde ich jetzt mal gucken ob es iptables sein kann indem ich den Befehl kurz umbenenne.
Einfach das Roo-Dateisystem mounten und dann mit mv -iv /mount-pfad/sbin/iptables /mount-pfad/sbin/iptables.save umbennen.
lks
PS: Du solltest Dir mal Linux-Grundlagen reinziehen, wenn Du an sowas grundlegendem wie eine Datei auf einem nicht gemoumteten Datenträger umbenenen scheiterst.
Hallo,
wie ist es denn dazu gekommen das der Zugriff weg war?
Wenn kein Script IPTABLES Reglen setzt, dann sind auch keine geladen und ohne Regeln die vergegeben werden macht IPTABLES nix.
Fail2ban kann man auch mal eben abstellen und dann den Server neu booten.
Lief das ganze schonmal mit proxmox auf dem Server?
Kann ich verstehen, aber durch ein iptables -nL und ein ifconfig im laufendesn System bekommst Du schneller infos darüber was falsch ist.
Wie schaut deine /etc/network/interfaces vom proxmox aus?
Gruß
Chonta
wie ist es denn dazu gekommen das der Zugriff weg war?
Wenn kein Script IPTABLES Reglen setzt, dann sind auch keine geladen und ohne Regeln die vergegeben werden macht IPTABLES nix.
Fail2ban kann man auch mal eben abstellen und dann den Server neu booten.
Lief das ganze schonmal mit proxmox auf dem Server?
Das ist in der Tat ein echter dedezierter Rootserver, mit dem kleinen Manko dass das RZ eine Gebühr für die Buchung von KVM-Zeit erhebt, die ich gerne vermeiden möchte :/
Kann ich verstehen, aber durch ein iptables -nL und ein ifconfig im laufendesn System bekommst Du schneller infos darüber was falsch ist.
Wie schaut deine /etc/network/interfaces vom proxmox aus?
Gruß
Chonta
Zitat von @Chonta:
Wenn kein Script IPTABLES Reglen setzt, dann sind auch keine geladen und ohne Regeln die vergegeben werden macht IPTABLES nix.
Wenn kein Script IPTABLES Reglen setzt, dann sind auch keine geladen und ohne Regeln die vergegeben werden macht IPTABLES nix.
wenn iptables-persistent installiert ist sind da skripte dabei, die automatisch die existierenden Regeln abspeichern udn wiederherstellen. Wenn man da im laufenden Betrieb mal eine falsche regeln eingefügt hat, wird die persistent, sofern man sie ncht manuell löscht.
Ich würde einfach im Rettungsystem das Filesystem des Servers mounten und in fail2ban und iptables(-persistent) deaktiveren.
lks
Nun wenn ich mal so die syslog überfliege wo du Zahlen mit * versehen hast aber anderes nicht nicht geändert hast..
Hast du entweder dein Netzwerkkonfig verstellt oder per iptables den Zugriff versperrt.
Über Rescue kannst du ja mal den Dienst iptables Deaktiveren und normal Starten ob dieser dann vorhanden ist.
Sowie vorher den Netzwerkkonfig mal Prüfen ob diese IO ist.
Da du 4 Netwerkdevice angibts aber eth1-eth3 nicht gefunden werden können laut Log....
Hast du entweder dein Netzwerkkonfig verstellt oder per iptables den Zugriff versperrt.
Über Rescue kannst du ja mal den Dienst iptables Deaktiveren und normal Starten ob dieser dann vorhanden ist.
Sowie vorher den Netzwerkkonfig mal Prüfen ob diese IO ist.
Da du 4 Netwerkdevice angibts aber eth1-eth3 nicht gefunden werden können laut Log....
Hi,
Das ist mir eben auch grade ein Rätsel. Beim Zeitpunkt des letzten Kontaktes vor drei Tagen lief alles super und nun ist alles gefiltert. Ich habe nichts gemacht. Cron hat da auch nix gemacht, hab ich schon geprüft... Fällt also der Verdacht doch auf Proxmox...
Bringt nix. Schon versucht. Auch von ner anderen IP aus...
Jap. Der vServer läufft (oder besser lief) ja auf der Virtualisierungsplattform Proxmox.
Mir ist gerade etwas schleierhaft was du mit "vom proxmox" meinst... Aber die /etc/network/interfaces ist ganz normal (ich habs vorsichtshalber mal angehängt) und wird bei einer Veränderung von proxmox editiert.
Danke
Christian
Hier die Netzwerkconfig:
Das ist mir eben auch grade ein Rätsel. Beim Zeitpunkt des letzten Kontaktes vor drei Tagen lief alles super und nun ist alles gefiltert. Ich habe nichts gemacht. Cron hat da auch nix gemacht, hab ich schon geprüft... Fällt also der Verdacht doch auf Proxmox...
Zitat von @Chonta:
Wenn kein Script IPTABLES Reglen setzt, dann sind auch keine geladen und ohne Regeln die vergegeben werden macht IPTABLES nix.
Da hast du allerdings wahr... Ausser Proxmox (oder fail2ban) führt diese Befehle aus...Wenn kein Script IPTABLES Reglen setzt, dann sind auch keine geladen und ohne Regeln die vergegeben werden macht IPTABLES nix.
Bringt nix. Schon versucht. Auch von ner anderen IP aus...
Jap. Der vServer läufft (oder besser lief) ja auf der Virtualisierungsplattform Proxmox.
Zitat von @Chonta:
Kann ich verstehen, aber durch ein iptables -nL und ein ifconfig im laufendesn System bekommst Du schneller infos darüber was falsch ist.
Da hast du Recht. Und wenn es nix hilft hilft´s nix. Aber ich will noch nicht aufgeben vor allem wenn ich so toll Hilfe bekomme Kann ich verstehen, aber durch ein iptables -nL und ein ifconfig im laufendesn System bekommst Du schneller infos darüber was falsch ist.
Mir ist gerade etwas schleierhaft was du mit "vom proxmox" meinst... Aber die /etc/network/interfaces ist ganz normal (ich habs vorsichtshalber mal angehängt) und wird bei einer Veränderung von proxmox editiert.
Danke
Christian
Hier die Netzwerkconfig:
# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage part of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!
auto lo
iface lo inet loopback
source-directory /etc/network/interfaces.d
auto eth0
iface eth0 inet dhcp
auto eth1
iface eth1 inet dhcp
auto eth2
iface eth2 inet dhcp
auto eth3
iface eth3 inet dhcp
auto vmbr0
iface vmbr0 inet manual
bridge_ports eth0
bridge_stp off
bridge_fd 0
Hi,
Danke
Christian
Zitat von @kaiand1:
Über Rescue kannst du ja mal den Dienst iptables Deaktiveren und normal Starten ob dieser dann vorhanden ist.
Wenn du mir jetzt noch sagst wie... IPtables ist doch im Kernel verankert, oder? Dementsprechend kann ich dieses nicht deaktivieren, sonder nur nicht spezifizieren, also keine Blockregeln festlegen. Oder ist das falsch?Über Rescue kannst du ja mal den Dienst iptables Deaktiveren und normal Starten ob dieser dann vorhanden ist.
Zitat von @kaiand1:
Sowie vorher den Netzwerkkonfig mal Prüfen ob diese IO ist.
Da du 4 Netwerkdevice angibts aber eth1-eth3 nicht gefunden werden können laut Log....
Die anderen generiert Proxmox automatisch. Die Config ist aber iO. siehe anderer Post.Sowie vorher den Netzwerkkonfig mal Prüfen ob diese IO ist.
Da du 4 Netwerkdevice angibts aber eth1-eth3 nicht gefunden werden können laut Log....
Danke
Christian
IPTables-Export
$ sudo iptables-save > /root/firewall.rules
IPTables "abstellen"
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
IPTables Restore
$ sudo iptables-save > /root/firewall.rules
IPTables "abstellen"
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
IPTables Restore
- iptables-restore < /root/firewall.rules
Hallo,
Warum ist in der Datei alles auf DHCP?
Die IP vom Server selber sollte eigentlich statisch sein.
Wenn fail2ban nicht gestartet ist hat fail2ban auch nichts im cache.
Was die festen Regeln betrifft hat cuilster was geschrieben.
Wenn alles lief, und jetzt nicht mehr ist meistens ein Update schuld.
Gruß
Chonta
Mir ist gerade etwas schleierhaft was du mit "vom proxmox" meinst
damit meine ich die Datei vom live System das im Moment nicht mehr geht.Warum ist in der Datei alles auf DHCP?
Die IP vom Server selber sollte eigentlich statisch sein.
Wenn fail2ban nicht gestartet ist hat fail2ban auch nichts im cache.
Was die festen Regeln betrifft hat cuilster was geschrieben.
Wenn alles lief, und jetzt nicht mehr ist meistens ein Update schuld.
Gruß
Chonta
Hallo zusamme ,
Ende der Geschichte: Ich habe iptables in iptables.save umbenannt, leider ist immernoch kein Zugriff auf das System möglich :/
Offen für weitere Vorschläge
LG Christian
,PS: Du solltest Dir mal Linux-Grundlagen reinziehen, wenn Du an sowas grundlegendem wie eine Datei auf einem nicht gemoumteten Datenträger > > umbenenen scheiterst.
Da hast du nicht ganz unrecht ;) , ABER das Problem lag nicht am mounten oder umbenennen (das könnte man ja wenns wäre auch noch googeln) sondern eher der Pfad (den ich nicht ergoogeln konnte, warum auch immer).Ende der Geschichte: Ich habe iptables in iptables.save umbenannt, leider ist immernoch kein Zugriff auf das System möglich :/
Ich würde einfach im Rettungsystem das Filesystem des Servers mounten und in fail2ban und iptables(-persistent) deaktiveren.
Eigentlich müsste das doch mit dem umbenennen von iptables schon übergangen worden sein. Ich probiers trozdem mal schnell... Passiert nichts anders.Warum ist in der Datei alles auf DHCP?
Weil sich der Server seine IP via DHCP holt. Das funktioniert laut Syslog ja auch...Wenn alles lief, und jetzt nicht mehr ist meistens ein Update schuld.
Daran hatte ich auch schon gedacht, aber wie gesagt, in der Zeit von "es geht" zu "es geht nicht mehr" habe ich keine Updates angestoßen und ein Cronjob ist nicht aktiv (siehe Syslog).IPTables-Export
$ sudo iptables-save > /root/firewall.rules
IPTables "abstellen"
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
IPTables Restore
iptables-restore < /root/firewall.rules
Übers Rettungssystem? Das würde doch dann nichts am Grundsystem ändern, oder?$ sudo iptables-save > /root/firewall.rules
IPTables "abstellen"
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
IPTables Restore
iptables-restore < /root/firewall.rules
Offen für weitere Vorschläge
LG Christian
EDIT:
Das könnte noch Interessant sein (hab ich grade festgestellt):
Wenn ich aus dem Rescuesystem einen reboot mache, und dabei bei mir auf dem Rechner den Rootie anpingen lasse (-t), dann bekomme ich relativ schnell "Zeitüberschreitung der Anforderung". Dann, nach ner kurzen Zeit kommt einmal kurz ein Ping zurück ("Antwort von..."), und dann wieder Zeitüberschreitung der Anforderung...
Das könnte noch Interessant sein (hab ich grade festgestellt):
Wenn ich aus dem Rescuesystem einen reboot mache, und dabei bei mir auf dem Rechner den Rootie anpingen lasse (-t), dann bekomme ich relativ schnell "Zeitüberschreitung der Anforderung". Dann, nach ner kurzen Zeit kommt einmal kurz ein Ping zurück ("Antwort von..."), und dann wieder Zeitüberschreitung der Anforderung...
Übers Rettungssystem? Das würde doch dann nichts am Grundsystem ändern, oder?
Über KVM im laufenden livesystem, sonst kannst Du iptables nicht zurücksetzen.
Die Befehle sichern alle aktuellen Regeln in eine Datei und danach werden alle Regeln entfernt und danach IPTABLES auf Empfang gestellt ohne blockmich.
Wenn Du das binary von iptables umbenannt hast musst du das aber wieder zurück ändern.
Ob die Regeln wirksam sind wenn das Binary nicht gefunden wird, kann ich nicht sagen.
Ende der Diskusion ohne KVM kommst Du nicht rum auser du findest irgendwann in irgeneinem der 10000 Logs über das Rettungssystem was.
Gruß
Chonta
Also wenn euch schon die Vorschläge ausgehen hilfts wohl nichts ;)
Ich werd dann man für heute Nachmittag eine KVM ordern und Bescheid geben wenn alles geklappt hat.
VIELEN DANK FÜR DIE VIELEN VORSCHLÄGE UND LÖSUNGSVERSUCHE
Ich werd dann man für heute Nachmittag eine KVM ordern und Bescheid geben wenn alles geklappt hat.
VIELEN DANK FÜR DIE VIELEN VORSCHLÄGE UND LÖSUNGSVERSUCHE
Wenn Du mit KVM drauf mist,
http://netz10.de/2010/03/18/ip_per_shellscript/
prüfe mal ob du nach draußen kommst und was deine IP ist, mit der Du ins internet gehst.
Wenn das aufeinmal eine andere als sonst ist, versuch Dich mal mit der zu verbinden.
Es kann auch sein, das die Ruten vom livesystem falsch sind und der eine statische Routingtabelle hat die ein falsches Defaultgateway vorgeben und der Server garnicht ins Internet kommt, weil sein Gateway nicht da ist.
Gruß
Chonta
http://netz10.de/2010/03/18/ip_per_shellscript/
prüfe mal ob du nach draußen kommst und was deine IP ist, mit der Du ins internet gehst.
Wenn das aufeinmal eine andere als sonst ist, versuch Dich mal mit der zu verbinden.
Es kann auch sein, das die Ruten vom livesystem falsch sind und der eine statische Routingtabelle hat die ein falsches Defaultgateway vorgeben und der Server garnicht ins Internet kommt, weil sein Gateway nicht da ist.
Gruß
Chonta
Hallo zusammen,
zugegebener Maßen... es ist mir mehr als peinlich das jetzt zu schreiben :P
Nachdem das mit der KVM vom RZ verbockt wurde (oder so), habe ich nochmal alles durchprobiert. Und da die Logs ständig wüste DHCP-Anfragen verschickt haben, hatte ich den Gedanken dass es vielleicht doch an der DHCP-Einstellung liegt.
Also IP auf statisch gesetzt und versucht. Nichts. Mir ist allerdings aufgefallen dass die Einstellung beim nächsten booten ins Rescuesystem wieder auf DHCP standen.
Also mal gegooglet und herrausgefunden, dass man Änderungen garnicht, wie in der /etc/network/interfaces als Kommentar beschrieben, im Ordner interfaces.d hinterlegt, sondern in eine neue datei interfaces.new schreiben muss, damit diese beim Neustart übernommen werden. Also das kurzerhand getestet, und siehe da. Es funktioniert.
VIELEN VIELEN DANK AN ALLE DIE MIR BEI DIESEM PROBLEM GEHOLFEN HABEN
Ganz besonders an Chonta der das Problem eigentlich schon ganz am Anfang diagnostizierte.
Nach einer Recherche wurde anscheinend von Proxmox über die Enterprise-Res. das Update selbstständig eingespielt das diese Änderungen bewirkte.
zugegebener Maßen... es ist mir mehr als peinlich das jetzt zu schreiben :P
Nachdem das mit der KVM vom RZ verbockt wurde (oder so), habe ich nochmal alles durchprobiert. Und da die Logs ständig wüste DHCP-Anfragen verschickt haben, hatte ich den Gedanken dass es vielleicht doch an der DHCP-Einstellung liegt.
Also IP auf statisch gesetzt und versucht. Nichts. Mir ist allerdings aufgefallen dass die Einstellung beim nächsten booten ins Rescuesystem wieder auf DHCP standen.
Also mal gegooglet und herrausgefunden, dass man Änderungen garnicht, wie in der /etc/network/interfaces als Kommentar beschrieben, im Ordner interfaces.d hinterlegt, sondern in eine neue datei interfaces.new schreiben muss, damit diese beim Neustart übernommen werden. Also das kurzerhand getestet, und siehe da. Es funktioniert.
VIELEN VIELEN DANK AN ALLE DIE MIR BEI DIESEM PROBLEM GEHOLFEN HABEN
Ganz besonders an Chonta der das Problem eigentlich schon ganz am Anfang diagnostizierte.
Wenn alles lief, und jetzt nicht mehr ist meistens ein Update schuld.
Nach einer Recherche wurde anscheinend von Proxmox über die Enterprise-Res. das Update selbstständig eingespielt das diese Änderungen bewirkte.
