netcup Summer Splash! Aktionstag am 27.06.2023

Zitat von Paul

Das war einmal ganz kurz (Black Friday). Müsste ungefähr die Zeit gewesen sein als hier in DE die Energiepreise so explodiert sind. Das hat sich aber dann doch wieder etwas beruhigt. Seit dem waren alle (mir bekannten) Angebotsserver eigentlich wieder in DE. Vielleicht hat man da einfach mal kurz das AT RZ ein wenig befüllen müssen.

Eigentlich unverständlich, dass ein Unternehmen, das seit Jahren laut eigenem Webauftritt ausschließlich Ökostrom bezieht, von Preisschwankungen bei anderen Energieträgern betroffen hätte sein sollen. Solche Verträge werden sicherlich auch auf Jahre im Voraus zum Fixpreis abgeschlossen und nicht als Floater. Oder?

Zitat von eripek

Solche Verträge werden sicherlich auch auf Jahre im Voraus zum Fixpreis abgeschlossen

Das ist nicht der Fall. Mittelfristig durchaus. Aber nicht auf viele Jahre im Voraus.

Aber natürlich enthalten Energieverträge von größeren Energieversorgern mit größeren Unternehmen immer entsprechende absicherende Klauseln. (Beiderseitg)

Zitat von friend_of_root

Ich kenne das Produkt, aber finde ich irgendwie nicht so attraktiv.
Viel, viel besser wäre, wenn man eine bestehende Server IP mit Aufzahlung zur Failover-IP machen könnte!
Oder mit zB 30 Euro Einmalgebühr 1xmal umsiedeln.

Gibt's überhaupt einen Anbieter wo das in diese Richtung geht?

Bei dem Fluss mit A schimpft sich das ElasticIP, Hätzner musst ebenfalls vorher erstellen....

Ansonsten kannst du dir doch auch https://www.netcup.de/bestellen/produkt.php?produkt=1072 einmalig buchen, da hast du doch defacto was du haben willst.

Zitat von friend_of_root

Viel, viel besser wäre, wenn man eine bestehende Server IP mit Aufzahlung zur Failover-IP machen könnte!
Oder mit zB 30 Euro Einmalgebühr 1xmal umsiedeln.

Wenn es darum geht, eine IP-Adresse langfristig beizubehalten – warum dann nicht zwei kleine VPS-KVM-Instanzen (Redundanz!) als Gateways davorhängen? Solange das Transfervolumen überschaubar ist, hat man hiermit eine relativ günstige, flexible Alternative (die hinreichend ausfallsicher sein sollte – ggf. rechnen sich hier auch kleine RS, welche von dem zubuchbaren "Root-Server Service Level A+" abgedeckt wären). Als Seiteneffekt hätte man damit auch die Möglichkeit, (später) ein transparentes Load-Balancing einzuführen.

Zitat von m_ueberall

Wenn es darum geht, eine IP-Adresse langfristig beizubehalten – warum dann nicht zwei kleine VPS-KVM-Instanzen (Redundanz!) als Gateways davorhängen? Solange das Transfervolumen überschaubar ist, hat man hiermit eine relativ günstige, flexible Alternative (die hinreichend ausfallsicher sein sollte – ggf. rechnen sich hier auch kleine RS, welche von dem zubuchbaren "Root-Server Service Level A+" abgedeckt wären). Als Seiteneffekt hätte man damit auch die Möglichkeit, (später) ein transparentes Load-Balancing einzuführen.

Das finde ich spitze.. aber was genau meinst du.. wie kann das mit 2 redundanten VPS-KVM-Instanzen klappen?

Ich hatte schon so ein Setup bei dem der 1. RS die IP für das A Record der verweisenden Domains stellte, sowie die Let's Encrypt SSL Zertifikate ermöglichte. Darauf lief ein Nginx als Reverse Proxy, der alle Anfragen auf einen 2. RS dahinter weiterleitet... umgesetzt war das mit Nginx Proxy Manager.
Das hat mir sehr gut gefallen, allerdings dachte ich dann, dass man mit der Abhängigkeit von noch einem Server weit mehr als die doppelte Ausfallwahrscheinlichkeit hat.

