Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Internet Key Exchange (IKE) für IPsec VPN

Internet Key Exchange Version 2 (IKEv2) ist ein IPsec-basiertes Tunneling-Protokoll, das einen sicheren VPN-Kommunikationskanal zwischen Peer-VPN-Geräten bereitstellt und die Aushandlung und Authentifizierung für IPsec-Sicherheitszuordnungen (SAs) auf geschützte Weise definiert.

IKE- und IPsec-Paketverarbeitung

IKE bietet Tunnelmanagement für IPsec und authentifiziert End-Entitäten. 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.

IKE-Paketverarbeitung

Wenn ein Cleartext-Paket auf einem Gerät von Juniper Networks eintrifft, das Tunneling erfordert, und für den Tunnel keine aktive Phase 2-SA vorhanden ist, beginnt Junos OS die IKE-Verhandlungen und löscht das Paket. Die Quell- und Zieladressen im IP-Paket-Header sind jeweils die der lokalen und Remote-IKE-Gateways. Im IP-Paket-Payload ist ein UDP-Segment vorhanden, das ein ISAKMP (IKE)-Paket einkapselt. Das Format für IKE-Pakete ist für Phase 1 und Phase 2 gleich. Siehe Abbildung 1.

In der Zwischenzeit hat der Quellhost das verlorene Paket erneut gesendet. Wenn das zweite Paket eintrifft, sind die IKE-Verhandlungen normalerweise abgeschlossen, und Junos OS schützt das Paket und alle nachfolgenden Pakete in der Sitzung – mit IPsec, bevor es weitergeleitet wird.

Abbildung 1: IKE-Paket für die Phasen 1 und 2IKE-Paket für die Phasen 1 und 2

Das Feld Next Payload enthält eine Zahl, die einen der folgenden Payload-Typen angibt:

  • 0002: SA Negotiation Payload enthält eine Definition für eine Phase 1- oder Phase 2-SA.

  • 0004: Vorschlagsnutzlast kann ein Phase-1- oder Phase-2-Vorschlag sein.

  • 0008: Transform Payload wird in einer Vorschlagsnutzlast verkapselt, die in einer SA-Nutzlast verkapselt wird.

  • 0010– Key Exchange (KE) Payload enthält Informationen, die für die Durchführung eines Schlüsselaustauschs erforderlich sind, z. B. einen DH-öffentlichen Wert.

  • 0020 – Identifizierung (IDx) Nutzlast.

    • In Phase 1 gibt IDii die Initiator-ID an, und IDir gibt die Responder-ID an.

    • In Phase 2 gibt IDui den Benutzerinitiator an, und IDur gibt den Benutzer-Responder an.

    Die IDs sind IKE-ID-Typen wie FQDN, U-FQDN, IP-Adresse und ASN.1_DN.

  • 0040 – Payload des Zertifikats (CERT).

  • 0080 – Payload für Zertifikatsanforderung (CERT_REQ).

  • 0100– Hash (HASH) Payload enthält die Digest-Ausgabe einer bestimmten Hash-Funktion.

  • 0200– Signatur (SIG) Payload enthält eine digitale Signatur.

  • 0400– Nonce (Nx) Payload enthält einige Pseudorandom-Informationen, die für den Austausch erforderlich sind).

  • 0800 – Payload benachrichtigen.

  • 1000 – ISAKMP Löschen Sie Payload.

  • 2000: Die Payload der Vendor ID (VID) kann überall in Phase 1-Verhandlungen einbezogen werden. Junos OS verwendet es zur Kennzeichnung der Nat-T-Unterstützung.

Jeder ISAKMP-Payload beginnt mit demselben generischen Header wie in Abbildung 2.

Abbildung 2: Generischer ISAKMP-Payload-HeaderGenerischer ISAKMP-Payload-Header

Es können mehrere ISAKMP-Nutzlasten miteinander verkettet werden, wobei jeder nachfolgende Nutzlasttyp durch den Wert im Feld Next Header angegeben wird. Ein Wert von 0000 gibt die letzte ISAKMP-Nutzlast an. Ein Beispiel finden Sie Abbildung 3 hier.

Abbildung 3: ISAKMP-Header mit generischen ISAKMP-PayloadsISAKMP-Header mit generischen ISAKMP-Payloads

IPsec-Paketverarbeitung

Nachdem die IKE-Verhandlungen abgeschlossen sind und die beiden IKE-Gateways Phase-1- und Phase-2-Sicherheitszuordnungen (SAs) eingerichtet haben, werden alle nachfolgenden Pakete über den Tunnel weitergeleitet. Wenn die Phase 2 SA das Encapsulating Security Protocol (ESP) im Tunnelmodus angibt, sieht das Paket wie das in Abbildung 4dargestellte aus. Das Gerät fügt dem ursprünglichen Paket, das der initiierende Host sendet, zwei zusätzliche Header hinzu.

Wie in Abbildung 4dargestellt, umfasst das Paket, das die initiierenden Host-Konstrukte enthalten, den Payload, den TCP-Header und den inneren IP-Header (IP1).

Abbildung 4: IPsec-Paket – ESP im TunnelmodusIPsec-Paket – ESP im Tunnelmodus

Der Router-IP-Header (IP2), den Junos OS hinzufügt, enthält die IP-Adresse des Remote-Gateways als Ziel-IP-Adresse und die IP-Adresse des lokalen Routers als Quell-IP-Adresse. Junos OS fügt auch einen ESP-Header zwischen den äußeren und inneren IP-Headern hinzu. Der ESP-Header enthält Informationen, die es dem Remote-Peer ermöglichen, das Paket beim Empfang ordnungsgemäß zu verarbeiten. Dies wird in Abbildung 5dargestellt.

Abbildung 5: Äußerer IP-Header (IP2) und ESP-HeaderÄußerer IP-Header (IP2) und ESP-Header

Das Feld Next Header gibt den Typ der Daten im Payload-Feld an. Im Tunnelmodus beträgt dieser Wert 4, was angibt, dass ein IP-Paket innerhalb des Payloads enthalten ist. Siehe Abbildung 6.

