Empfangen von DHCP-Optionen von einem RADIUS-Server

Optionen aus RADIUS

Die Anwenderverwaltung (auf den Routern) oder die DHCP-Verwaltung (auf den Switches) ermöglicht es Ihnen, DHCP-Optionen auf einem RADIUS-Server zentral zu konfigurieren und die Optionen dann pro Anwender oder pro DHCP-Client zu verteilen. Diese Methode führt zu DHCP-Optionen aus RADIUS-Quellen – die DHCP-Optionen stammen vom RADIUS-Server und werden an den Anwender (oder DHCP-Client) gesendet. Dies unterscheidet sich von der herkömmlichen Client-basierten Methode (auch DHCP-bezogen genannt) zur Konfiguration von DHCP-Optionen, bei der die Optionen vom Client stammen und an den RADIUS-Server gesendet werden. Die von RADIUS bezogenen DHCP-Optionen für die Anwender-Verwaltung (DHCP-Verwaltung) gelten ebenfalls als undurchsichtig, da der lokale DHCP-Server nur eine minimale Verarbeitung und Fehlerprüfung für die DHCP-Optionszeichenfolge durchführt, bevor er die Optionen an den Anwender (DHCP-Client) übergibt.

Die Teilnehmerverwaltung (oder DHCP-Verwaltung) verwendet Juniper Networks VSA 26-55 (DHCP-Optionen), um die von RADIUS bezogenen DHCP-Optionen zu verteilen. Der RADIUS-Server enthält VSA 26-55 in der Access-Accept-Nachricht, die der Server während der Authentifizierung des Anwenders oder der DHCP-Client-Authentifizierung zurückgibt. Der RADIUS-Server sendet die Access-Accept-Nachricht an den RADIUS-Client und dann an den lokalen DHCP-Server zur Rückgabe an den DHCP-Anwender. Der RADIUS-Server kann mehrere Instanzen von VSA 26-55 in einer einzigen Access-Accept-Nachricht enthalten. Der RADIUS-Client verkettet die mehreren Instanzen und verwendet das Ergebnis als einzelne Instanz.

Es ist keine CLI-Konfiguration erforderlich, um die Anwenderverwaltung (DHCP-Verwaltung) für die Verwendung der zentral konfigurierten DHCP-Optionen zu aktivieren – der Vorgang wird durch das Vorhandensein von VSA 26-55 in der RADIUS Access-Accept-Nachricht ausgelöst.

Beim Erstellen des Angebotspakets für den DHCP-Client verwendet der lokale DHCP-Server die folgende Reihenfolge:

1. Verarbeitet alle RADIUS-konfigurierten Parameter, die als separate RADIUS-Attribute übergeben werden. zum Beispiel das RADIUS-Attribut 27 (Sitzungs-Timeout).

2. Verarbeitet alle vom Client bezogenen Parameter; Beispielsweise die RADIUS-Attribute 53 (DHCP-Nachrichtentyp) und 54 (Server-ID).

3. Hängt (ohne jegliche Verarbeitung) die in der VSA 26-55 enthaltene undurchsichtige DHCP-Optionszeichenfolge an, die vom RADIUS-Server empfangen wurde.

Konfiguration von Client-basierten Optionen

Neben der Unterstützung der zentralen Konfiguration von DHCP-Optionen direkt auf dem RADIUS-Server (RADIUS-basierte Optionen) unterstützt die Anwender-Verwaltung (DHCP-Management) auch die traditionelle Client-basierte Optionskonfiguration, bei der die DHCP-Komponente des Routers (Switches) die Optionen an den RADIUS-Server sendet. Die clientbasierte DHCP-Optionsmethode wird sowohl für den lokalen DHCP-Server als auch für den DHCP-Relay-Agent unterstützt. Die zentrale Konfigurationsmethode aus RADIUS wird jedoch nur auf dem lokalen DHCP-Server unterstützt. Sowohl die von RADIUS stammenden als auch die von Clients stammenden Methoden unterstützen DHCPv4- und DHCPv6-Abonnenten (Clients).

Datenfluss für DHCP-Optionen aus RADIUS-Quellen

Abbildung 1 zeigt das Verfahren, das die Anwenderverwaltung (DHCP-Verwaltung) bei der Konfiguration von DHCP-Optionen für Anwender (DHCP-Clients) verwendet.

Abbildung 1: Datenfluss für DHCP-Optionen