Zitat von michaeleifel

Gibt's überhaupt einen Anbieter wo das in diese Richtung geht?

Bei dem Fluss mit A schimpft sich das ElasticIP, Hätzner musst ebenfalls vorher erstellen....

Ansonsten kannst du dir doch auch https://www.netcup.de/bestellen/produkt.php?produkt=1072 einmalig buchen, da hast du doch defacto was du haben willst.

"Zusaetzliche IPv4" ist auch eine sehr gute Lösung, die Umstellung muss beauftragt werden und wird nicht sofort umgesetzt. Aber dies ist absolut ok, denn die Failover IP ist im Vergleich auch nicht schnell (z.B. innerhalb von 1-2 Minuten).

Das einzige 'Problem' ist, dass man dies gleich von Anfang an so planen muss und dann nur diese zusätzlichen IP verwendet.
Bei meinem Vorschlag würde man die IP mitnehmen können und dies wäre dann für alle Server anwendbar die es schon gibt. Natürlich kann nc dies dann auch kompensiert werden durch einmalige Wechselgebühr, oder eine Auspreisung als "Zusaetzliche IPv4". Wodurch ich glaube, dass es mehr Umsatz macht.

Zitat von friend_of_root

Das finde ich spitze.. aber was genau meinst du.. wie kann das mit 2 redundanten VPS-KVM-Instanzen klappen?

Ich hatte schon so ein Setup bei dem der 1. RS die IP für das A Record der verweisenden Domains stellte, sowie die Let's Encrypt SSL Zertifikate ermöglichte. Darauf lief ein Nginx als Reverse Proxy, der alle Anfragen auf einen 2. RS dahinter weiterleitet... umgesetzt war das mit Nginx Proxy Manager.
Das hat mir sehr gut gefallen, allerdings dachte ich dann, dass man mit der Abhängigkeit von noch einem Server weit mehr als die doppelte Ausfallwahrscheinlichkeit hat.

Und diesem vorgenannten "1. RS" kann man einfach einen Zwilling an die Seite stellen, wobei alle Domänen im einfachsten Fall eben zwei öffentliche IP-Adressen erhalten (genau die der Gateways). Fällt einer aus, werden Clients heutzutage in der Regel einfach die andere IP-Adresse probieren (gerade beim https-Protokoll). Eine Sitzungsverwaltung sollte sicherstellen, dass einmal aufgebaute Sessions bei einem Gateway bleiben ("sticky sessions"), alternativ können sich diese auch gegenseitig über die gültigen Sitzungen austauschen. "Round Robin DNS" sorgt hier schon einmal für eine initiale Lastverteilung zwischen den Gateways. Einschlägige mächtigere/komplexere Softwarelösungen wie HAProxy sind eigentlich auch gut dokumentiert.

Sofern man Dienste im "Multi-Master-Betrieb" in einem Cluster installiert, kann man auf zusätzliche Gateways mbMn ggf. aber auch einfach verzichten – denn wenn die Clients immer mehrere IP-Adressen zur Auswahl haben, ist es nicht sonderlich schlimm, wenn sich einmal ab und zu eine ändert.

(Der Vorteil aller vorgenannter Ansätze gegenüber Failover-IPs liegt bzgl. Dienstleister-Unabhängigkeit auf der Hand.)

Zitat von m_ueberall

Und diesem vorgenannten "1. RS" kann man einfach einen Zwilling an die Seite stellen, wobei alle Domänen im einfachsten Fall eben zwei öffentliche IP-Adressen erhalten (genau die der Gateways). Fällt einer aus, werden Clients heutzutage in der Regel einfach die andere IP-Adresse probieren (gerade beim https-Protokoll).

Das ist eine tolle Antwort, die mich noch eine Weile beschäftigen wird

Lets encrypt SSL Challenge würde mit 2 A Records funktionieren?

Zitat von friend_of_root

Das ist eine tolle Antwort, die mich noch eine Weile beschäftigen wird