Abbildung 6: Inner IP Header (IP1) und TCP-HeaderInner IP Header (IP1) und TCP-Header

Einführung in IKE in Junos OS

IKE bietet Möglichkeiten, Schlüssel für Verschlüsselung und Authentifizierung sicher über ein unbesichertes Medium wie das Internet auszutauschen. IKE ermöglicht ein Paar Sicherheits-Gateways für: Dynamische Einrichtung eines sicheren Tunnels, über den Sicherheitsgateways Tunnel und wichtige Informationen austauschen können. Einrichten von Tunneln oder SAs auf Benutzerebene, einschließlich Tunnelattributverhandlungen und Schlüsselverwaltung. Diese Tunnel können auch aktualisiert und auf demselben sicheren Kanal beendet werden. IKE nutzt Diffie-Hellman-Methoden und ist optional in IPsec (die gemeinsam genutzten Schlüssel können manuell an den Endpunkten eingegeben werden).

IKEv2 unterstützt:

  • Routenbasierte VPNs.

  • Standort-zu-Standort-VPNs.

  • Erkennung von toten Peers.

  • Gehäuse-Cluster.

  • Vorinstallierte Schlüsselauthentifizierung.

  • Zertifikatsbasierte Authentifizierung.

  • Kinder-SAs. Eine IKEv2-Kinder-SA ist in IKEv1 als Phase 2-SA bekannt. In IKEv2 kann eine untergeordnete SA ohne die zugrunde liegende IKE SA nicht existieren.

  • AutoVPN.

  • Dynamisches Endpunkt-VPN.

  • EAP wird für den Remotezugriff mit IKEv2 unterstützt.

  • Datenverkehrs-Selektoren.

IKEv2 unterstützt die folgenden Funktionen nicht:

  • Richtlinienbasiertes VPN.

  • VPN-Überwachung.

  • IP Payload Compression Protocol (IPComp).

Konfigurieren von IKEv2 in Junos OS

Ein VPN-Peer ist entweder als IKEv1 oder IKEv2 konfiguriert. Wenn ein Peer als IKEv2 konfiguriert ist, kann er nicht auf IKEv1 zurückgreifen, wenn sein Remote-Peer die IKEv1-Aushandlung einleite. Die Sicherheitsgeräte von Juniper Networks sind standardmäßig IKEv1-Peers.

Verwenden Sie die version v2-only Konfigurationsanweisung auf [edit security ike gateway gw-name] Hierarchieebene, um IKEv2 zu konfigurieren.

Die IKE-Version wird in der Ausgabe der Befehlszeilen- und show security ipsec security-associations Befehlszeilenbefehle show security ike security-associations angezeigt.

Geräte von Juniper Networks unterstützen bis zu vier Vorschläge für Phase-2-Verhandlungen, sodass Sie festlegen können, wie restriktiv eine Reihe von Tunnelparametern ist, die Sie akzeptieren. Junos OS bietet vordefinierte Standard-, kompatible und grundlegende Phase 2-Angebotssätze. Sie können auch benutzerdefinierte Phase-2-Vorschläge definieren.

Understanding IKEv2 Configuration Payload

Der Konfigurations-Payload ist eine Internet Key Exchange Version 2 (IKEv2)-Option, die angeboten wird, um Bereitstellungsinformationen von einem Responder an einen Initiator weiterzuverbreiten. IKEv2-Konfigurations-Payload wird nur mit routenbasierten VPNs unterstützt.

RFC 5996, Internet Key Exchange Protocol Version 2 (IKEv2) definiert 15 verschiedene Konfigurationsattribute, die vom Responder an den Initiator zurückgegeben werden können. Tabelle 1 beschreibt die auf Geräten der SRX-Serie unterstützten IKEv2-Konfigurationsattribute.

Tabelle 1: IKEv2-Konfigurationsattribute

Attributtyp

Wert

Beschreibung

Länge

INTERNAL_IP4_ADDRESS

1

Gibt eine Adresse im internen Netzwerk an. Es können mehrere interne Adressen angefordert werden. Der Responder kann bis zur Anzahl der angeforderten Adressen senden.

0 oder 4 Oktette

INTERNAL_IP4_NETMASK

2

Gibt den Netzmaskenwert des internen Netzwerks an. In den Anforderungs- und Antwortmeldungen ist nur ein Netzmaskenwert zulässig (z. B. 255.255.255.0), und er darf nur mit einem INTERNAL_IP4_ADDRESS-Attribut verwendet werden.

0 oder 4 Oktette

INTERNAL_IP4_DNS

3

Gibt eine Adresse eines DNS-Servers innerhalb des Netzwerks an. Es können mehrere DNS-Server angefordert werden. Der Responder kann mit null oder mehr DNS-Serverattributen reagieren.

0 oder 4 Oktette

INTERNAL_IP4_NBNS

4

Gibt eine Adresse eines NetBIOS Name Servers (NBNS), z. B. eines WINS-Servers, innerhalb des Netzwerks an. Es können mehrere NBNS-Server angefordert werden. Der Responder kann mit Zero- oder More NBNS-Serverattributen reagieren.

0 oder 4 Oktette

INTERNAL_IP6_ADDRESS

8

Gibt eine Adresse im internen Netzwerk an. Es können mehrere interne Adressen angefordert werden. Der Responder kann bis zur Anzahl der angeforderten Adressen senden.

0 oder 17 Oktette

INTERNAL_IP6_DNS

10

Gibt eine Adresse eines DNS-Servers innerhalb des Netzwerks an. Es können mehrere DNS-Server angefordert werden. Der Responder kann mit null oder mehr DNS-Serverattributen reagieren.

0 oder 16 Oktette

