Ich hatte im Herbst - das war so um Oktober herum - mit einem Bekannten über mehrere Tage ein sehr ähnliches Problem bei Netcup debuggt. Am Ende auch erfolglos. Das Ergebnis hat mein Bekannter hier zusammengefasst:
https://forum.netcup.de/administrat...150960-freebsd-12-1-probleme-ipv6/#post150960
Bei Hetzner scheint es das gleiche oder ein ähnliches "Problem" zu sein. Nun sind diese Dinge immer etwas wackelig zu debuggen, wenn man nur einen Host im Netz hat und keinerlei weitere Informationen über der Router-Setup und so weiter besitzt. Dazu kam, dass bei Netcup der Support mit Detailfragen restlos überfordert war. Vielleicht ist das bei Hetzner bei besser.
Ich würde mir im ersten Schritt erst einmal den gesamten Verkehr mit
tcpdump mitschneiden. Gerne 15 Minuten und so. Das Ergebnis dann mit
wireshark auseinanderpulen. Außerdem den NDP-Cache mit
ndp -a im Auge behalten. Und prüfen, was passiert, wenn man gezielt Einträge aus dem NDP-Cache löscht. Bei Netcup ergaben sich da zwei Erkenntnisse. natürlich weiß ich nicht, ob es so auf Hetzner übertragbar ist:
- Das Routing ist völlig wirr. Aus Sicht des Server egress läuft alles über fe80::1%$device. Aus Sicht des Servers ingress kommen die Pakete aber von mehreren anderen IPs, die teilweise nicht einmal im eigenen Subnetz liegen, stattdessen aus übergeordneten Netzen. Das egress ungleich ingress ist, ist schon mal ein schlechtes Zeichen, aber mag man noch akzeptieren. Das die Router teilweise in übergeordneten Netzen liegen, hat das Potential für Probleme.
- Neighbor Solicitation von Hosts außerhalb des eigenen physischen Segments, bzw. Hosts die nicht auf dem eigenen Link liegen. Das ist äußert problematisch, denn es reißt 12 Jahre später https://www.freebsd.org/security/advisories/FreeBSD-SA-08:10.nd6.asc wieder auf. Ein Hoster, der seinen Kunden sowas zumutet, ist in meinen Augen selbst im Billigsegment inakzeptabel.
net.inet6.icmp6.nd6_onlink_ns_rfc4861=1 hilft, mit den in der SA genannten Konsequenzen.
Warum die ersten Paketen bei Erstkontakt zu einem Host verloren gehen, es sich dann fängt und einige Zeit stabil läuft, war nicht herauszufinden. Das hätte mehr Koorperation gebraucht, als der Support zu leisten in der Lage war. Ich vermute, dass es eine Mischung aus dem wirren Routing und kaputtem NDP ist. Sind die NDP-Caches der eigenen Maschine und der Router erstmal gefüllt, geht es. Andernfalls verkackt es mit FreeBSD (und auch OpenBSD, was aber nicht verwundert, weil beide Systeme letztendlich Nachfolger des KAME-Stacks nutzen), bis NDP irgendwann dann doch zu Rande gekommen ist. Mit Linux klappt es mehr aus Glück, als mit Verstand.
Man muss Netcup aber zu Gute halten, dass sie das Problem letztendlich durch Zuweisen eines anderen Netz gelöst haben. Dieses Netz routet egress gleich ingress und hat erkennbaren NDP-Probleme. Das ist mehr, als man von so manchem Hoster im Billigsegment erwarten kann.