Die folgende allgemeine Sequenz beschreibt den Datenfluss, wenn die Anwenderverwaltung (DHCP-Verwaltung) DHCP-Optionen aus RADIUS und VSA 26-55 verwendet, um einen DHCP-Anwender (Client) zu konfigurieren:

1. Der Anwender (DHCP-Client) sendet eine DHCP-Ermittlungsnachricht (oder DHCPv6-Anfragennachricht) an den lokalen DHCP-Server. Die Nachricht enthält Client-bezogene DHCP-Optionen.

2. Der lokale DHCP-Server initiiert die Authentifizierung mit dem Junos OS RADIUS-Client.

3. Der RADIUS-Client sendet im Namen des Anwenders (DHCP-Clients) eine Access-Request-Nachricht an den externen RADIUS-Server. Die Nachricht enthält die Client-bezogenen DHCP-Optionen des Anwenders (DHCP-Clients).

4. Der externe RADIUS-Server antwortet, indem er eine Access-Accept-Nachricht an den RADIUS-Client sendet. Die Access-Accept-Nachricht enthält die von RADIUS stammenden undurchsichtigen DHCP-Optionen in VSA 26-55.

5. Der RADIUS-Client sendet die DHCP-Optionszeichenfolge an den lokalen DHCP-Server. Wenn mehrere VSA 26-55-Instanzen vorhanden sind, stellt der RADIUS-Client diese zunächst in einer einzigen Optionszeichenfolge zusammen.

6. Der lokale DHCP-Server verarbeitet alle Optionen in der DHCP-Angebotsnachricht (oder DHCPv6-Antwort), mit Ausnahme der von RADIUS bezogenen VSA 26-55-DHCP-Optionen. Nach der Verarbeitung aller anderen Optionen fügt der lokale DHCP-Server die unveränderten VSA 26-55 DHCP-Optionen an die Nachricht an und sendet die Nachricht an den Anwender (DHCP-Client).

7. Der Anwender (DHCP-Client) ist mit den DHCP-Optionen konfiguriert.

8. Die folgenden Vorgänge werden ausgeführt, nachdem der Anwender (DHCP-Client) die DHCP-Optionen erhalten hat:

   • Accounting: Der RADIUS-Client sendet Acct-Start- und Interim-Accounting-Anforderungen an den RADIUS-Server, einschließlich der von RADIUS bezogenen DHCP-Optionen in VSA 26-55. Standardmäßig sind die DHCP-Optionen in Kontoführungsanforderungen enthalten.

   • Erneuerung: Wenn der Anwender (DHCP-Client) erneuert, wird der Wert der zwischengespeicherten DHCP-Optionen in der DHCP-Erneuerungsmeldung (oder DHCPv6 ACK) zurückgegeben. Die ursprünglich zugewiesenen DHCP-Optionen können während eines Erneuerungszyklus nicht geändert werden.

   • Abmelden: Wenn sich der Anwender (DHCP-Client) abmeldet, sendet der RADIUS-Client eine Acct-Stop-Nachricht an den RADIUS-Server, einschließlich des von RADIUS bezogenen VSA 26-55.

Konfiguration mehrerer VSA 26-55-Instanzen

VSA 26-55 unterstützt eine maximale Größe von 247 Byte. Wenn das Feld für die DHCP-Optionen aus RADIUS größer als 247 Byte ist, müssen Sie das Feld aufteilen und manuell mehrere Instanzen von VSA 26-55 konfigurieren, damit der RADIUS-Server zurückkehrt. Wenn Sie mehrere Instanzen für ein Optionsfeld verwenden, müssen Sie die Instanzen im Paket in der Reihenfolge platzieren, in der die Fragmente vom RADIUS-Client wieder zusammengesetzt werden sollen. Die Fragmente können eine beliebige Größe von 247 Byte oder weniger haben.

Wenn der RADIUS-Client in einer Kontoführungsanforderung ein wieder zusammengesetztes undurchsichtiges Optionsfeld an den RADIUS-Server zurückgibt, verwendet der Client 247-Byte-Fragmente. Wenn Sie ursprünglich Instanzen mit weniger als 247 Byte erstellt haben, sind die zurückgegebenen Fragmente möglicherweise nicht mit denen identisch, die Sie ursprünglich auf dem RADIUS-Server konfiguriert haben.

DHCP-Optionen, die nicht zentral konfiguriert werden können