Damit der IKE-Responder dem Initiator Bereitstellungsinformationen zur Verfügung stellt, muss er die Informationen von einer angegebenen Quelle wie einem RADIUS-Server erwerben. Bereitstellungsinformationen können auch von einem DHCP-Server über einen RADIUS-Server zurückgegeben werden. Auf dem RADIUS-Server sollten die Benutzerinformationen kein Authentifizierungskennwort enthalten. Das RADIUS-Serverprofil ist über die aaa access-profile profile-name Konfiguration auf [edit security ike gateway gateway-name] Hierarchieebene an das IKE-Gateway gebunden.

Ausgehend von Junos OS Version 20.3R1 auf Geräten der SRX5000-Reihe mit SPC3 und vSRX, auf denen ein iked-Prozess ausgeführt wird, haben wir die IKEv2-Konfigurationsnutzlast auf Folgendes verbessert:

  • Unterstützung für den lokalen IPv4- und IPv6-Adresspool. Sie können einem Peer auch eine feste IP-Adresse zuweisen.

    Während der IKE-Einrichtung fordert der Initiator vom Responder eine IPv4-, IPv6-, DNS- oder WINS-Adresse an. Nachdem der Responder den Initiator erfolgreich authentifiziert hat, weist er entweder eine IP-Adresse von einem lokalen Adresspool oder über einen RADIUS-Server zu. Je nach Konfiguration wird diese IP-Adresse entweder jedes Mal dynamisch zugewiesen, wenn sich ein Peer verbindet oder als feste IP-Adresse zugewiesen wird. Wenn der RADIUS-Server mit einem gerahmten Pool reagiert, weist Junos OS eine IP-Adresse oder Informationen basierend auf der Konfiguration des entsprechenden lokalen Pools zu. Wenn Sie sowohl den lokalen Adresspool als auch den RADIUS-Server konfigurieren, hat die vom RADIUS-Server zugewiesene IP-Adresse Vorrang vor dem lokalen Pool. Wenn Sie den lokalen IP-Adresspool konfigurieren und der RADIUS-Server keine IP-Adresse zurückgegeben hat, weist der lokale Pool der Anfrage die IP-Adresse zu.

  • Zusätzliche Option, none eingeführt für authentication-order. Siehe Authentifizierungsreihenfolge (Zugriffsprofil).

  • RADIUS-Accounting start- und stop-Nachrichten informieren den Zustand des Tunnels oder des Peers zum RADIUS-Server. Diese Nachrichten können zu Verfolgungszwecken oder Benachrichtigungen an Subsysteme wie einen DHCP-Server verwendet werden.

    Stellen Sie sicher, dass der RADIUS-Server Accounting-Start- oder Stop-Nachrichten unterstützt. Stellen Sie außerdem sicher, dass sowohl die Geräte der SRX-Serie als auch der RADIUS-Server über die entsprechenden Einstellungen verfügen, um diese Nachrichten zu verfolgen.

  • Einführung der IPv6-Unterstützung ermöglicht Dual-Stack-Tunnel mit Konfigurations-Payload. Während des Anmeldevorgangs fordert IKE sowohl IPv4- als auch IPv6-Adressen an. AAA erlaubt die Anmeldung nur, wenn alle angeforderten Adressen erfolgreich zugewiesen wurden. IKE beendet die Aushandlung, wenn die angeforderte IP nicht zugewiesen wird.

In einem routenbasierten VPN werden sichere Tunnelschnittstellen (st0) entweder im Point-to-Multipoint- oder Point-to-Point-Modus betrieben. Die Adresszuweisung über den IKEv2-Konfigurations-Payload wird jetzt im Point-to-Multipoint- oder Point-to-Point-Modus unterstützt. Bei Punkt-zu-Multipoint-Schnittstellen müssen die Schnittstellen nummeriert werden, und die Adressen im Konfigurationsnutzlast INTERNAL_IP4_ADDRESS Attributtyp müssen im Subnetworkbereich der zugehörigen Point-to-Multipoint-Schnittstelle liegen.

Ab Junos OS Version 20.1R1 können Sie ein gemeinsames Kennwort für IKEv2-Konfigurations-Payload-Anfragen für eine IKE-Gateway-Konfiguration konfigurieren. Das gemeinsame Kennwort im Bereich von 1 bis 128 Zeichen ermöglicht es dem Administrator, ein gemeinsames Kennwort zu definieren. Dieses Kennwort wird zwischen dem Gerät der SRX-Serie und dem RADIUS-Server verwendet, wenn das Gerät der SRX-Serie im Auftrag eines Remote-IPsec-Peers eine IP-Adresse mit IKEv2-Konfigurationsnutzlast anfordert. Der RADIUS-Server gleicht die Anmeldeinformationen ab, bevor er dem Gerät der SRX-Serie IP-Informationen für die Konfigurationslastanforderung bereitstellt. Sie können das gemeinsame Kennwort mithilfe einer config-payload-password configured-password Konfigurationsanweisung auf [edit security ike gateway gateway-name aaa access-profile access-profile-name] Hierarchieebene konfigurieren.

Sowohl auf dem Gerät der SRX-Serie als auch auf dem RADIUS-Server muss das gleiche Kennwort konfiguriert sein, und der RADIUS-Server sollte so konfiguriert werden, dass er das Password Authentication Protocol (PAP) als Authentifizierungsprotokoll verwendet. Ohne dies wird die Tunneleinrichtung nicht erfolgreich sein.

Abbildung 7 zeigt einen typischen Workflow für eine IKEv2 Configuration Payload.

Abbildung 7: Typischer IKEv2-Konfigurations-Payload-Workflow Typischer IKEv2-Konfigurations-Payload-Workflow

Die IKEv2-Konfigurations-Payload-Funktion wird sowohl für Point-to-Multipoint Secure Tunnel (st0)-Schnittstellen als auch für Punkt-zu-Punkt-Schnittstellen unterstützt. Point-to-Multipoint-Schnittstellen müssen nummeriert werden, und die in der Konfigurationsnutzlast angegebenen Adressen müssen sich im Subnetworkbereich der zugehörigen Punkt-zu-Multipoint-Schnittstelle befinden.

