Sitzungsoptionen für den Anwenderzugriff

Zeitüberschreitungen für Abonnentensitzungen

Sie können den Zugriff von Anwendern einschränken, indem Sie ein Sitzungs-Timeout oder ein Leerlauf-Timeout konfigurieren. Verwenden Sie ein Sitzungstimeout, um einen festen Zeitraum anzugeben, in dem der Anwender Zugriff haben darf. Verwenden Sie ein Leerlauftimeout, um einen maximalen Zeitraum anzugeben, in dem sich der Anwender im Leerlauf befinden kann. Sie können diese Timeouts einzeln oder zusammen verwenden. Standardmäßig ist keines der beiden Timeouts vorhanden.

Hinweis:

Für alle Anwendertypen außer DHCP (z. B. L2TP-getunnelte und PPP-terminierte Abonnenten) begrenzt der Sitzungs-Timeout-Wert die Anwender-Sitzung. Für DHCP-Abonnenten wird der Sitzungstimeoutwert verwendet, um die Lease einzuschränken, wenn keine andere Leasezeitkonfiguration vorhanden ist. Die Lease läuft ab, wenn der Timeoutwert abläuft. Wenn dieser Wert weder von der CLI noch von RADIUS bereitgestellt wird, läuft die DHCP-Lease nicht ab.

Das Leerlauftimeout basiert auf Abrechnungsstatistiken für den Anwender. Der Router ermittelt die Inaktivität des Anwenders, indem er den Datenverkehr überwacht, der sowohl vor dem Benutzer (Eingang) als auch nachgelagert zum Benutzer (Ausgang) ist. Datenverkehr kontrollieren wird ignoriert. Der Anwender gilt nicht als inaktiv, solange Datenverkehr in eine der beiden Richtungen erkannt wird.

Optional können Sie angeben, dass nur eingehender Datenverkehr des Anwenders überwacht wird. Ausgehender Datenverkehr wird ignoriert. Diese Konfiguration ist nützlich, wenn das LNS Datenverkehr an den Remote-Peer sendet, auch wenn der Peer nicht aktiv ist, z. B. wenn für das LNS keine PPP-Keepalives aktiviert sind und daher nicht erkannt werden kann, dass der Peer nicht aktiv ist. Da die LAC in diesem Fall standardmäßig sowohl den eingehenden als auch den ausgehenden Datenverkehr überwacht, erkennt sie den ausgehenden Datenverkehr vom LNS und meldet den Anwender entweder nicht ab oder verzögert die Erkennung von Inaktivität, bis der ausgehende Datenverkehr endet. Wenn Sie angeben, dass nur eingehender Datenverkehr überwacht wird, kann die LAC erkennen, dass der Peer inaktiv ist, und dann die Abmeldung initiieren.

Wenn einer der beiden Timeout-Perioden abläuft, werden die Nicht-DHCP-Abonnenten ordnungsgemäß abgemeldet, ähnlich wie bei einer von RADIUS initiierten Trennung oder einer CLI-initiierten Abmeldung. DHCP-Teilnehmer werden getrennt. Der Wert Acct-Terminate-Cause [RADIUS-Attribut 49] enthält den Ursachencode 5 für ein Sitzungstimeout und den Code 4 für ein Leerlauftimeout.

Sie können diese Einschränkungen für den Anwenderzugriff auf Anwender-Basis konfigurieren, indem Sie die RADIUS-Attribute Session-Timeout [27] und Idle-Timeout [28] verwenden. RADIUS gibt diese Attribute in Access-Accept-Nachrichten als Antwort auf Access-Request-Nachrichten vom Zugriffsserver zurück. Ab Junos OS Version 19.4R1 wird das Session-Timeout-Attribut [27] in RADIUS CoA-Nachrichten unterstützt. Diese Funktion ist beispielsweise nützlich, wenn Abonnenten einen Internetzugang für einen bestimmten Zeitraum erwerben und sich nach Ablauf der Sitzung abmelden müssen.

Wenn ein CoA mit Session-Timeout eintrifft, wird das Timeout ab dem Zeitpunkt gezählt, an dem die Sitzung aktiviert wurde. Dies hat folgende Konsequenzen:

• Wenn der Attributwert größer als die Betriebszeit der aktuellen Sitzung ist und zwischen den minimalen und maximalen Timeoutwerten liegt, wird der Anwender abgemeldet, wenn diese Anzahl von Sekunden seit der Aktivierung der Sitzung vergangen ist. Angenommen, die Sitzung wird um 12:00:00 Uhr aktiviert und das CoA wird um 12:00:30 Uhr mit einem Wert von 120 Sekunden empfangen. Der Anwender wird um 12:02:00 Uhr abgemeldet.

  Eine andere Möglichkeit, dies mit denselben Werten zu betrachten, ist, dass die aktuelle Sitzungsbetriebszeit 30 Sekunden und der Attributwert 120 Sekunden beträgt. Der Anwender wird abgemeldet, wenn weitere 90 Sekunden vergangen sind.

• Wenn der Attributwert größer als die Betriebszeit der aktuellen Sitzung, aber kleiner als der minimale Zeitüberschreitungswert von 60 Sekunden ist, wird der Anwender abgemeldet, wenn die Betriebszeit 60 Sekunden erreicht.

• Wenn der Attributwert größer als die Betriebszeit der aktuellen Sitzung, aber größer als der maximale Zeitüberschreitungswert von 31.622.400 Sekunden ist, wird der Anwender abgemeldet, wenn die Betriebszeit 31.622.400 Sekunden erreicht.

• Wenn der Attributwert kleiner als die Betriebszeit der aktuellen Sitzung ist, wird das Sitzungstimeout nicht angewendet. AAA antwortet auf die CoA-Nachricht mit einem NAK. Beispielsweise ist die Sitzung nicht betroffen, wenn das Sitzungs-Timeout 60 Sekunden beträgt, die Betriebszeit jedoch 100 Sekunden beträgt.

Das Anwenden eines Sitzungstimeouts gemäß den oben genannten Regeln hängt auch davon ab, ob alle anderen Aspekte des CoA erfolgreich sind. Wenn das CoA beispielsweise eine Serviceaktivierung enthält und diese Serviceaktivierung fehlschlägt, wird das Sitzungstimeout nicht angewendet. AAA antwortet auf die CoA-Nachricht mit einem NAK.

Hinweis:

Wenn der Session-Timeout-Wert 0 ist, wird jedes vorhandene Sitzungstimeout für diese Sitzung abgebrochen.

Service Provider entscheiden sich oft dafür, die gleichen Einschränkungen auf eine große Anzahl von Abonnenten anzuwenden. Sie können den RADIUS-Bereitstellungsaufwand für dieses Szenario reduzieren, indem Sie die Einschränkungen für Abonnenten in einem Zugriffsprofil pro Routinginstanz definieren. Wenn Sie dies tun, überschreiben RADIUS-Attribute, die anschließend für einen bestimmten Anwender zurückgegeben werden, der mit dem Profil angemeldet ist, die Werte pro Routing-Instanz.

Optimale Vorgehensweise:

Es wird empfohlen, kein Sitzungstimeout für Abonnenten zu konfigurieren, die Sprachdienste empfangen. Da das Sitzungstimeout nur auf der Zeit und nicht auf der Benutzeraktivität basiert, ist es wahrscheinlich, dass Teilnehmer, die aktiv einen Sprachdienst nutzen, unterbrochen und ihre Anrufe unerwartet beendet werden (aus Sicht des Anwenders). Dieses Ergebnis ist besonders besorgniserregend für Notrufe.

Optimale Vorgehensweise:

Es wird empfohlen, kein Leerlauf-Timeout für DHCP-Abonnenten zu konfigurieren. Wenn das Timeout ohne Aktivität abläuft und die Verbindung beendet wird, hat das Protokoll keine Möglichkeit, den Client zu informieren. Folglich sind diese Teilnehmer gezwungen, ihr CPE-Gerät neu zu starten, wenn sie das nächste Mal versuchen, auf das Internet zuzugreifen.

Vergleichen Sie das Verhalten, wenn ein Leerlauf-Timeout für PPP-Abonnenten konfiguriert ist. In diesem Fall führt der Ablauf des Timeouts dazu, dass PPP die Verbindung mit dem Peer beendet. Je nach CPE-Gerät ermöglicht diese Beendigung dem Peer, die Verbindung automatisch bei Bedarf oder sofort zu wiederholen. In beiden Fällen ist kein Eingreifen des Anwenders erforderlich.

Der verfügbare Bereich zum Festlegen eines Timeouts ist derselbe, unabhängig davon, ob Sie es in der CLI oder über die RADIUS-Attribute konfigurieren:

• Sitzungstimeouts können in der CLI auf 1 Minute bis 527.040 Minuten und im Session-Timeout-Attribut auf die entsprechende Anzahl von Sekunden (60 bis 31.622.400) festgelegt werden [27].

• Leerlauf-Timeouts können in der CLI auf 10 Minuten bis 1440 Minuten und im Idle-Timeout-Attribut auf die entsprechende Anzahl von Sekunden (600 bis 86.400) festgelegt werden [28].

Der Router interpretiert die Werte in den Attributen so, dass sie den unterstützten Bereichen entsprechen. Zum Beispiel für Session-Timeout [27]:

• Ein Wert von Null wird als kein Timeout behandelt.

• Ein Wert im Bereich von 1 bis 59 wird auf 60 Sekunden erhöht.

• Ein Wert, der 31.622.400 überschreitet, wird auf 31.622.400 Sekunden reduziert.

Für Leerlauf-Timeout [28]:

• Ein Wert von Null wird als kein Timeout behandelt.

• Ein Wert im Bereich von 1 bis 599 wird auf 600 Sekunden erhöht.

• Ein Wert, der 86.400 überschreitet, wird auf 86.400 Sekunden reduziert.

In Konfigurationen, die dynamisch erstellte Anwender-VLANs verwenden, löscht das Leerlauf-Timeout auch die inaktiven Anwender-VLANs, wenn der Inaktivitätsschwellenwert erreicht ist. Zusätzlich zum Löschen inaktiver dynamischer Anwender-VLANs werden durch das Leerlauf-Timeout auch dynamische VLANs entfernt, wenn nie eine Client-Sitzung erstellt wurde (z. B. wenn keine Client-Sitzungen im dynamischen VLAN erstellt werden oder nach dem Auftreten eines Fehlers während der Sitzungserstellung oder Client-Authentifizierung, wenn keine Client-Sitzungen im dynamischen VLAN erstellt werden).

Sitzungs- und Leerlauf-Timeouts zum Löschen dynamischer Anwender-VLANs sind nur in sehr begrenzten Anwendungsfällen nützlich. In der Regel ist keines der Timeouts für diesen Zweck konfiguriert.

Ein möglicher Umstand, unter dem sie nützlich sein könnten, ist, wenn die dynamischen VLANs kein Protokoll der oberen Schicht haben, das bestimmt, wann das VLAN mit der remove-when-no-subscribers Anweisung entfernt wird, z. B. wenn das VLAN IP over Ethernet ohne DHCP in einem Business-Zugriffsmodell mit festen Adressen unterstützt. Der geschäftliche Zugriff ist jedoch im Allgemeinen ein Service der höheren Ebene als der private Zugriff und unterliegt daher in der Regel keinen Zeitüberschreitungen aufgrund von Inaktivität, wie es für Privatkunden wünschenswert wäre.

Ein Leerlauf-Timeout kann in bestimmten Layer-2-Großhandels-Situationen angemessen sein, in denen die Verbindung neu generiert werden kann, wenn ein Paket vom CPE empfangen wird.

Wenn Sie das Leerlauf-Timeout für die dynamische VLAN-Entfernung verwenden, beachten Sie Folgendes:

• Die Leerlaufzeit beginnt, nachdem eine dynamische Anwender-VLAN-Schnittstelle erstellt wurde oder die Datenverkehrsaktivität auf einer dynamischen Anwender-VLAN-Schnittstelle gestoppt wurde.

• Wenn eine neue Client-Sitzung erstellt oder eine Client-Sitzung erfolgreich reaktiviert wird, wird das Client-Leerlauf-Timeout zurückgesetzt.

• Das Entfernen inaktiver Anwender-VLANs funktioniert nur bei authentifizierten VLANs.

Beschränkungen für Abonnentensitzungen pro Benutzername und Zugriffsprofil

Legitime Abonnenten könnten ihre Anmeldeinformationen an Unbefugte weitergeben und so Ressourcen des Service Providers verbrauchen, ohne dass der Provider davon profitiert. Ab Junos OS Version 18.4R1 können Sie die Freigabe von Anmeldeinformationen steuern oder verhindern, indem Sie die Anzahl der aktiven Anwender-Sitzungen begrenzen, die für einen bestimmten Benutzernamen zulässig sind, der einem Zugriffsprofil zugeordnet ist. Sie können diese Steuerung auch mit RADIUS erreichen, aber die lokale Konfiguration des Grenzwerts auf dem BNG beseitigt die Abhängigkeit von einem externen Server.

