Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Übersicht über IPsec-VPN

Ein VPN ist ein privates Netzwerk, das ein öffentliches Netzwerk verwendet, um zwei oder mehr entfernte Standorte zu verbinden. Anstatt dedizierte Verbindungen zwischen Netzwerken zu verwenden, verwenden VPNs virtuelle Verbindungen, die über öffentliche Netzwerke geroutet (Tunneled) werden. IPsec VPN ist ein Protokoll, das aus einem Satz von Standards für den Aufbau einer VPN-Verbindung besteht.

Ein VPN stellt ein Mittel zur Verfügung, mit dem Remote-Computer sicher über ein öffentliches WAN wie das Internet kommunizieren.

Eine VPN-Verbindung kann zwei LANs (Site-to-Site-VPN) oder einen Benutzer für die Remote-Einwahl und ein LAN verbinden. Der Datenverkehr zwischen diesen beiden Punkten passiert 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 Security (IPsec)-Tunnel.

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

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

Im Folgenden sind einige der IPsec-VPN-Topologien, die Betriebssystem Junos (OS) unterstützt:

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

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

  • VPNs für Remote-Zugriff: Ermöglicht Benutzern, die zu Hause oder von unterwegs arbeiten, die Verbindung zum Firmenbüro und seinen Ressourcen. Diese Topologie wird manchmal auch 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 eins besser als das andere ist.

Tabelle 1 listen 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 wird in einer Richtlinie nicht speziell auf einen VPN-Tunnel Bezug nimmt.

Bei richtlinienbasierten VPN-Tunneln wird ein Tunnel als ein Objekt behandelt, das zusammen mit Quelle, Ziel, Anwendung und Aktion eine Tunnelrichtlinie für den VPN-Datenverkehr bildet.

Die Richtlinie referenziert eine Zieladresse.

In einer richtlinienbasierten VPN-Konfiguration referenziert eine Tunnelrichtlinie insbesondere anhand von Namen auf einen VPN-Tunnel.

Die Anzahl der routenbasierten VPN-Tunnel, die Sie erstellen, wird durch die Anzahl von Routeneinträgen oder die Anzahl der vom Gerät unterstützten St0-Schnittstellen begrenzt, unabhängig davon, welche Anzahl niedriger ist.

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

Routenbasierte VPN-Tunnelkonfiguration ist eine gute Wahl, wenn Sie Tunnelressourcen konservieren und gleichzeitig detaillierte Einschränkungen für den VPN-Datenverkehr festlegen möchten.

Bei einem richtlinienbasierten VPN können Sie zwar zahlreiche Tunnelrichtlinien erstellen, auf die derselbe VPN-Tunnel referenziert wird, doch erstellt jedes Tunnelrichtlinienpaar eine individuelle IPsec-Sicherheitszuordnung (IPSec Security Association, SA) zum Remote-Peer. Jede Sicherheitszuordnung zählt als einzelner VPN-Tunnel.

Bei EINEM routenbasierten Ansatz für VPNs ist die Datenverkehrskontrolle nicht mit den Bereitstellungswegen gekoppelt. Sie können Dutzende von Richtlinien konfigurieren, um den Datenverkehr durch einen einzelnen VPN-Tunnel zwischen zwei Standorten zu regeln, und nur eine IPsec-SICHERHEITSzuordnung ist im Arbeit. Darüber hinaus können Sie über eine routenbasierte VPN-Konfiguration Richtlinien erstellen, die auf ein Ziel verweisen, das durch einen VPN-Tunnel erreicht wird, in dem die Aktion verweigern ist.

In einer richtlinienbasierten VPN-Konfiguration muss die Aktion möglich sein und einen Tunnel beinhalten.

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

Der Austausch dynamischer Routinginformationen wird in richtlinienbasierten VPNs nicht unterstützt.

In Hub-and-Spoke-Topologien werden routenbasierte Konfigurationen verwendet.

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

Bei routenbasierten VPNs wird in einer Richtlinie nicht speziell auf einen VPN-Tunnel Bezug nimmt.

Wenn ein Tunnel keine großen Netzwerke miteinander verbindet, auf denen dynamische Routingprotokolle ausgeführt werden, 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 VPN-Konfigurationen für Remotezugriff (DFÜ).

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

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

Richtlinienbasierte VPNs sind möglicherweise erforderlich, wenn ein Drittanbieter für jedes Remote-Subnetz separate Sicherheitsrichtlinien benötigt.

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