Ab Junos OS Version 20.1R1 unterstützen wir die IKEv2-Konfigurations-Payload-Funktion mit Point-to-Point-Schnittstellen auf Geräten der SRX5000-Reihe und vSRX, auf denen iked ausgeführt wird.

Verstehen der Pico Cell-Bereitstellung

IKEv2-Konfigurationsnutzlast kann verwendet werden, um Bereitstellungsinformationen von einem IKE-Responder, z. B. einem Gerät der SRX-Serie, an mehrere Initiatoren wie LTE pico-Basisstationen in einem Mobilfunknetz weiterzuleiten. Die pico Zellen werden ab Werk mit einer Standardkonfiguration geliefert, mit der sie eine Verbindung zum Gerät der SRX-Serie herstellen können, aber die Pico-Zellenbereitstellungsinformationen werden auf einem oder mehreren Bereitstellungsservern in einem geschützten Netzwerk gespeichert. Die pico-Zellen erhalten vollständige Bereitstellungsinformationen, nachdem sie sichere Verbindungen mit den Bereitstellungsservern hergestellt haben.

Der Workflow, der für das Bootstraping und die Bereitstellung einer pico-Zelle und deren Einführung in den Service erforderlich ist, umfasst vier verschiedene Phasen:

  1. Initiale Adresserfassung: Die pico cell wird ab Werk mit folgenden Informationen geliefert:

    • Konfiguration des Secure Gateway Tunnel zum Gerät der SRX-Serie

    • Digitales Zertifikat des Herstellers

    • Vollständig qualifizierter Domänenname (FQDN) der Bereitstellungsserver, die innerhalb des geschützten Netzwerks liegen

    Die pico-Zelle startet und erwirbt eine Adresse, die für die IKE-Aushandlung von einem DHCP-Server verwendet werden soll. Über diese Adresse wird dann ein Tunnel zum Sicheren Gateway auf dem Gerät der SRX-Serie erstellt. Eine Adresse für OAM-Datenverkehr (Operation, Administration and Management) wird ebenfalls vom DHCP-Server für die Verwendung im geschützten Netzwerk zugewiesen.

  2. Pico Cell-Bereitstellung: Mithilfe der zugewiesenen OAM-Datenverkehrsadresse fordert die pico cell die Bereitstellungsinformationen von Servern innerhalb des geschützten Netzwerks an – in der Regel Betreiberzertifikate, Lizenzen, Software und Konfigurationsinformationen.

  3. Neustart: Die pico-Zelle startet neu und verwendet die erfassten Bereitstellungsinformationen, um sie spezifisch für das Netzwerk- und Betriebsmodell des Service Providers zu machen.

  4. Servicebereitstellung: Wenn die pico-Zelle den Dienst eingibt, verwendet sie ein einzelnes Zertifikat, das Distinguished Name (DN) und alternative Namenswerte mit einem FQDN enthält, um zwei Tunnel zum Secure Gateway auf dem Gerät der SRX-Serie zu erstellen: eine für OAM-Datenverkehr und die andere für den Datenverkehr des Third-Generation Partnership Project (3GPP).

IKE-Vorschlag

Die IKE-Konfiguration definiert die Algorithmen und Schlüssel, die zum Herstellen der sicheren IKE-Verbindung mit dem Peer-Sicherheitsgateway verwendet werden. Sie können mindestens einen IKE-Vorschlag konfigurieren. Jeder Vorschlag enthält eine Liste mit IKE-Attributen zum Schutz der IKE-Verbindung zwischen dem IKE-Host und seinem Peer.

Um einen IKE-Vorschlag zu konfigurieren, fügen Sie die proposal Anweisung ein und geben Sie einen Namen auf der [edit security ike ] Hierarchieebene an:

IKE-Richtlinie

Eine IKE-Richtlinie definiert eine Kombination von Sicherheitsparametern (IKE-Vorschläge), die während der IKE-Aushandlung verwendet werden sollen. Es definiert eine Peer-Adresse und die für diese Verbindung erforderlichen Vorschläge. Je nachdem, welche Authentifizierungsmethode verwendet wird, definiert es den Preshared-Schlüssel für den angegebenen Peer oder das lokale Zertifikat. Während der IKE-Verhandlung sucht IKE nach einer IKE-Richtlinie, die auf beiden Peers gleich ist. Der Peer, der die Aushandlung initiiert, sendet alle seine Richtlinien an den Remote-Peer, und der Remote-Peer versucht, eine Übereinstimmung zu finden. Eine Übereinstimmung wird durchgeführt, wenn beide Richtlinien von den beiden Peers einen Vorschlag haben, der die gleichen konfigurierten Attribute enthält. Wenn die Lebensdauern nicht identisch sind, wird die kürzere Lebensdauer zwischen den beiden Richtlinien (vom Host und vom Peer) verwendet. Der konfigurierte Preshared-Schlüssel muss auch seinem Peer entsprechen.

Erstens konfigurieren Sie einen oder mehrere IKE-Vorschläge; dann verknüpfen Sie diese Vorschläge mit einer IKE-Richtlinie.

Um eine IKE-Richtlinie zu konfigurieren, fügen Sie die policy Anweisung ein und geben Sie einen Richtliniennamen auf der [edit security ike] Hierarchieebene an:

Rekeying und Reauthentication

Überblick

Mit IKEv2 sind Rekeying und Reauthentication separate Prozesse. Rekeying erstellt neue Schlüssel für die IKE Security Association (SA) und setzt Nachrichten-ID-Zähler zurück, authentifiziert die Peers jedoch nicht erneut. Eine erneute Authentifizierung überprüft, ob VPN-Peers ihren Zugriff auf Authentifizierungsnachweise behalten. Die reauthentication erstellt neue Schlüssel für die IKE SA und untergeordnete SAs; Es werden keine weiteren Schlüssel für ausstehende IKE SA oder untergeordnete SA mehr benötigt. Nachdem die neuen IKE- und Untergeordneten-SAs erstellt wurden, werden die alten IKE- und untergeordneten SAs gelöscht.

