IPv6-Adresse ändert sich ständig, Portfreigabe greift nicht mehr
Server mal per IPv6 erreichbar, mal nicht? Privacy Extensions vergeben temporäre Adressen. Für Server gehören sie aus, die stabile Adresse bleibt.
Aufwand:
ca. 30 Min.
Voraussetzung:
Terminal- oder Konsolenzugriff auf dem Server, Zugang zur Router-Oberfläche, Root- beziehungsweise Administrator-Rechte
Gilt für:
Linux mit sysctl, Windows 10 und 11, Router mit IPv6-Firewall
Das Symptom
Der Dienst im eigenen Netz war per IPv6 erreichbar – gestern noch, zuverlässig,
mit sauber gesetzter Freigabe im Router. Heute läuft die Verbindung ins Leere,
und morgen geht sie wieder. Auf dem Server selbst ist alles in Ordnung: Der
Prozess lauscht, das Log ist leer, die lokale Verbindung klappt. Nur von außen
ist der Rechner mal da und mal weg, ohne dass jemand etwas geändert hätte.
Die „Layer 8“-Wahrheit
Niemand hat etwas geändert – das Gerät ändert sich selbst, und das ist so
gewollt. IPv6-Hosts tragen mehrere globale Adressen gleichzeitig: eine stabile,
aus dem Präfix des Routers gebildete, und dazu temporäre Adressen nach RFC 8981.
Die temporären existieren aus einem guten Grund. Ohne sie bliebe der hintere Teil
der Adresse über Netze und Jahre hinweg gleich und wäre ein bequemes Merkmal, um
ein Gerät wiederzuerkennen. Deshalb werden sie regelmäßig ausgetauscht; der RFC
nennt als Standardwerte in Abschnitt 3.8 zwei Tage Gültigkeit und einen Tag
bevorzugte Nutzung, Linux setzt in der Praxis sieben Tage beziehungsweise einen
Tag an. Der Fehler entsteht dort, wo diese Datenschutzmechanik auf eine
Server-Rolle trifft: Die Firewall-Regel wurde einmal auf die Adresse gesetzt, die
gerade in der Ausgabe stand – und das war die temporäre. Sie zeigt seitdem auf
eine Adresse, die das Gerät nach Ablauf der Frist gar nicht mehr benutzt. Die
Lösung ist keine Bastelei, sondern eine Rollenentscheidung: Was erreichbar sein
soll, bekommt eine stabile Adresse und keine temporären mehr; was nur ins Netz
hinausgeht – Notebook, Telefon, Tablet – behält die Privacy Extensions, weil sie
dort genau das tun, wofür sie erfunden wurden. Zwei Sätze Konfiguration, und der
Spuk hat einen Namen statt eines Gespensts.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Die Adressen des Servers auseinanderhalten
Zuerst nachsehen, welche IPv6-Adressen das Interface wirklich trägt. Temporäre Adressen sind in der Ausgabe als solche markiert und haben typischerweise deutlich kürzere Restlaufzeiten als die stabile Adresse. Genau der Unterschied zwischen beiden ist der ganze Fehler.
ip -6 addr show scope global
ip -6 addr show scope global temporary
2.
Prüfen, ob Privacy Extensions aktiv sind
Der Kernel dokumentiert für use_tempaddr die Werte 0 (Privacy Extensions aus), 1 (an, aber öffentliche Adressen bevorzugt) und 2 (an, temporäre Adressen bevorzugt). Steht dort 2, benutzt der Host für ausgehenden Verkehr die wechselnde Adresse – und deine Freigabe passt spätestens beim nächsten Wechsel nicht mehr.
Temporäre Adressen auf dem Server dauerhaft abschalten
Auf einem Gerät, das erreichbar sein soll, gehören die temporären Adressen aus. Der Wert wird pro Interface gesetzt und in einer Datei unter /etc/sysctl.d/ hinterlegt, damit er einen Neustart überlebt. Interfacename anpassen.
printf 'net.ipv6.conf.all.use_tempaddr = 0\nnet.ipv6.conf.default.use_tempaddr = 0\nnet.ipv6.conf.eth0.use_tempaddr = 0\n' | sudo tee /etc/sysctl.d/60-ipv6-tempaddr.conf
sudo sysctl --system
ip -6 addr show scope global temporary
4.
Bei NetworkManager die Einstellung dort setzen
Verwaltet NetworkManager die Verbindung, überschreibt er die sysctl-Werte beim nächsten Verbindungsaufbau. Dann muss die Einstellung im Verbindungsprofil stehen, nicht nur im Kernel.
nmcli connection modify "<Verbindungsname>" ipv6.ip6-privacy 0
nmcli connection up "<Verbindungsname>"
5.
Unter Windows dasselbe erledigen
Windows kennt zwei getrennte Schalter: die temporären Adressen selbst und die Zufälligkeit des Interface Identifiers. Für einen Server, der über eine feste Adresse erreichbar sein soll, werden beide abgeschaltet – in einer Eingabeaufforderung mit Administrator-Rechten. Mit store=persistent überlebt die Einstellung den Neustart.
netsh interface ipv6 set privacy state=disabled store=persistent
netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent
netsh interface ipv6 show address
6.
Freigabe und Firewall-Regel auf die stabile Adresse umstellen
Jetzt die Regel im Router beziehungsweise in der Firewall neu setzen – auf die stabile Adresse oder, wo möglich, auf die Interface-ID. Danach prüfen, ob die Regel wirklich greift, und zwar von außen: Ein Test aus dem eigenen Netz beweist gar nichts, weil er die Firewall nie passiert.
sudo nft list ruleset | grep -i -A3 'ip6'
ss -tulpn | grep -i tcp6
7.
Sich nicht auf ausbleibende ping-Antworten verlassen
Ein Erreichbarkeitstest gehört gegen den Dienst und den Port geführt, nicht gegen die Antwortfreudigkeit auf Pings. Viele Firewalls beantworten die eine Sache und blockieren die andere. Erst die erfolgreiche Verbindung auf dem Zielport ist ein Beweis.
?Warum hat mein Gerät überhaupt mehrere IPv6-Adressen?
Weil das so vorgesehen ist. Über SLAAC bildet das Gerät aus dem Präfix des Routers eine stabile Adresse. Zusätzlich erzeugt RFC 8981 – Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 – zufällige temporäre Adressen, die regelmäßig ausgetauscht werden, damit dich niemand anhand eines gleichbleibenden Adress-Suffixes quer durchs Netz wiedererkennt. Für ausgehende Verbindungen ist das ein Gewinn. Nur: Deine Firewall-Regel oder Portfreigabe zeigt auf genau eine dieser Adressen – und wenn das zufällig die temporäre war, läuft sie ins Leere, sobald diese ausgetauscht wird.
?Wie lange lebt so eine temporäre Adresse?
RFC 8981 nennt in Abschnitt 3.8 zwei Konstanten mit Standardwerten: TEMP_VALID_LIFETIME hat den „Default value: 2 days“, TEMP_PREFERRED_LIFETIME den „Default value: 1 day“. Beide sind laut RFC durch den Nutzer überschreibbar, und die bevorzugte Lebensdauer muss kleiner sein als die gültige. Der Linux-Kernel dokumentierte am 10.08.2026 für temp_valid_lft noch „Default: 604800 (7 days)“; die am 15.10.2026 gelesene Fassung der Kernel-Dokumentation nennt „Default: 172800 (2 days)“ und für temp_prefered_lft „Default: 86400 (1 day)“ – also inzwischen genau die Werte des RFC. Die frühere Abweichung erklärt, warum das Aussetzen mal nach einem Tag und mal nach einer Woche auffiel: Es hing davon ab, wessen Standardwerte gerade griffen – und welcher Wert auf einem konkreten System gesetzt ist, zeigt nur `sysctl net.ipv6.conf.all.temp_valid_lft`.
?Ist das Abschalten der Privacy Extensions nicht ein Datenschutzproblem?
Auf einem Server nicht – dort ist das Gegenteil der Fall. RFC 8981 begründet den Sinn temporärer Adressen mit dem Wiedererkennen von Clients und stellt in Abschnitt 2.2 klar: Viele Hosts sind Client und Server zugleich, und dann braucht der Host für seine Server-Rolle ohnehin einen Namen. Wörtlich: „Whether the address stays fixed or changes has little impact on privacy, since the name remains constant and serves as a constant identifier.“ Wer den Dienst per DNS-Namen erreichbar macht, gewinnt durch eine wechselnde Adresse also nichts. Auf deinem Notebook und Telefon dagegen bleiben die Privacy Extensions eingeschaltet – dort erfüllen sie ihren Zweck.
?Reicht es, im Router die Freigabe auf die Interface-ID statt auf die volle Adresse zu setzen?
Das ist sogar der robustere Weg, sofern der Router es anbietet. Der Präfix vom Provider kann sich ändern, der hintere Teil der Adresse – der Interface Identifier – bleibt stabil, wenn das Gerät keine temporären Adressen mehr bildet. Viele Heimrouter kennen deshalb Freigaben, die nur die Interface-ID speichern und den aktuellen Präfix selbst ergänzen. Voraussetzung bleibt dieselbe: Auf dem Server müssen die temporären Adressen abgeschaltet sein, sonst zeigt die Freigabe zwar auf eine gültige, aber nicht auf die gerade benutzte Adresse.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.
Port ist freigegeben, Firewall offen, Dienst läuft – und von außen kommt nichts an? Dann lauscht er nur auf 127.0.0.1. Ein Unterschied, den niemand sieht.
Seiten hängen erst und laden dann doch? Oft ist IPv6 halb konfiguriert: Der Rechner versucht es zuerst, wartet ins Leere und fällt spät auf IPv4 zurück.