Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

IPsec-VPN – Übersicht

Ein VPN ist ein privates Netzwerk, das ein öffentliches Netzwerk verwendet, um zwei oder mehr Remotestandorte zu verbinden. Statt dedizierte Verbindungen zwischen Netzwerken zu verwenden, verwenden VPNs virtuelle Verbindungen, die über öffentliche Netzwerke geroutet (getunnelt) werden. IPsec VPN ist ein Protokoll, das aus einem Satz von Standards besteht, die zum Herstellen einer VPN-Verbindung verwendet werden.

Ein VPN bietet eine Möglichkeit, mit der Remotecomputer sicher über ein öffentliches WAN wie das Internet kommunizieren.

Eine VPN-Verbindung kann zwei LANs (Site-to-Site VPN) oder einen Remote-Einwahlbenutzer mit einem LAN verbinden. Der Datenverkehr, der zwischen diesen beiden Punkten fließt, führt über gemeinsame Ressourcen wie Router, Switches und andere Netzwerkgeräte, aus denen das öffentliche WAN besteht. Um die VPN-Kommunikation beim Passieren des WAN zu sichern, erstellen die beiden Teilnehmer einen IP-Sicherheits-Tunnel (IPsec).

Der Begriff Tunnel bezeichnet nicht den Tunnelmodus (siehe Paketverarbeitung im Tunnelmodus). Stattdessen bezieht es sich auf die IPsec-Verbindung.

IPSec-VPN-Topologien auf Geräten der SRX-Serie

Im Folgenden finden Sie einige der IPSec-VPN-Topologien, die das Junos-Betriebssystem (OS) unterstützt:

  • Site-to-Site-VPNs: Verbindet zwei Standorte in einer Organisation miteinander und ermöglicht eine sichere Kommunikation zwischen den Standorten.

  • Hub-and-Spoke-VPNs: Verbindet Zweigniederlassungen mit dem Unternehmensbüro in einem Unternehmensnetzwerk. Sie können diese Topologie auch verwenden, um Spokes miteinander zu verbinden, indem Sie Datenverkehr durch den Hub senden.

  • VPNs für Remote-Zugriff: Ermöglicht Benutzern, die zu Hause oder unterwegs arbeiten, eine Verbindung zum Unternehmensbüro und seinen Ressourcen herzustellen. Diese Topologie wird manchmal als End-to-Site-Tunnel bezeichnet.

Vergleich von richtlinien- und routenbasierten VPNs

Es ist wichtig, die Unterschiede zwischen richtlinien- und routenbasierten VPNs zu verstehen und zu verstehen, warum eine dem anderen vorzuziehen ist.

Tabelle 1 listet die Unterschiede zwischen routenbasierten VPNs und richtlinienbasierten VPNs auf.

Tabelle 1: Unterschiede zwischen routenbasierten VPNs und richtlinienbasierten VPNs

Routenbasierte VPNs

Richtlinienbasierte VPNs

Bei routenbasierten VPNs verweist eine Richtlinie nicht speziell auf einen VPN-Tunnel.

Bei richtlinienbasierten VPN-Tunneln wird ein Tunnel als Objekt behandelt, das zusammen mit Quelle, Ziel, Anwendung und Aktion eine Tunnelrichtlinie darstellt, die VPN-Datenverkehr zulässt.

Die Richtlinie verweist auf eine Zieladresse.

In einer richtlinienbasierten VPN-Konfiguration verweist eine Tunnelrichtlinie gezielt auf einen VPN-Tunnel nach Namen.

Die Anzahl der von Ihnen erstellten routenbasierten VPN-Tunnel wird durch die Anzahl der Routeneinträge oder die Anzahl der st0-Schnittstellen, die das Gerät unterstützt, begrenzt, unabhängig davon, welche Anzahl niedriger ist.

Die Anzahl der richtlinienbasierten VPN-Tunnel, die Sie erstellen können, wird durch die Anzahl der Vom Gerät unterstützten Richtlinien begrenzt.

Routenbasierte VPN-Tunnelkonfiguration ist eine gute Wahl, wenn Sie Tunnelressourcen einsparen und gleichzeitig granulare Einschränkungen des VPN-Datenverkehrs festlegen möchten.

Mit einem richtlinienbasierten VPN können Sie zwar zahlreiche Tunnelrichtlinien erstellen, die auf denselben VPN-Tunnel verweisen, aber jedes Tunnelrichtlinienpaar erstellt eine individuelle IPsec-Sicherheitszuordnung (SA) mit dem Remote-Peer. Jede SA zählt als einzelner VPN-Tunnel.