IKEv2-Reauthentication ist standardmäßig deaktiviert. Sie aktivieren die erneute Authentifizierung, indem Sie einen Frequenzwert für die erneute Authentifizierung zwischen 1 und 100 konfigurieren. Die Häufigkeit der erneuten Authentifizierung ist die Anzahl der IKE-Rekeys, die vor der erneuten Authentifizierung auftritt. Wenn beispielsweise die konfigurierte Frequenz für die erneute Authentifizierung 1 ist, erfolgt jedes Mal, wenn ein IKE-Rekey vorhanden ist, eine erneute Authentifizierung. Wenn die konfigurierte Reauthentication-Frequenz 2 ist, erfolgt eine erneute Authentifizierung bei jedem anderen IKE-Rekey. Wenn die konfigurierte Authentifizierungshäufigkeit 3 beträgt, erfolgt die erneute Authentifizierung bei jedem dritten IKE-Rekey usw.

Sie konfigurieren die Frequenz für die erneute Authentifizierung mit der reauth-frequency Anweisung auf der [edit security ike policy policy-name] Hierarchieebene. Die Erneute Authentifizierung wird deaktiviert, indem die Frequenz für die erneute Authentifizierung auf 0 (Standard) festgelegt wird. Die Frequenz für die erneute Authentifizierung wird nicht von Peers ausgehandelt, und jeder Peer kann seinen eigenen Frequenzwert für die erneute Authentifizierung haben.

Unterstützte Funktionen

IKEv2-Reauthentication wird mit den folgenden Funktionen unterstützt:

  • IKEv2-Initiatoren oder Responder

  • Dead Peer Detection (DPD)

  • Virtuelle Router und sichere Tunnelschnittstellen (ST0) in virtuellen Routern

  • Network Address Translation Traversal (NAT-T)

  • Gehäuse-Cluster im Aktiv-Aktiv- und Aktiv-Passiv-Modus für SRX5400-, SRX5600- und SRX5800-Geräte

  • In-Service Software Upgrade (ISSU) auf SRX5400-, SRX5600- und SRX5800-Geräten

  • Upgrade oder Einfügen einer neuen Service Processing Unit (SPU) mithilfe des ISHU-Verfahrens (In-Service Hardware Upgrade)

Einschränkungen

Beachten Sie die folgenden Einschränkungen bei der Verwendung von IKEv2-Reauthentication:

  • Mit NAT-T kann eine neue IKE SA mit verschiedenen Ports von der vorherigen IKE SA erstellt werden. In diesem Szenario wird die alte IKE SA möglicherweise nicht gelöscht.

  • In einem NAT-T-Szenario kann der Initiator hinter dem NAT-Gerät nach der erneuten Authentifizierung zum Responder werden. Wenn die NAT-Sitzung abläuft, kann das NAT-Gerät neue IKE-Pakete verwerfen, die an einem anderen Port eintreffen könnten. NAT-T-Keepalive oder DPD müssen aktiviert sein, um die NAT-Sitzung am Leben zu halten. Für AutoVPN empfehlen wir, dass die auf den Spokes konfigurierte Reauthentication Frequency kleiner ist als die am Hub konfigurierte Reauthentication Frequency.

  • Basierend auf der Frequenz der Reauthentication kann eine neue IKE SA entweder vom Initiator oder vom Responder der ursprünglichen IKE SA initiiert werden. Da die Authentifizierung und Der Konfigurations-Payload des Extensible Authentication Protocol (EAP) die IKE SA von derselben Partei wie die ursprüngliche IKE SA initiieren muss, wird die erneute Authentifizierung nicht mit der EAP-Authentifizierung oder Konfigurationsnutzlast unterstützt.

IKE-Authentifizierung (zertifikatsbasierte Authentifizierung)

Mehrschichtige Hierarchie für die Zertifikatsauthentifizierung

Bei der zertifikatbasierten Authentifizierung handelt es sich um eine Authentifizierungsmethode, die auf Geräten der SRX-Serie während der IKE-Erkennung unterstützt wird. In großen Netzwerken können mehrere Zertifizierungsstellen (CAs) End-Entity-Zertifikate (EE) an ihre jeweiligen Endgeräte ausstellen. Es ist üblich, separate CAs für einzelne Standorte, Abteilungen oder Organisationen zu haben.

Wenn eine einstufige Hierarchie für die zertifikatsbasierte Authentifizierung eingesetzt wird, müssen alle EE-Zertifikate im Netzwerk von derselben Zertifizierungsstelle signiert werden. Alle Firewall-Geräte müssen über das gleiche CA-Zertifikat verfügen, das für die Peer-Zertifikatsvalidierung registriert ist. Die während der IKE-Aushandlung gesendete Zertifikatsnutzlast enthält nur EE-Zertifikate.

Alternativ kann der bei der IKE-Aushandlung gesendete Zertifikatsnutzlast eine Kette von EE- und CA-Zertifikaten enthalten. Eine Zertifikatskette ist die Liste der Zertifikate, die für die Validierung des EE-Zertifikats eines Peers erforderlich sind. Die Zertifikatskette umfasst das EE-Zertifikat und alle CA-Zertifikate, die nicht im lokalen Peer vorhanden sind.

Der Netzwerkadministrator muss sicherstellen, dass alle Peers, die an einer IKE-Verhandlung teilnehmen, mindestens eine gemeinsame vertrauenswürdige Zertifizierungsstelle in ihren jeweiligen Zertifikatsketten haben. Die gängige vertrauenswürdige CA muss nicht die Stamm-CA sein. Die Anzahl der Zertifikate in der Kette, einschließlich der Zertifikate für EEs und der obersten CA in der Kette, darf 10 nicht überschreiten.

Ab Junos OS Version 18.1R1 kann die Validierung eines konfigurierten IKE-Peers mit einem angegebenen CA-Server oder einer Gruppe von CA-Servern durchgeführt werden. Bei Zertifikatsketten muss die Stamm-CA mit der in der IKE-Richtlinie konfigurierten vertrauenswürdigen CA-Gruppe oder dem CA-Server übereinstimmen

