Dynamisches Servicemanagement mit RADIUS

Vorteile von dynamischen Radius-Anfragen

Ermöglicht eine vereinfachte zentrale Verwaltung von Anwender-Sitzungen durch Senden unerwünschter Änderungen an Anwender-Sitzungen, einschließlich Änderungen von Attributen, Service-Aktivierung, Service-Deaktivierung und -Beendigung.

CoA-Meldungen

Die Unterstützung für dynamische Anforderungen ermöglicht es dem Router, unerwünschte CoA-Nachrichten von externen RADIUS-Servern zu empfangen und zu verarbeiten. RADIUS-initiierte CoA-Nachrichten verwenden die folgenden Codes in Anforderungs- und Antwortnachrichten:

• CoA-Antrag (43)

• CoA-ACK (44)

• CoA-NAK (45)

Voraussetzungen für die Änderung der Berechtigung

Um die Berechtigungsänderung für einen Benutzer abzuschließen, geben Sie Identifikationsattribute und Sitzungsattribute an. Die Identifikationsattribute identifizieren den Anwender. Sitzungsattribute geben den Vorgang (Aktivierung oder Deaktivierung) an, der für die Sitzung des Anwenders ausgeführt werden soll, und enthalten auch alle Clientattribute für die Sitzung (z. B. QoS-Attribute). Das AAA Service Framework verarbeitet die eigentliche Anfrage.

Tabelle 1 zeigt die Identifikationsmerkmale für CoA-Operationen.

Tabelle 2 zeigt die Sitzungsattribute für CoA-Vorgänge. Alle zusätzlichen Clientattribute, die Sie einbeziehen, hängen von Ihren speziellen Sitzungsanforderungen ab.

Nachrichtenaustausch

Der RADIUS-Server und das AAA Service Framework auf dem Router tauschen Nachrichten mithilfe von UDP aus. Die vom RADIUS-Server gesendete CoA-Request-Nachricht hat das gleiche Format wie das Disconnect-Request-Paket, das für einen Trennungsvorgang gesendet wird.

Die Antwort ist entweder eine CoA-ACK- oder eine CoA-NAK-Nachricht:

• Wenn das AAA Service Framework die Autorisierung erfolgreich ändert, ist die Antwort ein RADIUS-formatiertes Paket mit einer CoA-ACK-Nachricht, und der Datenfilter wird auf die Sitzung angewendet.

• Wenn AAA Service Framework nicht erfolgreich ist, die Anforderung falsch formatiert ist oder Attribute fehlen, ist die Antwort ein RADIUS-formatiertes Paket mit einer CoA-NAK-Nachricht.

CoA-Transaktionen in großen Mengen

Ab Junos OS Version 17.2R1 werden CoA-Massenanforderungen unterstützt, um die Verarbeitungseffizienz von RADIUS-basierten Anwender-Services auf der BNG zu verbessern. Die Bulk-CoA-Funktion ermöglicht die Akkumulation einer Reihe von CoA-Anfragen und committet sie alle zusammen automatisch in großen Mengen.

Alle Services in einer Massen-CoA-Anforderung müssen für dieselbe Anwender-Sitzung gelten.

CoA-Massentransaktionen sind besonders wertvoll für Unternehmensdienstleistungen. RADIUS-basierte Anwender-Services nutzen die Juniper Networks VSAs, Activate-Service (26-65) und Deactivate-Service (26-66). Die VSAs werden in RADIUS-Accept-Nachrichten während der Anmeldung oder in CoA-Anfragen nach der Anmeldung bereitgestellt.

Bei herkömmlichen, dynamischen, auf Serviceprofilen basierenden Services passen bis zu 12 Serviceaktivierungen problemlos in jede RADIUS-Nachricht. Die von Unternehmen verwendeten op-skriptbasierten Dienste haben jedoch in der Regel Skalierungsanforderungen, die die Kapazität beider Nachrichten übersteigen. Dies bedeutet, dass das Angeben und Aktivieren aller in einer bestimmten Anwender Sitzung benötigten Services die Verwendung einer Accept-Access-Nachricht und mehrerer CoA-Anforderungen erfordern kann.

Jede CoA-Anforderungsnachricht ist unabhängig von früheren und zukünftigen CoA-Anforderungen in derselben Anwender Sitzung. Alle Serviceaktivierungen und -deaktivierungen in einer Nachricht werden verarbeitet, bevor eine CoA-Antwort angeboten wird. Die CoA-Anforderung bietet eine Möglichkeit, eine Anwendersitzung inkrementell zu ändern, ohne dass sich dies auf vorhandene Services auswirkt, die bereits vorhanden sind.

