Empfangen von DHCP-Optionen von einem RADIUS-Server

Optionen aus RADIUS-Quellen

Mit der Teilnehmerverwaltung (auf den Routern) oder DHCP-Verwaltung (auf den Switches) können Sie DHCP-Optionen zentral auf einem RADIUS-Server konfigurieren und die Optionen dann pro Teilnehmer oder pro DHCP-Client verteilen. Diese Methode führt zu DHCP-Optionen aus RADIUS-Quellen – die DHCP-Optionen stammen vom RADIUS-Server und werden an den Abonnenten (oder DHCP-Client) gesendet. Dies unterscheidet sich von der traditionellen clientbasierten 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 Abonnentenverwaltung (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 die Optionen an den Abonnenten (DHCP-Client) übergeben werden.

Für die Abonnentenverwaltung (oder DHCP-Verwaltung) wird Juniper Networks VSA 26-55 (DHCP-Optionen) verwendet, um die DHCP-Optionen aus RADIUS-Quellen zu verteilen. Der RADIUS-Server enthält VSA 26-55 in der Access-Accept-Nachricht, die der Server während der Abonnentenauthentifizierung oder DHCP-Clientauthentifizierung zurückgibt. Der RADIUS-Server sendet die Access-Accept-Nachricht an den RADIUS-Client und dann weiter an den lokalen DHCP-Server, um sie an den DHCP-Abonnenten zurückzusenden. 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 eine einzelne Instanz.

Es ist keine CLI-Konfiguration erforderlich, um die Abonnentenverwaltung (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. Beispiel: RADIUS-Attribut 27 (Sitzungszeitüberschreitung).

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

3. Fügt (ohne jegliche Verarbeitung) die undurchsichtige Zeichenfolge für DHCP-Optionen an, die in der vom RADIUS-Server empfangenen VSA 26-55 enthalten ist.

Konfiguration von Client-basierten Optionen

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

Datenfluss für DHCP-Optionen mit RADIUS-Quelle

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

Abbildung 1: Datenfluss der DHCP-Optionen

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

1. Der Abonnent (DHCP-Client) sendet eine DHCP-Ermittlungsnachricht (oder DHCPv6-Anforderungsnachricht) an den lokalen DHCP-Server. Die Nachricht enthält DHCP-Optionen vom Client.

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

3. Der RADIUS-Client sendet im Namen des Abonnenten (DHCP-Clients) eine Access-Request-Nachricht an den externen RADIUS-Server. Die Meldung enthält die DHCP-Optionen des Abonnenten (DHCP-Clients), die vom Client bezogen werden.

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

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

6. Der lokale DHCP-Server verarbeitet alle Optionen in die DHCP-Angebotsnachricht (oder DHCPv6-Antwort), mit Ausnahme der von RADIUS bezogenen VSA 26-55-DHCP-Optionen. Nachdem alle anderen Optionen verarbeitet wurden, hängt der lokale DHCP-Server die unveränderten VSA 26-55 DHCP-Optionen an die Nachricht an und sendet die Nachricht an den Teilnehmer (DHCP-Client).

7. Der Teilnehmer (DHCP-Client) wird mit den DHCP-Optionen konfiguriert.

8. Die folgenden Vorgänge treten auf, nachdem der Teilnehmer (DHCP-Client) die DHCP-Optionen empfangen hat:

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

   • Verlängerung: Wenn der Abonnent (DHCP-Client) die DHCP-Erneuerung durchführt, wird der Wert für die zwischengespeicherten DHCP-Optionen in der DHCP-Erneuerungsnachricht (oder DHCPv6-ACK-Nachricht) zurückgegeben. Die ursprünglich zugewiesenen DHCP-Optionen können während eines Erneuerungszyklus nicht geändert werden.

   • Abmelden: Wenn sich der Teilnehmer (DHCP-Client) abmeldet, sendet der RADIUS-Client eine Acct-Stop-Nachricht an den RADIUS-Server, einschließlich des 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 von RADIUS stammende DHCP-Optionsfeld 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 ein wieder zusammengesetztes, nicht transparentes Optionsfeld in einer Accounting-Anforderung an den RADIUS-Server zurückgibt, verwendet der Client 247-Byte-Fragmente. Wenn Sie ursprünglich Instanzen mit weniger als 247 Byte erstellt haben, stimmen die zurückgegebenen Fragmente möglicherweise nicht mit denen überein, 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.

Unterscheidung von Teilnehmerklassen 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. Sie können z. B. verschiedenen Abonnentenklassen unterschiedliche IPv6-Präfixe zuweisen.

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

• Unternehmensnummer von Juniper Networks, 2636

• Suboption 5, JDHCPD_VS_OPT_CODE_KT_SUBSCRIBER_CLASS

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

VSA 26-207 übermittelt die Abonnentenklasseninformationen in der Access-Accept-Nachricht, die vom RADIUS-Server während der DHCPv6-Abonnentenauthentifizierung 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 Konfigurations- und Dienstinformationen des Relay-Agenten zurückgeben, die für die relevanten Abonnentenklassen spezifisch sind.

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

Von RADIUS empfangene Unteroptionen haben eine höhere Priorität als die lokal konfigurierten Informationen. Wenn z. B. 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. auf DHCPv4- oder DHCPv6-Servern oder auf dem RADIUS-Server. Wenn die Clientkonfiguration an mehreren Speicherorten verfügbar ist, kann ein Konflikt bezüglich der Quelle der Konfigurationsdetails auftreten. Im Falle solcher Konflikte wird die folgende Reihenfolge der Präferenz berücksichtigt:

• Optionen, die vom RADIUS-Server über herstellerspezifische 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-Leasezeit. Wenn die Option, bei AUTHD_ATTR_SESSION_TIMEOUT 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.

Entsprechend wird für die DHCPv6-Leasezeit der AUTHD_ATTR_SESSION_TIMEOUT VSA vom RADIUS-Server bevorzugt. Wenn AUTHD_ATTR_SESSION_TIMEOUT nicht vorhanden ist, hat die Option valid-lifetime RADIUS-sourced oder preferred-lifetime Vorrang. Wenn dies ebenfalls nicht verfügbar ist, wird die Option aus der lokalen DHCPv6-Konfiguration bezogen.

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

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

• Der DHCPv4-Server empfängt eine Erkennungsnachricht von einem DHCPv4-Client.

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

  In Junos OS-Versionen vor 17.4R1 wird dasselbe Attribut verwendet, um sowohl DHCPv4- als auch DHCPv6-Optionen zu speichern. 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.

• Dem Paket werden serverspezifische DHCPv4-Optionen hinzugefügt.

  Hinweis:

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

• DHCPv4-Leaseinformationen werden aus der DHCP-Option 51 extrahiert, die von RADIUS bezogen wird.

  Das jeweilige Sitzungsdatenbankattribut wird verwendet, um zu prüfen, ob Option 51 (Lease-Zeit) von RADIUS bezogen wird. Wenn dies der Fall ist, wird der Attributwert extrahiert und in der Clientdatenstruktur gespeichert. Wenn er nicht von RADIUS bezogen wird, wird der Attributwert aus der lokalen Poolkonfiguration 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 (Neubindungszeit (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:

• Der DHCPv6-Server empfängt eine Anforderungsnachricht von einem DHCP-Client.

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

  In Junos OS-Versionen vor 17.4R1 werden DHCPv6-Optionen im entsprechenden Sitzungsdatenbankattribut gespeichert. Aufgrund der aktuellen DHCP-Dual-Stack-Unterstützung für Einzelsitzungen sind separate Sitzungsdatenbankattribute zum Speichern von DHCPv4- und DHCPv6-Optionen erforderlich. Wenn der Client Teil einer Single-Session-Dual-Stack-Konfiguration ist, wird das entsprechende DHCPv6-options-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-Quelle, die in einem neuen Sitzungsdatenbankattribut gespeichert werden.

• DHCPv6-Leaseinformationen werden aus der DHCPv6-Option extrahiert, die von RADIUS bezogen wird.

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

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

  Hinweis:

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

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

Zweck

Hier finden Sie Informationen zu DHCP-Optionen, die zentral auf einem RADIUS-Server konfiguriert und ü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) von 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 sich eine bestimmte DHCP-Option zusammensetzt, hängt von der Länge der Option ab. Beispielsweise enthält die erste DHCP-Option, die in der Ausgabe angegeben ist, drei Sätze von Hexadezimalwerten (35 01 01). Der erste Hexadezimalwert () gibt den Optionstyp an35, der zweite Wert (01) gibt die Länge des Werteintrags an, d.h. in diesem Fall ist 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 werden in dieser Optionsspezifikation vier Sätze von Hexadezimaleinträgen verwendet. eine für den Typ (39), eine zur 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 der Länge (07), die angibt, dass die nächsten sieben Sätze von Hexadezimaleinträgen den Wert für die Option bilden. Daher werden in dieser Optionsspezifikation insgesamt neun Sätze von Hexadezimaleinträgen verwendet. eine für den Typ (3d), eine zum Angeben 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.