Posts by pgloor

Nachdem ich bei netcup nicht gerade den besten Start hinlegte und vorgestern leicht frustriert all meine meine Produkte wieder gekündigt habe, hatten mich letztendlich drei Dinge davon überzeugt die Sache nochmals zu überdenken und noch nicht aufzugeben:

1. Das Produkt Root-Server an und für sich.

2. Die Netzanbindung, die mir wichtig ist.

3. Die Community (sprich dieses Forum).

Bisher habe ich das noch nie so gesehen und normalerweise steht bei mir eine gute Doku (Wiki) und der Support an dritter Stelle. In meinem Fall war jetzt die Community dafür ausschlaggebend, dass ich bleiben werde.

Und o.k., dem Neujahrskracher konnte ich jetzt auch nicht widerstehen.

H6G wrote:

Kurze Vorwarnung: wenn es kein FailOver Subnet ist, kostet es eine Bearbeitungsgebühr das ganze auf einen anderen Server legen zu lassen, meine ich.

Ja, danke, das weiss ich schon. Aber das wird immer noch billiger als ein neues Subnet bestellen und das andere ein Jahr lang brach liegen lassen. Ich hab's doch bereits schon bezahlt.

H6G wrote:

Im Übrigen kannst du eine Kündigung auch wieder zurück ziehen. Sowas ist nicht in Stein gemeißelt.

Ja, das werde ich morgen regeln. Oder das Subnet auf den "Neujahrskracher" legen, da ich zur Zeit eher zuviel ungenutzte Kapazitäten habe. Die Root-Server sind einfach eine geniale Ergänzung zu dem was ich sonst noch habe und ich überlege mir einen älteren dedizierten Server damit abzulösen.

Nur so als Feedback: ich wollte es jetzt genau wissen und konnte nicht mehr bis morgen warten. Der Tag ist gerettet. Ich habe mein gewünschtes Setup mit den zwei Containern, wie von mir beschrieben, jetzt realisiert. Es funktioniert perfekt und passt bis auf den zusätzlichen Eintrag mit der Zieladresse im Server zu meinen sonstigen Konfigurationen. Schade, dass ich es in der Doku im Wiki so nicht finden konnte.

H6G : sorry, das habe ich in #11 dann nicht so verstanden.

Echt SUUUUUUUUUUUUUUUUUUUUPER!!!!! Das war's!

Der Rest wird ein Klacks, da bin ich mir sicher. Das mach ich dann morgen. Ich hab mir gleich noch den "Neujahrskracher" (RS 2000 G8) bestellt.

Ich dachte mir, dass es nur eine Kleinigkeit sein kann. Ich hatte das mit der Adresse auch schon mal versucht, aber dann war wahrscheinlich so viel durcheinander, dass es aus anderen Gründen nicht funktioniert hat.

Danke dir und allen anderen in diesem Thread für eure Bemühungen.

mainziman wrote:

https://www.internetsociety.or…e-ipv6-in-an-isp-network/

(irgendwie hat da jemand seine Hausaufgaben nicht gemacht, Punkt 8 ist sinnfrei)

Humor ist wenn man trotzdem lacht

Ich musste jetzt auch zweimal überlegen. Aber im ernst, auch wenn man es gerne anders hätte, so ist es doch so, dass immer noch täglich neue IPv4 Adressen aus irgendwelchen Gründen benötigt werden. Also macht doch die Strategie nicht mehr benötigte IPv4 Adressen für andere Projekte freizustellen durchaus mehr Sinn als diese für teures Geld einzukaufen.

Und wer seine Hausaufgaben gemacht hat und kaum mehr IPv4 Adressen braucht, kann sie immer noch für teures Geld denen verkaufen, welche ihre Hausaufgaben noch nicht gemacht haben.

Danke für den Hinweis, aber klar hab ich das

Ich hatte ja nebst dem Root Server schon den vServer und da fragte ich mich schon bei der Bestellung, ob die denn wissen wohin sie die Zuweisung machen müssen. Also war die Zuweisung das Erste was ich machte und sie erscheint auch richtig im SCP (unter Allgemein und Netzwerk).

Angenommen, ich habe einen neu aufgesetzten Server mit Ubuntu 18.04, ohne LXD oder irgendwas, kann ich dann eine Adresse aus dem zweiten IPv6 dem Interface ens3 einfach zuweisen oder muss ich noch was machen? Ich frage deshalb weil das nicht geht:

Das ist meine /etc/netplan/01-netcfg.yaml:

Das funktioniert. Ich kann von extern 2a03:4000:32:112::1 problemlos anpingen und in umgekehrter Richtung geht ein ping -6 auch.

