OpenWrt: Workaround für Timing-Problem bei WAN6-Interface (IPv6-Adressbereich)

Am Wochenende habe ich auf meinem OpenWrt-Router (Fritz!Box 4040 mit Version 21.02.1) IPv6 aktiviert. Dabei ist mir eine Art »Timing-Problem« aufgefallen, was in meinem Netzwerk-Setup eintritt:

Vor dem OpenWrt-Router habe ich eine Fritz!Box, die die eigentliche Internetverbindung herstellt. Wenn beide Geräte gleichzeitig hochfahren bzw. Strom bekommen, hat das mit der IP6-Adressvergabe allerdings nicht funktioniert.

Das Problem: Das WAN6-Interface des OpenWrt-Routers ist schon hochgefahren, bevor die davor liegende Fritz!Box einen IPv6-Adressbereich vom Provider zugewiesen bekommen hat. Als Folge bekommt das WAN6-Interface kein IPv6-Netzbereich (IPv6-PD) von der Fritz!Box zugewiesen. Klappt das nicht direkt beim Hochfahren des WAN6-Interfaces, unternimmt OpenWrt offenbar keinen neuen Versuch, um ein IPv6-Netzbereich (IPv6-PD) bei der Fritz!Box anzufragen. Starten also beide Geräte gleichzeitig sieht das WAN6-Interface wie folgt aus:

Protocol: DHCPv6 client
Uptime: 0h 0m 50s
MAC: F0:B0:14:B6:A7:05
RX: 38.85 MB (31737 Pkts.)
TX: 1.63 MB (12333 Pkts.)
IPv6: fd00::f2b0:14ff:efe5:e501/64
IPv6: 2a02:8071:3ec3:9100:f4c0:14df:fef5:e701/64

Es fehlt also der IPv6-PD-Netzbereich. Klickt man im Interface auf Restart beim WAN6-Interface, wird das IPv6-Netz von der Fritz!Box an den nachgelagerten OpenWrt-Router korrekt weitergegeben:

Protocol: DHCPv6 client
Uptime: 0h 2m 50s
MAC: F0:B0:14:B6:A7:05
RX: 38.85 MB (31737 Pkts.)
TX: 1.63 MB (12333 Pkts.)
IPv6: fd00::f2b0:14ff:efe5:e501/64
IPv6: 2a02:8071:3ec3:9100:f4c0:14df:fef5:e701/64
IPv6-PD: 2a02:8071:3ec3:9100::/62

Erst wenn dieser IPv6-Netzbereich /62 bekannt ist, kann der OpenWrt-Router IPv6-Adressen an die weiteren Interfaces wie LAN oder WIFI delegieren bzw. diese dann an die dahinterliegenden Clients.

Dieses »Timing-Problem« habe ich dann wie folgt gelöst:

• Zunächst wird das WAN6-Interface bearbeitet und bei Bring up on boot das Häkchen entfernt
• Anschließend wird über die Kommandozeile direkt auf dem Router die Datei /etc/rc.local bearbeitet

# Start wan-interfaces after 2 minutes
sleep 120
/sbin/ifup wan 
/sbin/ifup wan6

Nachdem der OpenWrt-Router hochgefahren ist und alle System-Inits abgeschlossen sind, wartet der Router zwei Minuten (sleep 120), bevor das WAN6-Inteface (bzw. alle WAN-Interfaces) gestartet wird (ifup wan6). Das löst das Timing-Problem in meinem Setup. Das WAN6-Interface fragt also nicht direkt nach dem Start nach dem IPv6-Adressbereich, sondern erst nach zwei Minuten. So hat die davorgelagerte Fritz!Box genug Zeit, vom Provider einen IPv6-Adressbereich zugewiesen zu bekommen.

Eventuell lässt sich das auch eleganter lösen. Ich bin mir auch nicht wirklich sicher, ob hier eventuell ein Bug in OpenWrt vorliegt, da das WAN6-Interface keinen erneuten Versuch unternimmt, ein IPv6-Netzbereich anzufragen.

Was passiert aber nun in diesem Fall?:

• Die Fritz!Box startet neu (wegen Absturz oder manuell initiiert) oder führt aufgrund von Netzproblemen ein Reconnect zum Provider durch
• Der OpenWrt-Router bleibt derweil an

In diesem Fall wird der IPv6-Adressbreich am WAN6-Interface leider nicht aktualisiert. Aber mittels einem Hotplug-Skript lässt sich das ebenfalls fixen.

Unter

/etc/hotplug.d/iface/99-ipv6_fix_prefix_delegation

wird ein neues Skript mit dem Inhalt angelegt:

__INTERFACE__="wan6"

if [ "$INTERFACE" = "$__INTERFACE__" -a "$IFUPDATE_ADDRESSES" = "1" ]; then
   /sbin/ifup wan6
   sleep 3
   /sbin/ifup lan
   /sbin/ifup wlan
fi

Sobald sich die IP-Adresse des WAN6-Interfaces seit dem letzten ifupdate-Event ändert, werden die Befehle getriggert. Das WAN6-Interface wird neu gestartet und so der neue IPv6-Adressbereich bei der Fritz!Box abgefragt. Zur Sicherheit werden dann auch noch die beiden Interfaces (LAN/WLAN) neu gestartet, damit diese ebenfalls eine Aktualisierung durchführen bzw. diese an die Clients weitergeben. Hinweis: Damit das Hotplug-Skript funktioniert, muss Force link beim WAN6-Interface deaktiviert sein, ansonsten werden keine Hotplug-Skripte getriggert.

---

Ähnliche Beiträge

31. Juli 2019

FRITZ!Box 4040 und Netzwerkaufbau – OpenWrt Teil1

Eine modemlose FRITZ!Box 4040 wird mittels OpenWrt zum Kompagnon für ein DSL- oder Kabelmodem bzw. Router umfunktioniert.

7. August 2019

Flash OpenWrt auf FRITZ!Box 4040 – OpenWrt Teil2

Via FTP-Recovery-Modus findet OpenWrt seinen Weg in den Systemspeicher der FRITZ!Box 4040.

10. Dezember 2019

OpenWrt-Upgrade einspielen – OpenWrt Teil7

Das regelmäßige Einspielen von OpenWrt-Updates bzw. -Upgrades stellt eine der wichtigsten Maßnahmen gegen bekannt gewordene Sicherheitslücken dar.

17. September 2019

Hardening SSH- und LuCI-Webzugang – OpenWrt Teil3

Härtung der OpenWrt-Administrationsschnittstellen: Secure Shell (SSH) und LuCI-Weboberfläche.

26. November 2019

Stubby: Verschlüsselte DNS-Anfragen – OpenWrt Teil5

Mit dem Addon stubby für OpenWrt lassen sich alle DNS-Anfragen und -Antworten über eine TLS-gesicherte Verbindung übertragen.