IPv6 – Wechsel von statischem zu dynamischem Präfix¶

Eine kurze Einführung in IPv6. Für diejenigen, die mit IPv6 noch nicht so vertraut sind, möchte ich einige Begriffe einführen. Die Welt von IPv6 unterscheidet sich ein wenig von der von IPv4. Insgesamt muss ich sagen, dass es mir viel besser gefällt. Dennoch gibt es einige Fallstricke, die ich gerne teile, damit Sie von meiner Erfahrung profitieren können.

ULA¶

In IPv6 gibt es mehrere Adresstypen, der erste, den wir uns ansehen, ist ULA. Es steht für Unique Local Address. Dieser Adressbereich umfasst fc00::/7 (fc00:: bis fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff) und ähnelt in gewisser Weise dem, wofür RFC1918-Adressen in IPv4 verwendet wurden. Es gibt einen IPv6 Buzz-Podcast über ULA-Adressen und warum deren Verwendung schlecht sei. Ihr Hauptargument ist, dass im DNS alles Vorrang vor ULA-Adressen hat, sogar IPv4. Ich stimme überhaupt nicht zu, dass ULA schlecht ist. Lesen Sie den vollständigen Artikel, um zu verstehen, warum.

GUA¶

GUA ist die Abkürzung für Global Unicast Address. Diese Adressen bilden das Internet, da sie öffentlich geroutet werden. Hier folgt ein beliebter Vergleich zwischen IPv6- und IPv4-Adressraum (gerundet):

IPv6 (2^128): 34,000,000,000,000,000,000,000,000,000,000,000,000,000
IPv4 (2^32):                                           4,200,000,000

One /48 (2^80): 1,200,000,000,000,000,000,000,000
One /56 (2^72):     4,700,000,000,000,000,000,000

Link Local¶

Link-Local-Adressen sind für den Nutzer größtenteils irrelevant. Sie werden für ein automatisches Setup verwendet, sodass Hosts innerhalb derselben Broadcast-Domain einander erreichen können. Mechanismen zum Finden voneinander, aber auch zum Finden spezieller Geräte wie Gateways, sind Teil dieses Adresstyps und des Neighbor Discovery Protocols (NDP). Für ein tieferes Verständnis von IPv6 sollte jeder diese Adressen sowie Neighbor Discovery kennen, für diesen Artikel ist das jedoch nicht relevant.

Hintergrund¶

Aktuell betreibe ich VDSL (NetAachen) mit Vectoring bei 100/40 Mbit/s zusammen mit statischer IPv4 und einem IPv6 (/48) Präfix. Das kostet etwa 55 € pro Monat. Die Deutsche Telekom wird mir bald Glasfaser bereitstellen, somit kann ich höhere Übertragungsraten erhalten. Es gibt nur zwei Produkte, die Geschwindigkeit verbessern, insbesondere beim Upstream:

MagentaZuhause XXL: 500/100 Mbit/s für 59,95 € pro Monat oder MagentaZuhause Giga: 1000/200 Mbit/s für 79,90 pro Monat

Wenn ich eine statische IP wollte, müsste ich einen Geschäftstarif wählen:

CompanyPro 500: 500/100 Mbit/s für 99,95 € pro Monat oder CompanyPro 1000: 1000/200 Mbit/s für 129,95 € pro Monat

Ich entschied mich für MagentaZuhause Giga, das mir ein dynamisches Präfix liefert. Wenn ich dieselbe Geschwindigkeit, aber mit statischem Präfix gewollt hätte, käme ein Aufschlag von 50 € pro Monat hinzu. 130 € pro Monat für einen Internet-Uplink? Nein, solange ich kein Einkommen daraus erziele. Das ist einfach zu teuer. Obwohl ich den Komfort eines statischen Präfixes wirklich gern gehabt hätte, hielt ich den Aufpreis nicht für gerechtfertigt, also fügte ich mich in den Gedanken eines dynamischen Präfixes.