Bei einem routenbasierten VPN-Tunnel können Sie einen Tunnel als Mittel für die Datenverkehrsbereitstellung betrachten und die Richtlinie als Methode betrachten, um diesen Datenverkehr zu erlaubt oder zu verweigern.

In einem richtlinienbasierten VPN-Tunnel können Sie einen Tunnel als ein Element bei der Errichtung einer Richtlinie betrachten.

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

Richtlinienbasierte VPNs können nicht verwendet werden, wenn NAT für den Tunneled Traffic erforderlich sind.

Proxy-ID wird sowohl für routenbasierte als auch richtlinienbasierte VPNs unterstützt. Routenbasierte Tunnel ermöglichen auch die Verwendung mehrerer Datenverkehrs-Selektoren, die auch als Multi-Proxy-ID bekannt sind. Ein Datenverkehrs-Selektor ist eine Vereinbarung zwischen IKE-Peers, um Datenverkehr über einen Tunnel zu zulassen, wenn der Datenverkehr mit einem bestimmten Paar lokaler und Remote-IP-Adressenpräfix, Quell-Portbereich, Ziel-Portbereich 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 Sicherheitszuordnung zulässig. Die Auswahl des Datenverkehrs ist in der Regel erforderlich, wenn Remote-Gateway-Geräte nicht auf Juniper Networks sind.

Richtlinienbasierte VPNs werden nur auf Geräten mit SRX5400, SRX5600 und SRX5800 unterstützt. Die Plattformunterstützung hängt von den Junos OS Installationsversion 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 ein Objekt behandelt, das zusammen mit Quelle, Ziel, Anwendung und Aktion eine Tunnelrichtlinie ist, die VPN-Datenverkehr ermöglicht.

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

Eine Tunnelrichtlinie referenziert 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 von Tunneln, die das Gerät unterstützt, je nach Geringerem begrenzt.

Bei einem richtlinienbasierten VPN können Sie zwar zahlreiche Tunnelrichtlinien erstellen, auf die derselbe VPN-Tunnel bezugiert wird, doch erstellt jedes Tunnel-Richtlinienpaar eine individuelle IPsec-SICHERHEITSzuordnung für den Remote-Peer. Jede Sicherheitszuordnung zählt als einzelner VPN-Tunnel.

Da die Route und nicht die Richtlinie bestimmt, welcher Datenverkehr durch den Tunnel fließt, können mehrere Richtlinien mit einer einzigen SICHERHEITSzuordnung oder einem VPN unterstützt werden.

In einem richtlinienbasierten VPN muss die Aktion möglich sein und einen Tunnel umfassen.

In einem routenbasierten VPN ist die Regulierung des Datenverkehrs nicht an die Mittel seiner Bereitstellung gekoppelt.

Der Austausch dynamischer Routinginformationen wird in richtlinienbasierten VPNs nicht unterstützt.

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

Wenn Sie eine höhere Granularität als eine Route benötigen, kann dies angeben, welchen Datenverkehr an einen Tunnel gesendet wird. Die beste Wahl ist ein richtlinienbasiertes VPN mit Sicherheitsrichtlinien.

Routenbasierte VPNs verwenden Routen, um den An einen Tunnel gesendeten Datenverkehr anzugeben. wird in einer Richtlinie nicht speziell auf einen VPN-Tunnel Bezug nimmt.

In einem richtlinienbasierten VPN-Tunnel können Sie einen Tunnel als ein Element bei der Errichtung einer Richtlinie betrachten.

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

Bei einem routenbasierten VPN-Tunnel können Sie einen Tunnel als Mittel für die Datenverkehrsbereitstellung betrachten und die Richtlinie als Methode betrachten, um diesen Datenverkehr zu erlaubt oder zu verweigern.

Grundlegende IKE und IPsec-Paketverarbeitung

Ein IPSec-VPN-Tunnel besteht aus der Tunnel-Einrichtung und den eingesetzten Sicherheitseinstellungen. Während der Tunnel-Einrichtung erstellen die Peers Sicherheitszuordnungen (SAs), die die Parameter für die Sicherung des Datenverkehrs zwischen sich selbst festlegen. (Siehe IPsec - Übersicht .) Nachdem der Tunnel eingerichtet wurde, schützt IPsec den Datenverkehr, der zwischen den beiden Tunnel-Endpunkten gesendet wird, durch die Anwendung der Sicherheitsparameter, die von den Sicherheitseinstellungen während der Tunnel-Einrichtung definiert werden. Innerhalb der Junos OS wird IPsec im Tunnelmodus angewendet, der die Encapsulating Security Payload (ESP)- und Authentication Header (AH)-Protokolle unterstützt.

