Sitzungsoptionen für den Anwenderzugriff

Zeitüberschreitungen bei Abonnentensitzungen

Sie können den Abonnentenzugriff einschränken, indem Sie ein Sitzungstimeout oder ein Leerlauftimeout konfigurieren. Verwenden Sie ein Sitzungstimeout, um einen festen Zeitraum anzugeben, auf den der Abonnent zugreifen darf. Verwenden Sie ein Leerlauftimeout, um eine maximale Zeitspanne anzugeben, in der sich der Abonnent im Leerlauf befinden kann. Sie können diese Zeitüberschreitungen einzeln oder zusammen verwenden. Standardmäßig ist keines der Zeitüberschreitungen vorhanden.

Anmerkung:

Für alle Anwendertypen außer DHCP (z. B. L2TP-getunnelte und PPP-terminierte Abonnenten) begrenzt der Sitzungstimeoutwert die Abonnentensitzung. Bei 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 Buchhaltungsstatistiken für den Abonnenten. Der Router ermittelt die Inaktivität des Teilnehmers, indem er den Datenverkehr überwacht, und zwar sowohl vorgelagert vom Benutzer (Ingress) als auch abwärts zum Benutzer (Egress). Steuerungsdatenverkehr wird ignoriert. Der Abonnent gilt nicht als inaktiv, solange Datenverkehr in eine der beiden Richtungen erkannt wird.

Optional können Sie angeben, dass nur eingehender Datenverkehr für Abonnenten überwacht wird. Ausgehender Datenverkehr wird ignoriert. Diese Konfiguration ist nützlich in Fällen, in denen der LNS Datenverkehr an den Remote-Peer sendet, auch wenn der Peer nicht aktiv ist, z. B. wenn der LNS keine PPP-Keepalives aktiviert hat und daher nicht erkennen kann, dass der Peer nicht aktiv ist. Da die LAC in dieser Situation standardmäßig sowohl den eingehenden als auch den ausgehenden Datenverkehr überwacht, erkennt sie den ausgehenden Datenverkehr vom LNS und meldet den Teilnehmer entweder nicht ab oder verzögert die Erkennung der Inaktivität, bis der ausgehende Datenverkehr beendet wird. Wenn Sie angeben, dass nur eingehender Datenverkehr überwacht wird, kann die LAC erkennen, dass der Peer inaktiv ist, und dann die Abmeldung einleiten.

Wenn eine Zeitüberschreitung abläuft, werden die Nicht-DHCP-Abonnenten ordnungsgemäß abgemeldet, ähnlich wie bei einer von RADIUS initiierten Trennung oder einer von der CLI initiierten Abmeldung. Die Verbindung zu DHCP-Abonnenten wird 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 Abonnentenzugriff auf Teilnehmerbasis 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 Attribut "Session-Timeout" [27] in RADIUS-CoA-Nachrichten unterstützt. Diese Funktion ist z. B. nützlich, wenn Abonnenten 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 aktuelle Sitzungsbetriebszeit und zwischen den minimalen und maximalen Timeoutwerten liegt, wird der Abonnent abgemeldet, wenn diese Anzahl von Sekunden seit der Sitzungsaktivierung 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 Abonnent wird um 12:02:00 Uhr abgemeldet.

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

• Wenn der Attributwert größer als die aktuelle Sitzungsbetriebszeit, aber kleiner als der minimale Timeoutwert von 60 Sekunden ist, wird der Abonnent abgemeldet, wenn die Betriebszeit 60 Sekunden erreicht.

• Wenn der Attributwert größer als die aktuelle Sitzungsbetriebszeit, aber größer als der maximale Timeoutwert von 31.622.400 Sekunden ist, wird der Abonnent abgemeldet, wenn die Betriebszeit 31.622.400 Sekunden erreicht.

• Wenn der Attributwert kleiner als die aktuelle Sitzungsbetriebszeit 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.

Die Anwendung eines Sitzungs-Timeouts gemäß den oben genannten Regeln hängt auch davon ab, ob alle anderen Aspekte des CoA erfolgreich sind. Wenn das CoA z. B. eine Dienstaktivierung enthält und diese Dienstaktivierung fehlschlägt, wird das Sitzungstimeout nicht angewendet. AAA antwortet auf die CoA-Nachricht mit einem NAK.

Anmerkung:

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

