Beiträge von fansari

Na mit "ip address show dev ens3" auf dem Server.

Ob deine Vermutungen stimmen lässt sich ja leicht testen.

Ich gehe also wieder zurück auf stable-privacy und siehe da der ping bleibt wieder stehen.

Nun schaue ich mir ens3 an. Ist dort nun eine andere oder zusätzliche IP? Nein, wie gehabt. Nur eine statische IP und zwar genau die, die da vorher auch war.

Und wie sieht nun die fe80 Adresse aus? Nun ist es irgendeine gewürftelte IP, die nicht mehr zur MAC Addresse passt.

Nun wieder Rolle rückwärts auf eui64: der ping läuft wieder durch und die fe80 Adresse passt wieder zur MAC Adresse und sonst ist alles gleich.

Es liegt also eindeutig an der fe80 Adresse. Auch die anderen Parameter (scope global noprefixroute bzw. scope link noprefixroute) sind gleich geblieben.

Ich verstehe nicht was du meinst. Was ist ein "Default Image" von netcup? Ich bin zu Netcup gewechselt, um die Linux Distribution installieren zu können, die ich bevorzuge. In meinem Fall ist das Fedora Core OS.

Natürlich muss mein Interface eine public IPv6 Adresse haben. So ist mein Server ja auch eingerichtet. Ich habe nie etwas anderes behauptet.

Bei der Diskussion um stable-privacy und eui64 ging es lediglich um die link-local Adresse (also die fe80:...). Diese Adresse wird ja eh nicht geroutet sondern ist nur für die "neigbors" sichtbar.

Die Router von netcup sollen den Traffic zu meiner statitschen IPv6 Adresse routen (also der 2003:4000:...). So ist es ja auch im Netzwerkbereich vom servicecontrolpanel eingerichtet.

Mein Problem wurde nun dadurch gelöst, dass die link-local Adresse statt stable-privacy nun eui64 ist. Das hat ja nichts mit der statischen public IP zu tun.

Was mir noch unklar ist, ist warum es mitt der link-local Adresse nach eui64 funktioniert und nach stable-privacy nicht.

Da ich meine statische IPv6 Adresse nach SLAAC aufgebaut (also gemäß der MAC Adresse) frage ich mich auch: was genau hat das Problem nun gelöst? Dass die link-local IP vom Schema her mit der public IP übereinstimmt? Oder dass die link-local nun zu der MAC Adresse passt?

Um das testen zu können müsste ich meine public IP ändern. Das könnte ich zwar machen - allerdings ist die Zuordnung von dieser Adresse zu der Adresse des gerouteten Netzwerks nur über den Support zu ändern.

Da es so wie es jetzt ist funktioniert werde ich das allerdings nicht machen.

Fazit: bei stimmen jetzt public IP, link-local Adresse und MAC überein (nach SLAAC) und damit funzt es nun.

Ja, ich habe die IP auch anders als mit ping getestet. Wie gesagt ich nutze sie für SSH. Bevor ich dieses zusätzliche geroutete Netz hatte war das das einzige Netz.

ens3: wie gesagt: die fe80::... Adresse hat nichts mit der IPv6 auf dem Interface gemeinsam. Aber genauso ist das auch bei meinem PC, der an einer FritzBox hängt. Ich gehe davon aus, dass das "normal" ist. Das liegt daran, dass addr-gen-mode auf "stable-privacy" eingestellt ist. Meines Wissens nach ist das der Defaultwert.

Vom Server aus ist sie auch pingbar:

PING fe80::f429:f8c3:64a:8694%ens3(fe80::f429:f8c3:64a:8694%ens3) 56 data bytes

64 bytes from fe80::f429:f8c3:64a:8694%ens3: icmp_seq=1 ttl=64 time=0.078 ms

64 bytes from fe80::f429:f8c3:64a:8694%ens3: icmp_seq=2 ttl=64 time=0.101 ms

64 bytes from fe80::f429:f8c3:64a:8694%ens3: icmp_seq=3 ttl=64 time=0.077 ms

