linux:radvd

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung		 Vorhergehende Überarbeitung
linux:radvd [06.07.2024 20:30. ] – [Rolle] djangolinux:radvd [10.07.2024 18:40. ] (aktuell) – [RA — Router Advertisement (ICMPv6 type 134)] django
Zeile 61: Zeile 61:
  
 === RA — Router Advertisement (ICMPv6 type 134) === === RA — Router Advertisement (ICMPv6 type 134) ===
-**Router Advertisment Nachrichten** werden vom Server entweder regelmässig an alle Clients im Netz oder ebnen speziell auf An Anfrage durch einen Client versandt. Es handelt sich also im ersten Fall um eine ICMPv6-Nachricht, die an die All-Nodes-Multicast-Adresse (ff02::1) oder eben als Unicast-Nachricht an einen bestimmten Host gesendet wird.+**Router Advertisment Nachrichten** werden vom Server entweder regelmässig an alle Clients im Netz oder ebnen speziell auf An Anfrage durch einen Client versandt. Es handelt sich also im ersten Fall um eine ICMPv6-Nachricht, die an die All-Nodes-Multicast-Adresse (ff02::1) oder eben als Unicast-Nachricht an einen bestimmten Host gesendet wird.e
   * Ein Router verwenden diese RA-Nachrichten, um seine Anwesenheit, Netzwerkparameter und weitere Konfigurationsoptionen für Hosts bekannt zu geben.   * Ein Router verwenden diese RA-Nachrichten, um seine Anwesenheit, Netzwerkparameter und weitere Konfigurationsoptionen für Hosts bekannt zu geben.
   * Hosts verwerten diese RA-Nachrichten, um daraus z.B. den Default-Router, den bzw. die Netzwerk-Präfixe, die Link-MTU oder ob z.B. ein DHCPv6-Server im Netz verfügbar ist, sowie weitere relevante Netzwerkinformationen abzuleiten. \\ Ist ein DHCPv6-Server verfügbar ist, wird dies durch zwei Flags in der Router-Ankündigung angezeigt. Diese Flags sind das Konfigurationsflag für die verwaltete Adresse und das andere Konfigurationsflag. Das M-Bit und das O-Bit werden verwendet, um diese Flaggen zu setzen. Das M-Bit zeigt an, dass DHCPv6-Dienste für Adress- und Konfigurationseinstellungen verfügbar sind. Das O-Bit zeigt an, ob andere Konfigurationsparameter als die IP-Adresse über den DHCPv6-Dienst verfügbar sind. RAs bestehen also aus bestimmten Flags und Optionen (Präfix, MTU, DNS, SLLA - Src Link-Layer Address). Die wichtigsten Optionen sind hierbei:   * Hosts verwerten diese RA-Nachrichten, um daraus z.B. den Default-Router, den bzw. die Netzwerk-Präfixe, die Link-MTU oder ob z.B. ein DHCPv6-Server im Netz verfügbar ist, sowie weitere relevante Netzwerkinformationen abzuleiten. \\ Ist ein DHCPv6-Server verfügbar ist, wird dies durch zwei Flags in der Router-Ankündigung angezeigt. Diese Flags sind das Konfigurationsflag für die verwaltete Adresse und das andere Konfigurationsflag. Das M-Bit und das O-Bit werden verwendet, um diese Flaggen zu setzen. Das M-Bit zeigt an, dass DHCPv6-Dienste für Adress- und Konfigurationseinstellungen verfügbar sind. Das O-Bit zeigt an, ob andere Konfigurationsparameter als die IP-Adresse über den DHCPv6-Dienst verfügbar sind. RAs bestehen also aus bestimmten Flags und Optionen (Präfix, MTU, DNS, SLLA - Src Link-Layer Address). Die wichtigsten Optionen sind hierbei:
Zeile 67: Zeile 67:
     * **Home-Agent H-Flag**: Dieses Flag wird verwendet, um anzuzeigen, dass es sich bei dem beworbenen Präfix um ein Heimnetzwerk-Präfix handelt, insbesondere für Mobile IPv6, dass sie also somit als Home Agent für Mobile IPv6 fungieren und Dienste für mobile Knoten bereitstellen können.     * **Home-Agent H-Flag**: Dieses Flag wird verwendet, um anzuzeigen, dass es sich bei dem beworbenen Präfix um ein Heimnetzwerk-Präfix handelt, insbesondere für Mobile IPv6, dass sie also somit als Home Agent für Mobile IPv6 fungieren und Dienste für mobile Knoten bereitstellen können.
     * **On-link L-Flag**: Ist dieses Flag gesetzt, wird definiert dass ein bestimmtes Präfix als "on-link" betrachtet wird, d.h. dass Hosts Adressen innerhalb dieses Präfixes verwenden können, um direkt mit anderen Hosts auf demselben Link zu kommunizieren. Ist das L-Flag nicht gesetzt, müssen Hosts einen Router verwenden um Hosts in diesem Präfix erreichen zu können.     * **On-link L-Flag**: Ist dieses Flag gesetzt, wird definiert dass ein bestimmtes Präfix als "on-link" betrachtet wird, d.h. dass Hosts Adressen innerhalb dieses Präfixes verwenden können, um direkt mit anderen Hosts auf demselben Link zu kommunizieren. Ist das L-Flag nicht gesetzt, müssen Hosts einen Router verwenden um Hosts in diesem Präfix erreichen zu können.
-    * **Managed M-Flag** : Eine '1' bedeutet, dass die Adresse durch stateful DHCPv6 bereitgestellt wird.+    * **Managed M-Flag** : Eine '1' bedeutet, dass die Adresse durch Stateful DHCPv6 bereitgestellt wird.
     * **Other O-Flag** : Eine '1' bedeutet, dass die Adresse von Stateless DHCPv6 bereitgestellt wird, was für die Bereitstellung von Optionen nützlich ist, wenn der Client SLAAC-StatelessAddress Autoconfiguration durchführt.     * **Other O-Flag** : Eine '1' bedeutet, dass die Adresse von Stateless DHCPv6 bereitgestellt wird, was für die Bereitstellung von Optionen nützlich ist, wenn der Client SLAAC-StatelessAddress Autoconfiguration durchführt.
     * **Router-Präferenz (Prf)**: Der Wert in diesem Feld steht für die Präferenzstufe des Routers, der die RA-Nachricht sendet. So wird z.B. darüber ermittelt ob das Gateway als Standardgateway fungieren soll. Das Prf-Feld kann drei Werte annehmen: Hoch (0x00), Mittel (0x40) oder Niedrig (0x80). Router mit einem höheren Präferenzwert werden gegenüber Routern mit niedrigeren Werten bevorzugt.     * **Router-Präferenz (Prf)**: Der Wert in diesem Feld steht für die Präferenzstufe des Routers, der die RA-Nachricht sendet. So wird z.B. darüber ermittelt ob das Gateway als Standardgateway fungieren soll. Das Prf-Feld kann drei Werte annehmen: Hoch (0x00), Mittel (0x40) oder Niedrig (0x80). Router mit einem höheren Präferenzwert werden gegenüber Routern mit niedrigeren Werten bevorzugt.
Zeile 174: Zeile 174:
 <WRAP center round info 80%> <WRAP center round info 80%>
 Starten werden wir den **radvd**-Daemon erst einmal noch nicht, da wir diesen ja noch konfigurieren müssen. Nachfolgend werden wir noch detailliert zu einzelnen Anwendungsfällen eingehen: Starten werden wir den **radvd**-Daemon erst einmal noch nicht, da wir diesen ja noch konfigurieren müssen. Nachfolgend werden wir noch detailliert zu einzelnen Anwendungsfällen eingehen:
-  - **[[#slaac_-_ipv6_stateless_address_auto-configuration|SLAAC - IPv6 Stateless Address Auto-configuration]]** +  - **[[#slaac_-_ipv6_stateless_address_auto-configuration|Konfigurationsbeispiel: SLAAC - IPv6 Stateless Address Auto-configuration]]** 
-  - **[[#router_advertisement_icmpv6-nachrichten_fuer_stateful_dhcpv6|DHCPv6 - stateless und stateful]]** +  - **[[#router_advertisement_icmpv6-nachrichten_fuer_stateful_dhcpv6|Konfigurationsbeispiel: DHCPv6 - stateless und stateful]]** 
 +  - **[[#musterkonfiguration_gua_via_slaac_und_ula_via_dhcpv6|Musterkonfiguration für GUA via SLAAC und statischen festen ULA mit Hilfe von DHCPv6]]**
 </WRAP> </WRAP>
  
-==== SLAAC - IPv6 Stateless Address Auto-configuration ==== +==== Konfigurationsbeispiel für SLAAC ==== 
-=== Was ist SLAAC und wie funktioniert es ===+=== Was ist SLAAC (IPv6 Stateless Address Autoconfiguration) und wie funktioniert es ===
 Bevor wir uns nun mit der Konfiguration unseres **radvd** beschäftigen, machen wir erst einmal klar, was SLAAC ist und wie es funktioniert. Jeder IPv6-Host in unserem Netz benötigt eine weltweit eindeutige Adresse, damit dieser auch ausserhalb dessen lokalen Segments kommunizieren zu können. Bevor wir uns nun mit der Konfiguration unseres **radvd** beschäftigen, machen wir erst einmal klar, was SLAAC ist und wie es funktioniert. Jeder IPv6-Host in unserem Netz benötigt eine weltweit eindeutige Adresse, damit dieser auch ausserhalb dessen lokalen Segments kommunizieren zu können.
  
Zeile 226: Zeile 226:
  
 Bei unserem Konfigurationsbeispiel hier gehen wir für den Router Advertisement Daemon **radvd** für die Adressvergabe über **SLAAC** von folgenden Eckwerten aus: Bei unserem Konfigurationsbeispiel hier gehen wir für den Router Advertisement Daemon **radvd** für die Adressvergabe über **SLAAC** von folgenden Eckwerten aus:
-  * **Netzwerkinterface** : \\ Der **radvd** soll nure auf dem Netzwerkinterface **''eth1''** operieren, also dort lauscht er auf Router Solicitation ICMPv6-Nachrichten neuer Klients und beantwortet selbige mit Router Advertisements ICMPv6-Nachrichten bzw. sendet auf dieser Netzwerkschnittstelle regelmäßig seine Router Advertisements ICMPv6-Nachrichten an alle Clients im lokalen betreffenden Netz.+  * **Netzwerkinterface** : \\ Der **radvd** soll nure auf dem Netzwerkinterface **''eth1''** operieren, also dort lauscht er auf Router Solicitation ICMPv6-Nachrichten neuer Clients und beantwortet selbige mit Router Advertisements ICMPv6-Nachrichten bzw. sendet auf dieser Netzwerkschnittstelle regelmäßig seine Router Advertisements ICMPv6-Nachrichten an alle Clients im lokalen betreffenden Netz.
   * **M-Flag**: \\ AdvManagedFlag = **''off''** (Adresskonfiguration über SLAAC)   * **M-Flag**: \\ AdvManagedFlag = **''off''** (Adresskonfiguration über SLAAC)
   * **O-Flag**: \\ AdvOtherConfigFlag = **''on''** (Abrufen einer DNS-Serverliste und einen Domain-Namen von einem Stateless DHCPv6-Server, aber __keine__ keine Adressierungsinformationen.    * **O-Flag**: \\ AdvOtherConfigFlag = **''on''** (Abrufen einer DNS-Serverliste und einen Domain-Namen von einem Stateless DHCPv6-Server, aber __keine__ keine Adressierungsinformationen. 
-  * **A-Flag**: \\AdvAutonomous = **''on''** (Adresskonfiguration über SLAAC)+  * **A-Flag**: \\ AdvAutonomous = **''on''** (Adresskonfiguration über SLAAC)
   * **Global-Scope Address Prefix** : \\ **''2001:a:bcd:1234''**   * **Global-Scope Address Prefix** : \\ **''2001:a:bcd:1234''**
     * **Route** : \\ **''2001:a:bcd:1234::/64''** und eine Gültigkeit von einer 1/2 Stunde, also **''1800''** Sekunden.     * **Route** : \\ **''2001:a:bcd:1234::/64''** und eine Gültigkeit von einer 1/2 Stunde, also **''1800''** Sekunden.
Zeile 698: Zeile 698:
 </WRAP> </WRAP>
  
-Warum ist das nun so? Ganz einfach, weil am Client-Renchner noch keine Privacy Extension ausgewählt wurde. Werfen wir einen Blick in die betreffende Konfigurationsdatei **''/etc/sysctl.d/10-ipv6-privacy.conf''**.+Warum ist das nun so? Ganz einfach, weil am Client-Rechner noch keine Privacy Extension ausgewählt wurde. Werfen wir einen Blick in die betreffende Konfigurationsdatei **''/etc/sysctl.d/10-ipv6-privacy.conf''**.
    # vim /etc/sysctl.d/10-ipv6-privacy.conf    # vim /etc/sysctl.d/10-ipv6-privacy.conf
 <file bash /etc/sysctl.d/10-ipv6-privacy.conf># Django : manual on 2024-06-27 <file bash /etc/sysctl.d/10-ipv6-privacy.conf># Django : manual on 2024-06-27
Zeile 763: Zeile 763:
 </WRAP> </WRAP>
  
-==== Router Advertisement ICMPv6-Nachrichten für Stateful DHCPv6 ====+==== Konfigurationsbeispiel DHCPv6 ==== 
 +=== Router Advertisement ICMPv6-Nachrichten für Stateful DHCPv6 ===
 Ein **Stateful DHCPv6-Server** liefert neben IPv6-Adressen auch weitere Informationen, wie z.B. wie eine DNS-Serverliste und einen Domänennamen, an einen Host aus. Hosts. Dieser Stateful DHCPv6-Server behält auch den Status jeder Zuweisung im Auge, sprich er verfolgt die Verfügbarkeit des Adresspools und löst doppelte Adresskonflikte auf. Darüber hinaus protokolliert er jede Zuweisung und behält die Ablaufzeiten im Auge. Im Gegensatz zu IPv4 stellt ein Stateful DHCPv6-Server den Hosts keine Standard-Gateway-Adressen zur Verfügung, das kann bei IPv6 nur Router, die Router Advertisement-Nachrichten sendet wie z.B. unser **radvd**! Ein **Stateful DHCPv6-Server** liefert neben IPv6-Adressen auch weitere Informationen, wie z.B. wie eine DNS-Serverliste und einen Domänennamen, an einen Host aus. Hosts. Dieser Stateful DHCPv6-Server behält auch den Status jeder Zuweisung im Auge, sprich er verfolgt die Verfügbarkeit des Adresspools und löst doppelte Adresskonflikte auf. Darüber hinaus protokolliert er jede Zuweisung und behält die Ablaufzeiten im Auge. Im Gegensatz zu IPv4 stellt ein Stateful DHCPv6-Server den Hosts keine Standard-Gateway-Adressen zur Verfügung, das kann bei IPv6 nur Router, die Router Advertisement-Nachrichten sendet wie z.B. unser **radvd**!
  
Zeile 1159: Zeile 1160:
 Verbindet sich nun ein Client mit dem Netzwerk, handelt dieser **__nicht__** eigenständig seine IPv6-Adressen aus, sondern richtet eine entsprechende Anfrage an den DHCPv6-Server! Verbindet sich nun ein Client mit dem Netzwerk, handelt dieser **__nicht__** eigenständig seine IPv6-Adressen aus, sondern richtet eine entsprechende Anfrage an den DHCPv6-Server!
  
 +==== Musterkonfiguration GUA via SLAAC und ULA via DHCPv6 ====
 +=== Grundüberlegungen ===
 +In den beiden vorgenannten Konfigurationsbeispielen **[[#konfigurationsbeispiel_fuer_slaac|Konfigurationsbeispiel für SLAAC]]** und **[[#konfigurationsbeispiel_dhcpv6|Konfigurationsbeispiel DHCPv6]]** haben wir gesehen, dass wir mit den **''M''**- und **''A''**-Flag steuern können, wie ein Client, wenn er sich mit unserem Netzwerk verbindet, zu einer oder mehreren IP-v6-Adressen kommen kann. Auch da Thema **[[#slaac_und_privacy_extension_-_konfiguration_der_arch_linux_clients|SLAAC und Privacy Extension]]** bei de Konfiguration der (Arch Linux) Clients haben wir uns im Detail vorgenommen. 
 +
 +Wenn wir uns mit dem Thema IPv6 im Intranet befassen, wird sich in aller Regel folgende Frage stellen: Welche Typen von Adressen werden benötigt und welche sollen letztendlich auch wirklich genutzt werden. Nun Gut, die **L**ink **L**ocla **A**ddress generiert ein Host selbst wie wir bereits wissen, denn ohne diese könnte er z.B. kein SLAAC initiieren. 
 +
 +<WRAP center round important 80%>
 +Betrachten wir also nun die **U**nified **L**ocal **A**ddress, können wir erkennen, dass mit Hilfe dieser Adressen z.B. ein Laptop den Drucker im Netz direkt erreichen kann, denn wollen wir unserem Drucker eine öffentliche IP-Adresse verpassen? Nein, sicherlich nicht! Ausserdem soll es ja unter anderem **ISP**((**I**nternet **S**ervice **P**rovider)) geben, die ihren Kunden mit Hinweis von //Privatsphäre// **__keine__** statischen **''/56''** oder **''/64''** zuweisen sondern lediglich dynamische Prefixe, die sich bei jeder Neueinwahl oder auch 1x Pro Tag ändern. Würde man mit Hilfe von Prefix-Delegation nun diesen vom ISP zugewiesenen dynamischen Prefix im Intranet weiterverwenden wollen, würde sich in unserem Beispiel auch jedes mal die **GUA** des Drucker ändern - welch gruselige Vorstellung und administrativ kaum handelbar! :-? Gar nicht toll, gar nicht schön ... Moment, da war doch noch so ein Thema, statische feste IPv6 **GUA**: Wie wir beim Abschnitt **[[#slaac_und_privacy_extension_-_konfiguration_der_arch_linux_clients|SLAAC und privacy extension]]** bereits bemerkt haben, können einzelnen Nutzer mit ihren Geräten anhand der letzten 48 Bits der IPv6-Adresse weltweit trackbar werden. Nun Gut unter SLAAC gibt es die Option **//privacy extension//**, in den RFCs zu **DHCPv6** sucht man aber leider vergebens nach einer derartigen Option - O.K. zumindest im Jahre 2024 noch! Als sind statische eineindeutige **GUA** im Intranet eigentlich auch nichts was man sehen und haben möchte!
 +</WRAP>
 +<WRAP center round info 80%>
 +
 +Je länger man sich nun mit der ganzen Thematik um nicht Misere zu sagen beschäftigt kommt man zu folgender Musterkonfigurationslösung: 
 +  - **ULA**:
 +    - Wir wollen statische eineindeutige wiederkehrende feste **ULA**s die wir per **DHCPv6** auf Basis der **DUID** oder anderen dem Host zuordenbare Eigenschafte fest vergeben.
 +    - Gästen oder entsprechenden Geräte lassen wir aus einem dynamischen Pool **ULA** zuweisen.
 +  - **GUA**: 
 +    - Die öffentlichen **IPv6** Adressen (**GUA**)) vergeben wir dynamisch via SLAAC.
 +    - Laptops oder Notebooks auf denen ein aktuelles fortschrittliches Linux, wie z.B. **[[https://archlinux.org/|Arch Linux]]** läuft, konfigurieren wir so, dass diese sich regelmässig mit den Optionen der privacy extension, neu Adressen via SLAAC holen.
 +    - Bei mobilen Geräten aus dem Hause Apple mit ihrem **[[https://de.wikipedia.org/wiki/IOS_(Betriebssystem)|IOS Betriebssystem]]** oder Google mit ihrem **[[https://de.wikipedia.org/wiki/Android_(Betriebssystem)|Android Betriebssystem]]** sind wir auf Gedeih und Verderben diesen Firmen ausgeliefert und müssen vertrauen, dass diese doch irgendwann andere MAC-Adressen in kurzen Zeitabständen selbst generieren. Spoiler: Besser nicht danach suchen, die Ergebnisse im Jahre 2024 sind mehr als **<%%-%%redacted%%-%%>** und vorab von dem was man eigentlich erhoffen und erwarten würde!
 +Wir wollen uns also nun ansehen, wie wir solch ein Muster-Szenario abbilden können
 +</WRAP>
 +
 +<WRAP center round alert 80%>
 +Der geneigte Leser wir sich nun fragen, ja wie macht man denn nun das beim **radvd**? Denn schliesslich wissen wir ja dass wir bei Nutzung von **SLAAC** die bekannten Flags wir folgt setzen müssen:
 +  * **M-Flag**: \\ AdvManagedFlag = **''off''** (Adresskonfiguration über SLAAC)
 +  * **O-Flag**: \\ AdvOtherConfigFlag = **''on''** (Abrufen einer DNS-Serverliste und einen Domain-Namen von einem Stateless DHCPv6-Server, aber __keine__ keine Adressierungsinformationen. 
 +  * **A-Flag**: \\ AdvAutonomous = **''on''** (Adresskonfiguration über SLAAC)
 +Hingegen bei **DHCPv6** hingegen müssen wir die Flags wie folgt setzen.
 +  * **M-Flag**: \\ AdvManagedFlag = **''on''** (Adresskonfiguration via Stateful DHCPv6)
 +  * **O-Flag**: \\ AdvOtherConfigFlag = **''on''** (Abrufen einer DNS-Serverliste und einen Domain-Namen von einem Stateless DHCPv6-Server, aber __keine__ keine Adressierungsinformationen. 
 +  * **A-Flag**: \\ AdvAutonomous = **''off''** (Adresskonfiguration via Stateful DHCPv6)
 +
 +O.K. das **''O''**-Flag macht uns keine Sorgen, das setzen wir ja immer auf **''on''**. Das **A-Flag** wird über die Konfigurationsoption **''AdvAutonomous''** entweder auf **''on''** bei **SLAAC** gesetzt und auf **''off''** **bei DHCPv6**. Da diese Option im jeweiligen Prefix-Abschnitt in der Konfigurationsdatei **''radvd.conf''** definiert wird, ist das auch keine allzu grosse Herausforderung. O.K. was bleibt übrig? Richtig, das **''M''**-Flag, welches bei **SLAAC** mit der Konfigurationsoption **''AdvManagedFlag''** auf **''off''** gesetzt werden muss und bei **DHCPv6** eben auf **''on''**. Tja aber leider ist die Konfigurationsoption **''AdvManagedFlag''** **__global__** in der Konfigurationsdatei **''radvd.conf''**, sie kann also nur **__1x__** definiert werden und leider nicht **__2-mal__** wie wir es eigentlich bräuchten!
 +</WRAP>
 +
 +=== radvd Konfiguration ===
 +Wie wir aber dennoch eine funktionierende Konfiguration des **radvd** hierzu hinbekommen werden wir uns nun ansehen. **SPOILER**: Ja die Konfiguration läuft wirklich uns wurde in fast Tagelangen nein Nächtelangen **[[https://de.wikipedia.org/wiki/Versuch_und_Irrtum|triel-and-error]]** Runden mehrfach validiert1 In unserem Konfigurationsbeispiel gehen wir von folgenden Rahmenbedingungen aus:
 +
 +  * **Netzwerkinterface** : \\ Der **radvd** soll auf dem Netzwerkinterface **''eth1''** operieren, also dort lauscht er auf Router Solicitation ICMPv6-Nachrichten neuer Clients und beantwortet selbige mit Router Advertisements ICMPv6-Nachrichten bzw. sendet auf dieser Netzwerkschnittstelle regelmässig seine Router Advertisements ICMPv6-Nachrichten an alle Clients im lokalen betreffenden Netz.
 +  * **GUA**
 +    * **SLAAC** : \\ Clients sollen sich über den Mechanismus **SLAAC** selbst öffentliche IPv6-Adressen generieren und das ohne Zuhilfenahme eines DHCPv6-Servers bei der Adressvergabe!
 +    * **Global-Scope Address Prefix** : \\ **''2001:a:bcd:1234''**
 +    * **Route** : \\ **''2001:a:bcd:1234::/64''** 
 +    * **AdvRouteLifetime** : \\ Gültigkeit der Routen Lifetime  von einer 1/2 Stunde, also **''1800''** Sekunden.
 +    * **M-Flag**: \\ AdvManagedFlag = **''off''** (Adresskonfiguration über SLAAC)
 +    * **O-Flag**: \\ AdvOtherConfigFlag = **''on''** (Abrufen einer DNS-Serverliste und einen Domain-Namen von einem Stateless DHCPv6-Server, aber __keine__ keine Adressierungsinformationen. 
 +    * **A-Flag**: \\ AdvAutonomous = **''on''** (Adresskonfiguration über SLAAC)
 +  * **ULA**
 +    * **DHCPv6** : \\ Der **radvd** lauscht auf dem Netzwerkinterface **''eth1''** des **radvd**-/**kea-dhcp6**-Host auf Router Solicitation ICMPv6-Nachrichten neuer Clients und beantwortet selbige mit Router Advertisements ICMPv6-Nachrichten bzw. sendet auf dieser Netzwerkschnittstelle regelmäßig seine Router Advertisements ICMPv6-Nachrichten an alle Clients im lokalen betreffenden Netz.
 +    * **Unique Local IPv6 prefix** : \\ Hier verwenden wir den zuvor erzeugten Unique Local IPv6 prefix von **''fdb6:cb48:9d77:0::/64''**.
 +    * **Route** : \\ **''fdb6:cb48:9d77:0::/64''**
 +    * **AdvRouteLifetime** : \\ Gültigkeit der Routen Lifetime  von einer 1/2 Stunde, also **''1800''** Sekunden.
 +    * **M-Flag**: \\ O.K. das **M-Flag** müssten wir ja eigentlich auf **''1''** AdvManagedFlag = **''on''** (Adresskonfiguration via Stateful DHCPv6) setzen. :!: Wir haben aber bereits bemerkt dass wir diese globale Option in der radvd.conf nur einmal setzen können - wir ignorieren also geflissentlich diese Option bei der **ULA** und **DHCPv6** :!:
 +    * **O-Flag**: \\ AdvOtherConfigFlag = **''on''** (Abrufen einer DNS-Serverliste und einen Domain-Namen von einem Stateless DHCPv6-Server, aber __keine__ keine Adressierungsinformationen. 
 +    * **A-Flag**: \\ AdvAutonomous = **''off''** (Adresskonfiguration via Stateful DHCPv6)
 +
 +Daraus ergibt sich nun folgende Konfigurationsdatei für unseren radvd: 
 +   # vim /etc/radvd.conf
 +<file bash /etc/radvd.conf># Configuration example for the router advertisement daemon radvd 
 +# for GUA and SLAAC as well as ULA with DHCPv6
 +#
 +#  - O-flag: AdvOtherConfigFlag = on (obtaining a DNS server list 
 +#            and a domain name from a Stateless DHCPv6 server, but
 +#            not addressing information.
 +#  - M-flag: AdvManagedFlag = off (address configuration via SLAAC for GUA)
 +#  - A-flag: AdvAutonomous = on (address configuration via SLAAC for GUA)
 +#  - A-flag: AdvAutonomous = off (address configuration via DHCPv6 for static ULA)
 +
 +interface eth1
 +{
 +  # A  flag  indicating  whether or not the router sends periodic 
 +  # router advertisements and responds to router solicitations.
 +  # This option no longer has to be specified first, but it needs
 +  # to be on to enable advertisement on this interface.
 +  AdvSendAdvert on;
 +
 +  # The  maximum  time  allowed between sending unsolicited multi-
 +  # cast router advertisements from the interface, in seconds.
 +  # Must be no less than 4 seconds and no greater than 1800 seconds.
 +  # Minimum when using Mobile IPv6 extensions: 0.07.
 +  # For values less than 0.2 seconds, 0.02 seconds is added to 
 +  # account for scheduling granularities as specified in RFC3775.
 +  MaxRtrAdvInterval 600;
 +
 +  # The minimum time allowed between sending unsolicited multicast
 +  # router advertisements from the interface, in seconds.
 +  # Must be no less than 3 seconds and no greater than 
 +  # 0.75 * MaxRtrAdvInterval.
 +  # Minimum when using Mobile IPv6 extensions: 0.03.
 +  MinRtrAdvInterval 200;
 +
 +  # The preference associated with the default router, as either 
 +  # "low", "medium", or "high".
 +  AdvDefaultPreference medium;
 +
 +  # Mobile IPv6 support, when set, indicates that sending router is 
 +  # able to serve as Mobile IPv6 Home Agent.
 +  # When set, minimum limits specified by Mobile IPv6 are used for 
 +  # MinRtrAdvInterval and MaxRtrAdvInterval.
 +  AdvHomeAgentFlag off;
 +
 +  # When set, hosts use the administered (stateful) protocol for 
 +  # address  autoconfiguration in  addition to any addresses 
 +  # autoconfigured using stateless address autoconfiguration.
 +  # The use of this flag is described in RFC 4862.
 +  # M-flag - if it is set to 1, this informs hosts that they can 
 +  # obtain a global address as well as DNS and a domain name from
 +  # a Stateful DHCPv6 server. Typically this means that auto-
 +  # addressing using SLAAC is not allowed on this segment and both
 +  # the A-flag and the O-flag are set to 0.
 +  AdvManagedFlag on;
 +
 +  # When set, hosts use the administered (stateful) protocol for 
 +  # autoconfiguration of other (non-address) information.
 +  # The use of this flag is described in RFC 4862
 +  # O-flag - if it is set to on, this informs hosts that they can
 +  # obtain a DNS server list and a domain name from a Stateless 
 +  # DHCPv6 server, but not addressing information. Typically it 
 +  # works in conjunction with SLAAC for auto-addressing and both
 +  # the A-flag and the O-flag are set to on.
 +  #
 +  AdvOtherConfigFlag on;
 +
 +  # The time, in milliseconds, that a node assumes a neighbor is 
 +  # reachable after having received a reachability confirmation.
 +  # Used by the Neighbor Unreachability Detection algorithm (see
 +  # Section 7.3 of RFC 4861).
 +  # A value of zero means unspecified (by this router).
 +  # Must be no greater than 3,600,000 milliseconds (1 hour).
 +  AdvReachableTime 0;
 +
 +  # The time,in milliseconds, between retransmitted Neighbor Soli-
 +  # citation messages. Used by address resolution and the Neighbor
 +  # Unreachability Detection algorithm (see Sections 7.2 and 7.3 
 +  # of RFC 4861).  A value of zero means unspecified (by this router).
 +  AdvRetransTimer 0;
 +
 +  # The default value that should be placed in the Hop Count field of
 +  # the IP header for outgoing (unicast) IP packets. The value should
 +  # be set to the current diameter of the Internet.
 +  # The value zero means unspecified (by this router).
 +  AdvCurHopLimit 64;
 +
 +  # The lifetime associated with the default router in units of seconds.
 +  # The maximum value corresponds to 18.2 hours. A lifetime of 0 indi-
 +  # cates that the router is not a default router and should not appear
 +  # on the default router list. The router lifetime applies only to the
 +  # router's usefulness as a default router; it does not apply to in-
 +  # formation contained in other message fields or options. Options that
 +  # need time limits for their information include their own lifetime 
 +  # fields.
 +  # Must be either zero or between MaxRtrAdvInterval and 9000 seconds.
 +  # Default: 3 * MaxRtrAdvInterval (Minimum 1 second).
 +  AdvDefaultLifetime 1800;
 +
 +  # When set, the link-layer address of the outgoing interface is 
 +  # included in the RA.
 +  AdvSourceLLAddress on;
 +
 +  # global-scope adress prefix
 +  prefix 2003:a:e0d:7607::/64
 +  {
 +    # When set, indicates that this prefix can be used for on-link 
 +    # determination. When not set the advertisement makes no statement
 +    # about on-link or off-link properties of the prefix. For instance,
 +    # the prefix might be used for address configuration with some of
 +    # the addresses belonging to the prefix being on-link and others 
 +    # being off-link.
 +    AdvOnLink on;
 +
 +    # When set, indicates that this prefix can be used for autonomous 
 +    # address configuration as specified in RFC 4862.
 +    # A-flag - if it is set to on, this informs hosts that they can 
 +    # auto-generate GUA address using SLAAC. If it is set to off means
 +    # that auto-configuration is not allowed for this segment.
 +    AdvAutonomous on;
 +
 +    # When set, indicates that the address of interface is sent instead
 +    # of network prefix, as is required by Mobile IPv6. When set, 
 +    # minimum limits specified by Mobile IPv6 are used for
 +    # MinRtrAdvInterval and MaxRtrAdvInterval.
 +    AdvRouterAddr off;
 +
 +    # The length of time in seconds (relative to the time the packet is 
 +    # sent) that the prefix is valid for the purpose of on-link de-
 +    # termination. The symbolic value infinity represents infinity 
 +    # (i.e. a value of all one bits (0xffffffff)). The valid lifetime
 +    # is also used by RFC 4862.
 +    #
 +    # Note that clients will ignore AdvValidLifetime of an existing
 +    # prefix if the lifetime is below two hours, as required in RFC
 +    # 4862 Section 5.5.3 point e).
 +    # Note: RFC4861's suggested default value is significantly longer:
 +    # 30 days.
 +    AdvValidLifetime 5400;
 +
 +    # The length of time in seconds (relative to the time the packet
 +    # is sent) that addresses generated from the prefix via stateless
 +    # address autoconfiguration remain preferred. The symbolic value
 +    # infinity represents infinity (i.e. a value of all one bits
 +    # (0xffffffff)).  See RFC 4862.
 +    #
 +    # Note: RFC4861's suggested default value is significantly longer:
 +    # 7 days.
 +    AdvPreferredLifetime 2700;
 +    };
 +
 + route 2003:a:e0d:7607::/64
 +  {
 +    # The preference associated with the default router, as either 
 +    # "low", "medium", or "high".
 +    AdvRoutePreference medium;
 +
 +    # The lifetime associated with the route in units of seconds. The
 +    # symbolic value infinity represents infinity (i.e. a value of
 +    # all one bits (0xffffffff)).
 +    #
 +    # Default: 3 * MaxRtrAdvInterval
 +    AdvRouteLifetime 1800;
 +  };
 +
 +  prefix fdb6:cb48:9d77:0::/64
 +  {
 +    # When set, indicates that this prefix can be used for on-link 
 +    # determination. When not set the advertisement makes no statement
 +    # about on-link or off-link properties of the prefix. For instance,
 +    # the prefix might be used for address configuration with some of
 +    # the addresses belonging to the prefix being on-link and others 
 +    # being off-link.
 +    AdvOnLink on;  
 +
 +    # When set, indicates that this prefix can be used for autonomous 
 +    # address configuration as specified in RFC 4862.
 +    # A-flag - if it is set to on, this informs hosts that they can 
 +    # auto-generate GUA address using SLAAC. If it is set to off means
 +    # that auto-configuration is not allowed for this segment.
 +    AdvAutonomous off;
 +
 +    # When set, indicates that the address of interface is sent instead
 +    # of network prefix, as is required by Mobile IPv6. When set, 
 +    # minimum limits specified by Mobile IPv6 are used for
 +    # MinRtrAdvInterval and MaxRtrAdvInterval.
 +    AdvRouterAddr off;
 +
 +    # The length of time in seconds (relative to the time the packet is 
 +    # sent) that the prefix is valid for the purpose of on-link de-
 +    # termination. The symbolic value infinity represents infinity 
 +    # (i.e. a value of all one bits (0xffffffff)). The valid lifetime
 +    # is also used by RFC 4862.
 +    #
 +    # Note that clients will ignore AdvValidLifetime of an existing
 +    # prefix if the lifetime is below two hours, as required in RFC
 +    # 4862 Section 5.5.3 point e).
 +    # Note: RFC4861's suggested default value is significantly longer:
 +    # 30 days.
 +    AdvValidLifetime 5400;
 +
 +    # The length of time in seconds (relative to the time the packet
 +    # is sent) that addresses generated from the prefix via stateless
 +    # address autoconfiguration remain preferred. The symbolic value
 +    # infinity represents infinity (i.e. a value of all one bits
 +    # (0xffffffff)).  See RFC 4862.
 +    #
 +    # Note: RFC4861's suggested default value is significantly longer:
 +    # 7 days.
 +    AdvPreferredLifetime 2700;
 +    };             
 +
 + route fdb6:cb48:9d77:0::/64
 +  {
 +    # The preference associated with the default router, as either 
 +    # "low", "medium", or "high".
 +    AdvRoutePreference medium;
 +
 +    # The lifetime associated with the route in units of seconds. The
 +    # symbolic value infinity represents infinity (i.e. a value of
 +    # all one bits (0xffffffff)).
 +    #                 
 +    # Default: 3 * MaxRtrAdvInterval
 +    AdvRouteLifetime 1800;
 +  };
 +                                                                                                                                              
 +};
 +</file>
 +
 +Wollen wir die Kondfigurationsdate ohne die Kommentare sehen, grep'en wir einfach entspprechend danach.
 +   # grep -Ev '(^.*#|^$)' /etc/radvd.conf
 +
 +++++ Beispielkonfigurationsdatei ohne Kommentare |
 +<code>interface eth1
 +{
 +  AdvSendAdvert on;
 +  MaxRtrAdvInterval 600;
 +  MinRtrAdvInterval 200;
 +  AdvDefaultPreference medium;
 +  AdvHomeAgentFlag off;
 +  AdvManagedFlag on;
 +  AdvOtherConfigFlag on;
 +  AdvReachableTime 0;
 +  AdvRetransTimer 0;
 +  AdvCurHopLimit 64;
 +  AdvDefaultLifetime 1800;
 +  AdvSourceLLAddress on;
 +  prefix 2003:a:e0d:7607::/64
 +  {
 +    AdvOnLink on;
 +    AdvAutonomous on;
 +    AdvRouterAddr off;
 +    AdvValidLifetime 5400;
 +    AdvPreferredLifetime 2700;
 +    };
 + route 2003:a:e0d:7607::/64
 +  {
 +    AdvRoutePreference medium;
 +    AdvRouteLifetime 1800;
 +  };
 +  prefix fdb6:cb48:9d77:0::/64
 +  {
 +    AdvOnLink on;  
 +    AdvAutonomous off;
 +    AdvRouterAddr off;
 +    AdvValidLifetime 5400;
 +    AdvPreferredLifetime 2700;
 +    };             
 + route fdb6:cb48:9d77:0::/64
 +  {
 +    AdvRoutePreference medium;
 +    AdvRouteLifetime 1800;
 +  };
 +                                                                                                                                              
 +};
 +</code>
 +++++
 +
 +Bevor wir nun unseren **radvd** starten, führen wir noch einen Konfigurationstest durch. 
 +Wir prüfen also nun die Konfigurationsdatei unseres **radvd** auf syntaktische Fehler.
 +   # radvd -cC /etc/radvd.conf
 +
 +  [Jul 09 17:59:05] radvd (1264): config file, /etc/radvd.conf, syntax ok
 +
 +Nun starten wir unseren **radvd** Daemon.
 +   # systemctl start radvd.service
 +
 +Im journald wir der Start entsprechend dokumentiert.
 +   # journalctl -fu radvd
 +
 +<code>Jul 09 18:00:37 vml000110 systemd[1]: Started IPv6 Router Advertisement Daemon.
 +Jul 09 18:00:37 vml000110 radvd[1296]: [Jul 09 18:00:37] radvd (1296): version 2.19 started</code>
 +Bei Bedarf können wir natürlich auch den Status unseres Daemons jederzeit abfragen.
 +   # systemctl status radvd.service
 +
 +<html><pre class="code">
 +<font style="color: rgb(29, 180, 29)"><b>●</b></font> radvd.service - IPv6 Router Advertisement Daemon
 +     Loaded: loaded (/usr/lib/systemd/system/radvd.service; </font><font style="color: rgb(29, 180, 29)"><b>disabled</b></font>; preset: <font style="color: rgb(201, 214, 95)"><b>disabled</b></font>)
 +   Active:<font style="color: rgb(29, 180, 29)"><b>active (running)</b></font> since Tue 2024-07-09 18:00:37 CEST; 1min 19s ago
 + Invocation: bc40f348d21e45bf83b5976494e7fe39
 +   Main PID: 1296 (radvd)
 +      Tasks: 2 (limit: 9510)
 +     Memory: 368K (peak: 1.5M)
 +        CPU: 13ms
 +     CGroup: /system.slice/radvd.service
 +             ├─1296 /usr/bin/radvd --nodaemon
 +             └─1297 /usr/bin/radvd --nodaemon
 +
 +Jul 09 18:00:37 vml000110 systemd[1]: Started IPv6 Router Advertisement Daemon.
 +Jul 09 18:00:37 vml000110 radvd[1296]: [Jul 09 18:00:37] radvd (1296): version 2.19 started</font></pre>
 +</html>
 +
 +
 +Nun prüfen wir, ob unser **radvd** auch die richtigen Router Advertisement ICMPv6 Nachrichten ins Netz schickt. Hier bieten sich zwei mögliche Varianten an:
 +  - Mit dem Programm **''radvdump''** aus dem Paket **radvd**. Hierzu starten wir dias besagte Binary auf einem unserer Clients im lokalen Netzwerk-Segment dieses Binary. <code> # radvdump</code><code>#                                                                                                                                                     
 +# radvd configuration generated by radvdump 2.18
 +# based on Router Advertisement from fe80::10:ff:fe10:110
 +# received by interface enp0s25
 +#
 + 
 +interface enp0s25
 +{
 +  AdvSendAdvert on;
 +  # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
 +  AdvManagedFlag on;
 +  AdvOtherConfigFlag on;
 +  AdvReachableTime 0;
 +  AdvRetransTimer 0;
 +  AdvCurHopLimit 64;
 +  AdvDefaultLifetime 1800;
 +  AdvHomeAgentFlag off;
 +  AdvDefaultPreference medium;
 +  AdvSourceLLAddress on;
 + 
 +  prefix 2001:a:bcd:1234::/64
 +  {
 +    AdvValidLifetime 5400;
 +    AdvPreferredLifetime 2700;
 +    AdvOnLink on;
 +    AdvAutonomous on;
 +    AdvRouterAddr off;
 +  }; # End of prefix definition
 + 
 + 
 +  prefix fdb6:cb48:9d77::/64
 +  {
 +    AdvValidLifetime 5400;
 +    AdvPreferredLifetime 2700;
 +    AdvOnLink on;
 +    AdvAutonomous off;
 +    AdvRouterAddr off;
 +  }; # End of prefix definition
 + 
 + 
 +  route 2001:a:bcd:1234::/64
 +  {
 +    AdvRoutePreference medium;
 +    AdvRouteLifetime 1800;
 +  }; # End of route definition
 + 
 + 
 +  route fdb6:cb48:9d77::/64
 +  {
 +    AdvRoutePreference medium;
 +    AdvRouteLifetime 1800;
 +  }; # End of route definition
 + 
 +}; # End of interface definition</code> In regelmäßigen Abständen tauchen also diese RA-Meldungen auf.
 +  - Mit Hilfe von **''tcpdump''** können wir auch die RA-Meldungen mitschneiden und darstellen, in nachfolgenden Beispiel ist der Name des Netzwerkinterfaces **''enp0s15''**.<code> # tcpdump -vi enp0s25 "icmp6[icmp6type] == icmp6-routeradvert"</code><code>tcpdump: listening on enp0s25, link-type EN10MB (Ethernet), snapshot length 262144 bytes
 +18:08:04.399616 IP6 (flowlabel 0x37bf6, hlim 255, next-header ICMPv6 (58) payload length: 136) _gateway > nitropad: [icmp6 sum ok] ICMP6, router adver
 +  hop limit 64, Flags [managed, other stateful], pref medium, router lifetime 1800s, reachable time 0ms, retrans timer 0ms
 +    prefix info option (3), length 32 (4): 2003:a:e0d:7607::/64, Flags [onlink, auto], valid time 5400s, pref. time 2700s
 +    prefix info option (3), length 32 (4): fdb6:cb48:9d77::/64, Flags [onlink], valid time 5400s, pref. time 2700s
 +    route info option (24), length 24 (3):  2003:a:e0d:7607::/64, pref=medium, lifetime=1800s
 +    route info option (24), length 24 (3):  fdb6:cb48:9d77::/64, pref=medium, lifetime=1800s
 +    source link-address option (1), length 8 (1): 52:54:00:41:11:02
 +^C
 +1 packet captured
 +1 packet received by filter
 +0 packets dropped by kernel
 +</code>
 +
 +
 +=== kea-dhcp6 Konfiguration ===
 +Wir brauchen jetzt natürlich für die statischen **ULA** noch eine passende Konfigurationsdatei. Wir greifen nun kurz dem Kapitel **[[linux:kea|DHCPv4/v6-Server mit DHCP ISC Kea unter Arch Linux einrichten und nutzen]]** vor und werfen einen kurzen Blick auf die unkommentierte Konfigurationsdatei **''/etc/kea/kea-dhcp6.conf''** des **kea-dhcp6**-Daemon. Im besagten [[linux:kea|Kapitel]] werden wir uns noch mit dem **[[|DHCP ISC Kea]]** ähnlich detailliert auseinander setzen wir hier in diesem Kapitel **[[#dokuwiki__top|Router Advertisements mit radvd unter Arch Linux einrichten und nutzen]]**!
 +
 +   # vim /etc/kea/kea-dhcp6.conf
 +++++ Beispielkonfigurationsdatei ohne Kommentare |
 +<code>{
 +  "Dhcp6": {
 +    "valid-lifetime": 4000,
 +    "renew-timer": 1000,
 +    "rebind-timer": 2000,
 +    "preferred-lifetime": 3000,
 +    "control-socket": {
 +      "socket-type": "unix",
 +      "socket-name": "/var/lib/kea/kea6-ctrl-socket"
 +    },
 +    "interfaces-config": {
 +      "interfaces": [
 +        "eth1"
 +      ]
 +    },
 +    "lease-database": {
 +      "type": "memfile",
 +      "persist": true,
 +      "name": "/var/lib/kea/kea-leases6.csv",
 +      "lfc-interval": 1800,
 +      "max-row-errors": 100
 +    },
 +    "expired-leases-processing": {
 +      "reclaim-timer-wait-time": 10,
 +      "flush-reclaimed-timer-wait-time": 25,
 +      "hold-reclaimed-time": 3600,
 +      "max-reclaim-leases": 100,
 +      "max-reclaim-time": 250,
 +      "unwarned-reclaim-cycles": 5
 +    },
 +    "option-data": [
 +      {
 +        "name": "dns-servers",
 +        "data": "fdb6:cb48:9d77:10:0:10:110"
 +      },
 +      {
 +        "name": "domain-search",
 +        "data": "intra.nausch.org"
 +      }
 +    ],
 +    "subnet6": [
 +      {
 +        "interface": "eth1",
 +        "id": 857665,
 +        "subnet": "fdb6:cb48:9d77::/64",
 +        "pools": [ 
 +          {
 +            "pool": "fdb6:cb48:9d77:10:0:10:300/120" 
 +          }
 +        ],
 +        "option-data": [
 +          {
 +            "name": "dns-servers",
 +            "data": "fdb6:cb48:9d77:10:0:10:110"
 +          }
 +        ],
 +        "reservations": [
 +          {
 +            "duid": "00:04:28:b0:df:3d:fd:11:6b:62:82:5c:14:95:dc:27:97:98",
 +            "ip-addresses": [ "fdb6:cb48:9d77:10:0:10:73" ]
 +          },
 +          {
 +            "duid": "00:04:80:6f:6d:f5:a6:44:99:a4:3f:9f:09:7c:69:8d:e8:d2",
 +            "ip-addresses": [ "fdb6:cb48:9d77:10:0:10:74" ]
 +          }
 +        ]
 +      }
 +    ],
 +    "loggers": [
 +      {
 +        "name": "kea-dhcp6",
 +        "output_options": [
 +          {
 +            "output": "/var/log/kea-dhcp6.log",
 +            "maxsize": 1048576,
 +            "maxver": 8
 +          }
 +        ],
 +        "severity": "DEBUG",
 +        "debuglevel": 99
 +      }
 +    ]
 +  }
 +}
 +</code>
 +++++
 +
 +=== IP-Adresse am Client ===
 +Fragen wir die IP-Adresse des Netzwerkinterfaces ab sehen wir:
 +  django@nitropad:~$ ip addr show enp0s25 
 +<code>2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
 +    link/ether 3c:97:0e:18:e4:dd brd ff:ff:ff:ff:ff:ff
 +    inet 10.0.10.73/24 brd 10.0.10.255 scope global dynamic noprefixroute enp0s25
 +       valid_lft 3594sec preferred_lft 3594sec
 +    inet6 fdb6:cb48:9d77:10:0:10:73/128 scope global dynamic noprefixroute 
 +       valid_lft 3995sec preferred_lft 2995sec
 +    inet6 2001:a:bcd:1234:c79d:9c68:ff37:3f53/64 scope global temporary dynamic 
 +       valid_lft 5395sec preferred_lft 2695sec
 +    inet6 2001:a:bcd:1234:2688:fdb0:775:c02c/64 scope global dynamic mngtmpaddr noprefixroute 
 +       valid_lft 5395sec preferred_lft 2695sec
 +    inet6 fe80::e9a6:bb03:1544:b000/64 scope link noprefixroute 
 +       valid_lft forever preferred_lft forever</code>
 +
 +<WRAP center round tip 80%>
 +Wir haben neben der **IPv4** Adresse **''10.0.10.73''** und der vom Client-System generierten **LLA** **''fe80::e9a6:bb03:1544:b000/64''** mit ***''scope link noprefixroute''** noch drei weitere IPv6-Adressen erhalten. Das wäre zum einen die statische feste **ULA** **''fdb6:cb48:9d77:10:0:10:73/128''** mit **''scope global dynamic noprefixrout''** noch eine stabile dynamische IPv6 Adresse **''2001:a:bcd:1234:2688:fdb0:775:c02c/64''** mit **''scope global dynamic mngtmpaddr''** und eine temporäre "privacy" IPv6 Adresse **''2001:a:bcd:1234:c79d:9c68:ff37:3f53/64''** mit **''scope global temporary dynamic''**. Erstere ist für eingehende Verbindungen und letztere ist für ausgehende Verbindungen und wird alle gemäß der RA-Option **''AdvPreferredLifetime 2700''** alle 45 Minuten neu ausgewürfelt.
 +</WRAP>
 ===== Orchestrierung - Installation und Konfiguration des radvd mit Hilfe von Ansible  ===== ===== Orchestrierung - Installation und Konfiguration des radvd mit Hilfe von Ansible  =====
 ==== Aufgabenstellung ==== ==== Aufgabenstellung ====
Zeile 1303: Zeile 1854:
 ++++ ++++
  
-Wie wir sehen ist die Rolle durchaus überschaubar, im Task **''main.yaml''** verweisen wir lediglich auf die beiden eigentlichen Tasks **''install.yml''** und **''firewalld.yml''**+Wie wir sehen ist die Rolle durchaus überschaubar, im Task **''main.yaml''** verweisen wir lediglich auf die eigentlichen Tasks **''variablencheck''**, **''install.yml''** und **''firewalld.yml''**
    $ vim roles/radvd/tasks/main.yml    $ vim roles/radvd/tasks/main.yml
  
 {{gh> https://gitlab.nausch.org/django/example_radvd/-/blob/main/roles/radvd/tasks/main.yml }} {{gh> https://gitlab.nausch.org/django/example_radvd/-/blob/main/roles/radvd/tasks/main.yml }}
- 
-Die eigentliche Installation und Konfiguration erfolgt dann im Task **''install.yml''**.  
-   $ vim roles/radvd/tasks/install.yml 
- 
-{{gh> https://gitlab.nausch.org/django/example_radvd/-/blob/main/roles/radvd/tasks/install.yml }} 
  
 Bei der Konfiguration unseres **radvd** haben wir in unserem Konfigurationsbeispiel, ob nur eine **GUA** oder eine **ULA** oder eben beide Adresstypen genutzt werden sollen. Zusätzlich haben wir noch die Wahl ob eine IPv6 mit Hilfe von **[[https://www.rfc-editor.org/rfc/rfc4862|SLAAC]]** oder **[[https://www.rfc-editor.org/rfc/rfc8415|Statful DHCPv6]]** bezogen werden soll.  Bei der Konfiguration unseres **radvd** haben wir in unserem Konfigurationsbeispiel, ob nur eine **GUA** oder eine **ULA** oder eben beide Adresstypen genutzt werden sollen. Zusätzlich haben wir noch die Wahl ob eine IPv6 mit Hilfe von **[[https://www.rfc-editor.org/rfc/rfc4862|SLAAC]]** oder **[[https://www.rfc-editor.org/rfc/rfc8415|Statful DHCPv6]]** bezogen werden soll. 
Zeile 1323: Zeile 1869:
 GUA-/LUA-Mode bei IPv6-Adressen:                                                                                                          GUA-/LUA-Mode bei IPv6-Adressen:                                                                                                         
   * **''noone''** = weder SLAAC noch DHCPv6, keine Adresse   * **''noone''** = weder SLAAC noch DHCPv6, keine Adresse
-  * **''slaac''** = Adreese via SLAAC generieren+  * **''slaac''** = Adresse via SLAAC generieren
   * **''dhcp6''** = Adresse via DHCPv6 beziehen   * **''dhcp6''** = Adresse via DHCPv6 beziehen
  
  
-Um sicher zu stellen, dass die beiden Variablen **''radvd_gua_mode''** und **''radvd_ula_mode''** mit validen Daten gefüttert werden, überprüfen wir in einerm Task die Gültigkeit der Daten.+Um sicher zu stellen, dass die beiden Variablen **''radvd_gua_mode''** und **''radvd_ula_mode''** mit validen Daten gefüttert werden, überprüfen wir in einem Task die Gültigkeit der Daten.
    $ vim roles/radvd/tasks/variablencheck.yml    $ vim roles/radvd/tasks/variablencheck.yml
  
 {{gh> https://gitlab.nausch.org/django/example_radvd/-/blob/main/roles/radvd/tasks/variablencheck.yml }} {{gh> https://gitlab.nausch.org/django/example_radvd/-/blob/main/roles/radvd/tasks/variablencheck.yml }}
 +
 +Die eigentliche Installation und Konfiguration erfolgt dann im Task **''install.yml''**. 
 +   $ vim roles/radvd/tasks/install.yml
 +
 +{{gh> https://gitlab.nausch.org/django/example_radvd/-/blob/main/roles/radvd/tasks/install.yml }}
  
 Die Anpassung an unserer Firewall-Konfiguration  erfolgt im Task **''firewalld''**. Die Anpassung an unserer Firewall-Konfiguration  erfolgt im Task **''firewalld''**.
Zeile 1380: Zeile 1931:
 </html> </html>
  
 +/*
 +[15:40:36] Gathering Facts
 +↳  vml010110 | SUCCESS | 3.43s
 +[15:40:40] radvd : Prüfen ob die Variablen für GUA und ULA valide Werte haben.
 +↳  vml010110 | SUCCESS | 12ms
 +[15:40:40]     ↳ variablencheck: Prüfen ob die Variable radvd_gua_mode gesetzt wurde.
 +↳  vml010110 | SUCCESS | 34ms
 +[15:40:40]     ↳ variablencheck: Prüfen ob die Variable radvd_ula_mode gesetzt wurde.
 +↳  vml010110 | SUCCESS | 34ms
 +[15:40:40]     ↳ variablencheck: Prüfen ob die beiden Variable raddv_gua_mode und radvd_ula_mode = noone sind.
 +vml010110 | SKIPPED | 19ms
 +[15:40:40] radvd : Installation und Konfiguration des Router Advertisement Daemon radvd.
 +↳  vml010110 | SUCCESS | 13ms
 +[15:40:40]     ↳ install: Installation des Router Advertisement Daemon radvd.
 +↳  vml010110 | SUCCESS | 4.12s
 +[15:40:44]     ↳ install: Checken ob es bereits eine Backupdatei der radvd.conf gibt.
 +↳  vml010110 | SUCCESS | 765ms
 +[15:40:45]     ↳ install: Backupdatei der radvd.conf Konfigurationsdatei erstellen.
 +vml010110 | SKIPPED | 18ms
 +[15:40:45]     ↳ install: GUA _oder_ ULA: Generieren und kopieren der radvd Konfigurationsdatei /etc/radvd.conf
 +vml010110 | SKIPPED | 17ms
 +[15:40:45]     ↳ install: GUA _und_ ULA: Generieren und kopieren der radvd Konfigurationsdatei /etc/radvd.conf
 +↳  vml010110 | CHANGED | 1.30s
 +[15:40:46]     ↳ install: Restart des radvd zur Aktivierung der Konfiguration.
 +↳  vml010110 | CHANGED | 1.08s
 +[15:40:47] radvd : Konfiguration des firewalld für den Router Advertisement Daemon radvd.
 +↳  vml010110 | SUCCESS | 16ms
 +[15:40:47]     ↳ firewalld: Sicherstellen, dass der Firewall-Daemon reboot(-fest) starten.
 +↳  vml010110 | CHANGED | 1.12s
 +[15:40:48]     ↳ firewalld: Service basierte Rules je Zone definieren
 +↳  vml010110 | SUCCESS | 874ms
 +[15:40:49]     ↳ firewalld: Zum Schluss den aktuellen permanenten Regelsatz final neu laden.
 +↳  vml010110 | CHANGED | 852ms
 +[15:40:50] system
 +-- Play recap --
 +vml010110                  : ok=13   changed=4    unreachable=0    failed=0    skipped=3    rescued=0    ignored=0   
 +✔ ~/devel/ansible [main|✚ 1] 
 +
 +*/
 FIXME FIXME
 === Ergebniskontrolle === === Ergebniskontrolle ===
  • linux/radvd.1720297840.txt.gz
  • Zuletzt geändert: 06.07.2024 20:30.
  • von django