Bei op-script-basierten Services werden die Servicesitzungen von den authd- und essmd-Prozessen gemeinsam erstellt, sodass der letzte Vorgang einen Commit initiiert, um alle resultierenden statischen geschäftslogischen Schnittstellen aus der CoA-Anforderung anzuwenden. Da die Commit-Zeit im Allgemeinen den größten Teil der Anwendung eines statischen Business Service ausmacht, ist es von Vorteil, so viele Serviceaktivierungen oder -deaktivierungen zu packen, wie in eine RADIUS-Nachricht passen, um das Commit-Fenster effizient zu nutzen. Bis zum Abschluss des Commitvorgangs kann die BNG keine nachfolgende CoA-Anforderung zum Anwenden zusätzlicher Geschäftsdienste für dieselbe Anwendersitzung akzeptieren.

Massen-CoA verbessert die Effizienz der Commit-Verarbeitung durch die Verwendung einer einzigen Commit-Aktion für alle Services in der Bulk-Transaktion. Die Massentransaktion hat den Effekt, dass eine Reihe von Anfragen als einzelne Metaanforderung verwaltet wird. Es verschiebt die Commit-Verarbeitung, bis die letzte CoA-Anforderung in der Massentransaktion empfangen wird.

Massen-CoA erfordert, dass jede einzelne Anforderung eine einzelne Instanz der Bulk-CoA-Transaction-Id VSA von Juniper Networks (26–194) enthält. Diese VSA identifiziert Anfragen als zur selben Massentransaktion gehörend. 26–194 muss in allen CoA-Anforderungen in der Massenserie denselben Wert haben. Jede nachfolgende Massentransaktion in der Sitzung muss eine andere Kennung haben. Beispielsweise können drei aufeinanderfolgende Massentransaktionen die IDs 1, 2 und 1 haben, aber nicht die aufeinanderfolgenden IDs 1, 1 und 2. In der Praxis wird der Bulk-CoA-Transaction-Id-Wert in der Regel für mehrere Massentransaktionen erhöht, dies ist jedoch nicht erforderlich. Ein ID-Wert, der in einer bestimmten Anwender-Sitzung verwendet wird, kann auch in verschiedenen Anwender-Sitzungen verwendet werden.

Jede CoA-Anforderung innerhalb einer Massentransaktion hat ihre eigene eindeutige Kennung, die von einer einzelnen Instanz des Bulk-CoA-Identifier VSA (26–195) in jeder CoA bereitgestellt wird. Eine zunehmende Reihe von Werten für die ID ist typisch, wird aber nicht erzwungen. Werte können innerhalb einer bestimmten Sitzung und zwischen Sitzungen wiederverwendet werden. Die letzte CoA-Anforderung in der Serie wird durch den Wert 0xFFFFFFFF für den Bulk-CoA-Identifier identifiziert.

Vorteile der von Radius initiierten Berechtigungsänderung

Ermöglicht das dynamische Pushen von Änderungen an Attributwerten in Anwender-Sitzungen sowie die dynamische Aktivierung und Deaktivierung von Anwender-Services.

Nachrichten trennen

Um die Trennung von RAS-Teilnehmern zentral zu steuern, empfängt und verarbeitet die dynamische Anforderungsfunktion von RADIUS auf dem Router unerwünschte Nachrichten von RADIUS-Servern.

Das Feature für dynamische Anforderungen verwendet das vorhandene Format von RADIUS-Trennungsanforderungs- und -antwortnachrichten. Die von RADIUS initiierte Trennung verwendet die folgenden Codes in ihren RADIUS-Anforderungs- und -Antwortnachrichten:

• Trennungs-Anfrage (40)

• Trenn-ACK (41)

• Trenn-NAK (42)

Voraussetzungen für Disconnect

Damit das AAA Service Framework einen Benutzer trennen kann, muss die Disconnect-Request-Nachricht ein Attribut mit einer Buchhaltungssitzungs-ID enthalten. Die Disconnect-Request-Nachricht kann ein Acct-Session-Id-Attribut (44) oder ein Acct-Multi-Session-Id-Attribut (50) für die Sitzungs-ID oder beides enthalten. Wenn sowohl die Attribute Acct-Session-Id als auch Acct-Multi-Session-Id in der Anforderung vorhanden sind, verwendet der Router beide Attribute. Wenn das Attribut Benutzername (1) auch in der Anforderung vorhanden ist, werden der Benutzername und die Buchhaltungssitzungs-ID verwendet, um die Trennung durchzuführen. Das AAA Service Framework verarbeitet die eigentliche Anfrage.

Nachrichtenaustausch

Der RADIUS-Server und das AAA Service Framework tauschen Nachrichten mithilfe von UDP aus. Die vom RADIUS-Server gesendete Disconnect-Request-Nachricht hat das gleiche Format wie das CoA-Request-Paket, das für einen Autorisierungsänderungsvorgang gesendet wird.

