IPs/Subnetze für VLANs

    Moin,


    ein großer und bekannter Anbieter für Dedicated Server bietet, so wie Netcup, an, zusätzliche private VLANs für Server zu konfigurieren. Was dieser Anbieter außerdem anbietet ist, zusätzliche IPs/Subnetze in dieses VLAN zu routen, sodass man auch innerhalb des VLANs öffentliche IP-Adressen haben und dort z. B. ein Kubernetes-Cluster mit MetalLB betreiben kann.


    Soweit ich das richtig sehe, geht das bei Netcup nicht, sondern eine zusätzliche IP ist immer an einen Server gebunden, oder? Ich weiß über die Existenz dieser FailOver-IPs, aber auch die haben immer einen Server-Bezug, den man aber übers SCP umstellen kann. Oder sehe ich das gerade falsch? Bei dem nicht näher genannten Anbieter erfolgt die Zuweisung der IP ausschließlich über die Konfiguration des Betriebssystems (also der Netzwerkkarte einfach die IP geben). Meine (nicht-Failover) zusätzliche IP hier bei Netcup musste ich im SCP konfigurieren, aber wie sieht das bei Failover-IPs aus?


    Viele Grüße

    Matthias

    Matthias Lohr Project Blog: https://mlohr.com/

    PGP: 0x8FC3060F80C31A0A

    Der Unterschied zwischen zusätzlicher IP und Failover IP ist, dass sich die Failover IP kostenlos auf einen anderen Server routen lässt (per SCP oder API). Die zusätzliche IP kann, einmal auf einen Server geroutet, nur noch nach Zahlung einer Gebühr umgebogen werden.

    Ok, dann... liebes Netcup, Lieber [netcup] Felix P., könntet ihr das vllt. als Feature Request irgendwo notieren? :) Das würde es ermöglichen, existierende HA-Lösungen (sowas wie z. B. Kubernetes) bei euch einzusetzen - das geht aktuell leider nicht wirklich gut.

    Matthias Lohr Project Blog: https://mlohr.com/

    PGP: 0x8FC3060F80C31A0A

    Die Failover IPs leitest Du auf einen bestimmten Server über das SCP oder die API. Das hat nichts mit dem vLAN zu tun und funktioniert komplett getrennt davon. Die netcup vLAN haben auch laut Produktbeschreibung keinen WAN Zugang.

    Quote from mlohr

    Ok, dann... liebes Netcup, Lieber [netcup] Felix P., könntet ihr das vllt. als Feature Request irgendwo notieren? :) Das würde es ermöglichen, existierende HA-Lösungen (sowas wie z. B. Kubernetes) bei euch einzusetzen - das geht aktuell leider nicht wirklich gut.

    Ich habe bei netcup HA mit den Failover IPs im Einsatz. Du kannst ohne große Probleme keepalived oder ähnliches nutzen und die Failover IPs umschalten (Rootserver scheinen im Gegensatz zu VPS wesentlich weniger Umschaltvorgänge zu erzeugen). Du kannst auch ne Firewall wie pfSense an die Netzwerkkarte hängen und dann Dein vLAN mit IPs versorgen, die da hin gerouted werden, entweder Failover oder ganz normale. Da bist Du nicht eingeschränkt, ganz im Gegenteil. Im Gegensatz zum anderen Hoster könntest Du dieses Gateway HA aufsetzen, während es dort immer den Single Point Of Failure gibt, auf den Du keinen Zugriff hast.

    eripek bist Du dann nicht dort, was Zugangsprovider auch veranstalten?

    z.B. bei IPv4 Du hast eine öffentliche IPv4, welche auf einem sogenanntem Transportnetz (ein RFC1918-Netz z.B. 10.0.0.0/8)

    geroutet wird;

    mit dem VLAN wär es genau so; nur bei IPv6 ist es etwas komplizierter; Du musst Dir ein RFC 4193 'suchen' und auf dem routest Du dann einen Teil vom /64-Prefix, der mit dem Server angegeben ist;


    ich hab hier was gebastelt f. diese sogenannten Unique Local Prefixes

    https://www.ipv6help.de/uniquelocal.html

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

    Quote from voja

    Ich habe bei netcup HA mit den Failover IPs im Einsatz. Du kannst ohne große Probleme keepalived oder ähnliches nutzen und die Failover IPs umschalten (Rootserver scheinen im Gegensatz zu VPS wesentlich weniger Umschaltvorgänge zu erzeugen).

    Wie genau? keepalived ruft dann die SCP-API auf?

    Quote

    Du kannst auch ne Firewall wie pfSense an die Netzwerkkarte hängen und dann Dein vLAN mit IPs versorgen, die da hin gerouted werden, entweder Failover oder ganz normale. Da bist Du nicht eingeschränkt, ganz im Gegenteil. Im Gegensatz zum anderen Hoster könntest Du dieses Gateway HA aufsetzen, während es dort immer den Single Point Of Failure gibt, auf den Du keinen Zugriff hast.

    Eben genau das ist der Punkt, den ich in Frage stelle. "eine Firewall wie pfSense" würde auf einem vServer laufen, richtig? Fällt dieser aus, wird die IP auch nicht länger irgendwo geroutet sondern ist offline. Ja, ich könnte 2 pfSensen betreiben und dann, wenn eine ausfällt, die IP (per SCP-API?) auf die jeweils gerade nicht ausgefallene VM biegen. Aber dann kann ich mir den pfSense-Zwischenschritt auch sparen und direkt per SCP-API auf den Zielserver biegen, oder?

    Matthias Lohr Project Blog: https://mlohr.com/

    PGP: 0x8FC3060F80C31A0A

    Quote from voja

    Die Failover IPs leitest Du auf einen bestimmten Server über das SCP oder die API. Das hat nichts mit dem vLAN zu tun und funktioniert komplett getrennt davon. Die netcup vLAN haben auch laut Produktbeschreibung keinen WAN Zugang.

    Ja, ich weiß, letzteres ist aber genau was, was ich als Feature Request bitte, irgendwann mal zu implementieren ;) (Nach dem Vorbild von besagtem bekannten Hoster mit dem großen H).

    Matthias Lohr Project Blog: https://mlohr.com/

    PGP: 0x8FC3060F80C31A0A

    Quote from eripek

    Was hindert Dich daran, Deinen einem Server zugewiesenen Prefix zu unterteilen, und das dann per Routingprotokoll im VLAN zu routen?

    Bei den v4-IPs ist es relativ witzlos, da man zu RS/VPS iaR nur je eine IP oder Zusatz-IP bekommt - und gerade kein Netz.

    Die Failover-IPs lassen sich per API schalten. https://www.netcup-wiki.de/wiki/Netcup_SCP_Webservice (changeIPRouting).

    Weil genau dieser Router erstmal ein Single-Point-of-Failure darstellt. Wie ich "irgendwie" öffentliche IPs in ein VLAN bekomme weiß ich. Mein Ziel wäre, nachher eine Layer2-HA-Lösung zu haben - so wie das z. B. Kubernetes mit MetalLB macht. Oder pfSense mit seinen VirtualIPs.

    Matthias Lohr Project Blog: https://mlohr.com/

    PGP: 0x8FC3060F80C31A0A

    Quote from mainziman

    eripek bist Du dann nicht dort, was Zugangsprovider auch veranstalten?

    z.B. bei IPv4 Du hast eine öffentliche IPv4, welche auf einem sogenanntem Transportnetz (ein RFC1918-Netz z.B. 10.0.0.0/8)

    geroutet wird;

    Man kann auch bloß v6 routen und das v4 der Hosts darin verkapseln. Ist vielleicht die einfachere Lösung.


    Quote from mlohr

    Weil genau dieser Router erstmal ein Single-Point-of-Failure darstellt. Wie ich "irgendwie" öffentliche IPs in ein VLAN bekomme weiß ich. Mein Ziel wäre, nachher eine Layer2-HA-Lösung zu haben - so wie das z. B. Kubernetes mit MetalLB macht. Oder pfSense mit seinen VirtualIPs.

    Den SPoF hast Du in jedem Fall, wenn Du das machst. Dafür gerade gibt es ja die Failover-IPs/Prefices samt API.


    Ich denke einmal, wenn v6-only VPS/RS kommen, wird dieses Feature -IPs an VLAN routen- sowieso irgendwann notwendig werden. Momentan ist eben jede IP an den Server gekoppelt. Auf kurz oder lang wird man dann wohl Subnetze als separates Produkt zu einem RS/VPS erwerben, wie bei den Managed Servern.


    Das Problem mit Route an VLAN ist aber auch, dass die VLANs (vxlan) bandbreitenlimitiert sind. Man würde so eventuell nicht das SLA einhalten.

    Quote from eripek

    Den SPoF hast Du in jedem Fall, wenn Du das machst. Dafür gerade gibt es ja die Failover-IPs/Prefices samt API.

    Wenn ich in der Lage wäre, eine IP in ein VLAN zu routen, wäre es ohne SPoF machbar (sofern die Anlieferung der VLANs ebenfalls redundant ausgelegt ist natürlich). Aber dann hängt es nicht mehr an meinen VMs.

    Matthias Lohr Project Blog: https://mlohr.com/

    PGP: 0x8FC3060F80C31A0A

    Quote from mlohr

    Wie genau? keepalived ruft dann die SCP-API auf?

    Eben genau das ist der Punkt, den ich in Frage stelle. "eine Firewall wie pfSense" würde auf einem vServer laufen, richtig? Fällt dieser aus, wird die IP auch nicht länger irgendwo geroutet sondern ist offline. Ja, ich könnte 2 pfSensen betreiben und dann, wenn eine ausfällt, die IP (per SCP-API?) auf die jeweils gerade nicht ausgefallene VM biegen. Aber dann kann ich mir den pfSense-Zwischenschritt auch sparen und direkt per SCP-API auf den Zielserver biegen, oder?

    Du kannst in keepalived Scripte einbinden. Ich habe mir da eins geschrieben, dass die Umschaltung vornimmt und auch regelmäßig auf Korrektheit überprüft.


    pfSense hat eine Funktion um die Konfiguration auf zwischen zwei Instanzen gleich zu halten. Ich habe das aber noch nicht mit netcup ausprobiert, wie man das nutzen könnte um die Failover IPs umzuschalten.

    Quote from mlohr

    Ja, ich weiß, letzteres ist aber genau was, was ich als Feature Request bitte, irgendwann mal zu implementieren ;) (Nach dem Vorbild von besagtem bekannten Hoster mit dem großen H).

    Wenn das richtig implementiert wird, wäre das natürlich schön. Mal schauen ob was daraus wird. Immerhin wird der Punkt mit dem WAN beim vLAN angegeben, also ist dieser Punkt bekannt.

    Quote from voja

    pfSense hat eine Funktion um die Konfiguration auf zwischen zwei Instanzen gleich zu halten. Ich habe das aber noch nicht mit netcup ausprobiert, wie man das nutzen könnte um die Failover IPs umzuschalten.

    Die Funktion an sich würde mit 2 pfSensen klappen. Was nicht klappt, ist die dann zwischen den pfSensen hin und her geschobene IP zu teilen. Das läuft auf Layer2 ab, sprich, solange pfSense1 lebt, antwortet sie auf ARP-Anfragen für diese IP, sobald das Ding tot ist, antwortet pfSense2. Also das, was bei H* geht, bei Netcup (noch?) nicht. Genau deswegen wünsche ich mir das Feature ja ;)

    Matthias Lohr Project Blog: https://mlohr.com/

    PGP: 0x8FC3060F80C31A0A

    Quote from mlohr

    Die Funktion an sich würde mit 2 pfSensen klappen. Was nicht klappt, ist die dann zwischen den pfSensen hin und her geschobene IP zu teilen. Das läuft auf Layer2 ab, sprich, solange pfSense1 lebt, antwortet sie auf ARP-Anfragen für diese IP, sobald das Ding tot ist, antwortet pfSense2. Also das, was bei H* geht, bei Netcup (noch?) nicht. Genau deswegen wünsche ich mir das Feature ja ;)

    Dafür gibt es ja Failover IPs. Die müssen auf die Master pfSense gerouted werden.

    Quote from voja

    Die müssen auf die Master pfSense gerouted werden.

    Genau. Aber es ist eben eine zusätzliche Aktion erforderlich, um die auf einen anderen Server zu bekommen. Und genau das würde ich gerne loswerden, um dafür auf etablierte Methoden zu wechseln.

    Matthias Lohr Project Blog: https://mlohr.com/

    PGP: 0x8FC3060F80C31A0A

    Quote from mlohr

    Genau. Aber es ist eben eine zusätzliche Aktion erforderlich, um die auf einen anderen Server zu bekommen. Und genau das würde ich gerne loswerden, um dafür auf etablierte Methoden zu wechseln.

    Das geht aber doch per Script? Wenn man Rootserver statt VPS verwendet sollte es ja nur selten zu einem Umschalten kommen.


    Und auch bei dem anderen Anbieter kann es sein, dass man den ARP Cache Ablauf warten muss, bis die Umschaltung durch ist, wenn die Kiste abraucht.

    Quote from mlohr

    Auf die Gefahr hin, dass ich mich wiederhole: Die Anforderung ist ohne Script. Z. B. via Kubernetes + MetalLB.

    Das Script muss nicht Teil Deines genannten Setups sein. Du musst nur feststellen können, wohin die IP geleitet werden soll. MetalLB kenne ich nicht, müsste ich erst anschauen.