Tabelle 1 zeigt die DHCP-Optionen, die Sie nicht zentral auf dem RADIUS-Server konfigurieren dürfen.

Differenzierung von Anwenderklassen mit DHCPv6 Option 17 und VSA 26-207

Ab Junos OS Version 18.3R1 können Sie die DHCPv6-Optionen VSA (26-207) verwenden, um bei der DHCPv6-Relay-Authentifizierung zwischen verschiedenen Klassen von Abonnenten zu unterscheiden. Beispielsweise können Sie verschiedenen Anwenderklassen unterschiedliche IPv6-Präfixe zuweisen.

Sie müssen Ihren RADIUS-Server so konfigurieren, dass er die folgenden Informationen in die VSA einbezieht:

• Juniper Networks Unternehmensnummer, 2636

• Unteroption 5, JDHCPD_VS_OPT_CODE_KT_SUBSCRIBER_CLASS

Sie legen für jede Klasse, die Sie unterscheiden möchten, einen anderen Wert für Unteroption 5 fest. Sie entwickeln Ihr eigenes Schema, um die Zuordnung zwischen Wert und Klasse zu bestimmen.

VSA 26-207 übermittelt die Informationen der Anwender-Klasse in der Access-Accept-Nachricht, die vom RADIUS-Server während der DHCPv6-Anwender-Authentifizierung zurückgegeben wird. Der Inhalt des VSA wird vom AAA-Prozess an den DHCP-Prozess im Sitzungsdatenbankattribut SDB_SERVER_DHCPV6_OPTIONS übergeben. Der DHCPv6-Relay-Agent extrahiert die Informationen aus dem SDB-Attribut und platziert sie in DHCPv6-Option 17. Der Relay-Agent übergibt anschließend Option 17 im Relay-Forward-Header an den lokalen DHCPv6-Server. Der lokale Server kann dann die Konfiguration des Relay-Agenten und die Serviceinformationen zurückgeben, die für die entsprechenden Anwender-Klassen spezifisch sind.

In Versionen vor Junos OS 18.3R1 unterstützt nur der lokale DHCP-Server VSA 26-207. Nur Unteroption 1 (JDHCPD_VS_OPT_CODE_HOST_NAME) und Unteroption 4 (JDHCPD_VS_OPT_CODE_LOCATION_NAME) werden unterstützt. Der DHCP-Relay-Agent verwirft auch das Attribut SDB_SERVER_DHCPV6_OPTIONS, wenn es empfangen wird.

Von RADIUS empfangene Unteroptionen haben eine höhere Priorität als die lokal konfigurierten Informationen. Wenn beispielsweise der Hostname und der Speicherort mit der host-name Anweisung auf Hierarchieebene [edit forwarding-options dhcp-relay dhcpv6 relay-option-vendor-specific] konfiguriert sind und in den Unteroptionen 1 und 4 von RADIUS empfangen werden, werden die RADIUS-Werte verwendet.

Ausschließen der VSAs aus RADIUS-Nachrichten

Sie können jede dieser VSAs vom Senden ausschließen, indem Sie die exclude Anweisung verwenden, wie im folgenden Beispiel gezeigt:

Client-Optionen

Die Clientoptionen können an mehreren Speicherorten konfiguriert werden, z. B. DHCPv4- oder DHCPv6-Server, oder auf dem RADIUS-Server. Wenn die Clientkonfiguration an mehreren Standorten verfügbar ist, kann es zu einem Konflikt bezüglich der Quelle der Konfigurationsdetails kommen. Im Falle solcher Konflikte wird die folgende Reihenfolge der Präferenz berücksichtigt:

• Optionen, die vom RADIUS-Server über anbieterspezifische Attribute (VSAs) empfangen werden

• Optionen, die vom RADIUS-Server über die jeweiligen Sitzungsdatenbanken empfangen werden

• Optionen aus der lokalen DHCP-Konfiguration, die auf dem DHCP-Server vorhanden sind

Betrachten Sie als Beispiel für die oben genannte Präferenz den Fall der DHCPv4-Lease-Zeit. Wenn die AUTHD_ATTR_SESSION_TIMEOUT Option, bei der es sich um eine auf dem RADIUS-Server gespeicherte VSA handelt, vom RADIUS-Server zurückgegeben wird, wird ihr der Vorzug gegeben. Wenn diese Option nicht zurückgegeben wird, wird Option 51 in der entsprechenden Sitzungsdatenbank für DHCPv4 bevorzugt. Wenn diese Option ebenfalls nicht zurückgegeben wird, stammt die Option aus der lokalen DHCP-Konfiguration.