Service Provider entscheiden sich häufig 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 die RADIUS-Attribute, die anschließend für einen bestimmten Abonnenten zurückgegeben werden, der mit dem Profil angemeldet ist, die Werte pro Routinginstanz.

Beste Praxis:

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 einen Sprachdienst aktiv nutzen, unterbrochen und ihre Anrufe unerwartet beendet werden (aus Sicht des Teilnehmers). Dieses Ergebnis ist besonders besorgniserregend für Notrufe.

Beste Praxis:

Es wird empfohlen, kein Leerlauftimeout für DHCP-Abonnenten zu konfigurieren. Wenn die Zeitüberschreitung 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 Leerlauftimeout für PPP-Abonnenten konfiguriert ist. In diesem Fall führt der Ablauf der Zeitüberschreitung dazu, dass PPP die Verbindung mit dem Peer beendet. Je nach CPE-Gerät ermöglicht diese Terminierung dem Peer, die Verbindung entweder bei Bedarf oder sofort automatisch 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 ihn in der CLI oder über die RADIUS-Attribute konfigurieren:

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

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

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 keine Zeitüberschreitung 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 Idle-Timeout [28]:

• Ein Wert von Null wird als keine Zeitüberschreitung 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 wurde. Zusätzlich zum Löschen inaktiver dynamischer Anwender-VLANs werden mit dem Leerlauf-Timeout auch dynamische VLANs entfernt, wenn noch keine Client-Sitzungen erstellt wurden (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 von dynamischen Abonnenten-VLANs sind nur in sehr begrenzten Anwendungsfällen sinnvoll. In der Regel wird keine Zeitüberschreitung für diesen Zweck konfiguriert.

Sie könnten unter Umständen nützlich sein, wenn die dynamischen VLANs über kein Protokoll der oberen Ebene verfügen, mit dem bestimmt werden kann, wann das VLAN mit der remove-when-no-subscribers Anweisung entfernt wird, z. B. wenn das VLAN IP over Ethernet ohne DHCP in einem Geschäftszugriffsmodell mit festen Adressen unterstützt. Der Geschäftszugriff ist jedoch in der Regel ein höherwertiger Dienst als der Privatzugriff und unterliegt daher in der Regel keinen Zeitüberschreitungen aufgrund von Inaktivität, wie dies für Privatkunden wünschenswert sein könnte.

Ein Leerlauftimeout kann in bestimmten Layer-2-Großhandelssituationen angemessen sein, in denen die Verbindung regeneriert werden kann, wenn ein Paket vom CPE empfangen wird.

Beachten Sie bei Verwendung des Leerlauf-Timeouts zum Entfernen dynamischer VLANs Folgendes:

• Die Leerlauf-Zeitüberschreitung beginnt, nachdem eine VLAN-Schnittstelle für dynamische Teilnehmer erstellt oder die Datenverkehrsaktivität auf einer VLAN-Schnittstelle für dynamische Teilnehmer beendet wurde.

• Wenn eine neue Clientsitzung erstellt oder eine Clientsitzung erfolgreich reaktiviert wird, wird das Leerlauftimeout des Clients zurückgesetzt.

• Das Entfernen inaktiver Anwender-VLANs funktioniert nur bei VLANs, die authentifiziert wurden.

Limits für Abonnentensitzungen pro Benutzername und Zugriffsprofil

Berechtigte Abonnenten können ihre Anmeldedaten an nicht autorisierte Personen weitergeben und so Ressourcen des Dienstanbieters ohne Vorteil für den Anbieter verbrauchen. Ab Junos OS Version 18.4R1 können Sie die gemeinsame Nutzung von Anmeldeinformationen steuern oder verhindern, indem Sie die Anzahl der aktiven Abonnentensitzungen 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 getrackten Sitzungen wird überprüft, wenn authd eine neue Session-Login-Anfrage erhält. Wenn die Anzahl der nachverfolgten Sitzungen dem Limit entspricht, wird der neue Anmeldeversuch abgelehnt und als blockierte Anfrage gezählt.

Wenn authd eine Abmelde- oder Client-Beendigungsanforderung für eine Sitzung erhält, wird die Anzahl der nachverfolgten Sitzungen für diesen Benutzernamen/Zugriffsprofileintrag verringert. Wenn dies so lange fortgesetzt wird, bis keine aktiven Sitzungen für die Kombination mehr vorhanden sind, wird der Eintrag aus der Sitzungslimittabelle entfernt. Alle zugehörigen Einträge für Benutzernamen/Zugriffsprofile 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 das konfigurierte Limit für ein bestimmtes Zugriffsprofil überschreiten, da derselbe Benutzername mit mehreren Zugriffsprofilen verwendet werden kann.

Anmerkung:

Bei gestapelten Abonnentensitzungen, wie z. B. PPP mit automatisch konfigurierten VLANs, werden beide Benutzernamen im Stack für die Authentifizierung verwendet und folglich beide auf das Sitzungslimit angerechnet.

Der konfigurierte Grenzwert gilt für vorhandene aktive Abonnenten, aber vorhandene Sitzungen werden nicht aufgelöst, wenn die Anzahl der aktiven Sitzungen den Grenzwert für einen Abonnenten 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 die Sitzungsbegrenzung für die Kombination als fünf aufgezeichnet.

2. Ein neuer Abonnent 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 Abonnent meldet sich ab, wodurch die Anzahl der aktiven Sitzungen auf vier reduziert wird.

4. Ein neuer Abonnent 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 vorhandene Abonnenten melden sich ab, wodurch die Anzahl der aktiven Sitzungen auf eine reduziert wird.

6. Ein neuer Abonnent 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 Sitzungslimit verhindert ein Denial-of-Service-Ereignis, bei dem ein böswilliger Benutzer mehrere Anmeldeversuche mit dem richtigen Benutzernamen und Zugriffsprofil, aber dem falschen Kennwort unternimmt. Die zahlreichen Anmeldeversuche können das konfigurierte Sitzungslimit überschreiten, dies tritt jedoch nicht auf, da die Anzahl der nachverfolgten Sitzungen nur dann erhöht wird, wenn der Sitzungsstatus des Abonnenten in den aktiven Zustand übergeht, was bei den böswilligen Anmeldungen nicht der Fall ist.

Vorteile der Begrenzung von Sitzungen 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, der das Limit bereitstellt.

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

Änderung des Benutzernamens des Abonnenten

Für Layer 2-Großhandelsanwendungen verwenden einige Netzwerk-Service Provider die Änderung von Benutzernamen, um Abonnenten an das entsprechende Unternehmensnetzwerk 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 Sitzungsauthentifizierung und Kontoführung verwendet. Die Änderungsparameter werden gemäß einem Abonnentenzugriffsprofil angewendet, das auch den Abonnenten- und Sitzungskontext bestimmt. d. h. die logische System:Routing-Instanz (LS:RI), die vom Abonnenten verwendet wird. Es wird nur das logische Standardsystem (primär) unterstützt. Da der Großhändler zwischen mehreren Einzelhändlern unterscheidet, indem er sie in einer anderen LS:RI platziert, werden die Benutzernamen für jeden Einzelhändler entsprechend angepasst.

Sie können bis zu acht Zeichen als Trennzeichen auswählen, um die Grenze zwischen den verworfenen und 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 unterschiedlich 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 lautet user1@example.com. In diesem Fall spielt die Analyserichtung keine Rolle. In beiden Fällen wird das einzelne Trennzeichen gefunden, und example.com wird verworfen. Der geänderte Benutzername lautet user1.

  

• Sie geben ein Trennzeichen an, @. Der Benutzername lautet 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 lautet user1.

  • Die Analyserichtung ist von rechts nach links: Das @ ganz rechts wird als Trennzeichen identifiziert und example.com 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: @ wird als Trennzeichen identifiziert und bldg1/example.com wird verworfen. Der geänderte Benutzername lautet 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 Teilnehmerzugriffsprofil so konfigurieren, dass ein Teil jeder Teilnehmeranmeldezeichenfolge entfernt und anschließend von einem externen AAA-Server als geänderter Benutzername für die Sitzungsauthentifizierung und Kontoführung verwendet wird. Der geänderte Benutzername wird z. B. in RADIUS-Access-Request-, Acct-Start- und Acct-Stop-Meldungen sowie in von RADIUS initiierten Trennungsanforderungen und CoA-Anforderungen (Change of Authorization) angezeigt.

Vorteile der Änderung des Benutzernamens für Abonnenten

• Ermöglicht Serviceanbietern von Layer 2-Großhandelsnetzwerken, ihre Teilnehmer problemlos an das geeignete Unternehmensnetzwerk für Großkunden weiterzuleiten.