Dieses Thema umfasst die folgenden Abschnitte:

Paketverarbeitung im Tunnelmodus

IPsec wird in einem von zwei Modi betrieben – Transport oder Tunnel. Wenn beide Enden des Tunnels Hosts sind, können Sie beide Modus verwenden. Wenn mindestens eines der Endpunkte eines Tunnels ein Sicherheitsgateway ist, z. B. ein Router Junos OS Firewall, müssen Sie den Tunnelmodus verwenden. Juniper Networks IPsec-Tunnel werden immer im Tunnelmodus betrieben.

Im Tunnelmodus wird das gesamte Original-IP-Paket – Payload und Header – in eine andere IP-Payload eingekapselt und ein neuer Header wird an den Header angehängt, wie in Abbildung 1 gezeigt. Das gesamte Originalpaket kann verschlüsselt, authentifiziert oder beides sein. Mit dem AH-Protokoll (Authentication Header) werden auch der 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 im neuen Header verwendeten Quell- und Zieladressen die IP-Adressen der ausgehenden Schnittstelle. Siehe Abbildung 2 .

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

In einem DFÜ-VPN befindet sich am Ende des Tunnels kein Tunnel-Gateway auf dem VPN-DFÜ-Client. erstreckt sich der Tunnel direkt zum Client selbst (siehe Abbildung 3 ). In diesem Fall haben sowohl der neue Header als auch der verkapselte Original-Header bei paketen, die vom DFÜ-Client gesendet werden, dieselbe IP-Adresse: auf dem Client-Computer.

Einige VPN-Clients wie der dynamische VPN-Client und Netscreen-Remote verwenden eine virtuelle innere IP-Adresse (auch "Sticky-Adresse" genannt). Mit Netscreen-Remote können Sie die virtuelle IP-Adresse definieren. Der dynamische VPN-Client verwendet die beim XAuth-Konfigurationswechsel zugewiesene virtuelle IP-Adresse. In solchen Fällen handelt es sich bei der virtuellen inneren IP-Adresse um die Quell-IP-Adresse im ursprünglichen Paket-Header des Datenverkehrs, der vom Client stammt, und die IP-Adresse, die dem ISP dynamisch dem DFÜ-Client zu weist, die Quell-IP-Adresse im äußeren Header.

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

Verteilung von IKE- und IPsec-Sitzungen über SPUs

In SRX5400-, SRX5600- und SRX5800-Geräten bietet IKE Tunnelverwaltung für IPsec und authentifiziert Endelemente. IKE führt einen Diffie-Hellman (DH)-Schlüsselwechsel 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 entsteht durch Verteilung der IKE- und IPsec-Arbeitslast auf mehrere Serviceverarbeitungseinheiten (Service Processing Units, SPUs) der Plattform. Bei Site-to-Site-Tunneln wird der am wenigsten belastete SPU als Anker-SPU gewählt. Wenn mehrere SPUs die gleiche kleinste Last haben, kann jede davon als Anker-SPU ausgewählt werden. Hierbei entspricht die Last der Anzahl der Standort-zu-Standort-Gateways bzw. manueller VPN-Tunnel, die auf einem SPU verankert sind. Bei dynamischen Tunneln nutzen die neu eingerichteten dynamischen Tunnel einen Round-Robin-Algorithmus, um den SPU auszuwählen.

In IPsec wird die Arbeitsauslastung über den gleichen Algorithmus verteilt, IKE. Die Phase 2-Sicherheitszuordnung für ein bestimmtes VPN-Tunnelabschlusspunktepaar gehört ausschließlich einem bestimmten SPU, und alle IPsec-Pakete, die zu dieser Phase-2-Sicherheitszuordnung gehören, werden zur IPsec-Verarbeitung an den Anker-SPU dieser SA weitergeleitet.

Mehrere IPsec-Sitzungen (Phase 2 SA) können über eine oder mehrere Sitzungen IKE werden. Der zur Ankerung der IPsec-Sitzung ausgewählte SPU basiert auf dem SPU, der die zugrunde liegende IKE ist. Daher werden alle IPsec-Sitzungen, die über ein einzelnes IKE Gateway ausgeführt werden, von demselben SPU serviceiert und nicht über mehrere SPUs ausgeglichen.