Ebenso wird für die DHCPv6-Lease-Zeit die AUTHD_ATTR_SESSION_TIMEOUT erste Präferenz dem VSA vom RADIUS-Server gegeben. Wenn AUTHD_ATTR_SESSION_TIMEOUT nicht vorhanden ist, hat die von RADIUS stammende Option valid-lifetime oder preferred-lifetime Vorrang. Wenn dies ebenfalls nicht verfügbar ist, stammt die Option aus der lokalen DHCPv6-Konfiguration.

Austausch von DHCPv4-Client-, DHCPv4-Server- und RADIUS-bezogenen Optionen

Die folgenden Schritte veranschaulichen den Prozess des Austauschs von Konfigurationsoptionen zwischen einem DHCPv4-Client, einem DHCPv4-Server und dem RADIUS-Server:

• Eine Ermittlungsnachricht von einem DHCPv4-Client wird vom DHCPv4-Server empfangen.

• Die DHCP-Option wird in der jeweiligen Sitzungsdatenbank gespeichert.

  In Junos OS-Versionen vor 17.4R1 wird dasselbe Attribut zum Speichern von DHCPv4- und DHCPv6-Optionen verwendet. Mit der Unterstützung für Single-Session-DHCP Dual-Stack gibt es jedoch separate Sitzungsdatenbankattribute für DHCPv4 und DHCPv6.

• Die DHCP-Header-Informationen werden in der Sitzungsdatenbank gespeichert.

  Ein neues Sitzungsdatenbankattribut wird hinzugefügt, um die Headerinformationen zu speichern, und diese Informationen werden zur Authentifizierung an den RADIUS-Server gesendet.

• Eine Zugriffsanforderungsnachricht wird vom DHCPv4-Server an den RADIUS-Server gesendet, und wenn eine Zugriffsannahmenachricht vom RADIUS-Server empfangen wird, werden die DHCPv4-Optionen in den entsprechenden Sitzungsdatenbankattributen gespeichert und an den Client gesendet.

• DHCPv4-Server-spezifische Optionen werden dem Paket hinzugefügt.

  Hinweis:

  Der DHCPv4-Server kann sowohl angeforderte als auch nicht angeforderte Optionen aus der lokalen Konfiguration beziehen. Daher ist es wichtig, Doppelarbeit zu vermeiden, während die Optionen hinzugefügt werden.

• Die DHCPv4-Lease-Informationen werden aus der von RADIUS bezogenen DHCP-Option 51 extrahiert.

  Das entsprechende Sitzungsdatenbankattribut wird verwendet, um zu prüfen, ob Option 51 (Leasingzeit) von RADIUS bezogen wird. Wenn dies der Fall ist, wird der Attributwert extrahiert und in der Client-Datenstruktur gespeichert. Wenn er nicht von RADIUS bezogen wird, wird der Attributwert aus der Konfiguration des lokalen Pools oder der DHCPv4-Attributkonfiguration übernommen, bei der es sich um eine vorhandene Funktionalität handelt. Eine ähnliche Prüfung wird für Option 58 (Verlängerungszeit (T1)) und Option 59 (Wiederbindungszeit (T2)) durchgeführt.

• Eine Angebotsnachricht wird vom DHCPv4-Server an den DHCPv4-Client gesendet.

Austausch von DHCPv6-Client-, DHCPv6-Server- und RADIUS-bezogenen Optionen

Die folgenden Schritte veranschaulichen den Prozess des Austauschs von Konfigurationsoptionen zwischen einem DHCPv6-Client, einem DHCPv6-Server und dem RADIUS-Server:

• Eine Solicit-Nachricht von einem DHCP-Client wird vom DHCPv6-Server empfangen.

• DHCPv6-Optionen werden in der Sitzungsdatenbank des DHCPv6-Servers gespeichert.

  In Junos OS-Versionen vor 17.4R1 werden DHCPv6-Optionen im jeweiligen Sitzungsdatenbankattribut gespeichert. Aufgrund der aktuellen Single-Session-DHCP-Dual-Stack-Unterstützung sind separate Sitzungsdatenbankattribute zum Speichern von DHCPv4- und DHCPv6-Optionen erforderlich. Wenn der Client Teil einer Dual-Stack-Konfiguration mit einer einzelnen Sitzung ist, wird das entsprechende DHCPv6-Optionen-Sitzungsdatenbankattribut verwendet. Die DHCPv6-Optionen werden ohne Änderungen direkt in die Sitzungsdatenbank kopiert und dann an den RADIUS-Server gesendet.

  Hinweis:

  DHCPv6 auth-option (Option 11) ist ebenfalls Teil dieser Optionen.

