Schlagwort: Sysadmin (Seite 8 von 13)

Man stolpert irgendwann über diese Meldung im Kernel-Log:

rt6_redirect: source isn't a valid nexthop for redirect target

Gerne im Zusammenhang mit IPv6, gerne dann, wenn man glaubt, eigentlich alles richtig gemacht zu haben. Routing stimmt. Neighbors sehen gut aus. Und trotzdem meckert der Kernel.

Die Kurzfassung: Der Linux-Kernel hat ein ICMPv6 Redirect bekommen und lehnt es ab, weil der vorgeschlagene Next Hop aus seiner Sicht kein gültiger First Hop ist.

Worum geht es überhaupt?

ICMPv6 Redirects (Typ 137) sind Teil von Neighbor Discovery. Ein Router sagt damit zu einem Host sinngemäß:

„Für dieses Ziel gibt es einen besseren ersten Hop als mich.“

Wichtig: erster Hop. Nicht irgendein Router irgendwo, sondern ein direkt erreichbarer Nachbar auf dem Link.

Ein Redirect enthält deshalb zwei zentrale Informationen:

• das Target (Zieladresse, für die das Redirect gilt)
• den Better Next Hop

Und jetzt kommt der Teil, den viele Implementierungen (und Admins) gerne unterschätzen:
Der Host muss diesem Vorschlag nicht glauben.

Was Linux hier tatsächlich prüft

Linux ist bei Redirects ziemlich streng. Zu Recht. Redirects sind ein beliebtes Einfallstor für Unsinn und Angriffe.

Bevor der Kernel ein Redirect akzeptiert, prüft er u. a.:

• stammt das Redirect von einem Router, den ich bereits als Router kenne?
• liegt der vorgeschlagene Next Hop auf demselben Link?
• ist dieser Next Hop als Neighbor bekannt bzw. grundsätzlich auflösbar?
• passt das Ganze zur bestehenden Routing-Entscheidung?

Und genau hier schlägt diese Logmeldung zu.

Der Kernel schaut auf den Better Next Hop im Redirect und stellt fest:

„Diese Adresse kann für dieses Ziel kein gültiger Next Hop sein.“

Dann wird das Redirect verworfen. Keine neue Route. Kein Update. Nur diese Meldung.

Der Klassiker: Global statt Link-Local

In der Praxis sieht man das oft in Setups, in denen Router ihre Default-Route oder interne Routen nicht sauber über Link-Local-Adressen aufbauen.

Beispiel (vereinfacht):

default via 2001:db8:1::1 dev eth0

Sieht harmlos aus. Funktioniert auch meistens. Aber:
IPv6 erwartet, dass Router auf einem Link über ihre Link-Local-Adresse angesprochen werden.

Korrekt wäre also eher:

default via fe80::1 dev eth0

Was passiert nun?

Der Router verschickt ein Redirect und trägt als „Better Next Hop“ seine globale Adresse ein (z. B. 2001:db8:1::1).
Der Host bekommt das Redirect, prüft es – und sagt:

„Moment. Dieser Next Hop ist kein gültiger direkt erreichbarer Neighbor für dieses Ziel.“

Und genau dann landet diese Meldung im Log.

Wichtig:
Das Problem ist nicht primär, dass die Adresse global ist.
Das Problem ist, dass der Kernel den vorgeschlagenen Next Hop nicht als legitimen First Hop auf diesem Link akzeptiert.

Link-Local ist der Normalfall. Alles andere muss extrem gut begründet sein – und ist es fast nie.

Ein Blick auf die Nachbartabelle hilft

Wenn man wissen will, warum der Kernel das Redirect ablehnt, lohnt sich ein Blick in die Neighbor-Daten:

ip -6 neigh show

Oder gezielter:

ip -6 route get 2001:db8:dead:beef::1

Wenn der vorgeschlagene Next Hop dort nicht als sinnvoller Neighbor auftaucht, ist die Sache im Prinzip entschieden.
Kein Neighbor → kein gültiger Next Hop → Redirect wird verworfen.

Das Redirect live mitschneiden

Wenn man genau wissen will, ob der Router wirklich ein Redirect schickt und was er als Next Hop vorschlägt, hilft tcpdump. ICMPv6 Typ 137 ist das Redirect:

tcpdump -n -i eth0 'icmp6 and ip6[40] == 137'

Im Paket sieht man den Router als Absender, das Target (Ziel, für das der Hinweis gilt) und den Better Next Hop. Passt der Next Hop nicht zu einem gültigen Neighbor auf dem Link, ist klar warum der Kernel ablehnt.

Ebenfalls nützlich: ob der Host Redirects überhaupt annehmen will.

sysctl net.ipv6.conf.all.accept_redirects
sysctl net.ipv6.conf.eth0.accept_redirects