Wenn Sie ein Limit konfigurieren, werden aktive Sitzungen für die Kombination aus Benutzername und Zugriffsprofil nachverfolgt. Die Anzahl der verfolgten Sitzungen wird überprüft, wenn authd eine neue Sitzungsanmeldeanforderung erhält. Wenn die Anzahl der nachverfolgten Sitzungen dem Limit entspricht, wird der neue Anmeldeversuch abgelehnt und als blockierte Anforderung gezählt.

Wenn authd eine Abmelde- oder Clientbeendigungsanforderung für eine Sitzung erhält, wird die Anzahl der nachverfolgten Sitzungen für diesen Benutzernamen/Zugriffsprofileintrag verringert. Wenn dies so lange anhält, bis keine aktiven Sitzungen für die Kombination vorhanden sind, wird der Eintrag aus der Sitzungslimittabelle entfernt. Alle zugehörigen Benutzernamen-/Zugriffsprofileinträge werden aus der Tabelle entfernt, wenn Sie das Zugriffsprofil oder das Sitzungslimit aus Ihrer Konfiguration löschen.

Die Gesamtzahl der Sitzungen für einen Benutzernamen kann den konfigurierten Grenzwert für ein bestimmtes Zugriffsprofil überschreiten, da derselbe Benutzername für mehrere Zugriffsprofile verwendet werden kann.

Hinweis:

Bei gestapelten Anwender-Sitzungen, wie z. B. PPP mit automatisch konfigurierten VLANs, werden beide Benutzernamen im Stapel zur Authentifizierung verwendet und folglich beide auf das Sitzungslimit angerechnet.

Der konfigurierte Grenzwert gilt für vorhandene aktive Abonnenten, vorhandene Sitzungen werden jedoch nicht beendet, wenn die Anzahl der aktiven Sitzungen den Grenzwert für einen Anwender mit dieser Kombination aus Benutzername und Zugriffsprofil überschreitet.

Stellen Sie sich eine Situation vor, in der derzeit fünf Sitzungen für eine bestimmte Kombination aus Benutzername und Zugriffsprofil aktiv sind, wenn Sie ein Limit von zwei konfigurieren.

1. Die Anzahl der aktiven Sitzungen wird im Tabelleneintrag für das Sitzungslimit für die Kombination als fünf vermerkt.

2. Ein neuer Anwender mit demselben Benutzernamen und Zugriffsprofil versucht sich anzumelden. Der Versuch wird blockiert, da das Limit von zwei Sitzungen bereits überschritten ist (fünf > zwei).

3. Ein vorhandener Anwender meldet sich ab, wodurch die Anzahl der aktiven Sitzungen auf vier reduziert wird.

4. Ein neuer Anwender mit demselben Benutzernamen und Zugriffsprofil versucht sich anzumelden. Der Versuch wird blockiert, da das Limit von zwei Sitzungen immer noch überschritten wird (vier > zwei).

5. Drei bestehende Abonnenten melden sich ab, wodurch sich die Anzahl der aktiven Sitzungen auf eine reduziert.

6. Ein neuer Anwender mit demselben Benutzernamen und Zugriffsprofil versucht sich anzumelden. Der Versuch wird zugelassen, da das Limit von zwei Sitzungen noch nicht erreicht wurde (eine < zwei).

Das Sitzungslimitdesign verhindert ein Denial-of-Service-Ereignis, bei dem ein böswilliger Benutzer mehrere Anmeldeversuche mit dem richtigen Benutzernamen und Zugriffsprofil, aber dem falschen Passwort unternimmt. Die zahlreichen Anmeldeversuche können das konfigurierte Sitzungslimit überschreiten, dies geschieht jedoch nicht, da die Anzahl der nachverfolgten Sitzungen nur erhöht wird, wenn der Sitzungsstatus des Anwenders in den aktiven Zustand übergeht, den die böswilligen Anmeldungen nicht erreichen.

Vorteile der Sitzungsbeschränkung für Benutzernamen mit der CLI

• Ermöglicht es Ihnen, die Anzahl der Sitzungen lokal auf dem Router zu begrenzen, anstatt von einem externen RADIUS-Server abhängig zu sein, um dieses Limit bereitzustellen.