Meine Netzwerkumgebung setzt stark auf IPv6. Es gibt kaum noch A-Records in meinen DNS-Zonen, da nur Hosts, die wirklich kein IPv6 beherrschen, einen A-Record bekommen. Alle AAAA-Records zeigen auf GUA-Adressen aus meinem öffentlichen Präfix. Zudem nutzte ich die Tatsache, dass ich ein statisches /48-Präfix besitze, recht intensiv. Ich verwende mehrere verschiedene VLANs, aber es kommt noch mehr. Ich betriebe auch Downstream-Router unterhalb meiner Haupt-Upstream-Firewall. Sie stellen Adressen für Clients in simulierten Umgebungen bereit. Somit gibt es mehrere Möglichkeiten, wie der Übergang gestaltet werden kann:

Zusätzlich zu meinem Heimnetz betreibe ich einen Server in einem Rechenzentrum, der Virtualisierung nutzt und eine virtuelle Firewall für die verschiedenen Gäste hat. Mein Heimatstandort ist über einen Wireguard-Tunnel mit der Firewall des Rechenzentrums verbunden.

Option 1: DHCPv6 mit RFC2136?¶

Mein erster Gedanke war, vollständig auf dynamische IP-Konfiguration zu setzen. Da ich weder möchte noch auf jedem Gerät einen Dynamic-DNS-Client betreiben kann, überlegte ich, von OpenWrt zurück zu OPNsense zu wechseln. OPNsense bietet eine eingebaute Funktion, sodass jeder DHCPv6-Client bei Bezug einer IP einen aktualisierten DNS-AAAA-Record in meinen autoritativen DNS-Servern hinterlässt. Selbst wenn ich ein neues Präfix bekomme, sähe es dank RFC2136 und einer sehr niedrigen TTL zumindest so aus, als hätte ich ein statisches Präfix.

Ich entschied mich aus mehreren Gründen gegen diesen Ansatz. Ein Grund war, dass nicht jedes Gerät, das ich betreibe, einen eingebauten DHCPv6-Client hat. Außerdem habe ich schlechte Erfahrungen mit DHCP allgemein gemacht, wenn der DHCP-Server ausfällt. Ich möchte, dass mein Netzwerk weiterläuft, auch bei einer Störung irgendwelcher Art.

Option 2: Statische IP aus dem Rechenzentrum?¶

Ein weiterer Gedanke war, statische IP-Adressen, die ich in einem Rechenzentrum betreibe, einfach zu tunneln. Dort habe ich ein geroutetes /48-Präfix, das für zwei oder vielleicht sogar tausende Standorte mehr als ausreichend ist. Während diese Idee auf den ersten Blick attraktiv wirkt, gibt es einige gewichtige Nachteile. Ich würde niemals einen ganzen Standort auf IP-Adressen eines anderen Standorts betreiben. Vielleicht versehe ich einen einzelnen Host oder zwei mit IP-Adressen des entfernten Standorts, aber das gesamte Netz auf IP-Adressen eines anderen Standorts laufen zu lassen ergibt einfach keinen Sinn. Das ist eine Abhängigkeit, die Ihr Netzwerk lahmlegen kann, falls das Rechenzentrum nicht erreichbar ist oder eventuell nur der Router dort wartet oder ausfällt. Also: Nein, diesem Ansatz folge ich nicht.

Option 3: ULA¶

ULA-Adressen sind ein gutes Werkzeug im Heimnetz, aber auch in Unternehmen. Man könnte ULA sogar bereitstellen, wenn ein statisches Präfix verfügbar ist. Das würde helfen, wenn man den Server von einem Hoster zum anderen umzieht. Ich habe begonnen, ULA auch im Rechenzentrum einzusetzen, bin mir aber nicht sicher, ob ich meine DNS-Records jemals auf die ULA-Adresse umstelle. Ich mag einfach den Gedanken, dass die IP-Adressen stets gleich bleiben, egal ob ich sie entfernt über den Tunnel adressiere, von meinem Roadwarrior-VPN oder gar aus dem öffentlichen Internet.