Die Trennungsantwort ist entweder eine Disconnect-ACK- oder eine Disconnect-NAK-Nachricht:

• Wenn das AAA Service Framework den Benutzer erfolgreich trennt, ist die Antwort ein RADIUS-formatiertes Paket mit einer Disconnect-ACK-Nachricht.

• Wenn das AAA Service Framework die Verbindung zum Benutzer nicht trennen kann, die Anforderung fehlerhaft ist oder Attribute in der Anforderung fehlen, ist die Antwort ein RADIUS-formatiertes Paket mit einer Disconnect-NAK-Nachricht.

Vorteile von Radius-initiierten Trennungen

Ermöglicht einem RADIUS-Server das dynamische Beenden von Anwender-Sitzungen. Diese zentralisierte Funktion zur Verwaltung von Anwendern vereinfacht die Handhabung einer großen Anzahl von Abonnenten, da die Kündigung durch den Betreiber andernfalls Maßnahmen am Router erfordern würde.

Aktivierungsprozess für Service- und Netzwerkfamilien

Wenn sich ein Anwender anmeldet, muss authd nach der Authentifizierung des Anwenders die entsprechende Adressfamilie aktivieren. Die Clientanwendung, z. B. DHCP oder PPP, kann die Aktivierung einer einzelnen Netzwerkfamilie, IPv4 oder IPv6, oder nacheinander die Aktivierung beider Familien anfordern. Die erfolgreiche Aktivierung der Netzwerkfamilie hängt mit der Aktivierung der zugehörigen Services zusammen. Die folgenden Schritte beschreiben den Prozess, wenn authd für die Verwendung von RADIUS für die Authentifizierung konfiguriert ist:

1. Ein Anwender versucht, sich anzumelden.

   1. Die Clientanwendung fordert die Authentifizierung von authd an.

   2. authd sendet eine Access-Request-Nachricht an den RADIUS-Server.

   3. Der RADIUS-Server sendet eine Access-Accept-Nachricht an authd, die den RADIUS Activate-Service VSA (26-65) enthält.

   4. authd speichert die Serviceaktivierungsattribute im Cache und sendet eine Erteilung an die Clientanwendung.

2. Die Clientanwendung sendet die erste Network-Family-Activate-Anforderung für die IPv4- oder IPv6-Adressfamilie. Diese Anforderung wird manchmal als Clientaktivierungsanforderung bezeichnet.

3. authd überprüft die zwischengespeicherten Serviceaktivierungsattribute und sendet eine Aktivierungsanforderung für die entsprechenden Services an die Anwender Management Infrastructure (SMI). Wenn die Anforderung beispielsweise für die IPv4-Familie gilt, wird nur die Aktivierung der IPv4-Dienste angefordert. Die SMI sendet wiederum Anforderungen an die Server-Daemonen, die dem Dienst zugeordnet sind, z. B. cosd oder filterd.

4. Was authd als nächstes tut, hängt davon ab, ob die Serviceaktivierungsanforderung fehlschlägt und ob der Service optional oder erforderlich ist.

   • Wenn die Dienstaktivierung aufgrund eines Konfigurationsfehlers fehlschlägt und der Dienst optional ist:

     1. authd löscht die zwischengespeicherten Serviceaktivierungsattribute für den Service.

        Hinweis:

        Dieser Löschvorgang ermöglicht es Ihnen, die Serviceanforderung mithilfe einer CoA-Anforderung (RADIUS Change of Authorization) oder eines CLI Befehls erneut auszugeben, ohne dass der fehlgeschlagene Dienst eingreift.

     2. authd sendet eine Bestätigung als Antwort auf die Familienaktivierungsanfrage, und die Familie wird aktiviert.

     3. Die Anmeldung des Anwenders wird fortgesetzt.

   • Wenn die Dienstaktivierung aufgrund eines Konfigurationsfehlers fehlschlägt und der Dienst benötigt wird:

     1. authd löscht die zwischengespeicherten Serviceaktivierungsattribute für den Service.

        Hinweis:

        Dieser Löschvorgang ermöglicht es Ihnen, die Serviceanforderung mithilfe einer CoA-Anforderung (RADIUS Change of Authorization) oder eines CLI Befehls erneut auszugeben, ohne dass der fehlgeschlagene Dienst eingreift.

     2. authd sendet eine NACK als Antwort auf die Familienaktivierung, wodurch die Clientanwendung die Anmeldung des Anwenders beendet.

   • Wenn die Dienstaktivierung aufgrund eines Nichtkonfigurationsfehlers fehlschlägt und der Dienst entweder optional oder erforderlich ist:

     1. authd löscht die zwischengespeicherten Serviceaktivierungsattribute für den Service.

        Hinweis:

        Dieser Löschvorgang ermöglicht es Ihnen, die Serviceanforderung mithilfe einer CoA-Anforderung (RADIUS Change of Authorization) oder eines CLI Befehls erneut auszugeben, ohne dass der fehlgeschlagene Dienst eingreift.

     2. authd sendet eine NACK als Antwort auf die Familienaktivierung, wodurch die Clientanwendung die Anmeldung des Anwenders beendet.

   • Wenn die Serviceaktivierung erfolgreich ist:

     1. authd aktiviert den Dienst.

     2. authd sendet eine Bestätigung als Antwort auf die Familienaktivierungsanfrage, und die Familie wird aktiviert.

     3. Die Anmeldung des Anwenders wird fortgesetzt.