In der in Abbildung 8root-CA dargestellten Beispielhierarchie ist Root-CA die gemeinsame vertrauenswürdige Zertifizierungsstelle für alle Geräte im Netzwerk. Root-CA gibt CA-Zertifikate an die Engineering- und Sales-CAs aus, die jeweils als Eng-CA bzw. Sales-CA identifiziert werden. Eng-CA gibt CA-Zertifikate an die Entwicklungs- und Qualitätssicherungs-CAs aus, die als Dev-CA bzw. Qa-CA identifiziert werden. Host-A erhält sein EE-Zertifikat von Dev-CA, Host-B erhält sein EE-Zertifikat von Sales-CA.

Abbildung 8: Mehrebenenhierarchie für zertifikatsbasierte AuthentifizierungMehrebenenhierarchie für zertifikatsbasierte Authentifizierung

Jedes Endgerät muss in seiner Hierarchie mit den CA-Zertifikaten geladen werden. Host-A muss über Root-CA-, Eng-CA- und Dev-CA-Zertifikate verfügen; Vertriebs-CA- und Qa-CA-Zertifikate sind nicht erforderlich. Host-B muss über Root-CA- und Sales-CA-Zertifikate verfügen. Zertifikate können manuell auf einem Gerät geladen oder mithilfe des Simple Certificate Enrollment Process (SCEP) registriert werden.

Jedes Endgerät muss mit einem CA-Profil für jede CA in der Zertifikatskette konfiguriert werden. Die folgende Ausgabe zeigt die auf Host-A konfigurierten CA-Profile:

Die folgende Ausgabe zeigt die auf Host-B konfigurierten CA-Profile:

Beispiel: Konfigurieren eines Geräts für die Validierung der Peer-Zertifikatskette

In diesem Beispiel wird gezeigt, wie ein Gerät für Zertifikatsketten konfiguriert wird, die verwendet werden, um Peer-Geräte während der IKE-Erkennung zu validieren.

Anforderungen

Bevor Sie beginnen, erhalten Sie die Adresse der Zertifizierungsstelle und die erforderlichen Informationen (z. B. das Challenge-Kennwort), wenn Sie Anfragen nach lokalen Zertifikaten stellen.

Überblick

Dieses Beispiel zeigt, wie Sie ein lokales Gerät für Zertifikatsketten konfigurieren, CA- und lokale Zertifikate registrieren, die Gültigkeit der registrierten Zertifikate prüfen und den Widerrufsstatus des Peer-Geräts überprüfen.

Topologie

Dieses Beispiel zeigt die Konfigurations- und Betriebsbefehle auf Host-A, wie in Abbildung 9dargestellt. Auf Host-A wird automatisch ein dynamisches CA-Profil erstellt, damit Host-A die CRL von Sales-CA herunterladen und den Widerrufsstatus des Host-B-Zertifikats prüfen kann.

Abbildung 9: Beispiel für die ZertifikatsketteBeispiel für die Zertifikatskette

Die IPSec-VPN-Konfiguration für die Phase 1- und Phase 2-Aushandlung wird für Host-A in diesem Beispiel dargestellt. Das Peer-Gerät (Host-B) muss ordnungsgemäß konfiguriert sein, damit die Optionen Phase 1 und Phase 2 erfolgreich ausgehandelt und Sicherheitszuordnungen (SAs) eingerichtet werden. Beispiele zur Konfiguration von Peer-Geräten für VPNs finden Sie unter Konfigurieren von Remote-IKE-IDs für Site-to-Site-VPNs .

Konfiguration

So konfigurieren Sie ein Gerät für Zertifikatsketten:

Ca-Profile konfigurieren

CLI-Schnellkonfiguration

Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für die Netzwerkkonfiguration erforderlich sind, kopieren Und fügen Sie die Befehle auf Hierarchieebene in die [edit] CLI ein und geben Sie dann aus dem Konfigurationsmodus ein commit .

Schritt-für-Schritt-Verfahren

Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Anweisungen dazu finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI-Benutzerhandbuch.

So konfigurieren Sie CA-Profile:

  1. Erstellen Sie das CA-Profil für Root-CA.

  2. Erstellen Sie das CA-Profil für Eng-CA.

  3. Erstellen Sie das CA-Profil für Dev-CA.

Ergebnisse

Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie den show security pki Befehl eingeben. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, wiederholen Sie die Konfigurationsanweisungen in diesem Beispiel, um sie zu korrigieren.

Wenn Sie die Konfiguration des Geräts durchgeführt haben, geben Sie aus dem Konfigurationsmodus ein commit .

Zertifikate registrieren

Schritt-für-Schritt-Verfahren

So registrieren Sie Zertifikate:

  1. Registrieren Sie die CA-Zertifikate.

    Geben Sie yes die Eingabeaufforderungen ein, um das CA-Zertifikat zu laden.

  2. Vergewissern Sie sich, dass die CA-Zertifikate auf dem Gerät registriert sind.

  3. Überprüfen Sie die Gültigkeit der registrierten CA-Zertifikate.

  4. Ein Schlüsselpaar generieren.

  5. Lokales Zertifikat registrieren.

  6. Vergewissern Sie sich, dass das lokale Zertifikat auf dem Gerät registriert ist.

  7. Überprüfen Sie die Gültigkeit des registrierten lokalen Zertifikats.

  8. Überprüfen Sie den CRL-Download für konfigurierte CA-Profile.

IPsec-VPN-Optionen konfigurieren

CLI-Schnellkonfiguration

Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für die Netzwerkkonfiguration erforderlich sind, kopieren Und fügen Sie die Befehle auf Hierarchieebene in die [edit] CLI ein und geben Sie dann aus dem Konfigurationsmodus ein commit .

Schritt-für-Schritt-Verfahren

Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Anweisungen dazu finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI-Benutzerhandbuch.

So konfigurieren Sie IPsec-VPN-Optionen:

  1. Konfiguration von Phase 1-Optionen.

  2. Konfiguration von Phase 2-Optionen.

Ergebnisse

