Was ist den das "korrekte" Gateway?
fe80::1 wie im SCP angegeben funktioniert jedenfalls nicht - weder bei der Netcup Standard Installation noch bei einem frisch installierten Debian 13 von DVD
Auf allen Dual HOmed Systemen die ich habe ist es auch fe80::1 als Gateway und die IP antwortet auch auf pings.
Ich vermute in der Automation was verk*ckt, oder gibts einen wo einer der IPv6 Only Server funktioniert?
"echtes Internet" bzw. "echte Adressen" sind keine RFC-Adressen...
Die Adresse ist beim Booten der images ja da. Trotzdem reagiert nichts.
Rescue System ist halt nochmal was anderes, da gehört der Screenshot zu.
Mit aktiviertem vLAN und tcpdump sehe ich dann ICMPv6 86 Neighbor Solicitation for fe80::1 from ba:3e:a6:16:84:50 und komische v4 ARP requests für ein spezielles Netz.
für alle interessierten, ich glaube ich muss nix blurren.
Rescue-System, ens3 ist Internet, ens4 ist vLAN.
Habe einen VPS OsterEi 2018 und einen Pico G11s und evtl. einen Nano G12s.
Welche Hardware haben diese denn im Hintergrund? Kann man das irgendwo nachsehen?
Da steht vermutlich noch SAS in der Plattenbereitstellung des CCP. Ich gehe nicht davon aus, dass sie für dich noch rotierende Scheibe vorhalten.
Am Ende ist ja die Frage, gerade bei den VPS mehr als bei den RS: behalte ich den Vertrag mit den entsprechenden Konditionen, die Hardware wird schon irgendwie produziert.
Ich hab noch nen "VPS 200 G8 10Prozent Rabatt" bei dem ich auch nicht sicher bin, was ich tun will.
Vor allem würde mich interessieren: Hat das Rescue System vielleicht auch eine ip4?
Ja, hat es, wie wir schon gefrotzelt haben: 169.254.115.253 
Ansonsten gehe ich davon aus, dass sie den Rollout an den Kunden nur unzureichend getestet haben.
Zum rescue-System:
dhcpcd im rescue-System kriegt zwar was zurück, aber kommunikation geht trotzdem keine.
grml-network scheint nicht so wirklich ipv6 geignet zu sein.
Support hat es auch schon mit der Standard-Prozedure "Rescue-System" probiert.
Ich habe den Nano G11 ipv6-only bestellt und im Auslieferungszustand kann ich die angegeben und konfigurierte IPv6 Adresse nicht erreichen.
Verschiedene Versuche, das Problem zu analysieren und zu testen oder eine korrektere Config dynamisch zu setzen, haben zu keinem Fortschritt gefühlt.
Dass ich mein Gateway fe80::1 nicht erreichen kann (im Gegensatz zu den Dual Stack-Systemen die ich bei Netcup schon betreibe) lässt mich glauben, dass das Problem ausserhalb meines Einflussbereiches liegt.
Und ja, netcup hat im ausgelieferten Image sogar IPv6 nameserver eingestellt.
Und bevor jemand fragt: der nano G11 hat keine Firewall davor.
Ich suche halt denjenigen, gerne auch diejenige, die mir sagt, sie hat auch einen ipv6 Only Server bestellt und der hat einfach erst mal funktioniert.
route -6n sagt "Command not found..."
ip -6 r s sagt
default via fe80::1 dev eth0
so wie alle anderen IPv6 Systeme (allerdings immer Dual-Stack), die ich bei netcup laufen habe. Und dort antwortet das Default Gateway auch tapfer auf die pings.
Hm, so viel Tickets hab ich ja noch nicht aufgemacht bei Netcup.
Hab mich also extra in CCP einloggt und dort dann dann den Kontakt ausgewählt und das Formular ausgefüllt.
In der Mail kriege ich dann unter anderem folgenden Hinweis:
Kennen Sie schon unser Kontaktformular? Gerne können Sie Ihre nächste Anfrage darüber versenden, damit wir Ihnen noch schneller und effizienter weiterhelfen können: https://helpcenter.netcup.com/de/support
D.h. wenn ich das Ticket im public-Bereich aufmache, helfen sie mir schneller? Ich muss ich gar nicht mit 2FA und allem im CCP anmelden um schnell Support zu bekommen?
Weil eigentlich gibts im angegebenen Kontaktformular keinen Abschnitt "Support", nur "Störung" ....
Hi
hab mir gerade einen VPS nano G11s 6M NUE mit ipv6 only rausgelassen.
Erste Herausforderung:
ping fe80::1%eth0
PING fe80::1%eth0 (fe80::1%eth0) 56 data bytes
From fe80::b83e:a6ff:fe16:8450%eth0 icmp_seq=1 Destination unreachable: Address unreachable
Geht auf allen anderen Dual-Stack-Systemen, mein neu geimagtes Alma 10 will das auf diesem System nicht.
Jemand bessere Erfahungen mit den neuen IPv6-Only systemen? evtl andere Distribution?
Sie müssen wohl die IPv4-Konnektivität noch rausfieseln.
Du meinst ich kriege 'ne ip in 169.254.x.x und den Rest macht die Firewall? Dafür haben sie die wirklich implementiert?
Hat schon jemand einen VPS Lite geordert und könnte einen yabs posten? Mich interessiert sehr, wie der CPU und IO technisch dasteht...
Bestellt habe ich, geliefert wurde noch nicht.
VPS Lite 1 G12s 6M |mindestens 6 Monat(e) |alle 6 Monat(e) |0,00 Euro |3,45 Euro
IPv6 Connectivity |mindestens 6 Monat(e) |alle 6 Monat(e) |0,00 Euro |0,00 Euro
Keine Ahnung was sie noch prüfen müssen ... oder sie würfeln immer noch am Standort
Das ist ja nur ein Problem der Vorratsdatenspeicherung, darum steht da in den Regelungen seit einigen Jahren immer IP/Port-Kombination und nicht mehr nur IP-Adresse drinnen.
Und für die Werbewirtschaft haben die Carrier sich zusammen getan und utiq aufgebaut, das trackt zuverlässiger.
Mit der richtigen Architektur sind die IPv6-Only-Systeme voll gut.
Aktuell habe ich einige Systeme wie Datenbanken auf denen die offizielle IPv4 komplett geblockt wird (ok, ssh ist gegen 2 vertrauenswürdige IP offen). Alles andere geht über das vLAN mir RFC-Adressen direkt zu den Webservern und zu einem Jumphost mit Wireguard-Gateway.
Komplett ohne externe IP (nur vLAN) bräuchte ich auf dem Jumphost ein Masquerading mit routing oder einen Proxy um beispielsweise Updates zu installieren. In der IPv6-Only Variante gehe ich davon aus, dass mir dieser Schritt erspart bleibt, weil die Linux-Update-Mirrors im Hochschulnetz IPv6 im Griff haben.
Habe mir heute mal den ersten Lite IPv6 Only bestellt, um das zu validieren, der wurde aber noch nicht ausgeliefert. Vermutlich würfeln sie noch den Standort aus ...
Die Source-Ports sind jetzt alle Sternchen? In der Theorie sollte das jetzt passen.
Hattest du den Setup schon mal ohne Firewall getestet? Ansonsten gibts da manigfaltige Optionen was noch so schief gehen kann...
picos sind schon lange nicht mehr erhältlich. schon mal angeklickt? da steht dann ausverkauft. wie jetzt auch bei den nanos. und mikros sind auch verschwunden.
When I wrote this around 6 hours ago, the "new priced" picos and nanos were still available, but the micros disappeared when the Lites came out.
Ja
Wenn du filtern willst, dann beispielsweise Quell-Adressen, aber nicht Quell-Ports. Bei HTTP(S) willst du ja, dass die ganze Welt deinen Webserver erreicht, jeder auf der Welt soll dir Mails schicken können.
Beim Lesen der Mails wirds schwieriger, aber die NC-Firewall kann meines Wissens keine Geo-Locations blocken (das verringert auch nur das Rauschen auf den Ports). Aber auch du bist im Urlaub, im Roaming, da jedesmal nachzujustieren ist auch aufwändig.
Ich würde beispielsweise die Zielports 110 und 143 schliessen, es ist nicht sinnvoll, unverschlüsselt Passworte durch (fremde) WLANs und das Internet zu schicken. So sparst du dir das Abschalten der Ports auf dem Server.
ja, die Zugriffe kommen von den sog. ephemeral ports, irgendwas zwischen 32000 und 65535.
Ausnahmen sind teilweise dns, snmp, ntp-server-server und syslog.
Ich hab mit der NC-Firewall nie was gemacht, aber die Source-Ports sind in der Regel nicht identisch mit den Ziel-Ports. Es gibt ein paar Ausnahmen, aber nicht im Mail-Umfeld. Nimm die Definition der Quell-Ports mal raus und ersetzte sie durch den *.