Bei einem routenbasierten Ansatz für VPNs ist die Regulierung des Datenverkehrs nicht an die Art der Bereitstellung gekoppelt. Sie können Dutzende von Richtlinien konfigurieren, um den Datenverkehr zu regulieren, der über einen einzelnen VPN-Tunnel zwischen zwei Standorten fließt, und nur eine IPsec-SA ist im Einsatz. Außerdem können Sie mithilfe einer routenbasierten VPN-Konfiguration Richtlinien erstellen, die auf ein Ziel verweisen, das über einen VPN-Tunnel erreicht wurde, in dem die Aktion verweigert wird.

In einer richtlinienbasierten VPN-Konfiguration muss die Aktion zugelassen werden und muss einen Tunnel enthalten.

Routenbasierte VPNs unterstützen den Austausch dynamischer Routing-Informationen über VPN-Tunnel. Sie können eine Instanz eines dynamischen Routing-Protokolls wie OSPF auf einer ST0-Schnittstelle aktivieren, die an einen VPN-Tunnel gebunden ist.

Der Austausch dynamischer Routing-Informationen wird in richtlinienbasierten VPNs nicht unterstützt.

Routenbasierte Konfigurationen werden für Hub-and-Spoke-Topologien verwendet.

Richtlinienbasierte VPNs können für Hub-and-Spoke-Topologien nicht verwendet werden.

Bei routenbasierten VPNs verweist eine Richtlinie nicht speziell auf einen VPN-Tunnel.

Wenn ein Tunnel keine Verbindungen zu großen Netzwerken mit dynamischen Routing-Protokollen verbindet und Sie keine Tunnel konservieren oder verschiedene Richtlinien definieren müssen, um den Datenverkehr durch den Tunnel zu filtern, ist ein richtlinienbasierter Tunnel die beste Wahl.

Routenbasierte VPNs unterstützen keine Einwahl-VPN-Konfigurationen (Remote Access).

Richtlinienbasierte VPN-Tunnel sind für Remotezugriffs-VPN-Konfigurationen (Einwahl) erforderlich.

Routenbasierte VPNs funktionieren möglicherweise nicht richtig mit einigen Drittanbietern.

Richtlinienbasierte VPNs können erforderlich sein, wenn der Drittanbieter für jedes Remote-Subnetz separate SAs benötigt.

Wenn das Sicherheitsgerät eine Route sucht, um die Schnittstelle zu finden, über die es Datenverkehr senden muss, um eine Adresse zu erreichen, findet es eine Route über eine sichere Tunnelschnittstelle (st0), die an einen bestimmten VPN-Tunnel gebunden ist.

Mit einem routenbasierten VPN-Tunnel können Sie einen Tunnel als Mittel zur Bereitstellung von Datenverkehr betrachten und die Richtlinie als Methode betrachten, um die Bereitstellung dieses Datenverkehrs zu ermöglichen oder abzulehnen.

Mit einem richtlinienbasierten VPN-Tunnel können Sie einen Tunnel als Element bei der Erstellung einer Richtlinie betrachten.

Routenbasierte VPNs unterstützen NAT für st0-Schnittstellen.

Richtlinienbasierte VPNs können nicht verwendet werden, wenn für tunnelierten Datenverkehr NAT erforderlich ist.

Proxy-ID wird sowohl für routenbasierte als auch richtlinienbasierte VPNs unterstützt. Routenbasierte Tunnel bieten auch die Verwendung mehrerer Datenverkehrs-Selektoren, die auch als Multi-Proxy-ID bezeichnet werden. Ein Datenverkehrs-Selektor ist eine Vereinbarung zwischen IKE-Peers, um den Datenverkehr durch einen Tunnel zuzulassen, wenn der Datenverkehr einem bestimmten Paar lokaler und remoter IP-Adressenpräfix, Quellportbereich, Zielportbereich und Protokoll entspricht. Sie definieren einen Datenverkehrs-Selektor innerhalb eines bestimmten routenbasierten VPN, was zu mehreren Phase-2-IPsec-SAs führen kann. Nur Datenverkehr, der einem Datenverkehrs-Selektor entspricht, ist über eine SA zulässig. Der Datenverkehrs-Selektor ist üblicherweise erforderlich, wenn Remote-Gateway-Geräte Nicht-Juniper Networks-Geräte sind.

Richtlinienbasierte VPNs werden nur auf SrX5400-, SRX5600- und SRX5800-Geräten unterstützt. Die Plattformunterstützung hängt von der Junos OS-Version in Ihrer Installation ab.

Vergleich von richtlinienbasierten VPNs und routenbasierten VPNs

Tabelle 2 fasst die Unterschiede zwischen richtlinienbasierten VPNs und routenbasierten VPNs zusammen.

Tabelle 2: Vergleich zwischen richtlinienbasierten VPNs und routenbasierten VPNs

Richtlinienbasierte VPNs

Routenbasierte VPNs

In richtlinienbasierten VPNs wird ein Tunnel als Objekt behandelt, das zusammen mit Quelle, Ziel, Anwendung und Aktion eine Tunnelrichtlinie darstellt, die VPN-Datenverkehr zulässt.

