Hast du nach dem Einspielen des Images vom alten Server auf den neuen Server auch die MAC-Adresse auf dem System des neuen Servers aktualisiert? Denn das Fehlerbild deutet auf eine falsche MAC-Adresse auf dem neuen Server hin.
Nein, habe ich nicht. Aber wo sollte die MAC-Adresse denn statisch konfiguriert sein? ip link show eth0 zeigt mir die korrekte MAC-Adresse vom neuen Server an.
Meine funktionierende netplan sieht so aus (angepasst an deine ips):
Vielen Dank! Leider macht es auch hier keinen Unterschied zum aktuellen Verhalten. Ich muss auch hier wieder mehrfach curl --interface 159.195.XXX.XXX icanhazip.com ausführen, damit es funktioniert. Einziger Unterschied im Verhalten dieser Konfiguration ist, dass ausgehende Anfragen von der originalen IP gemacht werden und nicht von der Failover-IP (curl -4 icanhazip.com).
ip route sieht dann natürlich auch entsprechend anders aus:
default via 159.195.XXX.1 dev eth0 proto static
152.53.XXX.XXX via 159.195.XXX.XXX dev eth0 proto static
159.195.XXX.0/22 dev eth0 proto kernel scope link src 159.195.XXX.XXX
192.168.0.0/24 via 192.168.255.1 dev eth1 proto static
192.168.254.0/24 via 192.168.255.1 dev eth1 proto static
192.168.255.0/24 dev eth1 proto kernel scope link src 192.168.255.4 educated guess
Für die IPv4-Route fehlt das "on-link: true"
---
Sonst schau dir mal die Routen an, die das Netplan generiert.
(ip route)
Habe es mal mit on-link: true probiert. Macht leider keinen Unterschied zum aktuellen Verhalten.
ip route gibt folgendes aus:
default via 159.195.XXX.1 dev eth0 proto static src 152.53.XXX.XXX
159.195.XXX.0/22 dev eth0 proto kernel scope link src 159.195.XXX.XXX
192.168.0.0/24 via 192.168.255.1 dev eth1 proto static
192.168.254.0/24 via 192.168.255.1 dev eth1 proto static
192.168.255.0/24 dev eth1 proto kernel scope link src 192.168.255.4 Wenn ich die Failover-IP gar nicht konfiguriere, funktioniert der Traffic über die originale IP des Servers problemlos. Sobald ich aber die Failover-IP hinzufüge (auch ohne from: "152.53.XXX.XXX" bei den Routes, geht gar nichts mehr. Wie konfiguriere ich denn die Failover IP, ohne danach netplan apply ausführen zu müssen? Denn damit ist die Verbindung dann sofort wieder futsch.
Hallo zusammen,
ich komme leider nicht weiter und brauche mal euren Rat.
Vor zwei Wochen habe ich einen Ubuntu-Server migriert (RS 2000 G11 SE NUE OST25 zu RS 2000 G12 Pro NUE BW25). Die Migration habe ich über einen Snapshot-Export durchgeführt. Dank Failover-IPs (IPv4 und IPv6) dachte ich, dass die Migration problemlos über die Bühne gehen müsste. Ich habe also die IP-Adressen angepasst und das Routing umgestellt. Lieder lief dann erstmal nur IPv6. Bei IPv4 ging weder etwas rein noch raus. Auch nicht auf der originalen IP vom neuen Server.
Nachdem ich dann mehrfach curl --interface 159.195.XXX.XXX icanhazip.com (159.195.XXX.XXX ist die originale IP vom neuen Server) ausgeführt habe, lief IPv4. Sowohl die originale als auch die Failover-IP funktionierten wie erwartet.
Sobald ich den Server aber neustarte oder netplan apply ausführe, ist die Verbindung wieder weg. Mehrfaches Ausführen des o.g. curl-Befehls behebt das Problem dann wieder.
Ich habe bereits versucht die Failover-IP kurz auf einen anderen Server zu schwenken und dann wieder zurück. Hat leider nicht geholfen. Es scheint so, als sei nur diese eine Server betroffen. Bei diesem Server fehlt auch die passende Subdomain unter yourvserver.net. Mein Gefühl sagt mir, dass dieser Server nicht ganz korrekt eingerichtet wurde und deswegen das Routing der Failover-IP irgendwie hakt.
In meiner Verzweiflung habe ich die KI nach Rat gefragt. Zurück kam nur "ARP/Neighbor-Cache" und wilde netplan-Konfigurationen.
Was ist eure Einschätzung? Was kann ich noch überprüfen? Liegt der Fehler eher auf meiner Seite oder auf der von netcup?
Hier noch meine netplan-Config:
network:
version: 2
ethernets:
eth0:
addresses:
- "159.195.XXX.XXX/22" # Originale IP vom Server
- "152.53.XXX.XXX/32" # Failover-IP
- "2a0a:XXXX:XX:db81:d4f8:feff:fede:3d9d/64" # Originale IP vom Server
- "2a03:XXXX:XX:2cc::1/64" # Failover-IP
routes:
- to: "default"
from: "152.53.XXX.XXX" # Failover-IP
via: "159.195.XXX.1"
- to: "default"
from: "2a03:XXXX:XX:2cc::1" # Failover-IP
via: "fe80::1"
on-link: true
eth1:
addresses:
- "192.168.255.4/24"
routes:
- to: "192.168.254.0/24"
via: "192.168.255.1"
- to: "192.168.0.0/24"
via: "192.168.255.1"Was sagen denn die Logs unter Systemstatus > Protokolle?
Netcup setzt da leider keine Standardwerte auf Werkeinstellung zurück, was ich sehr schade finde.
Also ich rede davon, dass dig a vXXXX….quicksrv.de funktioniert, dig a vXXXX….yourvserver.net nicht. Meinst du das auch?
Ich habe einen RS 2000 G12 aus der Black Week, bei dem der Eintrag unter vXXXXX….yourvserver.net fehlt. Wird dieser Eintrag neuerdings nicht mehr gesetzt? Hat jemand einen relativ neuen Server und könnte das mal überprüfen?
Gibts eigentlich noch Relay Services, die nicht auf definierte Absenderdomains beschränkt sind?
Ich nutze das Mailkonto von meinem ISP um Mails darüber zu relayen. Abersenderdomains sind dort egal. Funktioniert wirklich zuverlässig. 500 Mails pro Stunde sind theoretisch möglich. Man kann dort ein Mailkonto auch ohne Internetvertrag bekommen. Kostet dann 1,90€ im Monat.
Bei mir sieht alles gut aus:
Tut es aber nicht, es wird alle geblockt.
So, jetzt bin ich etwas wacher als vorhin.
Ich habe das mal bei mir nachgebaut:
Bei mir verhält es sich genau so wie erwartet. Port 22 ist dicht, auf Port 8080 kann ich noch zugreifen. Auf was versuchst du denn zuzugreifen, wenn du sagst, dass alles geblockt wird?
Die AUSGEHEND-Regeln sind übrigens in deinem Fall nicht nötig.
Edit: Hab mich verlesen. Hier stand Quatsch.
FYI: Let’s Encrypt bietet seit gestern Zertifikate für IP-Adressen auf Production an.
Übrigens kann man auch einstellen, dass immer der HTML-Editor verwendet werden soll:
Einstellungen → Nachrichtenerstellung → HTML-Nachrichten verfassen → immer
Nein. Du musst im Webmail-Editor eine HTML-Mail erstellen.
Dann wird auch die Signatur mit dem Bild korrekt eingebunden.
Ich vermute auch, dass du das hier nicht machst. Wenn du eine neue E-Mail erstellst, musst du auf den HTML-Editor wechseln:
Da es sich um Ubuntu handelt, wird hier vermutlich netplan zum Einsatz kommen. Meine Datei sieht so aus:
network:
version: 2
ethernets:
eth0:
addresses:
- "100.0.0.155/22" # IP, auf die die Failover-IP geroutet wird
- "200.0.0.111/32" # Failover-IP
- "2a0a:1:1:1:44cb:71ff:feda:dd2e/64" # IP, auf die die Failover-IP geroutet wird
- "2a03:2:2:2::1/64" # Failover-IP
routes:
- to: "default"
from: "200.0.0.111" # Ausgehende Requests sollen die Failover-IP als Quelle verwenden
via: "100.0.0.1"
- to: "default"
from: "2a03:2:2:2::1" # Ausgehende Requests sollen die Failover-IP als Quelle verwenden
via: "fe80::1"
on-link: trueWir haben die Darstellung angepasst, damit es klar und deutlich hervorkommt.
Danke! So ganz stimmt es aber noch nicht:
vs.
17,35 € ≠ 17,36 €
Finde es etwas irreführend, dass in der Übersicht 16,76 € stehen und wenn man auf das Produkt klickt 17,36 €. Dann sollte in der Übersicht wenigstens "ab 16,76 €" stehen.
Hab noch einen Bug entdeckt: Wenn man eine lange Liste an Einträgen in einer Firewall Policy hat und einen Eintrag editiert, kann man anschließend nicht mehr nach unten scrollen um z.B. auf "Speichern" oder "Löschen" zu drücken.
Schritte zum Nachstellen:
Getestet mit Firefox 146.0 und Chrome 143.0.7499.110 auf Mac.
Moderatoren
Hab noch einen Bug entdeckt: Wenn man im SCP auf Optionen klickt, lautet der Titel der Webseite SCP - Kundendaten (Optionen). Klickt man anschließend auf Firewall Policys, wählt irgendeine Firewall Policy aus und klickt dann z.B. auf SSH Keys, lautet der Titel SCP - SSH Keys (undefined) Moderatoren
