Beiträge von oliver.g

    Hi, genau, du musst die Zusatz IP auf jedem Server konfigurieren, an den diese möglicherweise geroutet wird, der Rest ist nur noch Weichenstellung. Ob du die IP jetzt an ein virtuelles Interface bindest, oder wie ich bei meinen Debian Maschinen direkt an das Interface bleibt dir überlassen. Das Gateway ändert sich nicht. Wichtig ist eben nur, dass du die Zusatz IP mit der richtigen Maske konfigurierst, wie im SCP angegeben. Beispiel für die Interface Datei wäre

    Code
    post-up ip address add <ip>/<mask> dev ens3
    down ip address del <ip>/<mask> dev ens3

    hm, dürfen vereine mit webseite sich da auch selbst spenden? :)

    auch steht da nur "an einen eingetragenen Verein". spendenquittungen kriegt man aber nur von gemeinnützigen vereinen.

    gelten nun alle vereine oder nur die gemeinnützigen?

    Du brauchst keine Spendenquittung, es reicht, laut Produktbeschreibung, der Kontoauszug.

    Hm, wenn aber doch schon dein Host diese IPv6 Adresse (11) nicht nach außen verfügbar macht, weiß doch das netcup Netzwerk gar nicht, dass diese überhaupt aktiv ist. Nach meinem Verständnis müsstest du in dem Falle entweder die Adresse dem Host zuweisen (analog zum IPv4 NAT), oder evtl. funktioniert das auch mit einem IPv6 neigh proxy.

    BTW: Ich wusste gar nicht, dass NAT bei IPv6 möglich ist. Ist das nur eine Art Workaround?

    Dass die TTL auf den netcup Nameservern standardmäßig auf 24h eingestellt ist, ist dir bewusst?!

    Hi, nein spricht nichts dagegen, das funktioniert so. Ist ja wie ein privates LAN zuhause. Was du allerdings beim "internen" Monitoring außer Acht lässt ist das gesamte Netcup Netzwerk. Wenn es darin Störungen gibt, bekommt es dein Monitoring Host evtl. nicht mit, da intern alles funktionieren kann, nach außen jedoch nicht. Ich behelfe mir in dem Falle noch mit einem externen Monitoringdienst, der meinen Monitoring Host überwacht.

    ist dann aber keine antwort auf meine frage. da du meine frage zitiert hast und dein beitrag als eine antwort formuliert war, nahm ich das an...

    Du fragtest nach dem Sinn zusätzlicher IP-Adressen, ich erklärte den Sinn, den die zusätzlichen (IPv6) IP-Adressen für meine Anwendungszwecke haben.

    Bitteschön, gern geschehen.

    ich beziehe mich nicht auf ipv6 sondern auf richtige ip adressen :)

    man zahlt also laufende gebühren dafür, daß man den dns "falsch" konfiguriert hat?

    Mein Beitrag bezog sich aber auf IPv6 und dann ist es genau der Routingvorteil bei mir (geht auch mit einem nicht-Failover Zusatzsubnet, dieses lässt sich aber bei einem Serverumzug nicht einfach umziehen). Weiterer Vorteil ist eben, wie der Commander schrieb, das einfache umswitchen der Failovers bei einem Serverausfall.

    Ein selbstsiginiertes Zertifikat sollte kein grundsätzliches Hindernis darstellen, aber als Anregung: Beispielsweise unter Verwendung des Cloud-vLANs könnte man ggf. auf die Verschlüsselung bei der Synchronisierung auch verzichten:

    Code
    service doveadm {
        inet_listener {
            ssl = no
        }
    }

    VLAN ist nicht verschlüsselt. Birgt das kein Sicherheitsrisiko?

    Hach, was bin ich froh, dass ich noch ein "Free Failover-IPv6-Subnet ab 2 Root-Server" hab. ^^

    Ich kann aber jetzt gar nicht mehr sagen, seit wann ich das hab oder wann das angeboten wurde.

    Die sind halt Gold wert, wenn man Containerlösungen, wie Proxmox oder Docker nutzt ? habe auch 3 davon.