In routenbasierten VPNs verweist eine Richtlinie nicht speziell auf einen VPN-Tunnel.

Eine Tunnelrichtlinie verweist speziell auf einen VPN-Tunnel nach Namen.

Eine Route bestimmt, welcher Datenverkehr basierend auf einer Ziel-IP-Adresse durch den Tunnel gesendet wird.

Die Anzahl der richtlinienbasierten VPN-Tunnel, die Sie erstellen können, wird durch die Anzahl der Tunnel begrenzt, die das Gerät unterstützt.

Die Anzahl der routenbasierten VPN-Tunnel, die Sie erstellen, wird durch die Anzahl der ST0-Schnittstellen (für Punkt-zu-Punkt-VPNs) oder die Anzahl der Vom Gerät unterstützten Tunnel begrenzt, unabhängig davon, welche niedriger ist.

Mit einem richtlinienbasierten VPN können Sie zwar zahlreiche Tunnelrichtlinien erstellen, die auf denselben VPN-Tunnel verweisen, aber jedes Tunnelrichtlinienpaar erstellt eine individuelle IPsec-SA mit dem Remote-Peer. Jede SA zählt als einzelner VPN-Tunnel.

Da die Route, nicht die Richtlinie, bestimmt, welcher Datenverkehr durch den Tunnel geleitet wird, können mehrere Richtlinien mit einer einzigen SA oder einem VPN unterstützt werden.

In einem richtlinienbasierten VPN muss die Aktion zugelassen werden und muss einen Tunnel enthalten.

Bei einem routenbasierten VPN ist die Regulierung des Datenverkehrs nicht an die Art und Weise der Bereitstellung gekoppelt.

Der Austausch dynamischer Routing-Informationen wird in richtlinienbasierten VPNs nicht unterstützt.

Routenbasierte VPNs unterstützen den Austausch dynamischer Routing-Informationen über VPN-Tunnel. Sie können eine Instanz eines dynamischen Routing-Protokolls wie OSPF auf einer ST0-Schnittstelle aktivieren, die an einen VPN-Tunnel gebunden ist.

Wenn Sie mehr Granularität benötigen, als eine Route bereitstellen kann, um den an einen Tunnel gesendeten Datenverkehr anzugeben, ist die Verwendung eines richtlinienbasierten VPN mit Sicherheitsrichtlinien die beste Wahl.

Routenbasierte VPNs verwenden Routen, um den an einen Tunnel gesendeten Datenverkehr anzugeben; eine Richtlinie nicht spezifisch auf einen VPN-Tunnel verweist.

Mit einem richtlinienbasierten VPN-Tunnel können Sie einen Tunnel als Element bei der Erstellung einer Richtlinie betrachten.

Wenn das Sicherheitsgerät eine Route sucht, um die Schnittstelle zu finden, über die es Datenverkehr senden muss, um eine Adresse zu erreichen, findet es eine Route durch eine sichere Tunnelschnittstelle (st0).

Mit einem routenbasierten VPN-Tunnel können Sie einen Tunnel als Mittel zur Bereitstellung von Datenverkehr betrachten und die Richtlinie als Methode betrachten, um die Bereitstellung dieses Datenverkehrs zu ermöglichen oder abzulehnen.

Informationen zur IKE- und IPsec-Paketverarbeitung

Ein IPsec-VPN-Tunnel besteht aus der Tunneleinrichtung und der angewandten Sicherheit. Während der Tunneleinrichtung erstellen die Peers Sicherheitszuordnungen (SAs), die die Parameter für die Sicherung des Datenverkehrs untereinander definieren. (Siehe IPsec-Übersicht.) Nach der Erstellung des Tunnels schützt IPsec den Datenverkehr, der zwischen den beiden Tunnelendstellen gesendet wird, indem die von den SAs während der Tunneleinrichtung definierten Sicherheitsparameter angewendet werden. Innerhalb der Junos OS-Implementierung wird IPsec im Tunnelmodus angewendet, der die Protokolle Encapsulating Security Payload (ESP) und Authentication Header (AH) unterstützt.

Dieses Thema umfasst die folgenden Abschnitte:

Paketverarbeitung im Tunnelmodus

IPsec wird in einem von zwei Modi ausgeführt: Transport oder Tunnel. Wenn beide Enden des Tunnels Hosts sind, können Sie beide Modus verwenden. Wenn mindestens ein Endpunkt eines Tunnels ein Sicherheitsgateway ist, z. B. ein Junos OS-Router oder eine Firewall, müssen Sie den Tunnelmodus verwenden. Geräte von Juniper Networks arbeiten immer im Tunnelmodus für IPsec-Tunnel.