Lets encrypt SSL Challenge würde mit 2 A Records funktionieren?

Natürlich, wenn die Antwort stimmt. Vgl. etwa Will Let’s Encrypt work for me? (Multiple servers serving one domain). Alternativ kann man auch entsprechende Schlüssel für die DNS-Challenge hinterlegen, wie es für Wildcard-Zertifikate sowieso unabdingbar ist, die ich beispielsweise im Intranet einsetze (funktioniert einwandfrei bei deSEC).

Zitat von friend_of_root

"Zusaetzliche IPv4" ist auch eine sehr gute Lösung, die Umstellung muss beauftragt werden und wird nicht sofort umgesetzt. Aber dies ist absolut ok, denn die Failover IP ist im Vergleich auch nicht schnell (z.B. innerhalb von 1-2 Minuten).

Bei mir sind es ~20 Sekunden, falls mal was passiert

Zitat von friend_of_root

Das einzige 'Problem' ist, dass man dies gleich von Anfang an so planen muss und dann nur diese zusätzlichen IP verwendet.
Bei meinem Vorschlag würde man die IP mitnehmen können und dies wäre dann für alle Server anwendbar die es schon gibt. Natürlich kann nc dies dann auch kompensiert werden durch einmalige Wechselgebühr, oder eine Auspreisung als "Zusaetzliche IPv4". Wodurch ich glaube, dass es mehr Umsatz macht.

Ich sehe da zu viel Verwaltungsufwand, damit sich das rechnet. Mit der Zusätzlichen IP gibts den Auftrag: "Wechsel die IP X von Server A -> B" fertig.

In deinem Fall wäre es vermutlich so:

- Was passiert mit dem Server, an dem aktuell diese IP hängt? Kündigen?

- Aktuell haben alle Netcup Server "mindestens" eine öffentliche IPv4. Falls du den Server behältst, muss dir eine neue IP zugewiesen werden als "Stamm IP"

- Wann soll die Umstellung erfolgen? Hat der Kunde Einstellungen auf dem Server, die nach der Umstellung dafür sorgen, dass dieser nicht mehr erreichbar ist ( IP statisch konfiguriert ) => Supportaufwand

Und das alles "nur", weil du nicht ordentlich geplant hast? <- ( Übertrieben formuliert ) Glaub genau aus dem Grund ist die zusätzliche IP entstanden, damit Leute bei Mailservern etc. diese mitnehmen können.

Beim Amazonas Cloud Anbieter ersetzt übrigens die Elastic IP die vorherige IP der Maschine, die ist dann auf der alten nicht mehr erreichbar. Muss man bspw berücksichtigen, wenn man die mit Terraform erstellt und basierend auf der Ausgabe direkt DNS Records erstellt.

Zitat von m_ueberall

Natürlich, wenn die Antwort stimmt. Vgl. etwa Will Let’s Encrypt work for me? (Multiple servers serving one domain). Alternativ kann man auch entsprechende Schlüssel für die DNS-Challenge hinterlegen, wie es für Wildcard-Zertifikate sowieso unabdingbar ist, die ich beispielsweise im Intranet einsetze (funktioniert einwandfrei bei deSEC).

Hast du deSEC auf einem eigenen Server installiert?

Zitat von friend_of_root

Hast du deSEC auf einem eigenen Server installiert?

deSEC.io ist ein (kostenloser) DNS-Betreiber, deren Server man als Nameserver für eigene Domains hinterlegen kann. Die unterstützen DNSSEC und haben eine API. Im Hintergrund steht ein gemeinnütziger Verein, der über Spenden finanziert wird.

Zitat von KB19

deSEC.io ist ein (kostenloser) DNS-Betreiber

DeSEC ist auch ein installierbarer Open-Source Software-Stack. Ist natürlich nicht nötig, das selbst zu betreiben, weil der deSEC.io Service ganz fantastisch funktioniert. Man kann die DNS-01 Challenge übrigens per CNAME an eine Domain dort delegieren.

