AWS EC2: IPv6 mit SUSE via DHCP

Kürzlich hatte ich versucht, ein aktuelles openSUSE Leap 42.2 als EC2-Instanz bei Amazon Web Services mit IPv6 zu nutzen. Diese VM sollte als Reverse-Proxy für dahinterliegende Websites dienen und über IPv4 und IPv6 erreichbar sein. Dummerweise lief das zunächst nicht so wie geplant.

Das VPC (Virtual Private Cloud) war korrekt konfiguriert und zwei dazugehörige Subnetze waren mit IPv6-Netzen versehen worden. Beim Starten einer EC2-Instanz wurde die automatische Vergabe der entsprechenden IP-Adressen ebenfalls aktiviert.

Kein IPv6 über DHCP

Nach dem Booten der openSUSE-Instanz stellte sich jedoch heraus, dass keine globale IPv6-Adresse im System konfiguriert worden war. Die Netzwerk-Einstellungen passten und eigentlich hätte alles prima funktionieren müssen. IPv4 war in Ordnung und eine Link-Local IPv6-Adresse (fe80::) war ebenfalls vorhanden.

Die „echte“ IPv6-Adresse fehlte…

Kurzerhand habe ich das dann auch direkt mit der aktuellen Enterprise Server Version, SLES 12 SP2, getestet. Ebenfalls ohne Erfolg.

Kein grundsätzliches Problem

Weitere Tests zeigten dann, dass nicht alle verfügbaren Betriebssysteme betroffen waren. Amazon Linux, SLES 11 SP4 und RHEL waren durchaus in der Lage, IPv6-Adressen über DHCP zu beziehen. Mein Verdacht fiel daraufhin auf Wicked, das in neueren openSUSE/SLE-Varianten genutzte Framework zur Netzwerkkonfiguration. Nachdem ich Wicked abgeschaltet und stattdessen das Kommando „dhclient -6 -v eth0“ ausgeführt hatte, wurde die IP-Adresse einwandfrei eingerichtet. Dies war natürlich nur ein manueller Workaround, daher musste eine echte Lösung her.

Unterstützung im SUSE-Forum

Glücklicherweise existiert ein SUSE-Forum rund um Public Cloud. Hier hatte ich einen neuen Thread gestartet, mein Problem geschildert und etwas später wurde die Ursache des Problems klar:

Wicked nutzt neuere RFC’s und fragt beim DHCP6-Server von Amazon einige zusätzliche DHCP-Optionen ab, die offenbar von Amazon (noch) nicht verstanden werden. Statt diese Optionen zu ignorieren, liefert Amazons DHCP6-Server in dieser Situation offenbar gar kein Lease mehr zurück.

Workaround

Im Thread wird außerdem ein Workaround beschrieben, der darin besteht, Wicked zu patchen und dann neu zu kompilieren. Ich habe das Ganze mit openSUSE Leap 42.2 und SLES 12 SP2 erfolgreich getestet.

Zunächst werden die erforderlichen Pakete installiert, die für den Code-Download und den Bau der neuen Pakete benötigt werden (beim SLES werden die zusätzlichen SDK-Repos benötigt):

zypper in git-core rpm-build gcc make \
    pkg-config autoconf automake libtool \
    systemd-devel libnl3-devel libiw-devel \
    dbus-1-devel libgcrypt-devel

Dann klont man das offizielle Wicked-Projekt aus dem openSUSE-Channel von GitHub in ein beliebiges Verzeichnis:

git clone https://github.com/openSUSE/wicked.git

Im nächsten Schritt wird der Patch für Wicked in das Code-Verzeichnis heruntergeladen und eingespielt:

cd wicked
wget "http://users.suse.com/~mt/wicked/dhcp6_req_basis_options_only.diff"
patch -p1 < dhcp6_req_basis_options_only.diff

Wenn bisher alles geklappt hat, können die RPM’s gebaut werden:

./autogen.sh
make rpmbuild

Ist auch das erfolgreich gewesen, stehen drei neue RPM’s bereit, die als Update eingespielt werden können:

zypper -v in /usr/src/packages/RPMS/x86_64/{wicked,wicked-service,libwicked}*.rpm

Zum Schluss reicht ein Neustart des Wicked-Daemons. Daraufhin sollte das DHCP6-Lease wieder funktionieren:

systemctl restart wicked.service

Für dieses Thema wurde außerdem ein Bug-Report bei SUSE erstellt, in dem das Problem diskutiert und final gelöst werden soll. Für den Fall, dass der verlinkte Patch nicht mehr verfügbar sein sollte, veröffentliche ich ihn auch hier:

diff --git a/src/dhcp6/protocol.c b/src/dhcp6/protocol.c
index 5dd5a5a..3344905 100644
--- a/src/dhcp6/protocol.c
+++ b/src/dhcp6/protocol.c
@@ -1333,17 +1333,23 @@ __ni_dhcp6_build_oro_opts(ni_dhcp6_device_t *dev,
 	ni_dhcp6_option_request_append(oro, NI_DHCP6_OPTION_NISP_SERVERS);
 	ni_dhcp6_option_request_append(oro, NI_DHCP6_OPTION_NISP_DOMAIN_NAME);
 	*/
+#if 0
 	ni_dhcp6_option_request_append(oro, NI_DHCP6_OPTION_POSIX_TZ_STRING);
 	ni_dhcp6_option_request_append(oro, NI_DHCP6_OPTION_POSIX_TZ_DBNAME);
+#endif
+#if 0
 	ni_dhcp6_option_request_append(oro, NI_DHCP6_OPTION_BOOTFILE_URL);
 	ni_dhcp6_option_request_append(oro, NI_DHCP6_OPTION_BOOTFILE_PARAM);
+#endif
 	/*
 	 * TODO: ntp options envelope - AFAIR ISC dhcp does not support it yet.
 	ni_dhcp6_option_request_append(oro, NI_DHCP6_OPTION_NTP_SERVER);
 	 */
 	ni_dhcp6_option_request_append(oro, NI_DHCP6_OPTION_SNTP_SERVERS);
+#if 0
 	ni_dhcp6_option_request_append(oro, NI_DHCP6_OPTION_SIP_SERVER_D);
 	ni_dhcp6_option_request_append(oro, NI_DHCP6_OPTION_SIP_SERVER_A);
+#endif
 	ni_dhcp6_option_request_append(oro, NI_DHCP6_OPTION_FQDN);
 
 	if (dev->config) {

Seid Ihr auch schon über dieses Problem gestolpert? Hat der Workaround geholfen?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.