Aber ich habe nun mal auf ens3 addr-gen-mode=eui64 eingestellt. Nach dem Neustart des Interfaces entspricht die fe80 Adresse damit der nach SLAAC umgerechneten MAC Adresse.

Wenn das jetzt nicht nur Zufall ist dann würde ich sagen: jetzt laufen die Pings tatsächlich durch! Ich habe mehrfach auf stable-privacy zurückgewechselt um sicher zu gehen, dass es tatsächlich daran liegt. Und damit hakt es wieder.

Sollte das weiterhin so stabil laufen wäre das Problem für mich gelöst.

Aber was macht netcup da? Das Thema IPv6 ist hier schon sehr merkwürdig. Zunächst einmal hätte ich erwartet, dass das mitgelieferte IPv6 Netz ausreichend ist und man lediglich einen Proxy NDP (entweder statisch oder halt den ndppd) braucht. Stattdessen muss man ein zusätzliches geroutetes Netz kaufen. Was ist das denn?

Und jetzt das hier: stable-privacy ist die Default Einstellung für IPv6. Darauf dass man auf eui64 wecheln muss, muss man erstmal kommen. Dass mir nicht klar ist, warum stable-privacy hier "unstable" ist brauche ich wohl nicht extra zu erwähnen.

Auf jeden Fall danke für eure Unterstüzung.

Ja, die global scope IP ist auf ens3.

Die fe80:: Adresse hat im hinteren Teil nicht die 64 Bit meiner Host IP. Letztere habe ich gemäß SLAAC nach der MAC Adresse aufgebaut. Die Loal-Link Adresse ist dagegen nicht nach SLAAC aufgebaut. Das ist allerdings auf meinem PC genauso. Die wird wohl automatisch vergeben.

Mag sein, dass es nicht notwendig oder sinnvoll ist accept_ra=2 zu setzen. Ich habe das jetzt auf 0 gesetzt und die VM neu gestartet.

Nun sieht es foldgendermaßen aus:

net.ipv6.conf.all.accept_ra = 0

net.ipv6.conf.default.accept_ra = 0

net.ipv6.conf.ens3.accept_ra = 0

net.ipv6.conf.lo.accept_ra = 1

net.ipv6.conf.podman1.accept_ra = 0

net.ipv6.conf.veth35ad154e.accept_ra = 0

net.ipv6.conf.veth3fb3fe66.accept_ra = 0

net.ipv6.conf.veth4b34798c.accept_ra = 0

net.ipv6.conf.vetha2e16c4e.accept_ra = 0

net.ipv6.conf.vetha71fe744.accept_ra = 0

net.ipv6.conf.vethbe1d18a8.accept_ra = 0

net.ipv6.conf.vethf912c47.accept_ra = 0

Allerdings ändert das nichts am Verhalten.

Ich habe mal getestet die IP vom nicht gerouteten Netz von außen zu pingen (also die IP, die auf ens3 liegt).

Wenn ich diese IP von meinem PC aus anpinge dann funktioniert der ping auf das geroutete Netz auch wieder (das hatte ich ja gestern schon mit pings von drinnen nach draußen getestet).

Man kann also sagen: nur wenn Traffic über das nicht geroutete Netz läuft, funktioniert auch das geroutete Netz. Andernfalls friert das geroutete Netz einfach ein.

So ist das aber nicht gedacht. Das nicht geroutete Netz soll nur dazu verwendet werden, dass der Server per SSH erreichbar ist.

Das geroutete Netz ist für podman und die Container und soll erreichbar sein auch wenn über das nicht geroutete Netz kein Traffic geht.

Ja, ich hatte ens3 eingetragen und testweise auch noch podman1.

Wenn ich das hier ausführe:

sysctl -a | grep 'accept_ra = '

Dann sehe ich

net.ipv6.conf.all.accept_ra = 2

net.ipv6.conf.default.accept_ra = 0

net.ipv6.conf.ens3.accept_ra = 0

net.ipv6.conf.lo.accept_ra = 1

net.ipv6.conf.podman1.accept_ra = 0

net.ipv6.conf.veth9567d854.accept_ra = 1

net.ipv6.conf.vetha94122d.accept_ra = 1

