Einrichtung und Entfernung von L2TP-Tunneln

Download-Optionen

PDF (181.7 KB)
Mit Adobe Reader auf verschiedenen Geräten anzeigen
ePub (134.4 KB)
In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
Mobi (Kindle) (177.6 KB)
Auf einem Kindle-Gerät oder einer Kindle-App auf mehreren Geräten anzeigen

Aktualisiert:29. Januar 2008

Dokument-ID:23980

Inklusive Sprache

In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.

Informationen zu dieser Übersetzung

Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.

Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Konventionen

PPP

L2TP

PPP und L2TP Flow Summary

Die PPP/L2TP-Verbindungssequenz

Debugging aus LAC, das PPP- und L2TP-Anrufaufbau zeigt

Debugging aus LNS, das PPP- und L2TP-Anrufaufbau zeigt

Die PPP/L2TP-Trennungssequenz

Debugging aus LAC, das PPP- und L2TP-Trennung anzeigt

Debugging aus LNS, das die PPP- und L2TP-Trennung anzeigt

Zugehörige Informationen

Einführung

In diesem Dokument wird die Einrichtung und Außerbetriebnahme des Layer-2-Tunneling-Protokolls (L2TP) erläutert. Das Dokument enthält auch eine Zusammenfassung von PPP und L2TP.

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den Cisco IOS® Software-Versionen 12.0(1)T und höher.

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps zu Konventionen von Cisco).

PPP

PPP ist ein symmetrisches Peer-to-Peer-Protokoll, das L2- und L3-Datenverkehr über Punkt-zu-Punkt-Verbindungen transportiert. Es gibt drei Hauptkomponenten:

Kapselung
Link Control Protocol (LCP)
Network Control Protocol (NCP)

Datagramme sind in PPP gekapselt. Das LCP ermöglicht die Aushandlung von Konfigurationsoptionen, um das Herstellen von Verbindungen zu ermöglichen. NCP werden für jedes L3-Protokoll ausgehandelt, das auf der Verbindung ausgeführt wird.

Während einer PPP-Sitzung wird die Verbindung in vier verschiedenen Phasen unterteilt:

Link-Einrichtung - Im Rahmen der Verbindungsphase verwendet PPP eine LCP-Funktion, die abgeschlossen und für offen erklärt werden muss, bevor die Verbindung gegebenenfalls in die Authentifizierungsphase eintritt, und handelt die Öffnung der Netzwerkschicht aus. LCP wird auch zum Terminieren der PPP-Verbindung verwendet.
Authentication (Authentifizierung): Die Authentifizierungsphase ist implementierungsspezifisch und nicht zwingend erforderlich, um von LCP auf NCP umzustellen. Wenn der Remote-Peer während der LCP-Phase ausgehandelt und vereinbart wurde, muss er sich identifizieren und die vereinbarte Authentifizierungsmethode durchlaufen, bevor PPP zur Netzwerkebene wechselt.
Network Layer - Bei der NCP-Aushandlung wird sichergestellt, dass beide Peers die Eigenschaften des L3-Protokolls einverstanden sind. Bei IP wird das Steuerungsprotokoll als IP Control Protocol (IPCP) bezeichnet. Neben den Verhandlungen zwischen Peers gibt es auch ein Element der Zuweisung. Dies ist bei Remotezugriffsclients vom Typ Microsoft Windows üblich, die über keine zugewiesene IP-Adresse verfügen und bei der Verbindung auf den Dienstanbieter angewiesen sind, die IP-Adresse zuzuweisen.
Verbindungsbeendigung - Die Verbindungsperiode kann während des Lebenszyklus des Anrufs jederzeit eingegeben werden. LCP wird zur Übermittlung der Terminierungsanfrage verwendet.

L2TP