Entferne ich jetzt das Kommentarzeichen für die IPv6 Adresse aus dem zweiten Subnet, dann kann ich 2a03:4000:32:112::1 von extern immer noch anpingen. Hingegen kann ich von extern 2a03:4000:20:196::1 nicht anpingen und ping -6 vom Root Server nach aussen gehen auch nicht mehr.

Dasselbe gilt wenn ich den Server im Rettungssystem starte und das Netzwerk entsprechend manuell mit ip konfiguriere. Und wie schon erwähnt, im tcpdump bekomme ich auch nie etwas aus diesem Subnet zu sehen (z.b. keine "neighbor solicitation, who has 2a03:4000:20:196::1" bei tcpdump icmp6 wenn extern dafür pings abgesetzt werden).

Am externen Server sieht es dann so aus:

Ich bin mal gespannt. Ich hab auf morgen einen telefonischen Termin vereinbart. Ich bin nicht der, welcher zuerst mal nach dem Support schreit und ich erwarte ja auch nicht, dass mir der Support meine Kiste konfiguriert, aber hier läuft mit der Anbindung gerade einiges nicht so wie ich mich es von anderen Providern gewohnt bin und wer kann denn sonst helfen, wenn nicht der Support?

Vielleicht habe ich mit der Kündigung etwas überreagiert, aber da der Root Server bis zum Ablauf der Kündigungsfrist eh noch vorhanden ist, habe ich beschlossen noch nicht aufzugeben. Ich finde den Root Server für meinen Zweck zu attraktiv.

Inzwischen habe ich auch noch festgestellt, dass ich etwas überlesen habe *Haare ruft*:

Mordor wrote:

Dein Standard IPv6 Subnet ist kein geroutetes Subnet. D.h. es funktioniert nur auf dem Interface deines Hosts. näheres z.B. Wikipedia

Entweder Du verwendest einen ND Proxy, oder Du brauchst ein geroutetes IPv6 Subnet (z.B. Failover IPv6)

Da habe ich "geroutetes IPv6 Subnet" wohl mit "zusätzliches IPv6 Subnet" verwechselt. Erst jetzt ist mir klar geworden, dass dann wohl die einzige Option ausser einem ND Proxy, ein Failover IPv6 ist. Schade hab ich den Adventskalender verpasst

Es bleibt dann immer noch die Frage offen, warum dieses zusätzlich bestellte IPv6 Subnet nicht funktioniert. Sobald ich eine Adresse aus diesem Netz zusätzlich dem Interface ens3 zuweise sind IPv6 Zugriffe ins Internet blockiert. Diese Adresse ist mit ping von aussen auch nicht erreichbar, die schon vorhandene IPv6 Adresse aus dem ersten IPv6 Subnet aber schon. Wenn ich da jetzt nicht wieder etwas durcheinander bringe, dann ist dies aber ein anderes Problem und hat für mich keine Priorität.

Antwort vom Support, nachdem ich die Situation mit den LXC/LXD Containern nochmals detailliert beschrieben habe und gezeigt habe, dass auch im Rettungssystem vom/zum zusätzlich bestellten IPv6 Subnet kein externer Verkehr möglich ist. Zudem habe ich geschrieben, dass der Server bis zum 7.1.2019 jederzeit und ohne Vorwarnung jederzeit abgestellt werden darf um das Problem zu analysieren.

"Natürlich wird das von uns zur Verfügung gestellte IPv6 Netz geroutet. Bitte gehen Sie nach folgender Anleitung vor um eine IPv6 Adresse zu konfigurieren https://www.netcup-wiki.de/wiki/Zus%c3%a4tzliche_IP_Adresse_konfigurieren#IPv6%7C

Was das System interne Routing angeht haben wir keine Möglichkeit irdgendwas zu überprüfen, da wir keinen Zugriff auf den Server haben.

Wir können aber versichern, dass das Standard Subnetz geroutet wird."

Natürlich bin ich der Anleitung gefolgt. Ich habe das zwar nicht explizit gesagt, aber umschrieben.

Es tut mir leid. Wenn sich der netcup Support nicht ein bisschen mehr Mühe gibt, dann bin ich hier definitiv beim falschen Anbieter. Mein Setup läuft bei meinem bisherigen Provider sowohl auf einem dedizierten Server als auch auf einem VPS und ist von mir in weniger als 30 Minuten aufgesetzt.

Ich habe alle Produkte bei netcup gekündigt.

ok, danke euch allen. Ich denke da muss der Support ran.

Bei einem Ping von extern kommt in sudo tcpdump -i ens3 -x icmp6 und dergleichen an der Schnittstelle am "Host" nichts an was das zusätzliche Subnet betrifft. "Neighbour solicitations" für das nicht geroutete IPv6 Subnet kommen an. Ping vom Host zum Container geht, ssh ebenfalls. Firewall hab ich zu dem Zeitpunkt keine.