• Verhindert einige Denial-of-Service-Angriffe basierend auf mehreren Anmeldungen.

Änderung des Benutzernamens des Abonnenten

Für Layer-2-Anwendungen im Großhandel verwenden einige Netzwerkdienstanbieter eine Änderung des Benutzernamens, um Abonnenten an das entsprechende Unternehmensnetzwerk für den Einzelhandel weiterzuleiten. Diese Änderung wird auch als Benutzernamen-Stripping bezeichnet, da einige der Zeichen im Benutzernamen entfernt und verworfen werden. Der Rest der Zeichenfolge wird zum neuen, geänderten Benutzernamen. Der geänderte Benutzername wird von einem externen AAA Server für die Sitzungs Authentifizierung und die Abrechnung verwendet. Die Änderungsparameter werden gemäß einem Anwender-Zugriffsprofil angewendet, das auch den Anwender- und Sitzungskontext bestimmt. Das heißt, die logische System:Routing-Instanz (LS:RI), die vom Anwender verwendet wird. Es wird nur das standardmäßige (primäre) logische System unterstützt. Da der Großhändler zwischen mehreren Einzelhändlern unterscheidet, indem er sie jeweils in eine andere LS:RI einordnet, werden die Benutzernamen für jeden Einzelhändler entsprechend geändert.

Sie können bis zu acht Zeichen als Trennzeichen auswählen, um die Grenze zwischen den verworfenen und den beibehaltenen Teilen des ursprünglichen Benutzernamens zu markieren. Es gibt kein Standardtrennzeichen. Der Teil des Namens rechts neben dem ausgewählten Trennzeichen wird zusammen mit dem Trennzeichen verworfen. Durch die Konfiguration mehrerer Trennzeichen kann eine bestimmte Benutzernamenstruktur zu unterschiedlichen geänderten Benutzernamen führen. Sie können die Richtung konfigurieren, in der der ursprüngliche Name analysiert wird, um zu bestimmen, welches Trennzeichen die Grenze markiert. Standardmäßig ist die Analyserichtung von links nach rechts.

Betrachten Sie die folgenden Beispiele:

• Sie geben ein Trennzeichen an, @. Der Benutzername ist user1@example.com. In diesem Fall spielt die Analyserichtung keine Rolle. In beiden Fällen wird das einzelne Trennzeichen gefunden und example.com verworfen. Der geänderte Benutzername ist user1.

  

• Sie geben ein Trennzeichen an, @. Der Benutzername ist user1@test@example.com. In diesem Fall führt die Analyserichtung zu unterschiedlichen Benutzernamen.

  • Die Analyserichtung ist von links nach rechts: Das @ ganz links wird als Trennzeichen identifiziert und test@example.com wird verworfen. Der geänderte Benutzername ist user1.

  • Die Analyserichtung ist von rechts nach links: Das @ ganz rechts wird als Trennzeichen identifiziert, und example.com wird verworfen. Der geänderte Benutzername ist user1@test.

  

• Sie geben zwei Trennzeichen an, @ und /. Der Benutzername lautet user1@bldg1/example.com. Die Analyserichtung führt zu unterschiedlichen Benutzernamen.

  • Die Analyserichtung ist von links nach rechts: Das @ wird als Trennzeichen identifiziert, und bldg1/example.com wird verworfen. Der geänderte Benutzername ist user1.

  • Die Analyserichtung ist von rechts nach links: Das / wird als Trennzeichen identifiziert und example.com wird verworfen. Der geänderte Benutzername ist user1@bldg1.

  

Sie können ein Anwender Zugriffsprofil konfigurieren, sodass ein Teil jeder Anwender Anmeldezeichenfolge entfernt und anschließend von einem externen AAA Server als geänderter Benutzername für die Sitzungs Authentifizierung und das Konto verwendet wird. Der geänderte Benutzername wird z. B. in RADIUS Access-Request-, Acct-Start- und Acct-Stop-Nachrichten sowie in von RADIUS initiierten Trennungsanforderungen und Change of Authorization (CoA)-Anforderungen angezeigt.

Vorteile der Änderung des Benutzernamens des Abonnenten

• Ermöglicht es Service Providern von Layer-2-Netzwerken im Großhandel, Abonnenten einfach an das entsprechende Unternehmensnetzwerk für den Einzelhandel zu leiten.