5. Sofern die Dienstaktivierung nicht erforderlich war und fehlgeschlagen ist, wodurch die Familienaktivierung in der ersten Anforderung fehlschlägt, sendet die Clientanwendung möglicherweise eine zweite Anforderung, jedoch nur für die Familie, die beim ersten Mal nicht angefordert wurde. Wenn die erste Anforderung für IPv4 war, kann die zweite Anforderung nur für IPv6 gelten. Wenn die erste Anforderung für IPv6 war, kann die zweite Anforderung nur für IPv4 gelten.

6. authd überprüft die zwischengespeicherten Serviceaktivierungsattribute und fordert die Aktivierung für die Services an, die der angeforderten Adressfamilie zugeordnet sind.

7. Was authd als nächstes tut, hängt davon ab, ob die Serviceaktivierungsanforderung fehlschlägt und ob der Service optional oder erforderlich ist.

   • Wenn die Dienstaktivierung aufgrund eines Konfigurationsfehlers fehlschlägt und der Dienst optional ist:

     1. authd löscht die zwischengespeicherten Serviceaktivierungsattribute für den Service.

        Hinweis:

        Dieser Löschvorgang ermöglicht es Ihnen, die Serviceanforderung mithilfe einer CoA-Anforderung (RADIUS Change of Authorization) oder eines CLI Befehls erneut auszugeben, ohne dass der fehlgeschlagene Dienst eingreift.

     2. authd sendet eine Bestätigung als Antwort auf die Familienaktivierungsanfrage, und die Familie wird aktiviert.

     3. Die Anmeldung des Anwenders wird fortgesetzt.

   • Wenn die Dienstaktivierung aufgrund eines Konfigurationsfehlers fehlschlägt und der Dienst benötigt wird:

     1. authd löscht die zwischengespeicherten Serviceaktivierungsattribute für den Service.

        Hinweis:

        Dieser Löschvorgang ermöglicht es Ihnen, die Serviceanforderung mithilfe einer CoA-Anforderung (RADIUS Change of Authorization) oder eines CLI Befehls erneut auszugeben, ohne dass der fehlgeschlagene Dienst eingreift.

     2. authd sendet einen NACK als Antwort auf die Familienaktivierung. Da es sich um die zweite Familienaktivierungsanforderung handelt, bestimmt das Ergebnis der ersten Familienaktivierung, was als nächstes passiert:

        • Wenn die erste Familienaktivierung erfolgreich war und sich dieser Anwender angemeldet hat, wird die Anmeldung des aktuellen Anwenders nicht gestoppt, wenn die zweite Anforderung fehlschlägt. Dieses Ereignis bewirkt auch nicht, dass authd den vorherigen (ersten Anforderungs-) Anwender abmeldet.

        • Wenn die erste Familienaktivierung nicht erfolgreich war, führt ein Fehler der zweiten Anforderung dazu, dass die Clientanwendung die aktuelle Anmeldung des Anwenders beendet.

   • Wenn die Dienstaktivierung aufgrund eines Nichtkonfigurationsfehlers fehlschlägt und der Dienst entweder optional oder erforderlich ist:

     1. authd löscht die zwischengespeicherten Serviceaktivierungsattribute für den Service.

        Hinweis:

        Dieser Löschvorgang ermöglicht es Ihnen, die Serviceanforderung mithilfe einer CoA-Anforderung (RADIUS Change of Authorization) oder eines CLI Befehls erneut auszugeben, ohne dass der fehlgeschlagene Dienst eingreift.

     2. authd sendet eine NACK als Antwort auf die Familienaktivierung, wodurch die Clientanwendung die Anmeldung des Anwenders beendet.

   • Wenn die Serviceaktivierung erfolgreich ist:

     1. authd aktiviert den Dienst.

     2. authd sendet eine Bestätigung als Antwort auf die Familienaktivierungsanfrage, und die Familie wird aktiviert.

     3. Die Anmeldung des Anwenders wird fortgesetzt.

Zweck

Zeigen Sie dynamische RADIUS-Anforderungsstatistiken und -informationen an.

Aktion

• So zeigen Sie dynamische RADIUS-Anforderungsstatistiken an: