Wie jede Geschichte hat auch diese einen Anfang, in diesem Fall war es ein neuer PC. Dafür habe ich mir sogar die Pro-Version von Windows 11 geleistet, und eigentlich klappte auch alles wie gewünscht. Naja, fast. Wie bereits in zwei Artikeln über pfSense hier und da beschrieben, funktioniert die Vergabe von IPv6-Adressen, die mir vom Provider angeboten, von der Fritz!Box durchgereicht und von pfSense letztlich an die Clients im Heimnetz verteilt werden, seit geraumer Zeit sehr gut.
tl;dr: Dies ist zunächst eher eine Geschichte rund um IPv6 und ChatGPT, wer nur an der Lösung interessiert ist, möge einfach nach unten scrollen.
Dabei handelt es sich um globale Adressen, oder auch Global Unicast Address, im Folgenden mit GUA bezeichnet, weltweit einzigartig und geroutet. Alles wie gewünscht, jeder Rechner im Netz erhält seine Adresse bzw. sein /64-Subnetz, pfSense sorgt mittels Router Advertisement (RA) und irgendwie auch noch DHCPv6 für die Vergabe von IPv6-Adressen sowie weiterer Netzwerk-Daten wie Gateway und vor allem DNS-Server. Als DNS-Server fungiert ein Server mit Pi-Hole, somit wird ein Teil der Werbung bereits an zentraler Stelle geblockt. Wobei Pi-Hole auf interne DNS-Server zugreift, die wiederum die IP-Adressen für lokale Maschinen, z.B. den Entwicklungsserver, mein Redmine-Ticket- und Wiki-System etc. auflösen. Letzteres zunächst völlig abseits von IPv6, denn bislang erschien mir dafür IPv4 völlig ausreichend, außerdem kann ich mir diese Adressen im Heimnetz wenigstens noch halbwegs im Kopf behalten.
Spaß mit DNS und IPv6
Doch der neue PC war zunächst so konfiguriert, dass sämtliche, d.h. IPv4- als auch IPv6-Adressen per DHCP bezogen wurden. Eigentlich keine schlechte Idee, aber an einer Stelle wurde es problematisch: Neben der IPv6-Adresse an sich wurde auch ein Nameserver unter einer IPv6-Adresse zugewiesen, und das, obwohl in pfSense die Einstellung „Provide DNS servers to DHCPv6 clients“ deaktiviert war. Zwar gegen ausdrückliche Empfehlung von pfSense, aber da im Heimnetz kein DNS existierte, der unter einer IPv6-Adresse erreichbar war, sollte ausschließlich Pi-Hole verwendet werden, der jedoch nur eine IPv4-Adresse besaß.
Aus mir zunächst unbekannten Gründen wurde diese Option jedoch ignoriert, so dass der Windows-PC nun auf zwei DNS-Server zurückgreifen konnte: Einmal den internen Pi-Hole, und – langsam nähern wir uns dem Problem – den DNS mit einer IPv6-Adresse, die letztlich mit der FRITZ!Box verbunden war, die wiederum den DNS des Providers nutzte. Nun hatte ich auf dem bisherigen PC den Bezug von IPv6-Adressen per DHCP deaktiviert bzw. auf „manuell“ geschaltet, aber genau das zeigte auf der neuen Maschine keine Besserung. Anstatt ausschließlich IPv4 zu verwenden wurden immer noch IPv6-Adressen in der Netzwerk-Konfiguration angezeigt, und neben dem gewünschten IPv4-DNS-Server zeigte sich die IPv6-DNS-Adresse in trauter Zweisamkeit. Sicherlich hätte ich IPv6 irgendwo tief in den Windows-Einstellungen komplett deaktivieren können, aber das erschien mir zumindest in heutiger Zeit irgendwie falsch, außerdem wollte ich die neue Windows-Version nicht schon zu Beginn „ver-konfigurieren“, das würde sich mit der Zeit zwar kaum vermeiden lassen, aber noch war alles so schön sauber und rein…
Das eigentliche Problem bestand somit nun darin, dass Windows munter und lustig mal auf den einen, mal auf den anderen DNS-Server, d.h. mal auf IPv4 und mal auf IPv6 zugegriffen hat. Und wie sich der aufmerksame Leser inzwischen denken können sollte, waren nur dem internen DNS die internen Server auch bekannt, nicht jedoch der FRITZ!Box bzw. dem Provider, auf dessen DNS die Anfrage letztlich landete. Dank Caching des Browsers dauerte es dann auch immer wieder eine Weile, bis ein neuer Request zwecks Test erfolgversprechend hätte sein können. Somit waren Zugriff auf interne (Web-)Server nur teil- oder vielmehr zeitweise erfolgreich, nicht jedoch, sobald der externe DNS-Server angesprochen wurde und statt einer internen IP-Adresse eine andere oder auch gar nichts zurück lieferte. Insgesamt also keine gute Kombination, aber damit auch Motivation genug, das Übel an der Wurzel zu packen und somit das Problem grundlegend zu lösen.
Einschub am Rande: In den Router Advertisements (RA) Einstellungen von pfSense war „Enable DNS“ aktiv („Provide DNS Configuration via the RA Daemon„). Das konnte zumindest eine Erklärung sein, weshalb eine IPv6-DNS-Adresse an die Clients verteilt wurde. Aber auch hier befand sich der Hinweis, dass die Deaktivierung der Option nicht empfehlenswert sei und gegen ein paar RFCs verstoßen würde, insofern erschien mir dies für eine dauerhafte Lösung ebenfalls nicht geeignet.
Die Idee bestand nun aus zwei Schritten:
- Erstens mussten im internen Netz irgendwie eine Art von lokalen IPv6-Adressen vergeben werden, d.h. analog zum IPv4-Netzwerk, in dem die Adressen entweder statisch auf den jeweiligen Hosts definiert sind oder per DHCP verteilt werden. Dabei sollte die Funktionalität des bestehenden IPv6-Netzes des Providers jedoch nicht beschränkt werden, das Routing sollte weiterhin funktionieren, externe IPv6-Adressen sollten erreichbar bleiben.
- Zweitens sollten Pi-Hole sowie die DNS-Server unter ihren – dann lokalen und somit statischen – IPv6-Adressen ansprechbar sein, so dass pfSense als DNS-Server weiterhin eine IPv6-Adresse an die Clients verteilen konnte, nur eben dann Pi-Hole als internen IPv6-DNS-Server anstatt der IPv6-Adresse der FRITZ!Box und somit den DNS des Providers.
Dieser Artikel beschäftigt sich mit der Umsetzung des ersten Schritts, ein späterer Beitrag wird sich Pi-Hole und den DNS-Servern widmen.
Lokale IPv6-Adressen – Hallo ULA!
Somit mussten zunächst lokale IPv6-Adressen her. Dazu ist der Bereich der Unique Local Adresses, oder auch ULA, gedacht. Diese Adressen beginnen mit fd00::/8 und sind auf ein privates Netzwerk beschränkt, ähnlich wie z.B. der Bereich 192.168.x.x bei IPv4-Adressen. Auf Namenskonflikte bei der Verwendung von ULA-Bereichen bei der Zusammenschaltung von zwei ULA-Netzen will ich hier nicht näher eingehen, einerseits ist die Wahrscheinlichkeit eher gering, andererseits handelt es sich noch immer um die Konfiguration eines heimischen Netzwerks, in dem lokale Adressen auch lokal bleiben sollen. Schließlich gibt es für die globale Erreichbarkeit weiterhin die IPv6-Adressen des Providers aus dem Bereich der Global Unicast Adresses (GUA). Und im Gegensatz zu IPv4 mit seinen Workarounds wie NAT ist die gleichzeitige Nutzung von globalen IPv6-Adressen eines Providers und ULA für lokale Adressen normal und sogar vorgesehen. Da IPv6-Adressen kontextabhängig verwendet werden, gibt es bei einer derartigen Konfiguration keine Konflikte.
Für externe Verbindungen sollten somit weiterhin die vom Provider bereitgestellten globalen IPv6-Adressen Verwendung finden, sie dienen der Kommunikation mit dem Internet und werden von Hosts für externe Verbindungen genutzt. Für interne, lokale Kommunikation hingegen sind die ULA-Adressen gedacht, das schließt auch die Verwendung eines internen DNS-Servers unter einer IPv6-Adresse mit ein. Diese Adressen sind nicht über das Internet erreichbar.
Somit stellte sich nun die Frage nach der genauen Konfiguration und Adressvergabe mittels pfSense. Dabei sollte die bisherigen Einstellungen, d.h. insbesondere die Nutzung des globalen IPv6-Netzes, das vom Provider vergeben wird, beibehalten werden.
Im ersten Schritt habe ich mit IPv6 – ULA-Generator einen der zahlreichen ULA-Generatoren genutzt, der aus einer MAC-Adresse, in diesem Fall der des pfSense-Routers, einen ULA-Adressbereich generiert. Zwar ist dieser Schritt optional, aber die Idee einer Einzigartigkeit des heimischen ULA-Adressbereiches gefiel mir recht gut, insofern wollte ich fortan mit dem ULA-Bereich fdec:e179:117a::/48 arbeiten.
pfSense, IPv6, ULA und die Auswüchse von ChatGPT
Nun hieß es, pfSense und die Hosts mit den entsprechenden Angaben zu bestücken. Und hier drehte ich mich zugegebenermaßen erstmal ein wenig im Kreis. Meine bevorzugte Lösung wäre es gewesen, die Adressvergabe ähnlich wie mit IPv4 zu realisieren. Dort regelt inzwischen pfSense mittels DHCP die Adressvergabe anhand der MAC-Adresse. Die Konfiguration findet somit an zentraler Stelle statt, z.B. hat ein Server die IP-Adresse 192.168.10.100, zugewiesen per DHCP. Meine erste Idee war somit, die IPv6-Adresse analog aufzubauen, das wäre dann z.B. die fdec:e179:117a::100/64. Am liebsten sollte auch hier die Vergabe per DHCPv6 stattfinden, eben wegen jener Konfiguration an zentraler Stelle.
Um die Geschichte ein wenig abzukürzen: Dieser Ansatz scheiterte kläglich. Nicht weil es rein technisch nicht irgendwie möglich gewesen wäre, sondern weil pfSense hier meiner Ansicht nach ein wenig unflexibel agiert. Ich hatte mir auch Unterstützung per ChatGPT geholt, aber auch die Künstliche Intelligenz schlug Lösungen vor, die in der Praxis schlicht und einfach nicht funktionierten – und war davon auch nach meinem Einspruch nicht abzubringen bzw. drehte sich genauso im Kreise und stellte drei Beiträge weiter dieselbe Lösung vor, die ich bereits als falsch deklariert hatte. Zwar ließen sich in pfSense per DHCPv6 feste IPv6-Adressen anhand der DUID (DHCP Unique Identifier) vergeben, aber wenn DHCPv6 für den internen ULA-Bereich konfiguriert war, funktionierte die Vergabe der globalen IPv6-Adressen nicht. Wie unter … beschrieben, muss das LAN-Interface im Bereich „Interfaces“ unter „IPv6 Configuration Type“ auf „Track Interface“ eingestellt sein. Im selben Bereich findet sich daraufhin „Track IPv6 Interface„, wo wiederum als „IPv6 Interface“ das zu trackende WAN-Interface, hier WAN_FRITZBOX genannt, konfiguriert wird. Damit funktioniert die Adressvergabe bzw. -Weitergabe des globalen IPv6-Netzes wie bisher. Doch genau mittels dieser Konfiguration ist im Bereich „Services“ -> „DHCPv6 Server“ -> „LAN“ unter „Primary Address Pool“ das Prefix „Delegated Prefix: WAN_FRITZBOX“ fest eingestellt. Zwar kann man den Bereich des Adress-Pools festlegen, aber das Prefix – und somit die Nutzung des globalen IPv6-Bereiches – lässt sich hier nicht ändern. Theoretisch wäre es somit möglich, in den „DHCPv6 Static Mappings“ „feste“ IPv6-Adressen für den globalen Bereich zu vergeben, aber diese können sich immer nur auf den Interface-Identifier, d.h. den letzten Teil der IPv6-Adresse beziehen, da das Prefix vom Provider vorgegeben wird. Und genau hier liegt der Wermutstropfen, denn da das Prefix außerhalb des eigenen Einflussbereiches liegt und sich außerdem von Zeit zu Zeit ändert, sind derart vergebene „feste“ Adressen alles andere als statisch und somit ungeeignet für lokale Server bzw. Dienste, die tatsächlich statische IPv6-Adressen erhalten sollen.
Konkret schlug ChatGPT zunächst vor, den LAN-Port mit „Static IPv6“ einzurichten, um dann mittels DHCPv6-Server den Adressbereich für ULA verwalten zu lassen. Dass das ziemlicher Unfug war, liegt auf der Hand, schließlich sollten die IPv6-Adressen des Providers weiterhin funktionieren, insofern sollte diese Idee nicht zum Erfolg führen. Anschließend faselte die KI irgendwas davon, zwei Adressbereiche, d.h. ULA sowie globale Adressen parallel per DHCPv6 zuzuweisen. Vielleicht funktioniert dies sogar – falls der DHCPv6-Server eine derartige Konfiguration zulassen würde, bei pfSense habe ich jedoch keine Möglichkeit gefunden, dies einzurichten. Danach wollte ChatGPT ULA-Adressen als Alias einrichten, und zwar mit einer Option „Additional IPs“ – doch eine solche existierte nicht unter „Interfaces“ -> „LAN„. Ich vermute hierbei veraltete Daten als Ursprung, denn auch im nachfolgenden Vorschlag sollten „Custom RA Options“ genutzt werden, die in der aktuellen pfSense-Version jedoch überhaupt nicht existierten. Anschließend wurde es erst richtig kurios, die Vorschläge gingen dann so weit, einen separaten DHCPv6-Server zu verwenden, irgendwas mit „Host Overrides“ im DNS einzustellen, im Static Mapping des DHCPv6-Servers ULA-Adressen einzutragen, obwohl der Prefix aus dem globalen Adressbereich war usw., bis hin zu der Idee, dynamische ULA-Adressen im DNS-Server mittels Skript dynamisch zu aktualisieren, wobei das Bash-Skript bereits mitgeliefert wurde… An dieser Stelle wurde es einfach sinnlos, sich weiterhin mit ChatGPT zu befassen. Diese Eigenheit ist mir übrigens in der Vergangenheit mehrfach aufgefallen – man stellt anfangs eine Frage, die Lösung der KI erscheint auf den ersten Blick nicht schlecht, man probiert ein wenig, stellt fest, dass der Vorschlag nicht funktioniert, chattet ein wenig weiter, der Dialog entwickelt sich, man zeigt auf, dass die angegebene Lösung nicht funktioniert bzw. nicht funktionieren kann, ChatGPT nennt Alternativen, die auch nicht korrekt sind, und es geht von vorne los. Irgendwann ist ein Zeitpunkt erreicht, an dem die Vorschläge von ChatGPT so absurd und umständlich werden, oder die Ideen sich auch einfach nur ständig wiederholen, dass jede weitere Interaktion nur noch sinnlos ist. Ein wenig erinnert mich dieses Verhalten an die KI aus dem Film „WarGames“ anno 1983, als der Großrechner in Form eines Traktors namens „WOPR“ lernt, dass es Spiele ohne Sieger geben kann, respektive in einem Krieg nur Verlierer. Vielleicht lernt ChatGPT diese Fähigkeit ja irgendwann auch einmal, so dass man nicht in Wiederholungen von nicht funktionierenden Vorschlägen strandet.
ChatGPT, einfach mal die Klappe halten…
Letztendlich musste ich einsehen, dass die ursprüngliche Idee zumindest mit der aktuellen Version von pfSense nicht realisierbar war. Die einfachste Lösung war somit tatsächlich, die IPv6-Adressen aus dem ULA-Bereich statisch auf den jeweiligen Hosts zu definieren, somit auf eine Vergabe per DHCPv6 zu verzichten. Sicherlich wäre es schön gewesen, aber da es sich letztlich um eine Handvoll IPv6-Adressen handelt, die jeweils in der Netzwerk-Konfiguration der einzelnen Server bzw. VMs konfiguriert werden, hält sich der Aufwand zumindest in Grenzen.
Schritt 1: virtuelle ULA IPv6 für pfSense
Um das LAN-Interface der pfSense-Maschine mit einer zusätzlichen IPv6-Adresse zu bestücken, wird eine virtuelle IP-Adresse eingerichtet, die sich auf den ULA-Bereich bezieht. Dazu ist einfach unter „Firewall“ -> „Virtual IPs“ der Typ „IP Alias“ für das Interface „LAN“ zu wählen und die entsprechende Adresse einzutragen, ggf. noch eine Beschreibung zur eigenen Gedächtnisstütze hinzuzufügen, und die Konfiguration abzuspeichern.
Die so definierte ULA-Adresse steht sofort zur Verfügung, wird jedoch unter „Status“ -> „Interfaces“ zumindest bei mir nicht angezeigt, da dort nur eine Zeile für die IPv6-Adresse vorhanden ist. Mittels „Diagnostics“ -> „Command Prompt“ kann jedoch das Kommando „ifconfig“ unter „Execute Shell Command“ ausgeführt werden, was zur vollständigen Ausgabe der Konfigurationen sämtlicher vorhandener Interfaces führt. Ich nutze hierbei den Netzwerk-Port des Mainboards als LAN-Interface, das als „re0“ bezeichnet wird. Darunter findet sich auch die als Virtual IP vergebene IPv6-Adresse:
re0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 description: LAN options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE> ether xx:xx:xx:xx:xx:xx inet 192.168.10.2 netmask 0xffffff00 broadcast 192.168.10.255 inet 192.168.10.4 netmask 0xffffff00 broadcast 192.168.10.255 inet6 fe80::xxxx:xxxx:xxxx:xxxx%re0 prefixlen 64 scopeid 0x5 inet6 fe80::1:1%re0 prefixlen 64 scopeid 0x5 inet6 fdec:e179:117a::4 prefixlen 64 inet6 2a0a:a541:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx prefixlen 64 media: Ethernet autoselect (1000baseT <full-duplex>) status: active nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
Neben der IPv6-Adresse aus dem Provider-Bereich, beginnend mit „2a0a:...“ finden sich die link-local-Adressen, ebenso die IPv4-Adressen, sowie die virtuelle IPv6-Adresse, die ich der Einfachheit halber analog zur ebenfalls virtuellen IPv4-Adresse eingerichtet habe (:4 bzw. .4).
Damit hat pfSense seine statische IPv6-ULA-Adresse erhalten. Nun muss nur noch dafür gesorgt werden, dass IPv6-Adressen an die angeschlossenen Hosts verteilt werden, was insbesondere relevant ist für diejenigen Rechner, bei denen die ULA-Adresse nicht statisch definiert wird. Damit einher geht die Verteilung der IPv6-Adresse des DNS-Servers, d.h. der IPv6-Adresse von Pi-Hole. Letztlich erhält somit jeder Host eine IPv6-Adresse aus dem ULA-Bereich bzw. sucht sich eine solche aus, und zusätzlich wird bei ausgewählten Rechnern eine ULA-Adresse statisch definiert, insbesondere auf den VMs von Pi-Hole und den DNS-Servern. Davon unabhängig ist die Nutzung und Vergabe der IPv6-Adresse aus dem globalen Bereich.
Schritt 2: WAN, LAN, alles wie gehabt…
Also kümmern wir uns zunächst darum. Grundsätzlich bleibt die Konfiguration wie unter „IPv6 im Heimnetz mit pfSense und dynamischer Prefix Delegation“ beschrieben, erst einmal bestehen. Das betrifft zunächst die Konfiguration des WAN-Interfaces:
Hier kommen praktisch alle Daten von der davor geschalteten FRITZ!Box, pfSense agiert als Client und übernimmt per „DHCP6“ die vom Provider zugewiesenen IPv6-Netze. Auch die Einstellungen des LAN-Interfaces haben sich nicht geändert:
Insbesondere bleibt hierbei „Track Interface“ für IPv6 bestehen, damit die IPv6-Adressen des Providers auch an die internen Netze durchgereicht werden.
Schritt 2a: Kein DHCPv6 Server auf pfSense
Ein Unterschied ergibt sich in den Einstellungen des zuvor noch aktivierten DHCPv6-Servers:
Dieser ist nun tatsächlich deaktiviert, die Vergabe von Provider-IPv6-Adressen erfolgt nun nicht mehr durch pfSense, sondern wird vom übergeordneten DHCPv6-Server, d.h. letztlich der FRITZ!Box, vorgenommen. Damit sind auch die übrigen Einstellungen letztlich egal, ich hatte einzig als DNS-Server den inzwischen intern über IPv6 erreichbaren Pi-Hole eingetragen, da zuvor dort die automatisch vergebene IPv6-Adresse des DNS der FRITZ!Box enthalten war.
Schritt 3: Router Advertisement für IPv6 ULA
Interessanter wird es nun beim internen IPv6-Netz aus dem ULA-Bereich. Hierbei spielt der Router Advertisement Service die entscheidende Rolle. Die Einstellungen unter „Services“ -> „Router Advertisement“ -> „LAN“ sehen wie folgt aus:
Die Konfiguration im Detail:
- Router Mode: Assisted. Hierbei werden RA-Pakete ausgesendet, so dass Adressen über DHCPv6 oder SLAAC (Stateless Address Autoconfiguration) zugewiesen werden. Ungeprüft, aber theoretisch müsste auch „Unmanaged“ funktionieren, d.h. dass RA Pakete sendet, die Clients anweisen, sich IPv6-Adressen per SLAAC selbst zuzuweisen, wobei DHCPv6 deaktiviert ist. Zugegebenermaßen empfinde ich diese RA-Modi immer noch als verwirrend, vor allem da sich die Funktionalität teilweise zu überlagern scheint.
- RA Subnet(s): Hier werden die Subnetze hinzugefügt, für die RA-Pakete gesendet werden sollen. An der Stelle nimmt somit das ULA-Netz Platz, so dass sich die Clients eine IPv6-Adresse aus dem entsprechenden Bereich zuweisen können.
- Enable DNS: Da die IPv6-Adresse des Pi-Hole-Servers als DNS-Adresse im internen Netz genutzt werden soll, ist es sinnvoll, diese Option zu aktivieren, so dass die DNS-Konfiguration per RA erfolgt.
- DNS Server 1: Hier ist die IPv6-Adresse von Pi-Hole enthalten. Die weiteren drei möglichen Einträge für DNS-Server bleiben ungenutzt, da Pi-Hole als einziger DNS-Server innerhalb des Heimnetzes Verwendung finden soll.
Alle anderen Einstellungen bleiben unverändert bzw. beim Default. Nach dem Speichern und ggf. Reload des RA-Daemons sollten die entsprechenden IPv6-Adressen bei den Clients ankommen, je nach Client muss ggf. die Netzwerk-Konfiguration neu geladen werden.
Folgendes Beispiel zeigt die Konfiguration der primären Netzwerk-Schnittstelle auf einer VM unter Linux:
geschke@gatow:~$ ip a
[...]
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
altname enp0s3
inet 192.168.10.110/24 metric 100 brd 192.168.10.255 scope global dynamic ens3
valid_lft 5440sec preferred_lft 5440sec
inet6 2a0a:a541:xxxx:xxxx:0123:4567:89ab:cdef/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 85958sec preferred_lft 13958sec
inet6 fdec:e179:117a:0:0123:4567:89ab:cdef/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 85958sec preferred_lft 13958sec
inet6 fe80::0123:4567:89ab:cdef/64 scope link
valid_lft forever preferred_lft forever
[...]
Zwar habe ich hier aus Gründen hier die MAC-Adresse und die IP-Adressen ein wenig modifiziert, aber ich denke, das Schema wird deutlich: Der 64 Bit lange hintere Teil, d.h. der Host-Adressanteil (Interface Identifier), ist in allen IPv6-Netzen identisch.
Schritt 4: Statische IPv6-Adressen
Bereits zu dem Zeitpunkt könnte man die ULA-Adresse („fdec:e179:117a:...„) als statisch bezeichnen, oder eine Vorstufe davon, nennen wir sie mal semi-statisch, da z.B. eine Änderung der MAC-Adresse auch zu einer Änderung des Interface Identifiers führen würde. Dies gilt allerdings auch nur, sofern die IPv6-Eigenschaft der „Privacy Extensions“ nicht aktiv sind, die die Bindung von MAC-Adresse und Interface Identifier aufheben und somit eine mehr oder minder zufällige Zuordnung ermöglichen.
Und da Router Advertisements kein statisches Mapping von MAC-Adresse bzw. DUID zu einer IPv6-Adresse ermöglichen, und DHCPv6 nicht für die ULA-Adressbereiche nutzbar ist, bleibt zur Einrichtung von statischen IPv6-Adressen nur noch die Netzwerkkonfiguration des jeweiligen Clients übrig. Zu Beginn der erneuten Odyssee ins IPv6-Land hatte ich diese Möglichkeit zwar explizit ausgeschlossen, aber letztlich erscheint es mir in der Situation ein akzeptabler Kompromiss zu sein, bei dem sich der Aufwand noch in Grenzen hält. Letztlich handelt es sich um ein paar VMs bzw. Server, die unter einer statischen IPv6-Adresse angesteuert werden sollen, an erster Stelle stehen dabei Pi-Hole und die DNS-Server, alle anderen tragen nicht zur Lösung des ursprünglichen Problems bei und sind somit optional.
Mittels der unter Ubuntu Linux verwendete Netzwerk-Konfigurations-Abstraktion netplan könnte die Konfigurationsdatei in /etc/netplan/ wie folgt aussehen:
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
version: 2
renderer: networkd
ethernets:
ens3:
addresses:
- fdec:e179:117a::101/64
dhcp4: yes
dhcp6: yes
Es genügt somit, die gewünschte IPv6-ULA-Adresse einzutragen, per netplan apply wird diese übernommen.
Das Ergebnis zeigt sich daraufhin sofort:
geschke@moabit:~$ ip a
[...]
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
altname enp0s3
inet 192.168.10.101/24 metric 100 brd 192.168.10.255 scope global dynamic ens3
valid_lft 3941sec preferred_lft 3941sec
inet6 2a0a:a541:xxxx:xxxx:0123:4567:89ab:cdef/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 86175sec preferred_lft 14175sec
inet6 fdec:e179:117a:0:0123:4567:89ab:cdef/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 86175sec preferred_lft 14175sec
inet6 fdec:e179:117a::101/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::0123:4567:89ab:cdef/64 scope link
valid_lft forever preferred_lft forever
Die statisch konfigurierte IPv6-Adresse wird zusätzlich zu der durch RA gewählten angelegt. Damit ist der Host auch unter beiden IPv6-Adressen aus dem ULA-Bereich erreichbar:
geschke@gatow:~$ ping6 fdec:e179:117a::101 PING fdec:e179:117a::101 (fdec:e179:117a::101) 56 data bytes 64 bytes from fdec:e179:117a::101: icmp_seq=1 ttl=64 time=0.680 ms 64 bytes from fdec:e179:117a::101: icmp_seq=2 ttl=64 time=0.598 ms 64 bytes from fdec:e179:117a::101: icmp_seq=3 ttl=64 time=0.574 ms 64 bytes from fdec:e179:117a::101: icmp_seq=4 ttl=64 time=0.682 ms ^C --- fdec:e179:117a::101 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3062ms rtt min/avg/max/mdev = 0.574/0.633/0.682/0.048 ms geschke@gatow:~$ ping6 fdec:e179:117a:0:0123:4567:89ab:cdef PING fdec:e179:117a:0:0123:4567:89ab:cdef (fdec:e179:117a:0:0123:4567:89ab:cdef) 56 data bytes 64 bytes from fdec:e179:117a:0:0123:4567:89ab:cdef: icmp_seq=1 ttl=64 time=0.521 ms 64 bytes from fdec:e179:117a:0:0123:4567:89ab:cdef: icmp_seq=2 ttl=64 time=0.641 ms ^C
An dieser Stelle muss ich mich beim User „the other“ aus dem „Heimnetz“-Forum bedanken, der eine für ihn funktionierende Lösung im Thread unter „IPv6 – Verteilung von ULA“ beschrieben hat. Der Beitrag im Forum ist zwar wesentlich kürzer, aber letztlich basiert die hier dargestellte Konfiguration darauf.
Im nächsten Teil werde ich noch auf die Einrichtung von Pi-Hole und den DNS-Servern eingehen, und evtl. noch zwei, drei Wörter zu keepalived schreiben. Und ich fürchte, das könnte wieder ein wenig länger werden als geplant…