Beiträge von MeisterYoda

    Zur geographischen Redundanz der Netcup DNS Server kann ich wenig sagen - die DNS API funktioniert aber soweit zuverlässig, nutze ich selbst seit Jahren für acme.sh.


    Allerdings solltest du es bei Domains, die über Netcup DNS Server ausgeliefert werden, vermeiden DNSSEC zu aktivieren. Das gab bei mir vor 2 Jahren mal ein böses Ende und die komplette Domain samt aller Subdomains war mehrmals offline und konnte nur durch Eingriff durch den Support wieder instand gesetzt werden (SERVFAIL). Keine Ahnung ob das Feature immer noch verbuggt ist, aber ich meide es seither.


    Langfristig werde ich mir aber ein paar VPS mieten und dort selbst ein PowerDNS bereitstellen, dann hat man auch die volle Kontrolle über den Dienst, inkl. der Schlüsselverwaltung bzgl. DNSSEC :)

    Wo bekommt man denn sonst noch virtuelle Systeme auf KVM-Basis mit dedizierten Cores? Wo Proxmox im Cluster funktioniert ... Ich kenne das sonst nur mit Hardware-basierten Maschinen.

    Beim Sieger (Platz 1) des diesjährigen Host Tests in der Kategorie vServer (also virtuelle Root-Server). ;)

    Ich selbst habe schon dort hin umgezogen, da neben einer garantierten Bandbreite von 1 Gbit/s (mit Spike darüber) auch nested KVM (sprich VMX/SVM) für vernünftige full Virtualization ohne Aufpreis möglich ist, und es immer wieder extrem günstige Sonderangebote gibt.

    Nachtrag: Übrigens ist es auch bei IPv4 falsch, alle ICMP zu blocken. Genau aus diesem Grund funktioniert zB. das Path MTU discovery nicht zuverlässig, weil es zu viele fehlerhaft konfigurierte Firewalls im Netz gibt....


    Hab gerade gelernt dass ipv6 ohne nd-* kram in der Firewall plötzlich kaputt ist, dinge über die man sie nie Gedanken macht solange man ipv4 only fährt..

    Ja, man muss einen großen Bereich von ICMP zulassen. Habe mir mal die Mühe gemacht die Types, die man zulassen sollte, per RFC zu erarbeiten (gleiches gilt natürlich auch für die Forwarding chain):


    Du sagtest ja was von Wohnheim und so; also ein Studentenheim; und hast Du bei IPv4 eine eigene od. bist Du da im NAT mit den anderen?

    ich bin jetzt davon ausgegangen, dass bei IPv4 jeder seine eigene IPv4 hat aber bei IPv6 teilt ihr euch einen Prefix ...

    mit 'Mist' bauen, etwas Phantasie; SPAM-Versand, Malware-Verbreitung - es muss nicht Absicht sein, kann auch unwissentlich geschehen;

    Wir haben einen recht komplexen Anschluss, also im Prinzip beides. Grundsätzlich teilen sich alle Bewohner ausgehend einen Pool aus ca. 500 public IPv4 Adressen per CG-Nat, wir haben aber auch noch ein /30ger Netz anliegen für Serverhosting, unfiltered NAT etc. Das CG-Nat fängt nach außen gehende Portscans etc. durchaus ab. Spam Versand ist auch nicht möglich, da Port 25 geblockt ist.


    Aber abgesehen davon: Der Kernaussage stimme ich halt nicht zu: Wer ein /48 Prefix blockt, kann auch ein /24ger IPv4 Prefix blocken. ;)

    klar so ist es auch sinnvoll; und damit bringst Du mich auf das nächste nicht unproblematische;

    man sperrt bei IPv6 keine einzelnen IPv6-Adressen sondern gleich ganze Prefixe;

    und wenn da einer von euch Mist baut, ist der ganze Prefix gesperrt; findest das dann auch toll?;)

    was meinst du konkret damit? Wie soll man "Mist" bauen, sodass man wo gesperrt wird? Außerdem - was ist der Unterschied zu IPv4? Da sperrst du halt nach der gleichen Logik die einzelne IP Adresse, das ist rein das gleiche.

    Zitat

    und NAT ist kein Klimmzug, sondern hat seinen Snn;

    und ehrlich würdest Du ein Unternehmen, z.B. eine Bank so konfigurieren,

    dass jeder Client direkt vom Internet aus erreichbar ist?

    NAT ist keine Firewall.


    Zitat

    doch einiges davon muss man dem Standard anlasten, IPv6 ist aus Sicht heute - dem fast zu Ende gehenden Jahr 2021 - immer noch unvollständig;

    und teilweise sogar fehlerhaft;

    IPv6 ist nicht unvollständig oder fehlerhaft - die Umsetzung durch die Provider ist unvollständig oder fehlerhaft. Fehlerhaft bei dem Serverprovider mit den zwei einsen und unvollständig hier bei Netcup (mit Blick auf den Leitsatz: der Kunde sollte sich niemals eingeschränkt fühlen und über so Krücken wie NAT nachdenken müssen). Darüber hinaus haben sämtliche DSL Provider, inklusive des großen T IPv6 fehlerhaft implementiert: so etwas wie dynamische Prefixe ist erst der Ursprung allen Übels und war nie vorgesehen.


    Wir beziehen im Wohnheim vom LRZ einen statischen /48 Prefix und können damit intern wunderbar und unbegrenzt arbeiten - so wie es sein sollte. Damit entfällt dann auch Murks wie NAT reflection etc.

    Bei den Sachsen sind IPv4 Adressen an dedizierten Servern nun optional. Die Cloud soll bald nachziehen.


    Ob Netcup auch bald nachzieht? :)

    Imho sollte Netcup, bevor Energie in sowas gesteckt wird, erstmal IPv6 vollumfänglich ausrollen, damit es auch für komplexere Szenarios jenseits einem simplen 0815 Webserver Hosting nutzbar wird.


    Sprich, Subnetze vernünftiger Größe anbieten.


    Die erwähnte große Konkurrenz (und auch einige andere) machen es bereits vor. ;)

    Weil ich es gerade in einem anderen Thread gelesen habe: könnte hier auch der qemu-guest-agent eine Rolle spielen? (direkt auf der Proxmox VM). Der muss ja ggf. manuell nachinstalliert werden.

    z.B. ECC-RAM wäre ein guter Grund (den gibt es in dieser Preisklasse bei dedizierter Hardware noch nicht).

    Also ich hab neulich erst nen Server dort gesehen mit 2*480GB Datacenter SSD, 1G Standleitung, 64 GB DDR4 ECC RAM, 4 dedi Cores (8 threads) (2016er Xeon 8500er CPU-B) und das ganze für 35€ ;)

    Ich habe den Container vor 2 Tagen auf Proxmox 6 (Kernel 5.4.128-1-pve) verschoben. Die Maschine hat inzwischen eine Uptime von 101 Tagen ohne Probleme.


    Die Proxmox 7 VM hat seitdem der Container weg ist dreimal spontan neu gebootet. Die VM ist jetzt ansonsten Idle.

    Ausschließlich bezogen auf Root-Server Gen9, oder?

    Mit Proxmox 6 habe ich die gleichen Probleme... - aber ein Commitment das Problem zu anzugehen seitens Netcup wäre echt nicht schlecht.

    wobei ich ergänzen muss, ich rede hier nur von reinen Containerlösungen, sprich ohne VMX/SVM flag und ohne nested kvm. Ich glaube da gabs nur unter Proxmox 7 ein Problem, oder?

    Ich mein es wäre ja schonmal ein Anfang, wenn Netcup sich dazu commiten könnte, dass das Problem definitiv bis Ende Q2 2022 durch ein Kernelupgrade behoben wird. So könnte man zB. weiterhin auf Proxmox 6.4 setzen, dessen Support 08/2022 ausläuft und dann auf 7.x upgraden. Aber so mit dem Tempo wie es aktuell läuft, bleibt wohl tatsächlich nur die Wahl eines anderen Providers bzw. direkt ein Dedi beim großen H.


    [netcup] Claudia H. wäre so etwas möglich?