Ich überlege und versuche mal ob ich über das Rettungssystem noch Erkenntnisse gewinnen kann, falls nicht werde ich mal den Support bemühen.

Aber vorerst wünsche ich allen noch einen Guten Rutsch und alles Gute im neuen Jahr!

voja wrote:

Wenn das IPv6 Subnetz gerouted ist, legst Du das /64 Netz auf das gewünschte Netzwerkinterface (Bridge).

Die Hostbridge kriegt eine IPv6 Adresse aus dem /64 Netz, das als Gateway für die Container dient. Die IPv6 für die Container kannst Du dann jeweils im Container festlegen.

Ok, danke. Ich dache mir, dass es so ist, aber es hat irgendwie nicht funktioniert. Ping bis zur Bridge geht, aber nicht zum Container und es geht auch nichts aus dem Container raus. Ich starte morgen nochmals von vorne mit einer frischen Installation.

voja wrote:

Nur damit ich das richtig verstehe: willst Du einem LXD Container eine IPv6 Adresse aus einem gerouteten Subnetz zuweisen? Welche LXD Version hast Du

Ja genau das möchte ich. Das wäre schon mal etwas Ich verwende Ubuntu 18.04 LTS mit LXD 3.0.3 und Netplan (gilt für Host und Container).

Die Adressen binde ich im Container statisch an eth1. All meine Container haben normalerweise immer die defaultmässige von LXD verwaltete lxdbr0 mit der Schnittstelle eth0. In meinen Konfigurationen hier bei Netcup habe ich diese aber bewusst ausgeschaltet (Profile default nach ipv6 kopiert und lxdbr0 durch lxdbr1 ersetzt, dann das Profile ipv6 dem Container zugewiesen).

Früher, unter Ubuntu 16.04, machte ich das über eine nicht von LXD verwaltete Layer 3 Bridge (virbr0 (brouter) oder wie immer man das nennen mag). Ich machte keine weitere Unterteilung.

Neu unter Ubuntu 18.04 mit Netplan und LXD 3.0.3 mache ich das über eine von LXD verwaltete Bridge. Das ist insgesamt einfacher. Ich weise dabei jeder Bridge ein /80 Netz zu, das gibt mir noch etwas Spielraum, muss aber nicht sein, da ich hier eh nur eine Bridge benutzen werde.

Ich habe jetzt hier bei netcup zwei Server. Einen root Server mit zusätzlichem IPv6/64 Subnetz und einen vServer ohne zusätzlichem Subnet. Ich verstehe jetzt schon die Notation -> 2a03:4000:32:112:8f5:4aff:feb3:b46a nicht ganz. Inwieweit betrifft mich das? Muss ich das auch als Gateway einsetzen oder bleibt fe80::1 mein Gateway? Bei meinem anderen Provider setzte ich im Container die Host-seitige Link Local Adresse der Bridge als Gateway. Der Rest bleibt sich gleich.

Ich versuche mein Vorgehen später oder morgen mal in den Details aufzuzeigen. Aber vielleicht hast du auch schon ein Tipp.

Ich frag mich gerade ob das jemals jemand zum laufen gebracht hat. Ich habe jetzt so ziemlich alles durchgespielt, was ich mir denken kann.

Auf meinem Root-Server hab ich ein zusätzliches IPv6/64 Subnetz das geroutet wird. Aber selbst damit hatte ich keinen Erfolg.

Auf meinem vServer habe ich es mit ndppd versucht aber auch damit keinen Erfolg.

Hat jemand funktionierende Beispiele dafür? (beide Szenarien sind gefagt)

Dass das IPv6/64 Subnet nicht an den Server geroutet wird fnde ich jetzt ein bisschen ein Schwachpunkt bei netcup. In der Hoffnung, dass es den erhofften Erfolg bringt, hab ich mal ein zusätzliches IPv6 Subnet bestellt. Ein Failover nur dafür ist mir zu teuer.

Klar kann ich einen ND Proxy konfigurieren, aber ich möchte meine Konfigurationen lieber überall gleich und weniger fehleranfällig haben. Auch wenn ich auf meinem ersten Server bei Netcup höchstens ein oder zwei Container haben werde, so ist mir eine möglichst einheitlich gehaltene einfache Konfiguration wichtig.

oliver.g : Ja, ich mach das normalerweise auch nicht so, ist nur ein Workaround, weil ich mit möglichst wenig Aufwand rasch eine ssh-Verbindung haben wollte. Der Schuss ging aber nach hinten los

Mordor : Danke, alles klar.

Ich habe einen RS 1000 mit frisch installiertem Ubuntu 18.04. Auf diesem Server habe ich LXD aktiviert und einen Container mit ubuntu:18.04 gestartet.