• Ein DHCPv6-Nachrichtenheader wird in der Sitzungsdatenbank gespeichert.

  Ein neues Sitzungsdatenbankattribut wird hinzugefügt, um den DHCPv6-Nachrichtenheader zu kopieren.

• Eine Zugriffsanforderungsnachricht wird vom DHCPv6-Server gesendet, der wiederum eine Zugriffsannahmenachricht vom RADIUS-Server empfängt. Diese Nachricht enthält DHCPv6-Optionen aus RADIUS, die in einem neuen Sitzungsdatenbankattribut gespeichert sind.

• DHCPv6-Leaseinformationen werden aus der DHCPv6-Option aus RADIUS extrahiert.

  Im Falle von DHCPv6 ist die Lease-Zeit in die Optionen OPTION_IA_NA und OPTION_IA_PDeingebettet. Die Client-Leasezeit beginnt mit diesen Werten vom RADIUS-Server. Wenn die IA_ADDRESSOption , IA_PREFIX, IA_NA, oder IA_PD nicht von RADIUS stammt, werden diese Optionen aus dem lokalen Pool und der Konfiguration des delegierten Pools übernommen.

• DHCPV6-Server-spezifische Optionen werden dem Paket hinzugefügt.

  Hinweis:

  Ein DHCPv6-Server kann sowohl angeforderte als auch nicht angeforderte Optionen aus der lokalen Konfiguration beziehen. Daher ist es wichtig, Doppelarbeit zu vermeiden, während die Optionen hinzugefügt werden.

• Eine Ankündigungsnachricht wird vom DHCPv6-Server an den DHCPv6-Client gesendet.

Zweck

Zeigen Sie Informationen für DHCP-Optionen an, die zentral auf einem RADIUS-Server konfiguriert sind und die über Juniper Networks VSA 26-55 (DHCP-Optionen) verteilt werden.

Aktion

So zeigen Sie Informationen für undurchsichtige DHCP-Optionen an:

Bedeutung

Die Ausgabe der DHCP-Optionen enthält die folgenden Informationen:

• Das len Feld ist die Gesamtzahl der Hexadezimalwerte in der Nachricht.

• Die Hexadezimalwerte geben den Typ, die Länge und den Wert (TLV) der DHCP-Optionen an und werden in Dezimalzahlen konvertiert, um die DHCP-Optionen zu identifizieren, wie in RFC 2132 definiert.

Die Anzahl der Hexadezimalwerte, aus denen eine bestimmte DHCP-Option besteht, variiert je nach Länge der Option. Die erste DHCP-Option, die in der Ausgabe angegeben ist, enthält beispielsweise drei Sätze von Hexadezimalwerten (35 01 01). Der erste Hexadezimalwert (35) gibt den Optionstyp an, der zweite Wert (01) gibt die Länge des Werteintrags an, in diesem Fall ist es ein Satz von Hexadezimalwerten. Der dritte Hexadezimalwert (01) gibt den Wert für die DHCP-Option an.

In der zweiten DHCP-Optionsspezifikation (39 02 02 40) ist der Hexadezimalwert 39 der Typ, und die Länge von 02 gibt an, dass zwei Sätze von Hexadezimaleinträgen den Wert für die Option bilden. Daher verwendet diese Optionsspezifikation vier Sätze von Hexadezimaleinträgen; eine für den Typ (39), eine für die Angabe der Länge (02) und zwei für den Optionswert (02 40).

Die dritte DHCP-Option wird durch die Hexadezimalwerte 3d 07 01 00 10 94 00 00 08angegeben. Der Hexadezimalwert 3d ist der Typ, gefolgt von length (07), der angibt, dass die nächsten sieben Sätze von Hexadezimaleinträgen den Wert für die Option bilden. Daher verwendet diese Optionsspezifikation insgesamt neun Sätze von Hexadezimaleinträgen; eine für den Typ (3d), eine für die Angabe der Länge (07) und sieben für den Wert der DHCP-Option (01 00 10 94 00 00 08).

In Tabelle 2 werden die ersten beiden Optionen ausführlicher beschrieben.