Firewall-Filter-basiertes L2TP-Tunneling in IPv4-Netzwerken – Ü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 z. B. PPP, für die Übertragung über ein Netzwerk. Ein L2TP-Zugriffskonzentrator (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. L2TPv3 definiert das Basissteuerungsprotokoll und die Kapselung für das Tunneling mehrerer Layer-2-Verbindungen zwischen zwei IPv6-Knoten. Die wesentlichen Unterschiede zwischen L2TPv2 und L2TPv3 umfassen Folgendes:
Trennung aller PPP-bezogenen AVPs und Referenzen, die die Aufnahme eines Teils des L2TP-Datenheaders ermöglicht, der speziell auf die Bedürfnisse von PPP zugeschnitten war.
Übergang von einer 16-Bit-Sitzungs-ID und Tunnel-ID zu einer 32-Bit-Sitzungs-ID bzw. Steuerungsverbindungs-ID.
Erweiterung des Tunnelauthentifizierungsmechanismus, um die gesamte Steuernachricht und nicht nur einen Teil bestimmter Nachrichten abzudecken.
L2TPv3 wird nur für IPv6 unterstützt.
Für Firewallfilter wird nur die L2TPv3-Kapselung/-Entkapselung auf Datenebene unterstützt.
L2TP besteht aus zwei Arten von Nachrichten, Steuernachrichten und Datennachrichten (manchmal auch als Steuerpakete bzw. Datenpakete bezeichnet). Steuernachrichten werden beim Herstellen, Verwalten und Löschen von Steuerverbindungen und -sitzungen verwendet. Diese Nachrichten nutzen einen zuverlässigen Steuerkanal innerhalb von L2TP, um die Zustellung zu garantieren. Datennachrichten werden verwendet, um den L2-Datenverkehr zu kapseln, der über die L2TP-Sitzung übertragen wird.
Sie können ein IPv4-Netzwerk für den Transport von IPv4-, IPv6- oder MPLS-Transitdatenverkehr konfigurieren, indem Sie GRE-Tunneling-Protokollmechanismen verwenden, die von zwei standardmäßigen Firewallfilteraktionen initiiert werden. Dieses Feature wird auch in logischen Systemen unterstützt. Wenn Sie L2TP-Tunneling mit Firewall-Filtern konfigurieren, müssen Sie keine Tunnelschnittstellen auf Tunnel Services Physical Interface Cards (PICs) oder auf MPC3E Modular Port Concentrators (MPCs) erstellen. Stattdessen stellen Paketweiterleitungs-Engines Tunnelservices für logische Ethernet-Schnittstellen oder aggregierte Ethernet-Schnittstellen bereit, die auf modularen Schnittstellenkarten (MICs) oder MPCs in universellen 5G-Routing-Plattformen der MX-Serie gehostet werden.
Zwei Router der MX-Serie, die als Provider-Edge-Router (PE) installiert sind, bieten Konnektivität zu Kunden-Edge-Routern (CE) in zwei getrennten Netzwerken. MIC- oder MPC-Schnittstellen auf den PE-Routern führen die L2TP-IPv4-Kapselung und -Entkapselung von Nutzlasten durch. Nach der Entkapselung werden Pakete an die lokale Schnittstelle einer Routing-Tabelle, die in der Aktion angegeben ist, oder an die Standard-Routing-Tabelle, basierend auf dem Protokollfeld des L2TP-Headers, gesendet. Optional kann jedoch ein L2TP-Paket mit einem Token, das einem Ausgabeschnittstellenindex entspricht, über die Fabric gesendet werden, um eine Layer-2-Cross-Verbindung durchzuführen. Sie können den Spezifizierer für die Ausgabeschnittstelle angeben, der für das zu sendende L2TP-Paket verwendet werden soll, indem Sie die decapsulate l2tp output-interface interface-name cookie l2tpv3-cookie Anweisung auf Hierarchieebene [edit firewall family family-name filter filter-name term term-name then] einfügen.
Während der Entkapselung muss der innere Header Ethernet für L2TP-Tunnel sein. Die Weiterleitungsklasse wird standardmäßig vor der Firewall angewendet und nicht für das entkapselte Paket beibehalten (mithilfe der forwarding-class class-name Anweisung auf Hierarchieebene [edit firewall family family-name] , bei der es sich um eine nicht beendende Filteraktion handelt). Sie können jedoch die Weiterleitungsklasse angeben, für die das Paket klassifiziert werden muss, indem Sie die Filteraktion für ein entkapseltes Paket mithilfe der decapsulate l2tp forwarding-class class-name Anweisung auf Hierarchieebene [edit firewall family family-name filter filter-name term term-name then] einschließen.
Die folgenden Felddefinitionen sind für die Verwendung in allen L2TP-Sitzungs-Header-Kapselungen definiert.
Das Feld "Sitzungs-ID" ist ein 32-Bit-Feld, das einen Bezeichner ungleich Null für eine Sitzung enthält. L2TP-Sitzungen werden nach Bezeichnern benannt, die nur lokale Bedeutung haben. Dieselbe logische Sitzung erhält für die Dauer der Sitzung von jedem Ende der Steuerverbindung unterschiedliche Sitzungs-IDs. Wenn die L2TP-Steuerungsverbindung für den Sitzungsaufbau verwendet wird, werden Sitzungs-IDs ausgewählt und während der Erstellung einer Sitzung als lokale Sitzungs-ID-AVPs ausgetauscht. Allein die Sitzungs-ID liefert den erforderlichen Kontext für die gesamte weitere Paketverarbeitung, einschließlich des Vorhandenseins, der Größe und des Werts des Cookies, des Typs der L2-spezifischen Subschicht und der Art der Nutzlast, die getunnelt wird.
Das optionale Feld Cookie enthält einen Wert variabler Länge (maximal 64 Bit), mit dem die Verknüpfung einer empfangenen Datennachricht mit der durch die Sitzungs-ID identifizierten Sitzung überprüft wird. Das Feld Cookie muss auf den konfigurierten oder signalisierten Zufallswert für diese Sitzung gesetzt werden. Das Cookie bietet eine zusätzliche Garantiestufe, dass eine Datennachricht von der Sitzungs-ID an die richtige Sitzung weitergeleitet wurde. Ein gut ausgewähltes Cookie kann die versehentliche Fehlleitung von zufälligen Paketen mit kürzlich wiederverwendeten Sitzungs-IDs oder von Sitzungs-IDs, die einer Paketbeschädigung unterliegen, verhindern. Das Cookie kann auch Schutz vor bestimmten böswilligen Paketeinfügungsangriffen bieten. Wenn die L2TP-Steuerungsverbindung für den Sitzungsaufbau verwendet wird, werden zufällige Cookie-Werte ausgewählt und während der Sitzungserstellung als zugewiesene Cookie-AVPs ausgetauscht.
Eine Sitzung ist eine logische Verbindung, die zwischen dem LAC und dem LNS hergestellt wird, wenn eine End-to-End-PPP-Verbindung zwischen einem Remote-System und dem LNS hergestellt wird. Es besteht eine Eins-zu-Eins-Beziehung zwischen etablierten L2TP-Sitzungen und den zugehörigen PPP-Verbindungen. Ein Tunnel ist eine Aggregation von einer oder mehreren L2TP-Sitzungen.
Ab Junos OS Version 15.1 erfolgt die Entkapselung von IP-Paketen, die über einen L2TP-Tunnel mit den angegebenen Standardbedingungen für Firewall-Filter und Aktionen gesendet werden, mithilfe eines Layer-3-Lookups. In Junos OS Version 14.2 und früher wird die Entkapselung des Datenverkehrs über einen L2TP-Tunnel mit konfigurierten Firewall-Filteraktionen mithilfe von Layer-2-Schnittstelleneigenschaften durchgeführt.
Unidirektionales Tunneling
Filterbasierte L2TP-Tunnel in IPv4-Netzwerken sind unidirektional. Sie transportieren nur Transitpakete und benötigen keine Tunnelschnittstellen. Obwohl Sie Firewall-Filter auf Loopback-Adressen anwenden können, werden GRE-Kapselungs- und -Entkapselungs-Firewall-Filteraktionen auf Router-Loopback-Schnittstellen nicht unterstützt. Filterinitiierte Kapselungs- und Entkapselungsvorgänge von L2TP-Paketen werden auf Paketweiterleitungs-Engines für logische Ethernet-Schnittstellen und aggregierte Ethernet-Schnittstellen ausgeführt. Dieses Design ermöglicht eine effizientere Nutzung der Bandbreite der Packet Forwarding Engine im Vergleich zum GRE-Tunneling mit Tunnelschnittstellen. Routing-Protokollsitzungen können nicht zusätzlich zu den Firewall-basierten Tunneln konfiguriert werden.
Tunnel-Sicherheit
Filterbasiertes Tunneling über IPv4-Netzwerke ist nicht verschlüsselt. Wenn Sie sicheres Tunneling benötigen, müssen Sie IPsec-Verschlüsselung (IP Security) verwenden, die von MIC- oder MPC-Schnittstellen nicht unterstützt wird. Multiservices DPC (MS-DPC)-Schnittstellen auf MX240-, MX480- und MX960-Routern unterstützen jedoch IPsec-Tools zur Konfiguration manueller oder dynamischer Sicherheitszuordnungen (SAs) für die Verschlüsselung des Datenverkehrs sowie des Datenverkehrs, der für die Routing-Engine bestimmt ist oder von ihr stammt.
Weiterleitungsleistung
Filterbasiertes Tunneling über IPv4-Netzwerke ermöglicht eine effizientere Nutzung der Bandbreite der Packet Forwarding Engine im Vergleich zum L2TP-Tunneling mit Tunnelschnittstellen. Kapselung, Entkapselung und Routensuche sind Paket-Header-Verarbeitungsaktivitäten, die für Firewall-Filter-basiertes Tunneling auf der Junos Trio-Chipsatz-basierten Packet Forwarding Engine ausgeführt werden. Folglich muss der Encapsulator niemals Nutzlastpakete an eine separate Tunnelschnittstelle senden (die sich auf einem PIC in einem anderen Steckplatz befinden kann als die Schnittstelle, die Nutzlastpakete empfängt).
Weiterleitungsskalierbarkeit
Für die Weiterleitung von L2TP-Datenverkehr mit Tunnelschnittstellen muss Datenverkehr an einen Slot gesendet werden, der die Tunnelschnittstellen hostet. Wenn Sie Tunnelschnittstellen zum Weiterleiten von GRE-Datenverkehr verwenden, begrenzt diese Anforderung die Menge an Datenverkehr, die pro GRE-Tunnelzieladresse weitergeleitet werden kann. Angenommen, Sie möchten 100 Gbit/s L2TP-Datenverkehr von Router A zu Router B senden und haben nur 10-Gbit/s-Schnittstellen. Um sicherzustellen, dass Ihre Konfiguration nicht den gesamten Datenverkehr auf derselben Karte kapselt, der an dieselbe 10-Gbit/s-Schnittstelle geht, müssen Sie den Datenverkehr auf mehrere Verkapselungspunkte verteilen.
Tabellarischer Änderungsverlauf
Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie Feature Explorer, um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.