Der Container verwendet also das Default Profile mit der standarmässig von LXD verwalteten Bridge (Network) lxdbr0.

So weit ist alles normal und der Container hat nach lxc exec box1 -- bash aus dem Container heraus IPv4 und IPv6 Zugriff auf das Internet.

In der /etc/sysctl.conf habe ich auch die Einträge net.ipv4.ip_forward=1 und net.ipv6.conf.all.forwarding=1 gesetzt und den Server neu gestartet.

Jetzt möchte ich von meinem PC mit ssh über IPv6 auf den Container zugreifen und habe zu diesem Zweck mit ip6tables einfach mal einen PREROUTING DNAT Eintrag erstellt.

sudo ip6tables -t nat -A PREROUTING -d 2a03:4000:xx:yyy::11 -j DNAT --to-destination fd42:58a3:ae0e:71df:216:3eff:fe27:de32

Die in Netplan statisch definierte IPv6 Adresse von ens0 des LXD Hosts ist 2a03:4000:xx:yyy::2/64. Mit dieser Adresse erreiche ich meinen Root Server.

Nachdem ich mit Hilfe von lxc exec im Container einen User angelegt und die /etc/ssh/sshd_config angepasst habe, erwartete ich (nach Neustart des Containers), dass ich über die Adresse 2a03:4000:xx:yyy::11 per ssh auf den Container zugreifen kann, oder diesen mit dieser Adresse anpingen kann. Leider funktioniert das nicht und ich habe keine Ahnung warum.

Wenn ich mit sudo ip addr add 2a03:4000:xx:yyy::11/64 dev ens3 die Adresse auch noch der Schnittstelle im LXD Host hinzufüge, dann funktioniert der Zugriff auf den Container von aussen. Ich halte diese Konstellation allein schon deshalb für falsch, da ich sie auf anderen Servern (nicht bei netcup gehostet) noch nie brauchte.

Ob es nun an solchen Experimenten mit Alias Adressen gelegen hat oder eine andere Ursache hatte weiss ich nicht, aber vor zwei Tagen hatte ich auch das Problem dass IPv6 Pings nach aussen nicht zu allen Destinationen funktioniert hat. Ich wollte das der Vollständigkeit halber noch erwähnen. Inzwischen habe ich den Server neu installiert und dies funktioniert jetzt wieder. Das Routing Problem ist aber weiterhin offen. Es hat sich daran nichts geändert.

Interessant. Ich denke, dass ich jetzt genau dasselbe Problem habe und bin deshalb auf diesen Thread gestossen.

Ich hoffe mal, dass ich nicht am zweiten Tag bei netcup schon den Support bemühen muss

Mit tshark und im Rettungssystem habe ich noch nicht getestet.

Da ich schon mal ein ähnliches oder dasselbe Problem hatte, dass sich nach einem Wochenende von selbst gelöst hat, warte ich mal noch.

Das heisst dann für mich Feierabend machen und zuerst mal Weihnachten geniessen

Bei mir sieht es ein bisschen anders aus:

Begründung:

1. Die IPv6 Adresse wird statisch zugewiesen, bzw. DHCP 6 ist nicht vorhanden, deshalb "dhcp6: no".
2. Die IPv4 Adresse wird vom DHCP zugewiesen, deshalb gebe ich sie in den addresses nicht nochmals an.

Ich bin neu hier. Ob das nun richtiger oder besser ist, weiss ich auch nicht. Ich hab's aus eigenen Überlegungen so gemacht.

Was die Darstellung der Adressen unter addresses betrifft, so ist das nur eine andere Form. Man kann so Adressen untereinander auflisten. Ich finde das bei langen Listen übersichtlicher.

Beispiel:

Und denkt daran, in Netplan sind die Einrückungen von höchster Bedeutung und eine der häufigsten Fehlerquellen. Niemals Tabulatoren verwenden!!! Ich verwende immer zwei Leerzeichen pro Stufe.

Was mir nicht ganz klar ist, warum meine Netplan-Konfiguration ohne Angabe der IPv6 DNS Serveradressen läuft. Auf einem dedizierten Ubuntu 18.04 Server bei einem anderen Provider musste ich diese in der Netplan-Konfiguration unter nameservers:/addresses: auch noch setzen.

ping -6 google.com funktioniert hier auf meinem RS 1000 aber ohne weiteres zutun meinerseits einfach so.

Eine letzte Frage (versprochen) hätte ich noch. Wann macht es Sinn bei einem RS 1000 im SCP unter Einstellungen/CPU Aufbau von "1 Socket/2 Cores" auf "2 Sockets/1 Core" umzustellen?

Alles klar... ich hab den verlinkten Beitrag auch gelesen und verstanden. Spannendes Thema.