Angenommen, Sie haben ein statisches Präfix und verwenden nur dieses, stehen Sie vor demselben Dilemma, vor dem ich jetzt stehe. Eine Ausnahme besteht natürlich, wenn Sie ein eigenes AS via BGP betreiben, entweder als RIR-Mitglied oder über einen eigenen PI-Präfix. In diesem Fall bleiben Ihre IPs unverändert, selbst wenn Sie Provider oder Rechenzentren wechseln.

Mit ULA gewinnen Sie ein Stück Unabhängigkeit. Angenommen, Sie wechseln zu einem anderen ISP oder steigen von einem statischen Präfix auf ein dynamisches herunter. Ihre ULA-Adressen bleiben identisch. Ihre Dienste bleiben erreichbar, und der Aufwand aus einer solchen Migration ist gering.

Allein reichen ULA-Adressen jedoch nicht, da sie im Internet nicht geroutet werden. Man könnte IP-Masquerading verwenden, aber niemand bei klarem Verstand will das tatsächlich. Zusätzlich zu einem statischen ULA werde ich daher auch Autoconf und/oder DHCP nutzen, um öffentliche Adressen zu erhalten. Aus diesem Grund kam ich zu dem Schluss, eine Kombination aus zustandsbehaftetem DHCP plus statischen ULA-Adressen zu verwenden.

Zum Argument von IPv6 Buzz. Nun, das ist ein Klacks. In einem ordentlichen Netz verwenden Sie keine A-Records. Und selbst wenn Sie es täten und IPv4 Vorrang vor ULA hat? Na und? Es gibt Ihnen lediglich eine weitere Ausfallsicherheit, falls v4 aus welchem Grund auch immer nicht funktioniert. Allerdings sehe ich keinen guten Grund, warum man überhaupt A-Records einführen sollte. Wir kamen jahrzehntelang ohne AAAA aus, also können wir jetzt auch ohne A leben. Das langfristige Ziel des Internets und auch lokaler Netzwerke ist zweifellos reines IPv6. Passen Sie Ihre Strategie entsprechend an! Sie möchten Ihre Firewall-Regeln, Ihre DNS-Records usw. schließlich nicht sowohl in IPv4 als auch in IPv6 pflegen müssen.

IPv6-Implementierungen unterscheiden sich¶

Bei den meisten Linux-Hosts ist die Konfigurationsart unproblematisch. Statische Adressierung ist natürlich kein Problem, und DHCPv6 ist meistens ebenfalls keins. Dennoch ist die Situation manchmal frustrierend. Es gibt so viele Unterschiede darin, wie Betriebssysteme diese Techniken umsetzen. Android macht beispielsweise gar kein DHCPv6. Das ist nicht so schlimm, da mich die Adresse eines dynamischen Android-Clients nicht interessiert.

Die Situation bei anderen Geräten ist eher problematisch. Proxmox VE verwendet beispielsweise Cumulus' ifupdown2-Framework, das offenbar nicht mit DHCPv6 funktioniert. Autoconf ist für Bridges komplett kaputt. Auf simplen Interfaces funktioniert Autoconf, aber DHCPv6 funktioniert überhaupt nicht. Wie kann man bei so einfachen Dingen scheitern?

Andere Geräte wie Drucker und Switches beherrschen manchmal kein DHCPv6, meistens unterstützen sie aber keine Mischung aus statischem ULA mit Autoconf/DHCP. Deshalb wähle ich für sie nur Autoconf oder DHCP, da eine statische ULA allein sie nicht aus meinem lokalen LAN herausbringt. Zusammen mit der DUID des Geräts kann ich ihnen eine statische ULA-Adresse zuweisen, ähnlich statischen Leases im DHCPv4. Im v4 waren diese an die MAC-Adresse gebunden. Bei DHCPv6 werden DUIDs verwendet, was mehr Flexibilität bietet, aber manchmal ist es etwas schwer, die DUID eines Geräts zu finden.