L2TP erweitert den Point-to-Point-Charakter von PPP. L2TP bietet eine Kapselungsmethode für die Übertragung von getunnelten PPP-Frames, mit der die PPP-Endpunkte über ein paketvermitteltes Netzwerk getunnelt werden können. L2TP wird in der Regel in Szenarien mit Remote-Zugriff bereitgestellt, die das Internet verwenden, um Intranet-Dienste anzubieten. Das Konzept ist ein Virtual Private Network (VPN).

Die beiden primären physischen Elemente von L2TP sind der L2TP Access Concentrator (LAC) und der L2TP Network Server (LNS):

LAC - Die LAC ist ein Peer zum LNS, der als eine Seite des Tunnelendpunkts fungiert. Die LAC terminiert die Remote-PPP-Verbindung und befindet sich zwischen der Remote-Verbindung und dem LNS. Pakete werden über die PPP-Verbindung an die Remote-Verbindung und von dieser an die PPP-Verbindung weitergeleitet. Pakete an das und vom LNS werden über den L2TP-Tunnel weitergeleitet.
LNS - Das LNS ist ein Peer der LAC, der als eine Seite des Tunnelendpunkts fungiert. Das LNS ist der Terminationspunkt für die PPP-Sitzungen des LAC. Diese Funktion dient zum Aggregieren mehrerer PPP-Sitzungen mit LAC-Tunneling und zum Eindringen in das private Netzwerk.

L2TP verwendet zwei verschiedene Meldungstypen:

Kontrollnachrichten - L2TP übergibt Kontroll- und Datennachrichten über separate Steuerungs- und Datenkanäle. Der In-Band-Steuerungskanal leitet sequenzielle Nachrichten für das Management von Steuerungsverbindungen, Anrufverwaltung, Fehlerberichte und Sitzungssteuerung weiter. Die Initiierung der Steuerungsverbindung ist nicht spezifisch für die LAC oder das LNS, sondern vielmehr für den Tunneloriginator und -empfänger, der für die Einrichtung der Steuerungsverbindung relevant ist. Zwischen den Tunnelendpunkten wird eine Authentifizierungsmethode für die gemeinsam genutzte geheime Herausforderung verwendet.
Datenmeldungen - Datenmeldungen werden verwendet, um die PPP-Frames zu kapseln, die in den L2TP-Tunnel gesendet werden.

L2TP verwendet den registrierten UDP-Port 1701 (User Datagram Protocol), und das gesamte L2TP-Paket wird in das UDP-Datagramm eingekapselt. Im normalen UDP-Betrieb wählt der Tunnelinitiator einen verfügbaren UDP-Port aus und sendet die Portnummer 1701 an das UDP-Ziel. In der Antwort entspricht die Ziel-Portnummer der Quell-Portnummer, die im eingehenden UDP-Header verwendet wird. Der Quellport wird auf Basis eines freien Ports festgelegt, der gefunden wird. Nachdem die Quell- und Zielports eingerichtet wurden, müssen die Ports für die Dauer des Tunnels gleich bleiben. In der Cisco IOS Software sind die Quell- und Ziel-Portnummern immer auf die UDP-Portnummer 1701 eingestellt.

Hinweis: Das Layer 2 Forwarding (L2F)-Protokoll und L2TP verwenden dieselbe UDP-Portnummer. Mit dem Feld Version im Header können Sie zwischen den beiden Protokollen unterscheiden. Ein Wert von 1 steht für L2F, ein Wert von 2 für L2TP.

PPP und L2TP Flow Summary

Bevor PPP-Frames durch den Tunnel weitergeleitet werden können, müssen Steuerungsverbindungen und -sitzungen eingerichtet werden.

Nach der erfolgreichen Einrichtung des Steuerungskanals werden Sitzungen für jede PPP-Verbindung erstellt. Die Sitzungseinrichtung ist in Bezug auf die LAC und das LNS richtungsgerichtet. Bei eingehenden Anrufen fordert die LAC das LNS auf, die Sitzung zu akzeptieren. Bei ausgehenden Anrufen bittet das LNS die LAC, die Sitzung zu akzeptieren.

