L2TP für Anwenderzugriff – Übersicht

Das Layer 2 Tunneling Protocol (L2TP) ist ein Client-Server-Protokoll, mit dem das Point-to-Point Protocol (PPP) über ein Netzwerk getunnelt werden kann. L2TP kapselt Layer-2-Pakete wie PPP für die Übertragung über ein Netzwerk ein. Ein L2TP Access Concentrator (LAC), der auf einem Zugriffsgerät konfiguriert ist, empfängt Pakete von einem Remote-Client und leitet sie an einen L2TP-Netzwerkserver (LNS) in einem Remote-Netzwerk weiter. Das LNS fungiert als logischer Endpunkt der PPP-Sitzung, die vom LAC vom Remote-Client aus getunnelt wird. Abbildung 1 zeigt eine einfache L2TP-Topologie.

L2TP trennt die Terminierung von Zugangstechnologien wie Kabel oder xDSL von der Beendigung von PPP und dem anschließenden Zugriff auf ein Netzwerk. Diese Trennung ermöglicht es öffentlichen ISPs, ihre Zugangstechnologien an wettbewerbsfähige Ortsnetzbetreiber (CLECs) auszulagern. L2TP bietet ISPs die Möglichkeit, VPN-Services bereitzustellen; Private Unternehmen können die Investitionen in Zugangstechnologien für Telearbeiter reduzieren oder vermeiden.

Sie können Ihren Router so konfigurieren, dass er als LAC im PPP-Pass-Through-Modus fungiert, in dem der LAC Pakete von einem Remote-Client empfängt und diese dann auf Layer 2 direkt an das LNS weiterleitet. Die PPP-Sitzung wird auf dem LNS beendet. Diese LAC-Implementierung unterstützt nur PPPoE-Abonnenten (Point-to-Point Protocol over Ethernet) über dynamische oder statische logische Schnittstellen. Abbildung 2 zeigt das Protokollschicht-Stacking für eine L2TP-Pass-Through-Verbindung.

Hinweis:

Auf Routern der MX-Serie werden die LAC- und LNS-Funktionen nur auf MPCs unterstützt. Sie werden von keinem Service, PIC oder MS-DPC unterstützt. Weitere Informationen zur MPC-Unterstützung für L2TP finden Sie in der Referenz zu Schnittstellenmodulen der MX-Serie.

Bestimmte Router der M Series unterstützen LNS-Funktionen für Service-PICs. Weitere Informationen zur L2TP-Implementierung auf Routern der M Series finden Sie unter L2TP Services Configuration Overview.

Die LAC erstellt dynamisch Tunnel auf der Grundlage von AAA-Authentifizierungsparametern und überträgt L2TP-Pakete über das IP/User Datagram Protocol (UDP) an das LNS. Der Datenverkehr wird in einem L2TP sessionübertragen; ein Tunnel ist eine Aggregation von einer oder mehreren Sitzungen. Sie können auch eine Domänenzuordnung bereitstellen, die von AAA verwendet wird, um zu bestimmen, ob der PPPoE-Anwender in der LAC per Tunnel getunnelt oder beendet werden soll. Zwischen jedem PPP-Anwender, der zum LNS getunnelt wird, und einer L2TP-Sitzung besteht eine Eins-zu-Eins-Zuordnung.

Wenn es sich bei dem LNS um einen Router der MX-Serie handelt, stellt eine LAC-ausgerichtete Peer-Schnittstelle auf einem MPC eine IP-Adresse für den Austausch von IP-Paketen zwischen den Tunnel-Endpunkten bereit. Die Routing-Engine verwaltet die L2TP-Tunnel. Die Packet Forwarding Engine hostet eine oder mehrere Inline-Serviceschnittstellen (si). Diese Schnittstellen funktionieren wie eine virtuelle physische Schnittstelle und verankern die L2TP-Sitzungen im LNS. Die si Schnittstelle ermöglicht L2TP-Services, ohne dass ein spezielles Services-PIC erforderlich ist. Schließlich wird eine weitere Schnittstelle verwendet, um die Daten des Anwenders in und aus dem Internet zu übertragen.