Bestätigen Sie ihre Konfiguration vom Konfigurationsmodus aus, indem Sie die Befehle und show security ipsec die Befehle show security ike eingeben. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, wiederholen Sie die Konfigurationsanweisungen in diesem Beispiel, um sie zu korrigieren.

Wenn Sie die Konfiguration des Geräts durchgeführt haben, geben Sie aus dem Konfigurationsmodus ein commit .

Überprüfung

Wenn die Zertifikatsvalidierung während der IKE-Aushandlung zwischen Peer-Geräten erfolgreich ist, werden sowohl IKE- als auch IPsec-Sicherheitszuordnungen (SAs) eingerichtet.

Die IKE SA ist UP, wenn das Zertifikat gültig ist. Die IKE SA ist DOWN und IPSEC SA wird gebildet, wenn das Zertifikat widerrufen wird, nur wenn die Widerrufsprüfung auf dem Peer-Gerät konfiguriert ist

Überprüfung des IKE Phase 1-Status

Zweck

Überprüfen Sie den IKE Phase 1-Status.

Aktion

Geben Sie den Befehl aus dem show security ike security-associations Betriebsmodus ein.

Überprüfen des IPsec Phase 2-Status

Zweck

Überprüfen Sie den IPsec Phase 2-Status.

Aktion

Geben Sie den Befehl aus dem show security ipsec security-associations Betriebsmodus ein.

IKE- und IPsec SA-Fehler für ein widerrufenes Zertifikat

Überprüfung auf widerrufene Zertifikate

Problem

Wenn die Zertifikatvalidierung während der IKE-Aushandlung zwischen Peer-Geräten fehlschlägt, vergewissern Sie sich, dass das Zertifikat des Peers nicht widerrufen wurde. Ein dynamisches CA-Profil ermöglicht es dem lokalen Gerät, die CRL aus der Zertifizierungsstelle des Peers herunterzuladen und den Widerrufsstatus des Peer-Zertifikats zu überprüfen. Um dynamische CA-Profile zu aktivieren, muss die revocation-check crl Option auf einem übergeordneten CA-Profil konfiguriert werden.

Lösung

Zur Prüfung des Widerrufsstatus eines Peer-Zertifikats:

  1. Identifizieren Sie das dynamische CA-Profil, das die CRL für das Peer-Gerät anzeigen wird, indem Sie den Befehl aus dem show security pki crl Betriebsmodus eingeben.

    Das CA-Profil dynamic-001 wird automatisch auf Host-A erstellt, sodass Host-A die CRL von Host-B's CA (Sales-CA) herunterladen und den Widerrufsstatus des Peer-Zertifikats prüfen kann.

  2. Zeigen Sie CRL-Informationen für das dynamische CA-Profil an, indem Sie den Befehl aus dem show security pki crl ca-profile dynamic-001 detail Betriebsmodus eingeben.

    Eingabe

    Das Zertifikat von Host-B (Seriennummer 10647084) wurde widerrufen.

IKEv2 Fragmentierung

Nachrichtenfragmentierung

IKEv2 Nachrichtenfragmentierung, wie in RFC 7383 beschrieben, Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation, ermöglicht IKEv2 den Betrieb in Umgebungen, in denen IP-Fragmente blockiert werden könnten und Peers keine IPsec-Sicherheitszuordnung (IPsec Security Association, SA) aufbauen könnten. Die IKEv2-Fragmentierung unterteilt eine große IKEv2-Nachricht in eine Reihe kleinerer Nachrichten, sodass es keine Fragmentierung auf IP-Ebene gibt. Die Fragmentierung erfolgt, bevor die ursprüngliche Nachricht verschlüsselt und authentifiziert wird, sodass jedes Fragment separat verschlüsselt und authentifiziert wird. Auf dem Empfänger werden die Fragmente erfasst, verifiziert, entschlüsselt und in der ursprünglichen Nachricht zusammengeführt.

Damit die IKEv2-Fragmentierung auftritt, müssen beide VPN-Peers die Fragmentierungsunterstützung angeben, indem sie die IKEV2_FRAGMENTATION_SUPPORTED Benachrichtigungsnutzlast in den IKE_SA_INIT-Austausch einbeziehen. Wenn beide Peers auf Fragmentierungsunterstützung hinweisen, müssen der Initiator des Nachrichtenaustauschs bestimmen, ob IKEv2-Fragmentierung verwendet wird oder nicht.

Auf Geräten der SRX-Serie sind pro IKEv2-Nachricht maximal 32 Fragmente zulässig. Wenn die Anzahl der gesendeten oder empfangenen IKEv2-Nachrichtenfragmente 32 überschreitet, werden die Fragmente abgebrochen und der Tunnel wird nicht festgelegt. Eine erneute Übertragung einzelner Nachrichtenfragmente wird nicht unterstützt.

Konfiguration

Auf Geräten der SRX-Serie ist die IKEv2-Fragmentierung standardmäßig für IPv4- und IPv6-Nachrichten aktiviert. Um die IKEv2-Fragmentierung zu deaktivieren, verwenden Sie die disable Anweisung auf der [edit security ike gateway gateway-name fragmentation] Hierarchieebene. Sie können die size Anweisung auch verwenden, um die Paketgröße zu konfigurieren, bei der Nachrichten fragmentiert sind; die Paketgröße liegt zwischen 500 und 1300 Bytes. Wenn size sie nicht konfiguriert ist, beträgt die Standardpaketgröße 576 Bytes für IPv4-Datenverkehr und 1280 Bytes für IPv6-Datenverkehr. Ein IKEv2-Paket, das größer als die konfigurierte Paketgröße ist, ist fragmentiert.

Nachdem die IKEv2-Fragmentierung deaktiviert oder aktiviert ist oder die Paketfragmentgröße geändert wurde, werden die VPN-Tunnel, die auf dem IKE-Gateway gehostet werden, heruntergefahren und IKE- und IPsec-SAs neu verhandelt.

Vorbehalte