Im Tunnelmodus wird das gesamte ursprüngliche IP-Paket – Payload und Header – innerhalb einer anderen IP-Payload eingekapselt, und ein neuer Header wird an sie angehängt, wie in Abbildung 1gezeigt. Das gesamte Originalpaket kann verschlüsselt, authentifiziert oder beides sein. Mit dem Authentication Header (AH)-Protokoll werden auch die AH und neue Header authentifiziert. Mit dem Encapsulating Security Payload (ESP)-Protokoll kann auch der ESP-Header authentifiziert werden.

Abbildung 1: TunnelmodusTunnelmodus

In einem Site-to-Site-VPN sind die Quell- und Zieladressen, die im neuen Header verwendet werden, die IP-Adressen der ausgehenden Schnittstelle. Siehe Abbildung 2.

Abbildung 2: Site-to-Site-VPN im TunnelmodusSite-to-Site-VPN im Tunnelmodus

In einem Einwahl-VPN gibt es am VPN-Einwahl-Client-Ende des Tunnels kein Tunnel-Gateway; der Tunnel erstreckt sich direkt auf den Client selbst (siehe Abbildung 3). In diesem Fall haben sowohl der neue Header als auch der eingekapselte Original-Header bei Paketen, die vom Einwahlclient gesendet werden, dieselbe IP-Adresse: die des Computers des Clients.

Einige VPN-Clients wie der dynamische VPN-Client und NetScreen-Remote verwenden eine virtuelle innere IP-Adresse (auch "Sticky-Adresse" genannt). Netscreen-Remote ermöglicht die Definition der virtuellen IP-Adresse. Der dynamische VPN-Client verwendet die während des XAuth-Konfigurationsaustauschs zugewiesene virtuelle IP-Adresse. In solchen Fällen ist die virtuelle innere IP-Adresse die Quell-IP-Adresse im Ursprünglichen Paket-Header des vom Client ausgehenden Datenverkehrs, und die IP-Adresse, die der ISP dem Einwahlclient dynamisch zugibt, ist die Quell-IP-Adresse im äußeren Header. Ab Junos OS Version 21.4R1 wird dynamisches VPN auf Geräten wie SRX300, SRX320, SRX340, SRX345, SRX380 und SRX550 HM nicht unterstützt.

Abbildung 3: Einwahl-VPN im TunnelmodusEinwahl-VPN im Tunnelmodus

Verteilung von IKE- und IPsec-Sitzungen über SPUs

In den Geräten SRX5400, SRX5600 und SRX5800 bietet IKE die Tunnelverwaltung für IPsec und authentifiziert Endeinheiten. IKE führt einen Diffie-Hellman (DH)-Schlüsselaustausch durch, um einen IPsec-Tunnel zwischen Netzwerkgeräten zu generieren. Die von IKE generierten IPsec-Tunnel werden zur Verschlüsselung, Entschlüsselung und Authentifizierung des Benutzerdatenverkehrs zwischen den Netzwerkgeräten auf der IP-Ebene verwendet.

Das VPN wird erstellt, indem die IKE- und IPsec-Workload auf mehrere Service Processing Units (SPUs) der Plattform verteilt wird. Bei Site-to-Site-Tunneln wird die am wenigsten geladene SPU als Anker-SPU gewählt. Wenn mehrere SPUs die gleiche kleinste Last haben, kann jede von ihnen als Anker-SPU gewählt werden. Die Last entspricht hier der Anzahl der Site-to-Site-Gateways oder manueller VPN-Tunnel, die auf einer SPU verankert sind. Bei dynamischen Tunneln verwenden die neu eingerichteten dynamischen Tunnel einen Round-Robin-Algorithmus, um die SPU auszuwählen.

In IPsec wird die Arbeitslast von demselben Algorithmus verteilt, der die IKE verteilt. Die Phase 2-SA für ein bestimmtes VPN-Tunnelterminierungspunktepaar ist ausschließlich Eigentum einer bestimmten SPU, und alle IPsec-Pakete, die zu dieser Phase 2 SA gehören, werden zur IPsec-Verarbeitung an die Anker-SPU dieser SA weitergeleitet.

Mehrere IPsec-Sitzungen (Phase 2 SA) können über eine oder mehrere IKE-Sitzungen ausgeführt werden. Die SPU, die zum Verankern der IPsec-Sitzung ausgewählt wird, basiert auf der SPU, die die zugrunde liegende IKE-Sitzung verankert. Daher werden alle IPsec-Sitzungen, die über ein einzelnes IKE-Gateway laufen, von derselben SPU verwaltet und sind nicht über mehrere SPUs lastausgleichend.

Tabelle 3 zeigt ein Beispiel für ein Gerät der SRX5000-Reihe mit drei SPUs, auf denen sieben IPsec-Tunnel über drei IKE-Gateways ausgeführt werden.

Tabelle 3: Verteilung von IKE- und IPsec-Sitzungen über SPUs

SPU

IKE-Gateway

IPsec-Tunnel

SPU0

IKE-1