Die Merkmale des Tunnels können entweder von einem von Ihnen konfigurierten Tunnel-Profil oder von RADIUS-Tunnel-Attributen und anbieterspezifischen Attributen (VSAs) des AAA-Servers stammen, auf den in der LAC zugegriffen werden kann. Sie können ein Tunnel-Profil in eine Domänenzuordnung aufnehmen, die das Tunnel-Profil anwendet, bevor die RADIUS-Authentifizierung stattfindet. Sie können RADIUS-Standardattribute und VSAs verwenden, um einige oder alle Merkmale zu überschreiben, die vom Tunnel-Profil in einer Domänenzuordnung konfiguriert wurden. Alternativ kann RADIUS selbst ein Tunnelprofil anwenden, wenn die RADIUS Tunnel-Group VSA [26-64] im RADIUS-Login angegeben ist.

Hinweis:

L2TP wird über GRE-Tunnel nicht unterstützt.

Der virtuelle Router VSA [26-1] im Anwenderprofil auf dem Service Provider AAA-Server (zugänglich über das LNS) bestimmt die Routing-Instanz, in der die L2TP-Sitzung auf dem LNS aufgerufen wird. Wenn dieser VSA nicht vorhanden ist, wird die Anwendersitzung in derselben Routing-Instanz wie der Tunnel gestartet, da auf den AAA-Server nur von der Routing-Instanz aus zugegriffen werden kann, in der der Tunnel auf dem LNS endet.

Dieses Verhalten unterscheidet sich von DHCP- und nicht getunnelten PPPoE-Abonnenten, die in der Standardrouting-Instanz angezeigt werden, wenn der virtuelle Router-VSA nicht vorhanden ist. Für L2TP-Abonnenten müssen Sie diesen VSA in das Anwenderprofil aufnehmen, wenn die Anwender-Sitzung in einer anderen Routing-Instanz als der Tunnel-Routing-Instanz gestartet werden soll.

Ab Junos OS Version 17.4R1 enthält das LNS die folgenden RADIUS-Attribute, wenn es eine Access-Request-Nachricht an den RADIUS-Server sendet:

• Tunnel-Typ (64)

• Tunnel-Mitteltyp (65)

• Tunnel-Client-Endpunkt (66)

• Tunnel-Server-Endpunkt (67)

• Acct-Tunnel-Verbindung (68)

• Tunnelzuweisungs-ID (82)

• Tunnel-Client-Authentifizierungs-ID (90)

• Tunnel-Server-Authentifizierungs-ID (91)

In früheren Versionen hat das LNS diese Attribute nur in die Buchhaltungsunterlagen aufgenommen, die es an den RADIUS-Server sendet. In den Access-Request-Nachrichten können sie verwendet werden, um auf dem RADIUS-Server die Sitzung von der LAC zum LNS zu korrelieren.

Die LAC unterstützt die von RADIUS initiierte Spiegelung, bei der sichere Richtlinien auf der Grundlage bestimmter RADIUS-VSAs erstellt werden, und verwendet RADIUS-Attribute zur Identifizierung eines Anwenders, dessen Datenverkehr gespiegelt werden soll. (Diese Funktion wird für LNS, das auf einem Router der MX-Serie konfiguriert ist, nicht unterstützt.)

Die LAC und die LNS unterstützen eine einheitliche ISSU. Wenn ein Upgrade initiiert wird, schließt die LAC alle laufenden L2TP-Verhandlungen ab, lehnt jedoch alle neuen Verhandlungen ab, bis das Upgrade abgeschlossen ist. Während des Upgrades werden keine neuen Tunnel oder Sitzungen eingerichtet. Abmeldungen von Abonnenten werden während des Upgrades aufgezeichnet und nach Abschluss des Upgrades abgeschlossen.

In Tabelle 1 werden die Grundbegriffe für L2TP beschrieben.