OpenWrt ist ein gutes Beispiel dafür, wie man es richtig macht. Sie unterstützen alles: dynamisch zustandslos, dynamisch zustandsbehaftet, statisch und auch eine Kombination aus beidem. Wenn man mehrere verschiedene Linux-Betriebssysteme betreibt, ist das ebenfalls recht ärgerlich. Jeder macht diese Sachen unterschiedlich. Raspbian verwendet beispielsweise dhcpcd, was recht gut funktioniert. Es implementiert v4 und v6 in einem Client. Andere Betriebssysteme verwenden ISC DHCP, wieder andere bringen standardmäßig keinen DHCPv6-Client mit. Man muss einen auswählen, installieren und konfigurieren. Es gibt beispielsweise den Dibbler oder wide DHCPv6. Letzterer ist in BSD-Umgebungen recht verbreitet. Was Gnomes Network Manager im Hintergrund tut, konnte ich nicht herausfinden.

Überlappende IPs¶

Da ich von einem statischen zu einem dynamischen Präfix wechsle, musste ich etwas Renumbering betreiben. Über die letzten Jahre habe ich IPv6-Adressen und Präfixe auswendig gelernt. JA, das ist möglich. Ich wollte nicht von vorne beginnen, deshalb wählte ich die ULA identisch zu meinem alten statischen Präfix – natürlich mit Ausnahme der ersten 7 Bits.

GUA: 2001:4dd0:28d4:7381::10 ULA: fd01:4dd0:28d4:7381::10

Auf diese Weise kann ich meine alten Erinnerungen behalten, und der Übergang fällt etwas leichter.

VPN¶

Auch für meine VPN-Verbindungen mussten einige Anpassungen vorgenommen werden. Ich verwende Wireguard für einen Site-to-Site-(S2S)-Tunnel zwischen meinem Heimnetz und einem Rechenzentrum. Wireguard wird zudem für Roadwarrior eingesetzt. Diese verbinden sich zum Rechenzentrum und gelangen über den S2S auch zum Heimatstandort.

Die Anpassungen für den S2S waren einfach. Auf Seiten des Rechenzentrums musste ich lediglich mein neues ULA-Präfix zu den allowed ips hinzufügen. Die entsprechende Option in OpenWrt sieht so aus:

config wireguard_S2S
   option description "my S2S"
   ...
   list allowed_ips "fd01:4dd0:28d4::/48"

        option endpoint_host "2a01:f20:1:4f::b1b1"
        option endpoint_port "51821"

[Interface]
Address = ...
PrivateKey = ...

[Peer]
PublicKey = ...
PresharedKey = ...
AllowedIPs = ... fd01:4dd0:28d4::/48

Firewall-Anpassungen¶

Ich verwende Ansible, um meine Firewalls und Server zu verwalten. Gut ist, dass es Variablen gibt, die ich einmal definieren und vielfach verwenden kann. Leider stellte ich fest, dass es viel zu viele IP-Adressen gab, die manuell in meinen Var-Definitionen standen. Diese Gelegenheit nutzte ich, um sie zu aktualisieren und die Anzahl hartcodierter IP-Adressen und Netzwerke zu minimieren. Zuvor hatte ich lediglich die ULA-IPs zur Regel hinzugefügt. Sobald der Übergang auf den neuen Glasfaseranschluss erfolgt ist, werden die alten GUA-Adressen entfernt.

Ich betreibe nicht nur zentrale Firewalls, sondern auf den Servern auch nftables, ebenfalls verwaltet durch meine eigene Ansible-Rolle. Auch diese benötigten Updates. In solchen Szenarien kann man sich glücklich schätzen, wenn man Ansible einsetzt, da der Aufwand für solche Änderungen im Vergleich zur manuellen Durchführung minimal ist.

Source Address Selection¶