Default ist 1 auf einem Host, 0 auf einem Router. Zusätzlich greift secure_redirects (Default 1): nur Redirects von bereits bekannten Gateways werden überhaupt akzeptiert.

Default-Route mit Link-Local als Next Hop

Wer die Route selbst setzt (statische Konfiguration ohne RA), sollte Link-Local nehmen. Link-Local ist pro Interface nicht eindeutig, der Eintrag braucht also immer ein dev:

ip -6 route add default via fe80::1 dev eth0

Persistenz hängt vom System ab. systemd-networkd in /etc/systemd/network/*.network unter [Route] Gateway=fe80::1, netplan in /etc/netplan/*.yaml, die klassische /etc/network/interfaces kennt post-up ip -6 route .... Wichtig: das Interface muss im Eintrag stehen.

Mit Link-Local als Next Hop verschwindet die rt6_redirect-Meldung in der Regel. Der Kernel hat einen gültigen First Hop als Neighbor, und ein Redirect desselben Routers passt dann sauber ins Modell.

Oder: Redirects abschalten

Auf Servern in kontrollierten Hosting-Umgebungen (Hetzner, Netcup, Cloud-VPCs) ist das Routing sauber vorgegeben, und der Provider-Router hat keinen besseren Next Hop anzubieten. Dann sind ICMPv6-Redirects nur Rauschen im Log:

sysctl -w net.ipv6.conf.all.accept_redirects=0
sysctl -w net.ipv6.conf.default.accept_redirects=0

Persistent in /etc/sysctl.d/99-ipv6.conf. Nachteil: kennt der Router tatsächlich einen legitimen besseren Weg, bleibt der Host trotzdem bei seiner existierenden Route. Im Rechenzentrum mit einer einzigen Default-Route ist das genau richtig, in einem verzweigten Firmennetz mit mehreren Uplinks eher nicht.

Warum das kein Bug ist

Die Meldung klingt erstmal nach kaputtem Routing. Ist es aber meistens nicht.

Im Gegenteil:
Der Kernel verhält sich exakt so, wie es das Protokoll vorsieht. Redirects sind Hinweise, keine Befehle. Und Linux nimmt diese Hinweise nur an, wenn sie sauber in das bestehende Neighbor- und Routing-Modell passen.

Das schützt unter anderem vor:

• falschen Router-Konfigurationen
• kaputten RA-Setups
• Bridge-/VM-Konstrukten mit „kreativem“ IPv6
• trivialen Redirect-Spoofing-Angriffen

Update 2026: was heute anders ist

In modernen Setups begegnet einem die Meldung seltener. Nicht weil das Protokoll sich geändert hätte, sondern weil die Umgebung drumherum sauberer geworden ist:

• Enterprise-Switches mit RA Guard und ND Inspection filtern unerwünschte RAs und Redirects bereits auf Layer 2 heraus. Cisco, Juniper und andere haben das seit Jahren im Portfolio.
• Cloud-Umgebungen (AWS VPC, Hetzner Cloud, Azure) liefern ein sauber vorgegebenes Default-Gateway aus, in der Regel ein Link-Local-Hop. Redirects tauchen praktisch nie auf.
• Home-Router (FritzBox, Unifi, OpenWrt) machen es per Default richtig.
• SEND/CGA (RFC 3971) hätte kryptografisch signierte Neighbor Discovery gebracht und Redirect-Spoofing strukturell verhindert. Die Adoption ist praktisch bei null geblieben. Tot.

Übrig bleibt die Meldung heute fast nur in selbstgebauten VM- und Container-Setups, in denen Host- und Gast-Routing nicht sauber zusammenpassen, oder wenn in statischer Konfiguration aus Gewohnheit eine globale Adresse als Next Hop gesetzt wird.

Fazit

Die Meldung

rt6_redirect: source isn't a valid nexthop for redirect target

bedeutet nicht „IPv6 kaputt“.
Sie bedeutet: Ein Router hat ein Redirect geschickt, das aus Sicht des Hosts keinen gültigen Next Hop beschreibt.

In der Praxis ist das fast immer ein Hinweis auf:

• Default- oder interne Routen ohne Link-Local-Next-Hop (siehe auch IPv6 ULA und Adresspriorisierung)
• Router, die globale Adressen in Redirects verwenden
• Setups, in denen Neighbor Discovery und Routing nicht sauber zusammenpassen

Oder anders gesagt:
Der Kernel ist hier nicht pingelig. Er ist vorsichtig. Und das ist gut so.

Siehe auch: IPv6 Grundlagen. Zum Nachlesen: RFC 4861 §8 (Redirect-Handling bei Hosts) und RFC 6980 (fragmentiertes Neighbor Discovery ist verboten — ein harter Security-Fix für ND-Spoofing).

Fragen? Einfach melden.