Tabelle 1: L2TP-Bedingungen

Begriff	Beschreibung
AVP	Attribut-Wert-Paar (AVP): Kombination aus einem eindeutigen Attribut, das durch eine ganze Zahl dargestellt wird, und einem Wert, der den tatsächlichen Wert enthält, der durch das Attribut identifiziert wird.
Anruf	Eine Verbindung (oder versuchte Verbindung) zwischen einem Remotesystem und der LAC.
LAC	L2TP Access Concentrator (LAC): Ein Knoten, der als eine Seite eines L2TP-Tunnel-Endgeräts fungiert und ein Peer zum LNS ist. Der LAC befindet sich zwischen einem LNS und einem Remote-System und leitet Pakete an und von jedem weiter.
LNS	L2TP-Netzwerkserver (LNS): Ein Knoten, der als eine Seite eines L2TP-Tunnel-Endgeräts fungiert und ein Peer zur LAC ist. Das LNS ist der logische Endpunkt einer PPP-Verbindung, die vom entfernten System durch die LAC getunnelt wird.
Peer	Im L2TP-Kontext entweder LAC oder LNS. Der Peer der LAC ist ein LNS und umgekehrt.
Proxy-Authentifizierung	PPP Pre-Authentifizierung von der LAC im Auftrag des LNS durchgeführt. Die Proxydaten werden von der LAC an das LNS gesendet, die Attribute wie Authentifizierungstyp, Authentifizierungsname und Authentifizierungs-Challenge enthalten. Das LNS antwortet mit den Ergebnissen der Authentifizierung.
Proxy-LCP	Link Control Protocol (LCP)-Aushandlung, die von der LAC im Namen des LNS durchgeführt wird. Der Proxy wird von der LAC an das LNS gesendet, das Attribute wie die letzten vom Client gesendeten und empfangenen Konfigurationsattribute enthält.
Remote-System	Ein Endsystem oder ein Router, der an ein RAS-Netzwerk angeschlossen ist und entweder der Initiator oder der Empfänger eines Anrufs ist.
Sitzung	Eine logische Verbindung zwischen der LAC und dem LNS, wenn eine End-to-End-PPP-Verbindung zwischen einem entfernten System und dem LNS hergestellt wird. Hinweis: Es besteht eine Eins-zu-Eins-Beziehung zwischen etablierten L2TP-Sitzungen und den zugehörigen PPP-Verbindungen.
Tunnel	Eine Verbindung zwischen dem LAC-LNS-Paar, bestehend aus einer Steuerverbindung und 0 oder mehr L2TP-Sitzungen.

L2TP wird auf vier Ebenen implementiert:

• Quelle: Der lokale Router, der als LAC fungiert.

• Ziel: Der Remote-Router, der als LNS fungiert.

• Tunnel: Ein direkter Pfad zwischen dem LAC und dem LNS.

• Session: Eine PPP-Verbindung in einem Tunnel.

Wenn der Router Ziele, Tunnel und Sitzungen eingerichtet hat, können Sie den L2TP-Datenverkehr steuern. Eine Änderung an einem Ziel wirkt sich auf alle Tunnel und Sitzungen zu diesem Ziel aus. Eine Änderung an einem Tunnel wirkt sich auf alle Sitzungen in diesem Tunnel aus. Wenn Sie beispielsweise ein Ziel schließen, werden alle Tunnel und Sitzungen zu diesem Ziel geschlossen.

• Ablauf der Ereignisse in der LAK
• Ereignisabfolge auf dem LNS

L2TP-Peers unterhalten eine Warteschlange von Steuernachrichten, die an das Peer-Gerät gesendet werden müssen. Nachdem der lokale Peer (LAC oder LNS) eine Nachricht gesendet hat, wartet er auf eine Antwort vom Remote-Peer. Wenn keine Antwort empfangen wird, überträgt der lokale Peer die Nachricht erneut. Dieses Verhalten gibt dem Remote-Peer mehr Zeit, um auf die Nachricht zu antworten.

