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 [09.07.2024 15:10. ] – [Musterkonfiguration GUA via SLAAC und ULA via DHCPv6] 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 176: Zeile 176:
   - **[[#slaac_-_ipv6_stateless_address_auto-configuration|Konfigurationsbeispiel: 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|Konfigurationsbeispiel: DHCPv6 - stateless und stateful]]**   - **[[#router_advertisement_icmpv6-nachrichten_fuer_stateful_dhcpv6|Konfigurationsbeispiel: DHCPv6 - stateless und stateful]]**
-  - **[[#musterkonfiguration|Musterkonfiguration für GUA via SLAAC und statischen festen ULA mit Hilfe von DHCPv6]]** FIXME //..coming soon..// FIXME +  - **[[#musterkonfiguration_gua_via_slaac_und_ula_via_dhcpv6|Musterkonfiguration für GUA via SLAAC und statischen festen ULA mit Hilfe von DHCPv6]]**
 </WRAP> </WRAP>
  
Zeile 230: Zeile 229:
   * **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 699: 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 1162: Zeile 1161:
  
 ==== Musterkonfiguration GUA via SLAAC und ULA via DHCPv6 ==== ==== 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.  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. 
  
Zeile 1177: Zeile 1177:
   - **GUA**:    - **GUA**: 
     - Die öffentlichen **IPv6** Adressen (**GUA**)) vergeben wir dynamisch via SLAAC.     - 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 Adrressen via SLAAC holen.+    - 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!     - 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+Wir wollen uns also nun ansehen, wie wir solch ein Muster-Szenario abbilden können
 </WRAP> </WRAP>
-Der geneigte Leser wir sich nun fragen, ja wie macht man denn nun das beim **radvd**. denn schließlich wissen wir ja folgendes: 
  
 +<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>
  
- FIXME+=== 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 ====
  • linux/radvd.1720537840.txt.gz
  • Zuletzt geändert: 09.07.2024 15:10.
  • von django