Mein vServer ist nicht mehr erreichbar, Störung?

  • Ja, und auch die IPv6 Adresse ist nicht die Standard-Adresse.

    Natürlich ist das default daran wurde nie was geändert, ist die selbe ip die im scp steht selber gw.


    wieso bootet das rescue system dann auch nicht über netzwerk das ist ja entkoppelt von dem disk image, selbst wenn es gehackt worden wäre.

  • Natürlich ist das default daran wurde nie was geändert, ist die selbe ip die im scp steht selber gw.

    Halte ich für völlig ausgeschlossen, denn die Host-ID ist nicht identisch mit der link-lokalen Adresse, sondern endet mit :1. Das ist praktisch ausgeschlossen bei einer EUI-64 Adresse.


    Was sagt denn tcpdump?

  • frank_m Ich habe niemals etwas an der ipv6 geändert. das stand da schon immer so drinn seitdem der server läuft und installiert wurde von netcup. und es ging auch alles bis vor ein paar tagen noch sowohl ipv4 als auch ipv6.


    ich kenn mich mit tcpdump und generell netzwerken nicht sonderlich gut aus, wenn ich etwas machen kann was helfen könnte wäre ich dankbar. kann ich irgendwas machen über die scp screen schnittstelle um informationen zu geben hier im forum was weiterhelfen kann, wenn ja, was soll ich tun und zurück melden? soll ich etwas an der interfaces config mal ändern? wieso wird denn dhcp zb nicht gezogen? ich hab wireguard mal entfernt das war aber eh niemals in betrieb, es war auch nie ein wg port geöffnet nach außen.

  • Halte ich für völlig ausgeschlossen, denn die Host-ID ist nicht identisch mit der link-lokalen Adresse, sondern endet mit :1. Das ist praktisch ausgeschlossen bei einer EUI-64 Adresse.


    Was sagt denn tcpdump?


    Letztlich ist das doch vollkommen irrelevant, ob die Host-ID nun in der globalen IPv6 ist oder die ::1 - sofern es im selben /64 ist, sollte es gehen. Kann @mkdr denn fe80::1 pingen?

  • Ich habe niemals etwas an der ipv6 geändert. das stand da schon immer so drinn seitdem der server läuft und installiert wurde von netcup.

    Das kann ich kaum glauben. Netcup nutzt als Default IP immer das zugewiesene Prefix mit der EUI-64 Host-ID des Netzwerk-Interfaces. Im SCP steht ja auch nicht - wie du oben schreibst - die Adresse, sondern nur das Prefix. Die Adressen, die dort auftauchen, hast du selber mal für RDNS eingetragen, damit hat netcup nichts zu tun.


    Letztlich ist das doch vollkommen irrelevant, ob die Host-ID nun in der globalen IPv6 ist oder die ::1 - sofern es im selben /64 ist, sollte es gehen.

    Ja, sollte, wenn alles richtig läuft. Im Moment sind wir ja noch dabei, einzugrenzen, was eigentlich schiefgeht. Und netcup nutzt die ursprüngliche Server-Adresse mit EUI-64 Host-ID ja für einige Dienste, z.B. als Routing-Ziel für zusätzliche Subnetze. Vielleicht geht was im NDP schief oder so, wer weiß?


    Was noch auffällt: In den Screenshots kann man sehen, dass durchaus Daten auf dem Interface empfangen werden, aber nur extrem wenig gesendet wird.


    tcpdump zeigt halt an, was auf dem Interface los ist. Da könnte man z.B. sehen, ob Broadcasts ankommen und welche, ob DHCP Datenverkehr im Netz usw. Ich weiß noch nicht, wonach man suchen soll, es geht erst mal darum, zu sehen, was überhaupt da ist. Es heißt hier ja immer, das Interface sei tot, aber danach sieht es ja nicht aus, da ja Daten empfangen werden, wie man auf den Screenshots sieht.

  • Das kann ich kaum glauben. hast du selber mal für RDNS eingetragen

    Schön, ist aber so. Nein hab ich nicht. an der ipv6 hab ich niemals was geändert.


    Server läuft wieder, sowohl ipv4 als auch ipv6, nachdem Netcup das Problem von "magischer Hand" gelöst hat heute. An meinem Server lag es nicht, es war irgend ein Problem bei Netcup selber. War ja auch nicht anders zu erwarten. Komisch, dass ich als einziger davon betroffen war und es sonst niemand aufgefallen war.

  • Das kann ich kaum glauben. Netcup nutzt als Default IP immer das zugewiesene Prefix mit der EUI-64 Host-ID des Netzwerk-Interfaces. Im SCP steht ja auch nicht - wie du oben schreibst - die Adresse, sondern nur das Prefix. Die Adressen, die dort auftauchen, hast du selber mal für RDNS eingetragen, damit hat netcup nichts zu tun.


    Ja, sollte, wenn alles richtig läuft. Im Moment sind wir ja noch dabei, einzugrenzen, was eigentlich schiefgeht. Und netcup nutzt die ursprüngliche Server-Adresse mit EUI-64 Host-ID ja für einige Dienste, z.B. als Routing-Ziel für zusätzliche Subnetze. Vielleicht geht was im NDP schief oder so, wer weiß?


    Der Gateway fe80::1 hat aber ja nix mit den gerouteten Netzen zu tun und würde von der LinkLocal aus gepingt. Und wie sich nun gezeigt hat, hatte es nichts mit seiner Config zu tun.

  • Wenn eh Probleme existieren, der Server wie hier schon mehrere Monate ungepatcht im Internet steht und die Sicherung der Daten machbar ist, könnte im vorliegenden Fall eine Neuinstallation nicht schaden.


    Dist Upgrades "können" funktionieren - oder unvorhergesehene Schwierigkeiten verursachen. Beides schon erlebt.

    RS Ostern L OST22 (~RS "3000" G9.5) (8C,24GB,960GB) | RS Cyber Quack (1C,2GB,40GB)

    Einmal editiert, zuletzt von TBT ()

  • Das beschreiben sie ja immer kurz in der Mail.

    Du scheinst gern eigene Erfahrungen auf alle zu übertragen kann das sein. Bei mir wurde nichts in der email gesagt woran es lag nur dass sie das Problem bei sich reproduzieren konnten und gelöst haben, das wars.


    Es existiert "do-release-upgrade".

    Ist keine Option hier, weil nur 1GB freier HDD Platz frei ist, das ist noch ein alter VServer wo ich nur 20GB Platz habe und auch nur 1 VCore. Daher werde ich das Paket auch auslaufen lassen / kündigen und ein neuen bestellen wo ich dann 40GB und 2 VCore habe. Leider gibt es bei Netcup ja keine Möglichkeit zu wechseln.