Meine Hosts zu Hause haben nun zusätzlich zu den GUA-Adressen auch ULA-Adressen. Ich experimentierte und stellte nach kurzem fest, dass es ein nerviges Problem gab. Es gibt mehrere Szenarien, wer mit wem die Kommunikation initiiert. Nur ein bestimmter Fall ist tatsächlich problematisch. Ein Host zu Hause versucht, über VPN auf einen Host im Rechenzentrum zuzugreifen. Die Methode der Source Address Selection wählt am heimischen Rechner zuverlässig eine GUA-Adresse statt der ULA-Adresse. Das ist zwar grundsätzlich wohl die beste Wahl, verhindert in diesem Szenario aber eine erfolgreiche Kommunikation. Ein Paket erreicht die VM im Rechenzentrum. Da der Tunnel zwischen den Standorten keine Informationen über das GUA-Präfix von zu Hause hat – es ist ja dynamisch –, kommt der Rückverkehr nie an. Er wird über das Internet geroutet, was fehlschlägt, da die Firewall zu Hause dafür keine Regeln hat. Davon abgesehen passen auch die gespeicherten Sitzungsinformationen an der Heim-Firewall nicht.

Kommunikationsabbruch

Heim-VM zu Rechenzentrum-VM¶

Dieses Sequenzdiagramm verdeutlicht das Problem bei einem Site-to-Site-Tunnel mit einem statischen und einem dynamischen Präfix.

sequenceDiagram
    HomeVM ->> HomeFW: SRC: GUA dynamic, DST: GUA static
    HomeFW ->> DatacenterFW: SRC: GUA dynamic, DST: GUA static (WIREGUARD)
    DatacenterFW ->> DatacenterVM: SRC: GUA dynamic, DST: GUA static
    DatacenterVM ->> DatacenterFW: SRC: GUA static, DST: GUA dynamic
    DatacenterFW ->> HomeFW: SRC: GUA static, DST: GUA dynamic (ASIDE WIREGUARD)

Rechenzentrum-VM zu Heim-VM¶

Wenn ein Host im Rechenzentrum den Verkehr initiiert, tritt das Problem nicht auf.

sequenceDiagram
    DatacenterVM ->> DatacenterFW: SRC: GUA dynamic, DST: ULA static
    DatacenterFW ->> HomeFW: SRC: GUA dynamic, DST: ULA static (WIREGUARD)
    HomeFW ->> HomeVM: SRC: GUA dynamic, DST: ULA static
    HomeVM ->> HomeFW: SRC: ULA static, DST: GUA static
    HomeFW ->> DatacenterFW: SRC: ULA static, DST: GUA static (WIREGUARD)
    DatacenterFW ->> DatacenterVM: SRC: ULA static, DST: GUA static

Es gibt mehrere Methoden, dieses Problem zu umgehen.

VPN-Spezifikationen manuell anpassen¶

Ich könnte manuell oder mittels Automatisierung die Tunnelspezifikationen jedes Mal anpassen, wenn zu Hause ein neues Präfix verteilt wird. Das ist offensichtlich die schlechteste Option.

Masquerading¶

Ich könnte den Verkehr maskieren, der von zu Hause ins Rechenzentrum stammt. Ganz bestimmt nicht.

ULA im Rechenzentrum¶

Ich könnte auch ULA im Rechenzentrum einrichten. Dann wären Quelle und Ziel jeweils ULA – zumindest nehme ich an, dass es so wäre. Egal wie, ich möchte die DNS-Records im Rechenzentrum nicht ändern, da sie auf GUA-Adressen zeigen sollen.

Babeld und Wireguard¶

Ich probierte einen Ansatz mit dynamischem Routing und experimentierte mit Quagga, FRR, babeld und Bird. Am Ende entschied ich mich für babeld, und hier folgt, was ich tat. Der Wireguard-Tunnel zwischen den beiden Standorten dient dem Austausch von Routinginformationen. Letztlich funktionierte das einwandfrei, aber der Weg war holprig.

Zunächst musste ich die Wireguard-Peer-Definition ändern. Sie bestand aus einer Direktive namens allowed_ips, die ich modifizieren musste. Diese Direktive hat zwei Zwecke. Erstens: Sie installiert Routen zum Remote-Standort. Zweitens: Sie begrenzt, welche IP-Adressen für Daten genutzt werden dürfen, die den Tunnel passieren. Ich änderte sie von der Nennung aller meiner Remote-Netze auf einfach