Tabelle 3 zeigt ein Beispiel für ein SrX5000-Leitungsgerät mit drei SPUs, die sieben IPsec-Tunnel über drei Gateways IKE laufen.

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 gleich große Last von 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 ankern.

Das Einrichten und Herunterreißen vorhandener IPsec-Tunnel beeinträchtigt nicht die zugrunde liegende Netzwerksitzung IKE oder vorhandene IPsec-Tunnel.

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

Verwenden Sie summary die Befehlsoption, um die Ankerpunkte jedes Gateways zu betrachten: show security ike tunnel-map summary.

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

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

In einem SRX5400-, SRX5600- oder SRX5800-Chassis-Cluster 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 in jedem Gehäuse des Clusters eine neue SPC einfügen, werden die vorhandenen Tunnel nicht beeinträchtigt, und der Datenverkehr fließt ohne Unterbrechung weiter.

Beginnend ab Junos OS Veröffentlichung 19.4R1 auf allen Geräten der SRX5000-Serie als Gehäusecluster können Sie 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 einem höheren Steckplatz als die vorhandene SPC3-Karte im Gehäuse einfügen. Sie müssen den Knoten nach dem Einfügen der SPC3 neu starten, um die Karte zu aktivieren. Nach dem Neustart des Knotens werden IPsec-Tunnel an die Karten verteilt.

Vorhandene Tunnel können jedoch die Verarbeitungsleistung der Service Processing Units (SPUs) in den neuen SPCs nicht nutzen. Ein neuer SPU kann neu eingerichtete Standort-zu-Standort- und dynamische Tunnel ankerinen. Neu konfigurierte Tunnel sind jedoch nicht garantiert auf einem neuen SPU verankert.

Site-to-Site-Tunnel sind auf verschiedenen SPUs basierend auf einem Load-Balancing-Algorithmus verankert. Der Load-Balancing-Algorithmus hängt von den Zahlen der Flussfäden ab, die jeder SPU verwendet. Tunnel, die zu den gleichen lokalen und Remote-Gateway-IP-Adressen gehören, sind auf dem gleichen SPU auf verschiedenen Fluss-RT-Threads verankert, die vom SPU verwendet werden. Als Anker-SPU wird der SPU mit der geringsten Last gewählt. Jeder SPU verwaltet die Anzahl der Fluss-RT-Threads, die in diesem bestimmten SPU gehostet werden. Die Anzahl der auf jedem SPU gehosteten Fluss-RT-Threads variiert je nach Typ des SPU.

Tunnellastfaktor = Anzahl der im SPU ankernden Tunnel/Gesamtanzahl der Fluss-RT-Threads, die vom SPU verwendet werden.

Dynamische Tunnel sind auf verschiedenen SPUs basierend auf einem Round-Robin-Algorithmus verankert. Die neu konfigurierten dynamischen Tunnel sind nicht auf der neuen SPC verankert.

Wir beginnen Junos OS Veröffentlichungsversion 18.2R2 und 18.4R1, Alle vorhandenen IPsec-VPN-Funktionen, die derzeit von 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 auf dem Gerät in einem Gehäuse-Clustermodus oder in einem Eigenständigen Modus installiert werden.

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

Verwenden Sie den show security ike tunnel-map Befehl, um die Tunnelzuordnung auf verschiedenen SPUs mit nur eingefügter SPC2-Karte zu anzeigen. Der Befehl show security ike tunnel-map ist in einer Umgebung, in der SPC2- und SPC3-Karten installiert sind, ungültig.

SPC3-Karte einfügen: Richtlinien und Beschränkungen:

  • Wenn einer der Knoten in einem Gehäusecluster über eine SPC3-Karte verfügt 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 einem vorhandenen Gehäuse in einem höheren Steckplatz einfügen als eine aktuelle SPC3, die in einem niedrigeren Steckplatz vorhanden ist.

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

  • Auf SRX5800 Chassis-Cluster dürfen Sie die SPC3-Karte im höchsten Steckplatz (Steckplatz Nr. 11) aufgrund der Begrenzung der Stromversorgung und Wärmeverteilung nicht einstecken.

  • Wir unterstützen SPC3 Hot Removal nicht.

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