IPsec-1

IPsec-2

IPsec-3

SPU1

IKE-2

IPsec-4

IPsec-5

IPsec-6

SPU2

IKE-3

IPsec-7

Die drei SPUs haben eine gleiche Last von jeweils einem IKE-Gateway. Wenn ein neues IKE-Gateway erstellt wird, können SPU0, SPU1 oder SPU2 ausgewählt werden, um das IKE-Gateway und seine IPsec-Sitzungen zu verankern.

Das Einrichten und Abreißen vorhandener IPsec-Tunnel wirkt sich nicht auf die zugrunde liegende IKE-Sitzung oder vorhandene IPsec-Tunnel aus.

Verwenden Sie den folgenden show Befehl, um die aktuelle Tunnelanzahl pro SPU anzuzeigen: show security ike tunnel-map.

Verwenden Sie die summary Option des Befehls, um die Ankerpunkte jedes Gateways anzuzeigen: show security ike tunnel-map summary.

VPN-Unterstützung für das Einfügen von Services Processing Cards

SRX5400-, SRX5600- und SRX5800-Geräte verfügen über eine chassisbasierte verteilte Prozessorarchitektur. Die Datenstromverarbeitungsleistung wird gemeinsam genutzt und basiert auf der Anzahl der Service Processing Cards (SPCs). Sie können die Verarbeitungsleistung des Geräts skalieren, indem Sie neue SPCs installieren.

In einem SrX5400-, SRX5600- oder SRX5800-Gehäusecluster können Sie neue SPCs auf den Geräten einfügen, ohne den Datenverkehr in den vorhandenen IKE- oder IPsec-VPN-Tunneln zu beeinträchtigen oder zu unterbrechen. Wenn Sie eine neue SPC in jedes Gehäuse des Clusters einfügen, sind die vorhandenen Tunnel nicht betroffen und der Datenverkehr wird unterbrechungsfrei weiterfließen.

Ab Junos OS Version 19.4R1 können Sie auf allen Gehäuse-Clustern der SRX5000-Serie eine neue SRX5K-SPC3 (SPC3) oder SRX5K-SPC-4-15-320 (SPC2)-Karte in ein vorhandenes Gehäuse mit SPC3-Karte einfügen. Sie können die Karten nur in einen höheren Steckplatz als die vorhandene SPC3-Karte im Gehäuse einsetzen. Sie müssen den Knoten nach dem Einfügen der SPC3 neu starten, um die Karte zu aktivieren. Nachdem der Knotenneustart abgeschlossen ist, werden IPsec-Tunnel auf die Karten verteilt.

Vorhandene Tunnel können jedoch die Verarbeitungsleistung der Service Processing Units (SPUs) in den neuen SPCs nicht nutzen. Eine neue SPU kann neu eingerichtete Site-to-Site- und dynamische Tunnel verankern. Neu konfigurierte Tunnel werden jedoch nicht garantiert auf einer neuen SPU verankert.

Site-to-Site-Tunnel sind auf verschiedenen SPUs basierend auf einem Load Balancing-Algorithmus verankert. Der Lastausgleichsalgorithmus ist abhängig von Zahlenfluss-Threads, die von jeder SPU verwendet werden. Tunnel, die zu den gleichen lokalen und Remote-Gateway-IP-Adressen gehören, werden auf derselben SPU auf verschiedenen Fluss-RT-Threads verankert, die von der SPU verwendet werden. Die SPU mit der kleinsten Last wird als Anker-SPU gewählt. Jede SPU behält die Anzahl der Flow RT-Threads bei, die in dieser speziellen SPU gehostet werden. Die Anzahl der auf jeder SPU gehosteten Flow RT-Threads hängt von der Art der SPU ab.

Tunnelladefaktor = Anzahl der auf der SPU verankerten Tunnel / Gesamtzahl der von der SPU verwendeten Flow RT-Threads.

Dynamische Tunnel sind auf verschiedenen SPUs basierend auf einem Round-Robin-Algorithmus verankert. Neu konfigurierte dynamische Tunnel werden nicht garantiert auf der neuen SPC verankert.

Ab Junos OS Version 18.2R2 und 18.4R1 alle vorhandenen IPSec-VPN-Funktionen, die derzeit auf SRX5K-SPC3 (SPC3) unterstützt werden, werden nur auf SRX5400-, SRX5600- und SRX5800-Geräten unterstützt, wenn SRX5K-SPC-4-15-320 (SPC2) und SPC3-Karten im Chassis-Cluster-Modus oder in einem eigenständigen Modus auf dem Gerät installiert und betrieben werden.

Wenn sowohl SPC2- als auch SPC3-Karten installiert sind, können Sie die Tunnelzuordnung auf verschiedenen SPUs mithilfe des Befehls show security ipsec tunnel-distribution überprüfen.