Ich empfehle auch, Wildcard-Zertifikate ausstellen zu lassen. Das ist besonders dann sinnvoll, wenn man privat genutzte Subdomains mit Zertifikaten ausstatten möchte, ohne dass die Hosts ständig auf Sicherheitslücken abgeklopft werden. Die CA Transparenz Logs von Letsencrypt werden nämlich von unzähligen Möchtegernangreifern als Quelle von Domainnamen genutzt. Mit Wildcard-Zertifikaten schiebt man dem einen Riegel vor, weil die letztendlich genutzten Subdomains nicht im Zertifikat stehen.

Zitat von NaN

Ich empfehle auch, Wildcard-Zertifikate ausstellen zu lassen. Das ist besonders dann sinnvoll, wenn man privat genutzte Subdomains mit Zertifikaten ausstatten möchte, ohne dass die Hosts ständig auf Sicherheitslücken abgeklopft werden. Die CA Transparenz Logs von Letsencrypt werden nämlich von unzähligen Möchtegernangreifern als Quelle von Domainnamen genutzt. Mit Wildcard-Zertifikaten schiebt man dem einen Riegel vor, weil die letztendlich genutzten Subdomains nicht im Zertifikat stehen.

Security thru Obscurity is no Security.

Entweder die Hosts halten das Abklopen aus, oder man sollte keine Hosts haben.

DNS ist Public Information.

Dieser Thread wird immer besser. Ich pack es nicht.

Zitat von michaeleifel

Bei mir sind es ~20 Sekunden, falls mal was passiert

Ich sehe da zu viel Verwaltungsufwand, damit sich das rechnet. Mit der Zusätzlichen IP gibts den Auftrag: "Wechsel die IP X von Server A -> B" fertig.

In deinem Fall wäre es vermutlich so:

- Was passiert mit dem Server, an dem aktuell diese IP hängt? Kündigen?

- Aktuell haben alle Netcup Server "mindestens" eine öffentliche IPv4. Falls du den Server behältst, muss dir eine neue IP zugewiesen werden als "Stamm IP"

- Wann soll die Umstellung erfolgen? Hat der Kunde Einstellungen auf dem Server, die nach der Umstellung dafür sorgen, dass dieser nicht mehr erreichbar ist ( IP statisch konfiguriert ) => Supportaufwand

Und das alles "nur", weil du nicht ordentlich geplant hast? <- ( Übertrieben formuliert ) Glaub genau aus dem Grund ist die zusätzliche IP entstanden, damit Leute bei Mailservern etc. diese mitnehmen können.

Beim Amazonas Cloud Anbieter ersetzt übrigens die Elastic IP die vorherige IP der Maschine, die ist dann auf der alten nicht mehr erreichbar. Muss man bspw berücksichtigen, wenn man die mit Terraform erstellt und basierend auf der Ausgabe direkt DNS Records erstellt.

Alles anzeigen

Auch ein guter Beitrag und sicher relevant die Praxis in Frage zu stellen.

Bei der Überlegung wären 1-2 Loadbalancer Server mit einem Reverse Proxy am Start. Und diese verweisen dann weiter.
Also spart man sich bei den 20-50 Servern dahinter die Wechsel IPs, bleibt aber total flexibel und kann immer alles ändern, crossgraden und so weiter (auch Anbieter unabhängig).
Statt den 20-50 Servern könnte auch ein großer Proxmox dastehen, wenn man aber z.B. einen Dienst auf einen anderen Server auslagern muss, geht dies auf Grund der Unabhängigkeit der IP ziemlich gut.

>Hat der Kunde Einstellungen auf dem Server, die nach der Umstellung dafür sorgen, dass dieser nicht mehr erreichbar ist ( IP statisch konfiguriert ) => Supportaufwand
Auf den Servern sind so und so vielleicht Einstellungen die einen Wechsel verkomplizieren können, das ist nicht nur von der IP nach außen abhängig.

Vielleicht ist es in der Praxis zu viel Aufwand, aber es ist als Playground echt spannend dies wieder zu verfolgen.

Zitat von H6G

Security thru Obscurity is no Security.

*Gähn*. Logspam ist Logspam.