Im Abschnitt "PPP/L2TP Connection Sequence" dieses Dokuments wird die Einrichtung von PPP- und L2TP-Anrufen beschrieben, wenn ein Benutzer mit Remotezugriff einen Anruf in der LAC tätigt. In diesem Beispiel wird der Dienst zur Rufnummernerkennung (DNIS) verwendet, um den L2TP-Tunnel zu initiieren. Sie können jedoch auch den Domänennamen für diesen Zweck verwenden. Die Sequenz zeigt den Start der PPP-Sitzung von einem SOHO 2500-Router aus, die LCP-Aushandlung zwischen dem Remote-Zugriffsbenutzer und der LAC sowie die teilweise Authentifizierung. Die LAC setzt dann den L2TP-Tunnel und die Sitzung innerhalb des Tunnels ein. Für jede PPP-Verbindung zwischen LAC und LNS wird eine Sitzung eingerichtet. L2TP verwendet den Peer-Tunnel und die Sitzungs-IDs in allen ausgehenden Nachrichten, um die PPP-Verbindungen zu multiplizieren und zu demultiplizieren. Diese Identifikatoren werden während der jeweiligen Kontroll-, Verbindungs- und Sitzungs-Einrichtungsphase zugewiesen und ausgetauscht. Tunnel- und Sitzungs-IDs haben nur lokale Bedeutung. Die Tunnel-Endpunkte verfügen über verschiedene IDs für denselben Tunnel und dieselbe Sitzung.

Hinweis: Der Wert 0 hat eine einzigartige Bedeutung und wird nur verwendet, wenn Tunnel- und Sitzungsbezeichner noch nicht zugewiesen werden müssen.

Nach der Einrichtung des Tunnels wird der PPP-Authentifizierungsprozess zwischen dem Remote-Benutzer und dem LNS abgeschlossen. Die LAC empfängt weiterhin PPP-Frames. Die Link-Framing- und CRC-Prüfung (zyklische Redundanzprüfung) werden entfernt, in LT2P eingekapselt und in den Tunnel an das LNS weitergeleitet. Dort wird das L2TP-Paket empfangen und behandelt, als ob es auf einer lokalen PPP-Schnittstelle terminiert würde. Die Aushandlung von PPP-NCP erfolgt, und anschließend wird IPCP als offen erklärt. Die Verbindung ist abgeschlossen.

Die PPP/L2TP-Verbindungssequenz

Dies ist die Verbindungssequenz der Ereignisse:

Der Remote-Benutzer initiiert eine PPP-Verbindung. Die LAC akzeptiert die Verbindung. Es wird eine PPP-Verbindung hergestellt.
LCP wird zwischen dem Remote-Benutzer und der LAC ausgehandelt. Die LAC stellt eine Challenge Handshake Authentication Protocol (CHAP)-Herausforderung aus, um eine teilweise Authentifizierung des Remote-Benutzers durchzuführen. Die Antwort wird während der Sitzungserstellung an das LNS gesendet. Die Antwort wird als AVP-33-Proxy-Authentifizierungsantwort in der ICCN (Incoming-Call-Connected) gesendet.
Mit dem DNIS wird bestimmt, ob es sich bei dem Benutzer um einen Virtual Private Dial-up Network (VPDN)-Client handelt.
Da für die gewählte Nummer (614629) kein Tunnel vorhanden ist, ist die Erstellung eines neuen Tunnels erforderlich. RADIUS wird abgefragt, und die Tunnelinformationen werden in die LAC heruntergeladen.
Die Steuerungsverbindung wird gestartet. Der Tunnel befindet sich im IDLE-Status:
- Der Tunnelinitiator (in diesem Fall die LAC) sendet eine Start-Control-Connection-Request (SCCRQ) an das LNS. Das SCCRQ enthält eine AVP 11-Herausforderung, die anzeigt, dass die LAC den Tunnel mithilfe einer CHAP-artigen Authentifizierung authentifizieren möchte. Das gleiche Geheimnis ist beiden Tunnelendpunkten bekannt. Der Tunnel befindet sich jetzt im Status WAIT-CTL-REPLY.
- Das LNS kann den Tunnel aufrufen, sodass das LNS mit einer Start-Control-Connection-Reply (SCCRP) antwortet. Das SCCRP enthält eine AVP 11-Herausforderung und eine AVP 13-Herausforderung-Antwort als Antwort auf das SCCRQ. Der Tunnel befindet sich jetzt im Status WAIT-CTL-REPLY.
- Die LAC reagiert mit einer SCCCN-Nachricht (Start-Control-Connection-Connected). Das SCCCN enthält einen AVP 13 als Antwort auf das SCCRP. Der Tunnel befindet sich jetzt in einem etablierten Zustand.
- Das LNS sendet eine ZLB-Nachricht (Zero Length Body) an die LAC. Die ZLB-Nachricht ist eine sequenzielle Bestätigung. Der Tunnel befindet sich jetzt in einem etablierten Zustand.
Die Tunnelauthentifizierung ist nun abgeschlossen, und der Tunnel ist eingerichtet. Die Sitzung befindet sich jetzt im IDLE-Status.
Nachdem der Tunnel vorhanden ist, wird ein Dreiwege-Austausch zur Sitzungseinrichtung im Tunnel durchgeführt:
- Die LAC sendet eine ICRQ (Incoming Call Request) mit Parameterinformationen für die Sitzung. Die Sitzung befindet sich jetzt im Zustand "Wait Reply" (Antworten warten).
- Das LNS sendet eine eingehende Anrufantwort (Incoming Call Reply, ICRP), die die Sitzungs-ID enthält. Die Sitzung befindet sich jetzt im Zustand Wait Connect.
- Die LAC sendet eine ICCN und stellt dem LNS zusätzliche Informationen für den angenommenen Anruf zur Verfügung. Diese Informationen enthalten die LCP-Informationen aus der Aushandlung, die die LAC und der Remote-Benutzer durchgeführt haben. Die Sitzung befindet sich jetzt in einem etablierten Zustand.
- Das LNS sendet eine ZLB-Nachricht, eine sequenzierte Bestätigung, an die LAC. Die Sitzung befindet sich jetzt in einem etablierten Zustand.
Nach Einrichtung der Sitzung wird auf dem LNS eine virtuelle Zugriffsschnittstelle erstellt. Die im ICCN bereitgestellten LCP-Konfigurationsinformationen werden in den PPP-Stack der virtuellen Zugriffsschnittstelle gezwungen. Diese Informationen enthalten Informationen zur teilweisen Authentifizierung.
Das LNS erzeugt eine Authentifizierungsproblem. Die Proxy-Authentifizierungsantwort AVP 33, die im ICCN bereitgestellt wurde, wird erneut abgespielt.
Die normale Authentifizierung, Autorisierung und Abrechnung (AAA) oder PPP-Authentifizierung und -Autorisierung erfolgt.
Eine RADIUS-Zugriffsanfrage wird für eine benutzerspezifische Authentifizierung und Autorisierung gesendet.
Es wird eine RADIUS Access-Accept-Nachricht empfangen.

Hinweis: RADIUS wurde so konfiguriert, dass die IP-Adresse, die der Remote-Benutzer in der eingehenden IPCP-Konfigurationsanforderung angegeben hat, zugelassen wird.
Eine CHAP-Erfolgsmeldung wird an den Remote-Benutzer gesendet.
Die PPP-IPCP-Aushandlung ist abgeschlossen und wird für OPEN erklärt. Eine Hostroute wird auf der Remote-Schnittstelle installiert. Der Remote-Benutzer ist nun verbunden, und der Datenverkehrsfluss kann beginnen.

Anrufablauf der PPP- und L2TP-Verbindung