Verwenden Sie den Befehl show security ike tunnel-map , um die Tunnelzuordnung auf verschiedenen SPUs anzuzeigen, wobei nur die SPC2-Karte eingefügt wurde. Der Befehl show security ike tunnel-map ist in einer Umgebung, in der SPC2- und SPC3-Karten installiert sind, nicht gültig.

Einfügen der SPC3-Karte: Richtlinien und Einschränkungen:

  • Wenn einer der Knoten über eine SPC3-Karte und der andere Knoten über 2 SPC3-Karten verfügt, wird das Failover zu dem Knoten mit 1 SPC3-Karte nicht unterstützt.

  • Sie müssen die SPC3 oder SPC2 in ein vorhandenes Gehäuse in einem höheren Steckplatz einsetzen als eine aktuelle SPC3, die in einem niedrigeren Steckplatz vorhanden ist.

  • Damit SPC3 ISHU funktioniert, müssen Sie die neue SPC3-Karte in die höhere Steckplatznummer einfügen.

  • In einem SRX5800-Gehäusecluster dürfen Sie die SPC3-Karte aufgrund der Begrenzung der Stromversorgungs- und Wärmeverteilung nicht in den höchsten Steckplatz (Steckplatz 11) einsetzen.

  • Wir unterstützen keine SPC3 Hot Removal.

Tabelle 4 fasst die Geräte der SRX5000-Reihe mit SPC2- oder SPC3-Karte zusammen, die Folgendes unterstützt kmd oder iked verarbeitet:

Tabelle 4: kmd/iked Prozessunterstützung für Geräte der SRX5000-Reihe

Geräte der SRX5000-Reihe

Support für kmd oder iked Prozess

Geräte der SRX5000-Reihe mit nur installierter SPC2-Karte

Unterstützt Prozesse kmd .

Geräte der SRX5000-Reihe mit nur installierter SPC3-Karte

Unterstützt Prozesse iked .

Geräte der SRX5000-Reihe mit installierter SPC2- und SPC3-Karte

Unterstützt Prozesse iked .

Aktivieren von IPSec-VPN-Funktionen auf der SRX5K-SPC3 Services Processing Card

Für Geräte der SRX5000-Reihe mit SRX5K-SPC3-Karte ist die Installation und Aktivierung aller IPSec-VPN-Funktionen erforderlich junos-ike . Standardmäßig junos-ike ist das Paket in Junos OS-Versionen 20.1R2, 20.2R2, 20.3R2, 20.4R1 und höher für Geräte der SRX5000-Reihe mit RE3 installiert. Aus diesem Grund ikedikemd wird der Prozess standardmäßig auf der Routing-Engine anstelle des IPsec-Schlüsselverwaltungs-Daemons (kmd) ausgeführt.

Wenn Sie IPsec-VPN-Funktionen auf Geräten der SRX5000-Reihe ohne SPC3-Karte aktivieren möchten kmd , müssen Sie den request system software delete junos-ike Befehl ausführen. Nachdem Sie den Befehl ausgeführt haben, müssen Sie das Gerät neu starten.

Um das installierte junos-ike Paket zu überprüfen, verwenden Sie den folgenden Befehl:

IPsec-VPN-Funktionsunterstützung für Geräte der SRX5000-Serie mit SRX5K-SPC3 und vSRX-Instanzen mit neuem Paket

In diesem Thema erhalten Sie eine Zusammenfassung der IPsec-VPN-Funktionen und -Konfigurationen, die von Geräten der SRX5000-Reihe mit SPC3 und auf vSRX-Instanzen nicht unterstützt werden.

IPsec-VPN-Funktion wird von zwei Prozessen iked und ikemd auf SRX5K-SPC3- und vSRX-Instanzen unterstützt. Eine einzelne Instanz von iked und ikemd wird auf der Routing-Engine gleichzeitig ausgeführt.

Standardmäßig Junos-ike ist das Paket in Junos OS Releases 20.1R2, 20.2R2, 20.3R2, 20.4R1 und höher für Geräte der SRX5000-Reihe mit RE3 installiert. Sowohl der Prozess als auch der ikedikemd Prozess werden auf der Routing-Engine ausgeführt.

Um den Prozess in der Routine-Engine neu zu starten ikemd , verwenden Sie den restart ike-config-management Befehl.

Verwenden Sie den restart ike-key-management Befehl, um den Prozess in der Routing-Engine neu zu starteniked.

Wenn Sie IPsec-VPN-Funktionen auf Geräten der SRX5000-Reihe ohne SPC3-Karte aktivieren möchten kmd , müssen Sie den request system software delete junos-ike Befehl ausführen. Nachdem Sie den Befehl ausgeführt haben, müssen Sie das Gerät neu starten.

IPsec-VPN-Funktionen werden nicht unterstützt

Informationen darüber, ob eine Funktion von einer bestimmten Plattform oder Junos OS-Version unterstützt wird, finden Sie im Feature Explorer.