config wireguard_RXFORELLE
        option description "fw.libcom.de"
        option public_key "sjdfklsjdkfljdsklfjsdklfjkldsjfkldsjklfjdsklf"
        option preshared_key "sdjfklsjdkfljskldfjsdklfjkdsljfkldsjfklsdj"
        list allowed_ips "0.0.0.0/0"
        list allowed_ips "::/0"
        option route_allowed_ips "0"
        option endpoint_host "2a00:fee:fee:4f::b1b1"
        option endpoint_port "51821"

Babel ist eine moderne und sehr spaßige Lösung für dynamisches Routing. FRR hat eine Implementation dafür, aber es gibt die Referenzimplementierung namens babeld, die ich wählte. Meine Wireguard-Schnittstelle heißt auf beiden Enden RXFORELLE, und hier ist die Beispielkonfiguration einer Seite. Denken Sie daran: Dies ist OpenWrt, also handelt es sich um eine UCI-Konfigurationsdatei.

config general
        option ipv6_subtrees 'true'
        option ubus_bindings 'true'
        option random_id 'true'
        option local_port '33123'

config interface
        option ifname "RXFORELLE"
        option type "tunnel"


config filter
        option type "redistribute"
        option action "deny"
        option local "true"
config filter
        option type "redistribute"
        option ip "fd01:4dd0:28d4::/48"
config filter
        option type "redistribute"
        option ip "2001:4dd0:28d4::/48"
config filter
        option type "redistribute"
        option ip "10.10.128.0/20"
config filter
        option type "redistribute"
        option ip "2a03:fe3:fe3::/48"

config filter
     option type "redistribute"
     option ip "2a00:afe::/32"

sequenceDiagram
    HomeVM ->> HomeFW: SRC: GUA dynamic, DST: GUA static
    HomeFW ->> DatacenterFW: SRC: GUA dynamic, DST: GUA static (WIREGUARD)
    DatacenterFW ->> DatacenterVM: SRC: GUA dynamic, DST: GUA static
    DatacenterVM ->> DatacenterFW: SRC: GUA static, DST: GUA dynamic
    DatacenterFW ->> HomeFW: SRC: GUA static, DST: GUA dynamic (WIREGUARD)
    HomeFW ->> HomeVM: SRC: GUA static, DST: GUA dynamic

Eingehender Verkehr¶

Ich betreibe mehrere Dienste in meinem Heimnetz, die von außerhalb des Internets erreichbar sind. Einige betreibe ich nur für mich. Diese funktionieren weiterhin, sobald ich in DNS auf ULA-Adressen umgestellt und das VPN modifiziert hatte. Öffentlich erreichbare Dienste benötigen Dynamic DNS. Wenn sich das Präfix ändert, werden die AAAA-Records aktualisiert, und die Ausfallzeiten bleiben minimal. Den DNS-Dienst für meine Domains hoste ich selbst. Ich verteile ihn auf drei synchronisierte Server, von denen einer in meinem Heimnetz steht. Dieser wird aus dem öffentlichen Verzeichnis entfernt. Dennoch lasse ich ihn lokal unter einer ULA-Adresse weiterlaufen, da ich Domain-Overrides an meinen lokalen Resolvern konfiguriere, sodass die Auflösung meiner Geräte via DNS weiterhin funktioniert, selbst wenn mein Uplink ausfällt.

Die Server sind alle so konfiguriert, dass sie auf :: lauschen, sodass ich die Binding-IPs nicht ändern muss. Es sind mehrere Paketfilter aktiv, die sicherstellen, dass unbefugte IPs keine Verbindung aufbauen können.

Schlussworte¶

Am Ende kostete dieser Übergang von statischem zu dynamischem Präfix rund ~12 Stunden Arbeit. Machen Sie nicht dieselben Fehler wie ich. Nutzen Sie ULA!