Verschiedene Netcup Server erreichen sich nicht per IPv6 (IPv6 Routing-Probleme innerhalb Netcup?) [gelöst]

Hallo zusammen, ich hab gerade folgendes Problem:

Ich habe – unter zwei verschiedenen Accounts (einmal Privat, einmal für einen Verein) – je einen Server bei Netcup

- einen "Root-Server M SSD v6 12M"

- einen "VPS 100 G7 SE 12M"

Beide haben mehrere IPv6 Subnetze zugewiesen und mehrere statische IPv6-Adressen konfiguriert.

Beide sind von außen über IPv6 problemlos erreichbar und beide erreichen problemlos IPv6-Adressen außerhalb von Netcup.

Das Problem ist: Die beiden Server erreichen sich gegenseitig nicht über IPv6.

Ist das ein IPv6-Routing innerhalb von Netcup? Muss ich für Routing innerhalb von Netcup irgendetwas gesondert einstellen? Ich habe die Einrichtung wie in https://helpcenter.netcup.com/de/wiki/server/ip/ beschrieben vorgenommen.

Zitat von frank_m

Zeig das doch mal anhand von Traces auf die jeweiligen Adressen beim Zugriff von außen und beim Zugriff zwischen den VServern.

Kommen die Adressen der beiden Server aus dem gleichen Prefix? Passen die Prefix-Längen der Routen auf deinen Servern? Du schreibst von mehreren Subnetzen. Das Routing dieser zusätzlichen Netze auf die Standard-EUI-64 Adresse des Servers funktioniert einwandfrei?

Hmm, ne, das sollten verschiedene Prefixe sein, oder nicht?

(Ich hab die IP-Adressen ganz leicht obfuscated.)

@a:~$ ip -6 addr
1: lo: […]
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2a03:4000:20:2c3::1/64 scope global
       valid_lft forever preferred_lft forever
    inet6 2a03:4000:6:b06c::1/32 scope global
       valid_lft forever preferred_lft forever
    […]

@a:~$ ip -6 route
2a03:4000:6:b06c::/64 dev eth0 proto kernel metric 256 pref medium
2a03:4000:20:2c3::/64 dev eth0 proto kernel metric 256 pref medium
2a03:4000::/32 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::1 dev eth0 metric 1024 onlink pref medium

@b:~$ ip -6 addr
1: lo: […]
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2a03:4000:20:30d::1/64 scope global
       valid_lft forever preferred_lft forever
    inet6 2a03:4000:19:87::1/64 scope global
       valid_lft forever preferred_lft forever
    […]

@b:~$ ip -6 route
2a03:4000:19:87::/64 dev eth0 proto kernel metric 256 pref medium
2a03:4000:20:30d::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::1 dev eth0 metric 1024 onlink pref medium

Ich stelle gerade fest, dass der Server a noch eine Route zusätzliche eingetragen hat: 2a03:4000::/32 dev eth0 proto kernel metric 256 pref medium, aber da eh alles über eth0 geroutet wird, sollte das keinen Unterschied machen, oder?

Meinst du das mit Traces?

@b:~$ traceroute 2a03:4000:20:2c3::1
traceroute to 2a03:4000:20:2c3::1 (2a03:4000:20:2c3::1), 30 hops max, 80 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *^C

Ahhh, vollkommen richtig! Das Problem sitzt mal wieder vor der Tastatur!

Ich habe das Subnetz auf /64 korrigiert, und jetzt funktioniert alles!

Vielen Dank!

Zitat von frank_m

Das ist immer noch falsch. Du hast 2a03:4000::/64 auf deinen Systemen ja nicht in Benutzung. Damit wirst du Systeme aus diesem konkreten Prefix nicht erreichen. Die Route muss komplett weg, und die Prefix-Länge der Adresse muss auf /64 geändert werden.

Daneben sieht man die EUI-64 Adresse nicht, die fürs Routing der zusätzlichen Subnetze erforderlich ist. Wenn du sie nicht weg-editiert hast, musst du noch mal ran an die Konfiguration.

Ah, ja, ich hatte mich da missverständlich ausgedrückt.

Ich hatte im Gegensatz zu https://helpcenter.netcup.com/de/wiki/server/ip/

iface eth0 inet6 static address 2a03:4000:2:11c5::1 netmask 32 gateway fe80::1

statt

iface eth0 inet6 static address 2a03:4000:2:11c5::1 netmask 64 gateway fe80::1

in meiner /etc/network/interfaces. Dadurch ist die falsche Route da (automatisch) gelandet. Nach Korrektur der Netmask-Angabe, ist die zusäztliche Route wieder entfernt worden.

kA ob die Konfigurationsanleitung früher mal anders ausgesehen hat, oder ich damals einfach was falsch gemacht habe (ist jetzt auch schon fast 10 Jahre her). Ich bin froh, dass ich das mit deiner Hilfe fixen konnte!