Die folgenden Funktionen werden mit IKEv2-Fragmentierung nicht unterstützt:

  • Pfad-MTU-Erkennung.

  • SNMP.

IKE-Richtlinie mit einer vertrauenswürdigen CA

Dieses Beispiel zeigt, wie ein vertrauenswürdiger CA-Server an eine IKE-Richtlinie des Peers gebunden wird.

Bevor Sie beginnen, müssen Sie eine Liste aller vertrauenswürdigen CAs haben, die Sie mit der IKE-Richtlinie des Peers zuordnen möchten.

Sie können eine IKE-Richtlinie einem vertrauenswürdigen CA-Profil oder einer vertrauenswürdigen CA-Gruppe zuordnen. Zum Herstellen einer sicheren Verbindung verwendet das IKE-Gateway die IKE-Richtlinie, um sich auf die konfigurierte Gruppe von CAs (CA-Profilen) zu beschränken und gleichzeitig das Zertifikat zu validieren. Ein Zertifikat, das von einer anderen Quelle als der vertrauenswürdigen CA oder vertrauenswürdigen CA-Gruppe ausgestellt wurde, wird nicht validiert. Wenn eine Zertifikatsvalidierungsanforderung von einer IKE-Richtlinie stammt, validiert das zugehörige CA-Profil der IKE-Richtlinie das Zertifikat. Wenn eine IKE-Richtlinie nicht mit einer CA verknüpft ist, wird das Zertifikat standardmäßig von einem der konfigurierten CA-Profile validiert.

In diesem Beispiel wird ein CA-Profil mit dem Namen root-ca erstellt und einem root-ca-identity Profil zugeordnet.

Sie können maximal 20 CA-Profile konfigurieren, die Sie einer vertrauenswürdigen CA-Gruppe hinzufügen möchten. Sie können ihre Konfiguration nicht bestätigen, wenn Sie mehr als 20 CA-Profile in einer vertrauenswürdigen CA-Gruppe konfigurieren.

  1. Erstellen Sie ein CA-Profil und verknüpfen Sie dem Profil eine CA-Kennung.
  2. Definieren Sie einen IKE-Vorschlag und die Authentifizierungsmethode für IKE-Vorschläge.
  3. Beschreiben Sie die Diffie-Hellman-Gruppe, den Authentifizierungsalgorithmus, einen Verschlüsselungsalgorithmus für den IKE-Vorschlag.
  4. Konfigurieren Sie eine IKE-Richtlinie und verknüpfen Sie die Richtlinie mit dem IKE-Vorschlag.
  5. Konfigurieren Sie eine lokale Zertifikatskennung für die IKE-Richtlinie.
  6. Definieren Sie die CA, die für die IKE-Richtlinie verwendet werden soll.

Führen Sie zum Anzeigen der CA-Profile und der auf Ihrem Gerät konfigurierten vertrauenswürdigen CA-Gruppen einen Befehl aus show security pki .

Der show security ike Befehl zeigt die CA-Profilgruppe unter der IKE-Richtlinie mit dem Namen ike_policy und das der IKE-Richtlinie zugeordnete Zertifikat an.

Konfiguration nur für Denktunnel-Responder in IKE

In diesem Thema wird gezeigt, wie Sie die Einrichtung von Tunneln nur in Internet Key Exchange (IKE) konfigurieren. Initiieren Sie die Tunnel vom Remote-Peer und senden Sie den Datenverkehr durch alle Tunnel. Gibt an, wann IKE aktiviert ist.

Ab Junos OS Version 19.1R1 auf Geräten der SRX5000-Reihe unterstützt die Einrichtungs-Tunneloption die Werte und responder-only-no-rekey die responder-only Werte unter der [edit security ipsec vpn vpn-name] Hierarchieebene.

Die responder-only Und responder-only-no-rekey Optionen werden auf den Geräten der SRX5000-Reihe nur mit einer SPC3-Karte unterstützt, wenn diese junos-ike-package installiert ist. Diese Optionen werden nur auf einem Site-to-Site-VPN unterstützt. Diese Option wird auf Auto-VPN nicht unterstützt.

Die responder-only und responder-only-no-rekey die Optionen stellen keine VPN-Tunnel vom Gerät her her, daher wird der VPN-Tunnel vom Remote-Peer initiiert. Bei der Konfiguration responder-onlysetzt ein etablierter Tunnel sowohl IKE als auch IPsec basierend auf den konfigurierten IKE- und IPsec-Lebenszeitwerten um. Bei der Konfiguration responder-only-no-rekeywird ein etablierter Tunnel nicht vom Gerät wieder schlüsselt und verlässt sich auf den Remote-Peer, um einen erneuten Schlüssel zu initiieren. Wenn der Remote-Peer keine erneute Schlüsselung einleite, erfolgt der Tunnel-Teardown nach Ablauf der harten Lebensdauer.

Bevor Sie beginnen:

  • Erfahren Sie, wie Sie einen AutoKey IKE IPsec-Tunnel einrichten. Lesen Sie IPsec-Übersicht.

So konfigurieren Sie "Establish-Tunnel Responder-only" in IKE:

  1. Nur Einrichtungstunnel-Responder konfigurieren
  2. Bestätigen Sie Ihre Konfiguration, indem Sie den show security ipsec vpn IPSEC_VPN Befehl eingeben.
  3. Konfigurieren sie den "Establish Tunnel Responder-only-no-rekey"
  4. Bestätigen Sie Ihre Konfiguration, indem Sie den show security ipsec vpn IPSEC_VPN Befehl eingeben.

    Bei mehreren VPN-Objekten hat der ausschließliche Responder-Modus Vorrang. Wenn ein VPN in einem Gateway mit dem responder-only-Modus konfiguriert ist, müssen alle VPN im Gateway mit dem responder-only-Modus konfiguriert werden.

Release-Verlaufstabelle
Release
Beschreibung
18.1R1
Ab Junos OS Version 18.1R1 kann die Validierung eines konfigurierten IKE-Peers mit einem angegebenen CA-Server oder einer Gruppe von CA-Servern durchgeführt werden.