IPv6 bei Hetzner nutzen?

SolarCatcher

Well-Known Member
Ich habe nun einen Dedizierten Server bei Hetzner, IPv4 klappt tadellos, aber ich bekomme IPv6 nicht zum Laufen.

In /etc/rc.conf habe ich folgendes eingetragen:
Code:
ifconfig_igb0_ipv6="inet6 <meine_ipv6_adresse> prefixlen 64"
ipv6_defaultrouter="fe80::1"

Ifconfig sieht auch soweit gut aus. Aber alle Tests (ping6, traceroute6, fetch -6...) schlagen fehl. Was fehlt mir hier noch?
 
Also meine komplette Konfig hab ich aus der Doku mal genommen und sieht so aus:

Code:
ifconfig_re0="inet <ip4> netmask <netmask> broadcast <bcast>"
gateway_if="re0"
gateway_ip="<gwip>"
static_routes="gateway default"
route_gateway="-host $gateway_ip -interface $gateway_if"
route_default="default $gateway_ip"
ipv6_default_interface="re0"
ifconfig_re0_ipv6="<ipv6addr>::/64"
ipv6_defaultrouter="fe80::1%re0"
 
Vielen Dank @-Nuke- ! Dass man das Interface an die defaultrouter-Adresse anhängen muss, war es, was den Unterschied ausmachte. So klappt es also auch bei mir:
Code:
ipv6_defaultrouter="fe80::1%igb0"

@mogbo Auch Dir vielen Dank, aber das hatte ich schon (mehrfach) probiert - das bietet Hetzner offenbar nicht an. Man muss das schon fix konfigurieren.
 
static_routes="gateway default"
route_gateway="-host $gateway_ip -interface $gateway_if"
route_default="default $gateway_ip"

Nur zur Info: es ist nicht mehr notwendig, bei Nutzung einer Interface-Route auf das GW die defaultroute in static_routes zu setzen. Du kannst stattdessen sowas machen
Code:
defaultrouter="ip.adr.es.se"
static_routes="gw"
route_gw="$defaultrouter -interface foo"

Früher (vor 10-RELEASE oder so) wurde zuerst die defaultroute gesetzt, dann die statischen. Nun wird es umgekehrt gemacht, daher geht es ein wenig übersichtlicher mit Hilfe der normalen Schlüsselwörter.

Rob
 
OK, danke für die Info. Solange es nicht schadet, lasse ich das auch erst mal so. Bei FreeBSD ändern sich die Konfigurationen eh alle Nase lang.
 
Bei mir (11.1) funktioniert es so nicht:
Code:
defaultrouter="aa.bb.cc.dd"
ipv6_defaultrouter="fe80::1%vtnet0"
Aber dafür so:
Code:
ipv6_defaultrouter="fe80::1%vtnet0"
defaultrouter="aa.bb.cc.dd"
Im ersten Fall funktioniert die IPv6 Route einfach nicht oder der Rechner verliert diese nach einigen Minuten.
 
Die Reihenfolge der Angaben sollte irrelevant sein, beide Variablen werden im Skript /etc/rc.d/routing genutzt. Das eigentlich Problem muss woanders liegen.

Fragt sich, wo?! Alleine diese Änderung entscheidet über eine funktionierende IPv6 Route.

Werden da vielleicht Router Advertisements beachtet, obwohl eine statische Adresse konfiguriert ist.

Nein, ich habe net.inet6.ip6.accept_rtadv=0 gesetzt. Interessanterweise lässt sich fe80::1%vtnet0 immer erfolgreich anpingen, auch wenn die Route nicht funktioniert. Ich habe testweise auch mal rtadv=1 gesetzt, was aber keinen Unterschied macht. Über den "Trick" mit der Reihenfolge bin ich in einem US-Forum gestolpert. Nachdem ich es erst nicht glauben wollte, hat mich irgendwann die Verzweiflung gepackt. Immerhin liefer der Server bis Ende Juli auch mit der anderen Reihenfolge (auf 11.0). Nach einem Reboot ohne Konfigurationsänderung ist dann das seltsame Verhalten aufgetreten. Ich hatte dann ein Upgrade auf 11.1 ohne Erfolg gemacht und dachte schon daran, den Server zurückzugeben.
 
Hallo @ed1949. Ich hab das gleiche Problem mit der Default Route fe80::1. Ich habe deinen Post mit dem Vertauschen der Routeneinstellungen gefunden. Weil ich hier mit dem Hoster verzweifelt war, habe ich das mal stumpf ausprobiert. Auf den ersten Blick klappt es!

Sorry, dass ich den Thread raushole, aber es scheint auch auf 12.2-RELEASE-p2 zu funktionieren. Ich wollte mich auch bedanken.

Ist da schon ein Bug dazu gemeldet worden?
 
Ausführliche Tests haben gezeigt, dass Paketverluste nach dem Tausch der Konfigurationseinstellungen leider immer noch auftreten (28% Pakete eingehend gehen verloren). Traceroute6 auf Google vom Host aus spinnt total. Bin ratlos.

Also: Kommando zurück. Wahrscheinlich war der Effekt wegen des Reboots, den ich gemacht habe, nur temporärer Natur.
 
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.
 
Hatte das Problem bei Netcup übrigens auch und dank eurem hilfreichen Forumspost auch auf dem gleichen Weg lösen können :)


Vielen Dank dafür.
 
IPv6 läuft auf meinem Hetznerserver mit OpenBSD seit Jahren problemlos mit statischer Konfiguration. Nach einer Netzwerk Wartung war deren NDP switchseitig murksig, was aber durch den Support durch einen flush des Caches gelöst wurde.
 
Ich habe wieder mal stundenlang für Netcup debugged. Es gibt meiner Ansicht nach tatsächlich Probleme mit der Neighbor Discovery aber nur bei einem von 3 Routern, deswegen fällt das sporadisch aus, wenn man den einen Router bekommt.

Mein Host antwortet mit einer Solicitation und der eine Router kriegt sie nicht mit und fragt nochmal, dann nochmal und .... Sendepause (kein Paket kommt mehr zu mir) bis ein anderer von den 2 übrigen Routern übernimmt.

Ich habe meine Erkenntnisse dem Support mitgeteilt. Ich glaube ich bin auch schon bis zum dritten Level durch oder wieder zurück zum 1sten, keine Ahnung. ;)
 
Ich hatte auch lange Probleme mit IPv6 bei Netcup und bin schlussendlich dann zu Hetzner gewechselt.
Mit dieser Konfiguration habe ich unter 12.2-RELEASE keinerlei Mucken mehr.
Code:
# IPv6
ipv6_defaultrouter="fe80::1%em0"
ifconfig_em0_ipv6="inet6 2a01:xx:xx:xx::foo/64"
 
Zurück
Oben