IPsec-VPN – Übersicht
In diesem Thema erfahren Sie mehr über die IKE- und IPsec-Paketverarbeitung und die IPsec-VPN-Topologien auf Firewalls der SRX-Serie. Erfahren Sie mehr über die Services Processing Cards, die kryptografische Beschleunigung, die Unterstützung von Routing-Protokollen und die iked-Prozessunterstützung.
Ein VPN ist ein privates Netzwerk, das ein öffentliches Netzwerk verwendet, um zwei oder mehr Remote-Standorte zu verbinden. Anstatt dedizierte Verbindungen zwischen Netzwerken zu verwenden, verwenden VPNs virtuelle Verbindungen, die durch öffentliche Netzwerke geroutet (getunnelt) werden. IPsec VPN ist ein Protokoll, das aus einer Reihe von Standards besteht, die zum Aufbau einer VPN-Verbindung verwendet werden.
Ein VPN bietet ein Mittel, mit dem Remotecomputer sicher über ein öffentliches WAN wie das Internet kommunizieren können.
Eine VPN-Verbindung kann zwei LANs (Site-to-Site-VPN) oder einen Remote-DFÜ-Benutzer und ein LAN verbinden. Der Datenverkehr, der zwischen diesen beiden Punkten fließt, durchläuft gemeinsam genutzte Ressourcen wie Router, Switches und andere Netzwerkgeräte, aus denen das öffentliche WAN besteht. Um die VPN-Kommunikation während des Übergangs durch das WAN zu sichern, bauen die beiden Teilnehmer einen IPsec-Tunnel auf.
Der Begriff Tunnel bezeichnet nicht den Tunnelmodus (siehe Paketverarbeitung im Tunnelmodus). Stattdessen bezieht es sich auf die IPsec-Verbindung.
Verwenden Sie den Funktions-Explorer , um die Plattform- und Releaseunterstützung für bestimmte Features zu bestätigen.
Plattformspezifisches IPsec-VPN-Verhalten Im Abschnitt finden Sie Hinweise zu Ihrer Plattform.
Weitere Informationen finden Sie in diesem Zusätzliche Plattforminformationen Abschnitt.
IPsec-VPN-Topologien auf Firewalls der SRX-Serie
Im Folgenden sind einige der IPsec-VPN-Topologien aufgeführt, die vom Betriebssystem Junos unterstützt werden:
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 Zweigstellen mit der Unternehmenszentrale 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 es Benutzern, die zu Hause oder auf Reisen arbeiten, sich mit der Unternehmenszentrale und ihren Ressourcen zu verbinden. Diese Topologie wird manchmal auch als end-to-site tunnel.
Siehe auch
Vergleich von richtlinienbasierten und routenbasierten VPNs
Lesen Sie dieses Thema, um die Unterschiede zwischen richtlinienbasierten und routenbasierten VPNs zu verstehen.
Es ist wichtig, die Unterschiede zwischen richtlinienbasierten und routenbasierten VPNs zu verstehen und zu verstehen, warum eines dem anderen vorzuziehen ist.
Tabelle 1 listet die Unterschiede zwischen routenbasierten VPNs und richtlinienbasierten VPNs auf.
|
Routenbasierte VPNs |
Richtlinienbasierte VPNs |
|---|---|
|
Bei routenbasierten VPNs verweist eine Richtlinie nicht ausdrücklich auf einen VPN-Tunnel. |
Bei richtlinienbasierten VPN-Tunneln wird ein Tunnel als ein 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 namentlich auf einen VPN-Tunnel. |
|
Die Anzahl der routenbasierten VPN-Tunnel, die Sie erstellen, wird durch die Anzahl der Routeneinträge oder die Anzahl der vom Gerät unterstützten st0-Schnittstellen begrenzt, je nachdem, welche Zahl niedriger ist. |
Die Anzahl der richtlinienbasierten VPN-Tunnel, die Sie erstellen können, ist durch die Anzahl der Richtlinien begrenzt, die das Gerät unterstützt. |
|
Die routenbasierte VPN-Tunnelkonfiguration ist eine gute Wahl, wenn Sie Tunnelressourcen schonen und gleichzeitig granulare Einschränkungen für den VPN-Datenverkehr festlegen möchten. |
Bei 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 individueller VPN-Tunnel. |
|
Bei einem routenbasierten Ansatz für VPNs ist die Regulierung des Datenverkehrs nicht an die Art und Weise seiner Bereitstellung gekoppelt. Sie können Dutzende von Richtlinien konfigurieren, um den Datenverkehr zu regulieren, der durch einen einzigen VPN-Tunnel zwischen zwei Standorten fließt, und es ist nur eine IPsec-Sicherheitszuordnung aktiv. Außerdem können Sie mit einer routenbasierten VPN-Konfiguration Richtlinien erstellen, die auf ein Ziel verweisen, das über einen VPN-Tunnel erreicht wird, in dem die Aktion verweigert wird. |
In einer richtlinienbasierten VPN-Konfiguration muss die Aktion zulässig sein und einen Tunnel umfassen. |
|
Routenbasierte VPNs unterstützen den Austausch dynamischer Routing-Informationen über VPN-Tunnel. Sie können eine Instanz eines dynamischen Routingprotokolls, z. B. 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 nicht für Hub-and-Spoke-Topologien verwendet werden. |
|
Bei routenbasierten VPNs verweist eine Richtlinie nicht ausdrücklich auf einen VPN-Tunnel. |
Wenn ein Tunnel keine großen Netzwerke 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 VPN-Konfigurationen für den Remotezugriff (DFÜ). |
Richtlinienbasierte VPN-Tunnel sind für VPN-Konfigurationen mit Remotezugriff (DFÜ) erforderlich. |
|
Routenbasierte VPNs funktionieren bei einigen Drittanbietern möglicherweise nicht richtig. |
Richtlinienbasierte VPNs können erforderlich sein, wenn der Drittanbieter separate Sicherheitszuordnungen für jedes Remote-Subnetz benötigt. |
|
Wenn das Sicherheitsgerät eine Routensuche durchführt, um die Schnittstelle zu finden, über die es Datenverkehr senden muss, um eine Adresse zu erreichen, findet es eine Route über eine sichere Tunnelschnittstelle ( Bei einem routenbasierten VPN-Tunnel können Sie einen Tunnel als Mittel zum Übermitteln von Datenverkehr in Betracht ziehen und die Richtlinie als Methode zum Zulassen oder Verweigern der Übermittlung dieses Datenverkehrs betrachten. |
Bei einem richtlinienbasierten VPN-Tunnel können Sie einen Tunnel als Element beim Aufbau einer Richtlinie betrachten. |
|
Routenbasierte VPNs unterstützen NAT für st0-Schnittstellen. |
Richtlinienbasierte VPNs können nicht verwendet werden, wenn NAT für getunnelten Datenverkehr erforderlich ist. |
Die Proxy-ID wird sowohl für routenbasierte als auch für richtlinienbasierte VPNs unterstützt. Routenbasierte Tunnel bieten auch die Verwendung mehrerer Datenverkehrsselektoren, die auch als Multi-Proxy-ID bezeichnet werden. Ein Datenverkehrsselektor ist eine Vereinbarung zwischen IKE-Peers, um Datenverkehr durch einen Tunnel zuzulassen, wenn der Datenverkehr mit einem bestimmten Paar aus lokalem und Remote-IP-Adresspräfix, Quellportbereich, Zielportbereich und Protokoll übereinstimmt. Sie definieren einen Datenverkehrsselektor innerhalb eines bestimmten routenbasierten VPNs, was zu mehreren IPsec-Sicherheitszuordnungen der Phase 2 führen kann. Nur Datenverkehr, der einem Datenverkehrsselektor entspricht, wird über eine Sicherheitszuordnung zugelassen. Die Datenverkehrsauswahl ist in der Regel erforderlich, wenn es sich bei Remote-Gateway-Geräten um Geräte handelt, die nicht von Juniper Networks stammen.
Siehe auch
Vergleich von richtlinienbasierten VPNs und routenbasierten VPNs
Tabelle 2 fasst die Unterschiede zwischen richtlinienbasierten VPNs und routenbasierten VPNs zusammen.
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 ausdrücklich auf einen VPN-Tunnel. |
Eine Tunnelrichtlinie verweist namentlich auf einen VPN-Tunnel. |
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, ist 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, je nachdem, welcher Wert niedriger ist. |
Bei einem richtlinienbasierten VPN können Sie zwar zahlreiche Tunnelrichtlinien erstellen, die auf denselben VPN-Tunnel verweisen, aber jedes Tunnelrichtlinienpaar erstellt eine individuelle IPsec-Sicherheitszuordnung mit dem Remotepeer. Jede SA zählt als individueller VPN-Tunnel. |
Da die Route und 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 zulässig sein und einen Tunnel umfassen. |
In einem routenbasierten VPN ist die Regulierung des Datenverkehrs nicht an die Art und Weise seiner 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 Routingprotokolls, z. B. OSPF, auf einer st0-Schnittstelle aktivieren, die an einen VPN-Tunnel gebunden ist. |
Wenn Sie mehr Granularität benötigen, als eine Route bieten kann, um den an einen Tunnel gesendeten Datenverkehr zu spezifizieren, ist die Verwendung eines richtlinienbasierten VPN mit Sicherheitsrichtlinien die beste Wahl. |
Routenbasierte VPNs verwenden Routen, um den Datenverkehr anzugeben, der an einen Tunnel gesendet wird. Eine Richtlinie verweist nicht ausdrücklich auf einen VPN-Tunnel. |
Bei einem richtlinienbasierten VPN-Tunnel können Sie einen Tunnel als Element beim Aufbau einer Richtlinie betrachten. |
Wenn das Sicherheitsgerät eine Routensuche durchführt, 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). Bei einem routenbasierten VPN-Tunnel können Sie einen Tunnel als Mittel zum Übermitteln von Datenverkehr in Betracht ziehen und die Richtlinie als Methode zum Zulassen oder Verweigern der Übermittlung dieses Datenverkehrs betrachten. |
Grundlegendes zur Paketverarbeitung von IKE und IPsec
Ein IPsec-VPN-Tunnel besteht aus der Einrichtung des Tunnels und der angewendeten Sicherheit. Während des Tunnelaufbaus richten die Peers Sicherheitszuordnungen (Security Associations, SAs) ein, die die Parameter für die Sicherung des Datenverkehrs untereinander definieren. Weitere Informationen finden Sie unter IPsec – Übersicht. Nachdem der Tunnel eingerichtet wurde, schützt IPsec den Datenverkehr, der zwischen den beiden Tunnelendpunkten gesendet wird, indem die von den SAs während der Tunneleinrichtung definierten Sicherheitsparameter angewendet werden. In 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 arbeitet in einem von zwei Modi: Transport oder Tunnel. Wenn beide Enden des Tunnels Hosts sind, können Sie beide Modi verwenden. Wenn es sich bei mindestens einem der Endpunkte eines Tunnels um ein Sicherheitsgateway handelt, z. B. ein Junos OS-Router oder eine Firewall, müssen Sie den Tunnelmodus verwenden. Geräte von Juniper Networks werden für IPsec-Tunnel immer im Tunnelmodus betrieben.
Im Tunnelmodus wird das gesamte ursprüngliche IP-Paket – Nutzlast und Header – in eine andere IP-Nutzlast gekapselt und ein neuer Header wird angehängt, wie in Abbildung 1gezeigt. Das gesamte ursprüngliche Paket kann verschlüsselt, authentifiziert oder beides sein. Mit dem AH-Protokoll (Authentication Header) werden auch der AH und neue Header authentifiziert. Mit dem ESP-Protokoll (Encapsulating Security Payload) kann auch der ESP-Header authentifiziert werden.
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.
In einem DFÜ-VPN gibt es kein Tunnelgateway am VPN-DFÜ-Client-Ende des Tunnels. Der Tunnel erstreckt sich direkt auf den Client selbst (siehe Abbildung 3). In diesem Fall haben bei Paketen, die vom DFÜ-Client gesendet werden, sowohl der neue Header als auch der gekapselte ursprüngliche Header dieselbe IP-Adresse: die des Computers des Clients.
Einige VPN-Clients, wie z.B. die Netscreen-Remote, verwenden eine virtuelle innere IP-Adresse (auch "Sticky Address" genannt). Netscreen-Remote ermöglicht es Ihnen, die virtuelle IP-Adresse zu definieren. In solchen Fällen ist die virtuelle innere IP-Adresse die Quell-IP-Adresse im ursprünglichen Paket-Header des Datenverkehrs, der vom Client stammt, und die IP-Adresse, die der ISP dem DFÜ-Client dynamisch zuweist, ist die Quell-IP-Adresse im äußeren Header.
Siehe auch
Verteilung von IKE- und IPsec-Sitzungen auf SPUs
Plattformspezifische SPUs, VPN-Verarbeitungsverhalten Im Abschnitt finden Sie Hinweise zu Ihrer Plattform.
In Firewallsder SRX-Serie bietet IKE Tunnelmanagement für IPsec und authentifiziert Endentitäten. IKE führt einen Diffie-Hellman-Schlüsselaustausch (DH) durch, um einen IPsec-Tunnel zwischen Netzwerkgeräten zu erzeugen. Die von IKE generierten IPsec-Tunnel werden verwendet, um den Benutzerdatenverkehr zwischen den Netzwerkgeräten auf der IP-Ebene zu verschlüsseln, zu entschlüsseln und zu authentifizieren.
Das VPN wird erstellt, indem die IKE- und IPsec-Arbeitsauslastung auf die verschiedenen Services Processing Units (SPUs) der Plattform verteilt wird. Bei Site-to-Site-Tunneln wird die SPU mit der geringsten Auslastung als Anker-SPU ausgewählt. Wenn mehrere SPUs die gleiche kleinste Last haben, kann jede von ihnen als Anker-SPU ausgewählt werden. Hier entspricht die Last der Anzahl der Site-to-Site-Gateways oder manuellen VPN-Tunnel, die auf einer SPU verankert sind. Bei dynamischen Tunneln verwenden die neu eingerichteten dynamischen Tunnel einen Round-Robin-Algorithmus zur Auswahl der SPU.
Bei IPsec wird die Arbeitsauslastung durch denselben Algorithmus verteilt, der auch die IKE verteilt. Die Phase-2-Sicherheitszuordnung für ein bestimmtes VPN-Tunnel-Endpunktpaar gehört ausschließlich einer bestimmten SPU, und alle IPsec-Pakete, die zu dieser Phase-2-Sicherheitszuordnung gehören, werden zur IPsec-Verarbeitung an die Verankerungs-SPU dieser Sicherheitszuordnung weitergeleitet.
Mehrere IPsec-Sitzungen (Phase 2 SA) können über eine oder mehrere IKE-Sitzungen ausgeführt werden. Die SPU, die für die Verankerung 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 ausgeführt werden, von derselben SPU bedient und haben keinen Lastenausgleich über mehrere SPUs.
Tabelle 3 zeigt ein Beispiel für eine Firewall mit drei SPUs, die sieben IPsec-Tunnel über drei IKE-Gateways ausführen.
|
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 die 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 Beenden 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 Anzahl der Tunnel pro SPU anzuzeigen: show security ike tunnel-map.
Verwenden Sie die summary Option des Befehls, um die Ankerpunkte der einzelnen Gateways anzuzeigen: show security ike tunnel-map summary.
VPN-Unterstützung für das Einfügen von Dienstverarbeitungskarten
High-End-Firewalls der SRX-Serie verfügen über eine gehäusebasierte, verteilte Prozessorarchitektur. Die Flow-Verarbeitungsleistung wird geteilt und basiert auf der Anzahl der Services Processing Cards (SPCs). Sie können die Rechenleistung des Geräts skalieren, indem Sie neue SPCs installieren.
Plattformspezifisches SRX5000-Line-SPC-Verhalten Im Abschnitt finden Sie Hinweise zu Ihrer Plattform.
Weitere Informationen finden Sie im Abschnitt Zusätzliche Plattforminformationen für kmd- und iked-Prozess in SRX5000 Zeile .
In High-End-Gehäuse-Clustern der SRX-Serie können Sie SPCs in die Geräte einfügen , ohne den Datenverkehr in den vorhandenen IKE- oder IPsec-VPN-Tunnelnzu beeinträchtigen oder zu unterbrechen.
Siekönnen eine SPC3 - oder SPC2-Karte in ein vorhandenes Gehäuse mit einer SPC3-Karte einfügen. Sie können die Karten nur in einen höheren Steckplatz als die vorhandene SPC3-Karte im Gehäuse einsetzen.
Vorhandene Tunnel können jedoch nicht die Rechenleistung der Service Processing Units (SPUs) in den neuen SPCs nutzen. Eine neue SPU kann neu eingerichtete Site-to-Site- und dynamische Tunnel verankern. Es kann jedoch nicht garantiert werden, dass neu konfigurierte Tunnel auf einer neuen SPU verankert werden.
Site-to-Site-Tunnel werden auf der Grundlage eines Lastausgleichsalgorithmus auf verschiedenen SPUs verankert. Der Lastenausgleichsalgorithmus ist abhängig von der Anzahl der Datenflussthreads, die jede SPU verwendet. Tunnel, die zu denselben lokalen und Remote-Gateway-IP-Adressen gehören, sind in derselben SPU in unterschiedlichen Datenfluss-RT-Threads verankert, die von der SPU verwendet werden. Als Anker-SPU wird die SPU mit der geringsten Last gewählt. Jede SPU verwaltet die Anzahl der Flow-RT-Threads, die in dieser bestimmten SPU gehostet werden. Die Anzahl der Flow-RT-Threads, die auf jeder SPU gehostet werden, hängt vom Typ der SPU ab.
Tunnellastfaktor = Anzahl der auf der SPU verankerten Tunnel / Gesamtzahl der von der SPU verwendeten RT-Threads im Fluss.
Dynamische Tunnel werden auf der Grundlage eines Round-Robin-Algorithmus auf verschiedenen SPUs verankert. Es kann nicht garantiert werden, dass neu konfigurierte dynamische Tunnel auf der neuen SPC verankert werden.
Wenn sowohl SPC2- als auch SPC3-Karten installiert sind, können Sie die Tunnelzuordnung auf verschiedenen SPUs mit dem show security ipsec tunnel-distribution Befehl überprüfen.
Verwenden Sie den Befehl show security ike tunnel-map , um die Tunnelzuordnung auf verschiedenen SPUs anzuzeigen, in die nur eine SPC2-Karte eingelegt ist. Der Befehl show security ike tunnel-map ist in einer Umgebung, in der SPC2- und SPC3-Karten installiert sind, nicht gültig.
Einsetzen der SPC3-Karte: Richtlinien und Einschränkungen:
-
Wenn in einem Chassis-Cluster einer der Knoten über 1 SPC3-Karte und der andere Knoten über 2 SPC3-Karten verfügt, wird das Failover auf den Knoten mit 1 SPC3-Karte nicht unterstützt.
-
Sie müssen SPC3 oder SPC2 in ein vorhandenes Gehäuse in einem höheren Steckplatz einsetzen als ein aktuelles SPC3 in einem niedrigeren Steckplatz.
-
Damit SPC3 ISHU funktioniert, müssen Sie die neue SPC3-Karte in die höhere Steckplatznummer einsetzen.
-
Wir unterstützen die SPC3-Hot-Removal nicht.
Siehe auch
IPsec-VPN mit iked-Verfahren
Die beiden Prozesse iked und ikemd unterstützen IPsec-VPN-Funktionen auf Firewalls der SRX-Serie. Es wird jeweils eine einzelne Instanz von iked und ikemd auf der Routing-Engine ausgeführt.
Mit junos-ike dem Paket führt die Firewall den IPsec-VPN-Dienst unter Verwendung des iked-Prozesses aus. Das Support-Paket junos-ike für Firewalls der SRX-Serie umfasst mehrere Versionen.
Weitere Informationen finden Sie im Abschnitt Zusätzliche Plattforminformationen für junos-ike die Paketunterstützung .
Sowohl der iked - als auch der ikemd-Prozess , der auf der Routing-Engine ausgeführt wird, sind mit dem junos-ike Paket verfügbar.
Verwenden Sie den folgenden Befehl, um das junos-ike Paket auf einer Firewall der SRX-Serie zu installieren:
user@host> request system software add optional://junos-ike.tgz Verified junos-ike signed by PackageProductionECP256_2022 method ECDSA256+SHA256 Rebuilding schema and Activating configuration... mgd: commit complete Restarting MGD ... WARNING: cli has been replaced by an updated version: CLI release 20220208.163814_builder.r1239105 built by builder on 2022-02-08 17:07:55 UTC Restart cli using the new version ? [yes,no] (yes)
Um den ikemd-Prozess in der Routine Engine neu zu starten, verwenden Sie den restart ike-config-management Befehl.
Um den iked-Prozess in der Routing-Engine neu zu starten, verwenden Sie den restart ike-key-management Befehl.
Das Missachten der angegebenen Junos OS-Releaseversionen bei der Installation des junos-ike Pakets kann dazu führen, dass nicht unterstützte Funktionen nicht wie erwartet funktionieren.
Führen Sie den request system software delete junos-ike Befehl aus,und starten Sie das Gerät neu, um IPsec-VPN-Funktionen mit dem veralteten kmd-Prozess auf Firewalls der SRX-Serie auszuführen.
Um das installierte junos-ike Paket zu überprüfen, verwenden Sie den folgenden Befehl:
user@host> show version | grep ike
JUNOS ike [20190617.180318_builder_junos_182_x41]
JUNOS ike [20190617.180318_builder_junos_182_x41]
{primary:node0}
IPsec-VPN-Funktionen, die von iked Process nicht unterstützt werden
Dieser Abschnitt enthält eine Zusammenfassung der IPsec-VPN-Funktionen, die von den Firewalls der SRX-Serie nicht unterstützt werden.
Tabelle 4 Fasst die nicht unterstützten IPsec-VPN-Funktionen der Firewalls der SRX-Serie und der virtuellen Firewall vSRX zusammen, die den iked-Prozessausführen.
|
Funktionen |
Support-Verfügbarkeit |
|---|---|
|
AutoVPN Protocol Independent Multicast (PIM) Punkt-zu-Multipunkt-Modus. |
Nein. Support ist jedoch für vSRX 3.0 verfügbar |
|
Konfigurieren der Weiterleitungsklasse auf IPsec-VPNs. |
Nein |
|
Gruppen-VPN. |
Nein |
|
Paketgrößenkonfiguration für die IPsec-Datenpfadüberprüfung. |
Nein |
|
Richtlinienbasiertes IPsec-VPN. |
Nein |
Unterstützung für kryptografische Beschleunigung
Lesen Sie den Abschnitt Plattformspezifisches kryptografisches Beschleunigungsverhalten , um Hinweise zu Ihrer Plattform zu erhalten.
Weitere Informationen finden Sie im Abschnitt Zusätzliche Plattforminformationen für die Unterstützung der kryptografischen Beschleunigung .
Junos OS unterstützt die Beschleunigung kryptografischer Vorgänge der Hardware-Kryptografie-Engine. Die Firewall der SRX-Serie kann kryptografische DH-, RSA- und ECDSA-Vorgänge an die Hardware-Kryptografie-Engine auslagern.
Mit dem Junos-ike-Paket führt die Firewall den IPsec-VPN-Dienst unter Verwendung des iked-Prozesses aus. Die Firewall benötigt den iked-Prozess als Software der Steuerungsebene, um erweiterte IPsec-VPN-Funktionen zu installieren und zu aktivieren. Als Ergebnis des Junos-ike-Pakets führt die Firewall standardmäßig den iked - und ikemd-Prozess auf der Routing-Engine anstelle des IPsec Key Management Daemon (kmd)aus.
Die Firewalls unterstützen Hardwarebeschleunigung für verschiedene Verschlüsselungen.
Siehe auch
Unterstützung von Routing-Protokollen in IPsec-VPN-Tunneln
Weitere Informationen finden Sie im Tabelle 12Abschnitt , Tabelle 13, Tabelle 14, Tabelle 15Tabelle 16, und Tabelle 17 im Abschnitt Zusätzliche Plattforminformationen .
Junos OS unterstützt Routing-Protokolle auf IPsec-VPN-Tunneln mit Firewalls der SRX-Serie und Routern der MX-Serie mit SPC3. Zu den unterstützten Protokollen gehören OSPF, BGP, PIM, RIP und BFD beim Ausführen des kmd- oder iked-Prozesses. Die Protokollunterstützung hängt von den folgenden Faktoren ab:
-
IP-Adressierungsschema: IPv4- oder IPv6-Adressen
-
Art der st0-Schnittstelle: Punkt-zu-Punkt (P2P) oder Punkt-zu-Mehrpunkt (P2MP)
Anti-Replay-Fenster
Plattformspezifisches Anti-Replay-Fensterverhalten Im Abschnitt finden Sie Hinweise zu Ihrer Plattform.
Bei Firewalls anti-replay-window der SRX-Serie ist standardmäßig mit einem Fenstergrößenwert von 64 aktiviert.
Um die Fenstergröße zu konfigurieren, verwenden Sie die neue anti-replay-window-size Option. Ein eingehendes Paket wird basierend auf dem anti-replay-window-size konfigurierten Wert für einen Replay-Angriff validiert.
Sie können auf zwei verschiedenen Ebenen konfigurieren replay-window-size :
-
Global level– Wird auf der Hierarchieebene [
edit security ipsec] konfiguriert.Zum Beispiel:
[edit security ipsec] user@host# set anti-replay-window-size <64..8192>;
-
VPN object– Wird auf der Hierarchieebene [
edit security ipsec vpn vpn-name ike] konfiguriert.Zum Beispiel:
[edit security ipsec vpn vpn-name ike] user@host# set anti-replay-window-size <64..8192>;
Wenn 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 Anti-Replay nicht konfiguriert ist, beträgt die Fenstergröße standardmäßig 64.
Um die Option für das Anti-Wiedergabe-Fenster für ein VPN-Objekt zu deaktivieren, verwenden Sie den set no-anti-replay Befehl auf der Hierarchieebene [edit security ipsec vpn vpn-name ike]. Sie können Anti-Replay nicht auf globaler Ebene deaktivieren.
Sie können nicht sowohl als auch anti-replay-window-sizeno-anti-replay für ein VPN-Objekt konfigurieren.
Siehe auch
Grundlegendes zu Hub-and-Spoke-VPNs
Wenn Sie zwei VPN-Tunnel erstellen, die an einem Gerät enden, können Sie ein Routenpaar so einrichten, dass das Gerät den Datenverkehr, der einen Tunnel verlässt, an den anderen Tunnel weiterleitet. Außerdem müssen Sie eine Richtlinie erstellen, damit der Datenverkehr von einem Tunnel zum anderen weitergeleitet werden kann. Eine solche Anordnung wird als Hub-and-Spoke-VPNbezeichnet. (Siehe Abbildung 4.)
Sie können auch mehrere VPNs konfigurieren und den Datenverkehr zwischen zwei beliebigen Tunneln weiterleiten.
Die Firewalls der SRX-Serie unterstützen nur die routenbasierte Hub-and-Spoke-Funktion.
Siehe auch
Plattformspezifisches IPsec-VPN-Verhalten
Verwenden Sie den Funktions-Explorer , um die Plattform- und Releaseunterstützung für bestimmte Features zu bestätigen.
Weitere Informationen finden Sie in diesem Zusätzliche Plattforminformationen Abschnitt.
Verwenden Sie die folgenden Tabellen, um das plattformspezifische Verhalten für Ihre Plattformen zu überprüfen.
- Plattformspezifische SPUs, VPN-Verarbeitungsverhalten
- Plattformspezifisches SRX5000-Line-SPC-Verhalten
- Plattformspezifisches kryptografisches Beschleunigungsverhalten
- Plattformspezifisches Anti-Replay-Fensterverhalten
Plattformspezifische SPUs, VPN-Verarbeitungsverhalten
| Plattform | Unterschied |
|---|---|
| SRX-Serie |
|
Plattformspezifisches SRX5000-Line-SPC-Verhalten
| Plattform | Unterschied |
|---|---|
| SRX-Serie |
|
Plattformspezifisches kryptografisches Beschleunigungsverhalten
| Plattform | Unterschied |
|---|---|
| SRX-Serie |
|
Plattformspezifisches Anti-Replay-Fensterverhalten
| Plattform | Unterschied |
|---|---|
| SRX-Serie |
|
Zusätzliche Plattforminformationen
Verwenden Sie den Funktions-Explorer , um die Plattform- und Releaseunterstützung für bestimmte Features zu bestätigen. Zusätzliche Plattformen können unterstützt werden.
| Unterstützter Prozess | SRX5000 Linie |
|---|---|
| IKED-Prozess |
Unterstützt zwei Optionen:
|
| KMD-Prozess |
|
junos-ike Paket |
SRX1500 | SRX1600SRX2300 | SRX4100SRX4200SRX4600 | SRX4300 | SRX4700 | SRX5000-Linie mit SPC3 | vSRX 3.0 |
|---|---|---|---|---|---|---|---|
| Vorgabe | 25.2R1 und höher | 23.4R1 und höher | 25.2R1 und höher | 24.2R1 und höher |
24.4R1 und höher |
19.4R1 und höher (für RE3) | 25.2R1 und höher |
| Optional | 22.3R1 und höher | n/z | 22.3R1 und höher | n/z | n/z | 18.2R1 und höher (für RE2) | 20.3R1 und höher |
| Chiffren | SRX1500 (KMD) | SRX1500 (iked) | SRX4100SRX4200(KMD) | SRX4100SRX4200(iked) | SRX4600(KMD) | SRX4600(iked) | SRX5000-Linie mit SPC3(iked) | vSRX 3.0(KMD) | vSRX 3.0(iked) |
|---|---|---|---|---|---|---|---|---|---|
| DH (Gruppen 1, 2, 5, 14) | Ja | Ja | Ja | Ja | Ja | Ja | Ja | Ja | Ja |
| DH (Gruppen 19, 20) | Nein | Ja | Nein | Ja | Nein | Ja | Ja | Ja | Ja |
| DH (Gruppen 15, 16) | Nein | Ja | Nein | Ja | Nein | Ja | Ja | Ja | Ja |
| DH Gruppe 21 | Nein | Ja | Nein | Ja | Nein | Ja | Ja | Ja | Ja |
| DH Gruppe 24 | Ja | Ja | Ja | Ja | Ja | Ja | Nein | Nein | Nein |
| RSA | Ja | Ja | Ja | Ja | Ja | Ja | Ja | Ja | Ja |
| ECDSA (256, 384, 521) | Nein | Ja | Nein | Ja | Nein | Ja | Ja | Ja | Ja |
|
OSPF für IPsec-VPN |
SRX300SRX320 SRX340SRX345SRX380 |
SRX550 HM |
SRX1500 |
SRX4100SRX4200SRX4600 |
SRX5000-Linie mit SPC3SRX5000-Linie mit SPC2 |
SRX5000-Leitung mit Mixed-Mode (SPC3+SPC2) |
vSRX 3.0 |
MX-SPC3 |
|
|---|---|---|---|---|---|---|---|---|---|
|
st0 in P2P |
Mit IPv4-Adresse |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
|
Mit IPv6-Adresse |
Nein |
Nein |
Nein |
Nein |
Nein |
Nein |
Nein |
Nein |
|
|
st0 in P2MP |
Mit IPv4-Adresse |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
|
Mit IPv6-Adresse |
Nein |
Nein |
Nein |
Nein |
Nein |
Nein |
Nein |
Nein |
|
|
OSPFv3 auf IPsec-VPN |
SRX300SRX320 SRX340SRX345SRX380 |
SRX550 HM |
SRX1500 |
SRX4100SRX4200SRX4600 |
SRX5000-Linie mit SPC3SRX5000-Linie mit SPC2 |
SRX5000-Leitung mit Mixed-Mode (SPC3+SPC2) |
vSRX 3.0 |
MX-SPC3 |
|
|---|---|---|---|---|---|---|---|---|---|
|
st0 in P2P |
Mit IPv4-Adresse |
Nein |
Nein |
Nein |
Nein |
Nein |
Nein |
Nein |
Nein |
|
Mit IPv6-Adresse |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
|
|
st0 in P2MP |
Mit IPv4-Adresse |
Nein |
Nein |
Nein |
Nein |
Nein |
Nein |
Nein |
Nein |
|
Mit IPv6-Adresse |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
|
|
BGP auf IPsec-VPN |
SRX300SRX320 SRX340SRX345SRX380 |
SRX550 HM |
SRX1500 |
SRX4100SRX4200SRX4600 |
SRX5000-Linie mit SPC3SRX5000-Linie mit SPC2 |
SRX5000-Leitung mit Mixed-Mode (SPC3+SPC2) |
vSRX 3.0 |
MX-SPC3 |
|
|---|---|---|---|---|---|---|---|---|---|
|
st0 in P2P |
Mit IPv4-Adresse |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
|
Mit IPv6-Adresse |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
|
|
st0 in P2MP |
Mit IPv4-Adresse |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Nein |
|
Mit IPv6-Adresse |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Nein |
|
|
PIM auf IPsec-VPN |
SRX300SRX320 SRX340SRX345SRX380 |
SRX550 HM |
SRX1500 |
SRX4100SRX4200SRX4600 |
SRX5000-Linie mit SPC3SRX5000-Linie mit SPC2 |
SRX5000-Leitung mit Mixed-Mode (SPC3+SPC2) |
vSRX 3.0 |
MX-SPC3 |
|
|---|---|---|---|---|---|---|---|---|---|
|
st0 in P2P |
Mit IPv4-Adresse |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
|
Mit IPv6-Adresse |
Nein |
Nein |
Nein |
Nein |
Nein |
Nein |
Nein |
Nein |
|
|
st0 in P2MP |
Mit IPv4-Adresse |
Ja |
Nein |
Ja |
Nein |
Nein |
Nein |
Ja. Multithread wird nicht unterstützt. |
Nein |
|
Mit IPv6-Adresse |
Nein |
Nein |
Nein |
Nein |
Nein |
Nein |
Nein |
Nein |
|
|
RIP-Protokoll für IPsec-VPN |
SRX300SRX320 SRX340SRX345SRX380 |
SRX550 HM |
SRX1500 |
SRX4100SRX4200SRX4600 |
SRX5000-Linie mit SPC3SRX5000-Linie mit SPC2 |
SRX5000-Leitung mit Mixed-Mode (SPC3+SPC2) |
vSRX 3.0 |
MX-SPC3 |
|
|---|---|---|---|---|---|---|---|---|---|
|
st0 in P2P |
Mit IPv4-Adresse |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
|
Mit IPv6-Adresse |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
|
|
st0 in P2MP |
Mit IPv4-Adresse |
Nein |
Nein |
Nein |
Nein |
Nein |
Nein |
Nein |
Nein |
|
Mit IPv6-Adresse |
Nein |
Nein |
Nein |
Nein |
Nein |
Nein |
Nein |
Nein |
|
|
BFD auf IPsec-VPN |
SRX300SRX320 SRX340SRX345SRX380 |
SRX550 HM |
SRX1500 |
SRX4100SRX4200SRX4600 |
SRX5000-Linie mit SPC3SRX5000-Linie mit SPC2 |
SRX5000-Leitung mit Mixed-Mode (SPC3+SPC2) |
vSRX 3.0 |
MX-SPC3 |
|
|---|---|---|---|---|---|---|---|---|---|
|
st0 in P2P |
Mit IPv4-Adresse |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
|
Mit IPv6-Adresse |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
|
|
st0 in P2MP |
Mit IPv4-Adresse |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Nein |
|
Mit IPv6-Adresse |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Nein |
|
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.
junos-ike wird das Paket in den Junos OS-Versionen 20.1R2, 20.2R2, 20.3R2, 20.4R1 und höher für SRX5000 Zeile mit RE3 installiert. iked Daher wird der ikemd Prozess standardmäßig auf der Routing-Engine und nicht auf dem IPsec Key Management Daemon (kmd) ausgeführt.