Sie können das Neuübertragungsverhalten auf zwei Arten steuern:

• Anzahl der erneuten Übertragungen: Sie können konfigurieren, wie oft eine nicht bestätigte Nachricht vom lokalen Peer erneut übertragen wird. Eine Erhöhung der Anzahl bietet mehr Möglichkeiten für den Remote-Peer zu reagieren, erhöht jedoch auch den Umfang des Kontrolldatenverkehrs. Fügen Sie für eingerichtete Tunnel die retransmission-count-established Anweisung auf Hierarchieebene [edit services l2tp tunnel] ein. Fügen Sie für Tunnel, die noch nicht eingerichtet sind, die retransmission-count-not-established Anweisung ein.

• Erneutes Übertragungsintervall: Sie können konfigurieren, wie lange der lokale Peer auf die erste Antwort auf eine Steuernachricht wartet. Wenn innerhalb des ersten Timeoutintervalls keine Antwort empfangen wird, verdoppelt der Timer für die erneute Übertragung das Intervall zwischen jeder nachfolgenden erneuten Übertragung bis zu einem Maximum von 16 Sekunden. Durch die Verlängerung des Intervalls hat der Remote-Peer mehr Zeit zum Reagieren, verbraucht aber auch mehr Ressourcen für einen möglicherweise nicht verfügbaren Peer. Fügen Sie die minimum-retransmission-interval Anweisung auf Hierarchieebene [edit services l2tp tunnel] ein.

Der lokale Peer setzt die erneute Übertragung der Steuernachricht fort, bis einer der folgenden Fälle eintritt:

• Eine Antwort geht innerhalb der aktuellen Wartefrist ein.

• Die maximale Anzahl für die erneute Übertragung ist erreicht.

Wenn die maximale Anzahl erreicht ist und keine Antwort eingegangen ist, werden der Tunnel und alle seine Sitzungen gelöscht.

Hinweis:

Das Erreichen des maximalen Intervalls von 16 Sekunden stoppt die erneuten Übertragungen nicht. Der lokale Peer wartet nach jeder weiteren erneuten Übertragung weiterhin 16 Sekunden.

Die folgenden Beispiele beschreiben das erneute Übertragungsverhalten unter verschiedenen Umständen:

• Beispiel 1: Die Anzahl der erneuten Übertragungen beträgt drei, und das minimale Intervall für die erneute Übertragung beträgt 1 Sekunde.

  1. Der lokale Peer sendet eine Steuernachricht.

  2. Der lokale Peer wartet 1 Sekunde, erhält aber keine Antwort.

  3. Der lokale Peer überträgt die Steuernachricht erneut. Dies ist die erste Neuübertragung.

  4. Der lokale Peer wartet 2 Sekunden, erhält aber eine Antwort, bevor das Intervall abläuft.

  5. Die erneute Übertragung wird beendet, da innerhalb des Intervalls eine Antwort empfangen wird.

• Beispiel 2: Die Anzahl der erneuten Übertragung beträgt zwei, und das minimale Intervall für die erneute Übertragung beträgt 8 Sekunden.

  1. Der lokale Peer sendet eine Steuernachricht.

  2. Der lokale Peer wartet 8 Sekunden, erhält aber keine Antwort.

  3. Der lokale Peer überträgt die Steuernachricht erneut. Dies ist die erste Neuübertragung.

  4. Der lokale Peer wartet 16 Sekunden, erhält aber keine Antwort.

  5. Der lokale Peer überträgt die Steuernachricht erneut. Dies ist die zweite Neuübertragung.

  6. Der lokale Peer wartet erneut 16 Sekunden, da das Intervall nicht über 16 hinaus verlängert werden kann, erhält aber keine Antwort.

  7. Die erneute Übertragung wird beendet, da die maximale Anzahl von zwei erneuten Übertragungen erreicht wurde.

  8. Der Tunnel und alle seine Sitzungen werden geräumt.

• Zweck
• Aktion