net.ipv6.conf.vethb7c03cd.accept_ra = 1

net.ipv6.conf.vethc1dfe830.accept_ra = 1

net.ipv6.conf.vethc70e0a79.accept_ra = 1

net.ipv6.conf.vetheeef9bc8.accept_ra = 1

net.ipv6.conf.vethfbe7e734.accept_ra = 1

Im Test versuche ich ja das podman1 Interface zu pingen. Da steht accep_ra auf 0 wie in deser Anleitung.

Also erstmal wegen der Netze: so wie du das beschrieben hast ist es auch mir. Die IP rechts vom Pfeil ist die IP meines Servers. Die hate er auch schon bevor ich das neue Netz gekauft habe.

Ich pinge von meinem PC (der wiederum an einer FritzBox hängt) den Server an. Ich habe durch meinen ISP ein /64er IPv6 Netz. Ich pinge also von IPv6 nach IPv6.

Mit tracepath habe ich jetzt auch versucht.

In dem Fall wo es nicht mehr geht ist die letzte IP Adresese wo noch Replies kommen diese hier:

2a03:4000:ff00:1::1

In dem Fall wo es geht kommt direkt danach dann meine IP, die ich anpinge.

Daraus folgt, dass die 2a03:4000:ff00:1::1 immer anpingbar sein müsste. Das scheint auch so zu sein.

Ich kann auch statt Google diese IP anpingen und habe dasselbe Ergebnis.

Allerdings möchte ich, dass ich auch ohne Dauerpings IPv6 zur Verfügung habe.

An der Firewall liegt es nicht. Wenn ich nftables abschalte verhält sich alles genau wie vorher.

Der Server hatte ja schon vor der Anschaffung des Zusatznetzes eine IPv6. Diese hat er auch weiterhin. Von default sehe ich da nichts. Es gibt halt die beiden Netze.

Das neue geroutete Netz habe ich im SCP mit dieser IP verbunden. Das war der Schritt, der nicht ohne den Support wieder rückgängig gemacht werden kann.

Das geroutete Netz nutze ich auf dem Server für podman.

Wie in diesem Forum empfohlen habe ich mir nun ein "routed network" für IPv6 dazu gebucht, damit ich IPv6 ohne NAT nutzen kann.

In meinem Szenario habe ich dieses geroutete Netz genutzt, um meinen Containern statische IPv6 Adressen zu geben.

Wie ich festgestellt habe hakt es aber ständig. Ich kann eine IP von außen ca. 30-40s lang anpingen und dann kommt plötzlich eine Sendepause wo die IP auf einmal nicht mehr erreichbar ist.

Irgendwann geht es plötzlich wieder.

Ich habe zusätzlich auch noch den ndppd installiert obwohl der für geroutete Netze ja eingentlich nicht notwenig ist. Aber auch das hilft nicht.

Diese Tipp hier hat mir auch nicht geholfen:

Zusätzliche IP Adresse konfigurieren – netcup Wiki

Die IPv6 Adresse des Servers selbst ist immer erreichbar.

Nur die IPs, die an dem gerouteten Netz hängen sind davon betroffen.

Ich habe nun folgenden Test gemacht: ich pinge das podman1 Interface meines Servers (das ist eine IP aus dem gerouteten Netz).

Nun kriege ich wie gesagt etwas 30-40 pings durch und dann bleibt alles stehen.

Wenn ich aber auf dem Server einen Dauerping auf die IPv6 des Google DNS setze und laufen lasse dann läuft mein ping weiter.

Das sieht ja nach irgendeinem Timeout Problem aus. Weiß jemand was man da machen kann? Der Dauerping auf Google kann ja wohl nicht die Lösung sein.

Das zusätzliche Netz hatte ich mir gestern gekauft, nachdem ich in deinem Post gelesen habe, dass man die Probleme damit lösen kann.

Damit funktioniert es nun wie es soll. Vielen Dank!

Na das hattest du doch geschrieben:

"Nein, wenn du ein zusätzliches IPv6 Netz buchst, dann brauchst du keinen NDP Proxy mehr. Den braucht man nur fürs mitgelieferte Subnetz."