Für die SRX5000-Reihe der Geräte mit SRX5K-SPC3-Karte ist das Paket erforderlich, um eine der junos-ike IPSec-VPN-Funktionen zu installieren und zu aktivieren. Standardmäßig wird das Paket für geräte der junos-ike SRX5000-Reihe mit RE3 in Junos OS, 20.1R2, 20.2R2, 20.3R2, 20.4R1 und höher installiert. Daher läuft der Prozess standardmäßig auf der Routing-Engine anstelle von ikedikemd IPsec Key Management Daemon (kmd).

Wenn Sie den KMD-Prozess verwenden möchten, um die IPSec-VPN-Funktion anstelle von Standardeinstellungen IKE, führen Sie den request system software delete junos-ike Befehl aus.

Verwenden Sie den folgenden Befehl, um das junos-ike installierte Paket zu prüfen:

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

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

Die IPsec-VPN-Funktion wird von zwei Prozessen unterstützt, und auf ikedikemd SRX5K-SPC3- vSRX Instanzen. Eine einzige Instanz iked von und wird auf dem ikemd Echtzeit-Routing-Engine gleichzeitig ausgeführt.

Standardmäßig wird das Paket für die Geräte der Junos-ike SRX5000-Reihe mit RE3 in den Junos OS-Versionen 20.1R2, 20.2R2, 20.3R2, 20.4R1 und höher ikedikemd installiert.

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

Verwenden Sie den Befehl, um den Prozess im Routing-Engine ikedrestart ike-key-management neu zu starten.

Wenn Sie den KMD-Prozess verwenden möchten, um die IPSec-VPN-Funktion anstelle von Standardeinstellungen IKE, führen Sie den request system software delete junos-ike Befehl aus.

IPSec-VPN-Funktionen nicht unterstützt

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

Tabelle 4: Unterstützung von IPsec-VPN-Funktionen auf Geräten und Instanzen vSRX SRX-Serie

Funktionen

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

VPN mit automatischer Erkennung (ADVPN).

Nein

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

Nein

AutoVPN RIP-Unterstützung für Unicast-Datenverkehr.

Nein

Bidirectional Forwarding Detection (BFD) über OSPFv3-Routen an der st0-Schnittstelle.

Wird auf dieser Seite nicht vSRX

Konfigurieren der Weiterleitungsklasse auf IPSec-VPNs.

Nein

Config Mode (draft-dukes-ike-mode-cfg-03).

Nein

Dead Peer Detection (DPD) und DPD-Gateway-Failover.

Ein DPD-Gateway-Failover wird auf dieser Seite vSRX.

AH-Transportmodi.

Nein

Gruppen-VPN.

Nein

Leerlauf-Timer für IKE.

Nein

Leerlauf-Timer für IPsec-SA.

Nein

Ungültige SPI-Antwort.

Nein

Lebensdauer von IKE SA in KB.

Nein

Logisches System.

Nein

Manuelles VPN.

Nein

Multicast-Datenverkehr.

Nein

Neighbor Discovery Protocol (NDP) über St0-Schnittstellen.

Nein

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

Nein

Paket-Neuordnung für IPv6-Fragmente über Tunnel.

Nein

Point-to-Multipoint-Tunnelschnittstellen.

Nein

Richtlinienbasiertes IPSec-VPN.

Nein

Ras.

Nein

Unterstützung von Gruppen-IDs IKE für dynamische VPN-Konfiguration.

Nein

TOS/DSCP-Honoring für IPsec (außen/innen).

Wird auf SRX- und vSRX

Statisches Routing

Wird auf SRX- und vSRX

Dynamisches Routing (RIP, OSPF, BGP) Nein

VPN-Überwachung.

Nein

Xauth

Nein

Verstehen von Hub-and-Spoke-VPNs

Wenn Sie zwei VPN-Tunnel erstellen, die mit einem Gerät enden, können Sie ein Paar Routen einrichten, sodass das Gerät den Datenverkehr, der einen Tunnel verlässt, auf den anderen Tunnel leitet. Außerdem müssen Sie eine Richtlinie erstellen, damit der Datenverkehr von einem Tunnel an den anderen übergeben kann. Eine solche Anordnung ist als Hub-and-Spoke-VPN bekannt. (Siehe Abbildung 4 .)

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

Geräte der SRX-Serie unterstützen nur routebasierte 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 wird das Paket für geräte der junos-ike SRX5000-Reihe mit RE3 in Junos OS, 20.1R2, 20.2R2, 20.3R2, 20.4R1 und höher installiert. Daher läuft der Prozess standardmäßig auf der Routing-Engine anstelle von ikedikemd IPsec Key Management Daemon (kmd).