Tabelle 5 fasst die nicht unterstützten IPsec-VPN-Funktionen auf Geräten der SRX-Serie und vSRX zusammen, auf denen ein iked-Prozess ausgeführt wird:

Tabelle 5: IPsec-VPN-Funktionen werden auf Geräten der SRX-Serie und vSRX-Instanzen nicht unterstützt

Funktionen

Unterstützung für Geräte der SRX5000-Reihe mit SRX5K-SPC3- und vSRX-Instanzen

Auto Discovery VPN (ADVPN).

Nein

AutoVPN Protocol Independent Multicast (PIM)-Point-to-Multipoint-Modus.

Nein

Konfigurieren der Weiterleitungsklasse auf IPsec-VPNs.

Nein

Dead Peer Detection (DPD)-Gateway-Failover.

DpD-Gateway-Failover wird auf vSRX nicht unterstützt.

Gruppen-VPN.

Nein

Lebensdauer von IKE SA in KB.

Nein

Konfiguration der Paketgröße für IPsec-Datenpfadüberprüfung.

Nein

Richtlinienbasiertes IPsec-VPN.

Nein

VPN-Überwachung.

Nein

Unterstützung von Routingprotokollen auf IPSec-VPN-Tunneln

Wir unterstützen Routing-Protokolle wie OSPF, BGP, PIM, RIP und BFD zur Ausführung auf IPsec-Tunneln auf Geräten der SRX-Serie und Routern der MX-Serie, die ausgeführt kmd oder iked verarbeitet werden. Die Protokollunterstützung variiert je nach IP-Adressierungsschema oder Typ der St0-Schnittstelle, Point-to-Point (P2P) oder Point-to-Multipoint (P2MP).

Tabelle 6 fasst die OSPF-Protokollunterstützung auf Geräten der SRX-Serie und MX-Routern zusammen.

Tabelle 6: OSPF-Protokollunterstützung für IPsec-VPN-Tunnel
OSPF
Geräte P2P P2MP
IPv4 IPv6 IPv4 IPv6
SRX100, SRX110, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, SRX380, SRX550, SRX550 HM, SRX650, SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600 und SRX5K-SPC2 Ja Nein Ja Nein
SRX5K-SPC3 Ja Nein Ja Nein
SRX5K im gemischten Modus (SPC3 + SPC2) Ja Nein Ja Nein
vSRX 3.0 Ja Nein Ja Nein
MX-SPC3 Ja Nein Nicht vorhanden. Nein

Tabelle 7 fasst die OSPFv3-Protokollunterstützung auf Geräten der SRX-Serie und MX-Routern zusammen.

Tabelle 7: OSPFv3-Protokollunterstützung für IPsec-VPN-Tunnel
OSPFv3
Geräte P2P P2MP
IPv4 IPv6 IPv4 IPv6
SRX100, SRX110, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, SRX380, SRX550, SRX550 HM, SRX650, SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600 und SRX5K-SPC2 Nein Ja Nein Ja
SRX5K-SPC3 Nein Ja Nein Ja
SRX5K im gemischten Modus (SPC3 + SPC2) Nein Ja Nein Ja
vSRX 3.0 Nein Ja Nein Ja
MX-SPC3 Nein Ja Nein Nein

Tabelle 8 fasst die BGP-Protokollunterstützung auf Geräten der SRX-Serie und MX-Routern zusammen.

Tabelle 8: BGP-Protokollunterstützung für IPsec-VPN-Tunnel
BGP
Geräte P2P P2MP
IPv4 IPv6 IPv4 IPv6
SRX100, SRX110, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, SRX380, SRX550, SRX550 HM, SRX650, SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600 und SRX5K-SPC2 Ja Ja Ja Ja
SRX5K-SPC3 Ja Ja Ja Ja
SRX5K im gemischten Modus (SPC3 + SPC2) Ja Ja Ja Ja
vSRX 3.0 Ja Ja Ja Ja
MX-SPC3 Ja Ja Nein Nein

Tabelle 9 fasst die PIM-Protokollunterstützung auf Geräten der SRX-Serie und MX-Routern zusammen.

Tabelle 9: PIM-Protokollunterstützung für IPsec-VPN-Tunnel
PIM
Geräte P2P P2MP
IPv4 IPv6 IPv4 IPv6
SRX100, SRX110, SRX210, SRX220, SRX240, SRX550, SRX550 HM, SRX650, SRX1400, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600 und SRX5K-SPC2 Ja Nein Nicht vorhanden. Nein
SRX300, SRX320, SRX340, SRX345, SRX380 und SRX1500 Ja Nein Ja Nein
SRX5K-SPC3 Ja Nein Nicht vorhanden. Nein
SRX5K im gemischten Modus (SPC3 + SPC2) Ja Nein Nicht vorhanden. Nein
vSRX 3.0 Ja Nein Ja
Anmerkung:

Multithread wird nicht unterstützt.

Nein
MX-SPC3 Ja Nein Nicht vorhanden. Nein

Tabelle 10 fasst die RIP-Protokollunterstützung auf Geräten der SRX-Serie und MX-Routern zusammen.

Tabelle 10: RIP-Protokollunterstützung für IPsec-VPN-Tunnel
RIP
Geräte P2P P2MP
IPv4 IPv6 IPv4 IPv6
SRX100, SRX110, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, SRX380, SRX550, SRX550 HM, SRX650, SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600 und SRX5K-SPC2 Ja Ja Nein Nein
SRX5K-SPC3 Ja Ja Nein Nein
SRX5K im gemischten Modus (SPC3 + SPC2) Ja Ja Nein Nein
vSRX 3.0 Ja Ja Nein Nein
MX-SPC3 Ja Ja Nein Nein

Tabelle 11 fasst die BFP-Protokollunterstützung auf Geräten der SRX-Serie und MX-Routern zusammen.

Tabelle 11: BFD-Protokollunterstützung für IPsec-VPN-Tunnel
BFD
Geräte P2P P2MP
IPv4 IPv6 IPv4 IPv6
SRX100, SRX110, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, SRX380, SRX550, SRX550 HM, SRX650, SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600 und SRX5K-SPC2 Ja Ja Ja Ja
SRX5K-SPC3 Ja Ja Ja Ja
SRX5K im gemischten Modus (SPC3 + SPC2) Ja Ja Ja Ja
vSRX 3.0 Ja Ja Ja Ja
MX-SPC3 Ja Ja Nein Nein

Anti-Replay-Fenster

Auf Geräten anti-replay-window der SRX-Serie ist standardmäßig mit einem Fenstergrößenwert von 64 aktiviert.

Auf Geräten der SRX-Serie 5000 mit installierten SPC3-Karten können Sie die anti-replay-window Größe im Bereich von 64 bis 8192 (Leistung von 2) konfigurieren. Verwenden Sie die neue anti-replay-window-size Option, um die Fenstergröße zu konfigurieren. Ein eingehendes Paket wird für Replay-Angriffe basierend auf dem anti-replay-window-size konfigurierten validiert.

Sie können auf zwei verschiedenen Ebenen konfigurieren replay-window-size :

  • Global level— Konfiguration auf [edit security ipsec] Hierarchieebene.

    Zum Beispiel:

  • VPN object— Konfiguration auf [edit security ipsec vpn vpn-name ike] Hierarchieebene.

    Zum Beispiel:

Wenn das Anti-Replay auf beiden Ebenen konfiguriert ist, hat die für eine VPN-Objektebene konfigurierte Fenstergröße Vorrang vor der auf globaler Ebene konfigurierten Fenstergröße. Wenn die Anti-Wiedergabe nicht konfiguriert ist, beträgt die Fenstergröße standardmäßig 64.

Um die Anti-Wiedergabe-Fensteroption für ein VPN-Objekt zu deaktivieren, verwenden Sie den set no-anti-replay Befehl auf der [edit security ipsec vpn vpn-name ike] Hierarchieebene. Sie können Anti-Replay auf globaler Ebene nicht deaktivieren.

Sie können sowohl als auch anti-replay-window-sizeno-anti-replay auf einem VPN-Objekt nicht konfigurieren.

Verstehen von Hub-and-Spoke-VPNs

Wenn Sie zwei VPN-Tunnel erstellen, die auf einem Gerät enden, können Sie ein Routenpaar so einrichten, dass das Gerät den Datenverkehr leitet, der einen Tunnel verlässt, zum anderen Tunnel. Sie müssen auch eine Richtlinie erstellen, damit der Datenverkehr von einem Tunnel zum anderen übertragen werden kann. Eine solche Anordnung wird als Hub-and-Spoke-VPN bezeichnet. (Siehe Abbildung 4.)

Sie können auch mehrere VPNs konfigurieren und den Datenverkehr zwischen zwei beliebigen Tunneln routen.

Geräte der SRX-Serie unterstützen nur die routenbasierte Hub-and-Spoke-Funktion.

Abbildung 4: Mehrere Tunnel in einer Hub-and-Spoke-VPN-KonfigurationMehrere Tunnel in einer Hub-and-Spoke-VPN-Konfiguration
Release-Verlaufstabelle
Release
Beschreibung
20.1R2
Standardmäßig junos-ike ist das Paket in Junos OS-Versionen 20.1R2, 20.2R2, 20.3R2, 20.4R1 und höher für Geräte der SRX5000-Reihe mit RE3 installiert. Aus diesem Grund ikedikemd wird der Prozess standardmäßig auf der Routing-Engine anstelle des IPsec-Schlüsselverwaltungs-Daemons (kmd) ausgeführt.