Dabei hatte ich mich auf das zusätzliche Netz bezogen.

Beim Standardnetz hatte ich keine "anfänglichen Paketverluste" sondern es ging überhaupt nicht.

Du hast wieder Recht: ich habe das Proxy NDP mal rausgenommen und es funktioniert immer noch.

An meinem PC brauche ich das - sonst geht nach kurzer Zeit nichts mehr. Dort habe ich meinen PC an einer FritzBox.

Wieso man das hier nun nicht braucht verstehe ich noch nicht.

Vielleicht ist es so zu verstehen, dass die netcup Infrastruktur gar nichts von meinem Proxy NDP hat, weil sie die Pakete gar nicht an meine VM schickt.

Wenn ich das jetzt richtig verstehe, passiert das nur bei dem gerouteten zusätzlich gekauften Netz.

Wobei ich mich dann frage, warum denn das Standard Netz nicht auch geroutet wird. Möglicherweise deshalb, weil der Kunde initial noch gar keine VM mit einer Gateway IP hat, an die man routen könnte. Im Menü musste ich festlegen, dass das neue Netz an meine VM geroutet wird und dass das auch nur kostenpflichtig durch einen Supportmitarbeiter geändert weden kann.

Ja, wie gesagt für IPv6 Forwarding und dass generell Proxy erlaubt ist habe ich gesorgt:

net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.all.proxy_ndp = 1

Den ndppd verwende ich nicht - ich mache Proxy NDP für jede Adresse einzeln.

Mein Routing arbeitet mit einem /96er Netz, das innerhalb des /64er Netzes liegt. Anders geht es nicht, wenn man nur ein /64er Netz hat.

Was es mit dem "Cache der Infrastruktur" auf sich hat weiß ich nicht. Auf die habe ich ja eh keinen Einfluss.

Eigentlich müsste doch das komplette /64er Netz an meinen Host durchgereicht werden. Oder verstehe ich da etwas falsch?

Dann müsste ich doch zumindest mit tcpdump ankommende Pakete sehen.

Was ich aus dem Post, den du geschickt hast herauslese: ist es richitg, das man ein zusätzliches IPv6 Netz buchen muss, damit Proxy NDP funktioniert?

Aber es sieht so aus, dass du Recht hast: ich habe mir gerade eins gekauft und damit geht es.

Aber das ist ja schon eigenartig. Denn man geht ja eigentlich nicht davon aus, dass das mitgelieferte IPv6 Netz nicht richtig funktioniert.

Ich habe hier mal bei Github ein Ticket angelegt:

https://github.com/containers/podman/issues/14407

Allerdings zweifel ich gerade daran, dass das überhaupt was mit podman zu tun hat.

IPv6 Adressen, die ich als Neighbor Proxy auf das externe Netzwerkinterface lege, kann ich trotzdem von außen nicht erreichen.

Ein tcpdump zeigt nichts, was reinkommt.

Mache ich da etwas falsch oder ist das ein spezielles Problem bei netcup?

Bedeutet das, dass es sowas wie ein richtiges Online Backup gar nicht gibt? Von anderen Anbietern kenne ich das.

Wenn ich mir ein externes Backup auf die HDD meines PCs ziehe ist dieses weg, wenn die HDD defekt ist.

Ich habe mir jetzt die relevanten Daten herunter geladen - daraus kann ich den aktuellen Zustand wieder aufbauen. Das OS selbst braucht ja eigentlich kein Backup.

Ich habe mir gerade einen vServer (KVM) eingerichtet und anschließend einen ersten Snapshot erstellt.

Nun bekomme ich folgende Meldung unter "SCP - Media":

"You have snapshots, these snapshots will be deleted while the storage optimization is in action. Therefore an intensive storage optimization is necessary. This can take up to 10 minutes."

Daraufhin habe ich die Optimierung durchführen lassen und den Snapshot erneut erstellt. Wenn ich das tue ersceheint diese Meldung erneut.

Ich bin davon ausgegangen, dass ich zumindest einen solchen Offline-Snapshot als Backup halten darf. Mache ich hier was falsch?