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 (Security Associations, SAs) auf geschützte Weise definiert.
IKE- und IPsec-Paketverarbeitung
IKE bietet 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.
IKE-Paketverarbeitung
Wenn ein Klartextpaket auf einem Gerät von Juniper Networks eintrifft, für das Tunneling erforderlich ist, und für diesen Tunnel keine aktive Phase-2-Sicherheitszuordnung vorhanden ist, beginnt Junos OS mit den IKE-Verhandlungen und verwirft das Paket. Die Quell- und Zieladressen im IP-Paket-Header sind die des lokalen bzw. des Remote-IKE-Gateways. In der IP-Paketnutzlast gibt es ein UDP-Segment, das ein ISAKMP (IKE)-Paket kapselt. Das Format für IKE-Pakete ist für Phase 1 und Phase 2 identisch. Siehe Abbildung 1.
In der Zwischenzeit hat der Quellhost das verworfene Paket erneut gesendet. In der Regel sind die IKE-Verhandlungen abgeschlossen, wenn das zweite Paket eintrifft, und Junos OS schützt das Paket und alle nachfolgenden Pakete in der Sitzung mit IPsec, bevor es weitergeleitet wird.
Das Feld "Nächste Nutzlast" enthält eine Zahl, die einen der folgenden Nutzlasttypen angibt:
-
0002 – Die SA-Aushandlungsnutzlast enthält eine Definition für eine SA der Phase 1 oder Phase 2.
-
0004 – Bei der Angebotsnutzlast kann es sich um einen Vorschlag der Phase 1 oder Phase 2 handeln.
-
0008—Die Transformationsnutzlast wird in eine Vorschlagsnutzlast gekapselt, die wiederum in eine SA-Nutzlast gekapselt wird.
-
0010 – Die Payload "Key Exchange" (KE) enthält Informationen, die für die Durchführung eines Schlüsselaustauschs erforderlich sind, z. B. einen öffentlichen DH-Wert.
-
0020 – Identifikationsnutzlast (IDx).
-
In Phase 1 gibt IDii die Initiator-ID und IDir die Responder-ID an.
-
In Phase 2 gibt IDui den Benutzerinitiator und IDur den Benutzer-Responder an.
Bei den IDs handelt es sich um IKE-ID-Typen wie FQDN, U-FQDN, IP-Adresse und ASN.1_DN.
-
-
0040 – Payload "Zertifikat (CERT)".
-
0080 – Nutzlast für Zertifikatsanforderungen (CERT_REQ).
-
0100 – Die Hash-Nutzlast (HASH) enthält die Digest-Ausgabe einer bestimmten Hash-Funktion.
-
0200 – Die Signatur-Nutzlast (SIG) enthält eine digitale Signatur.
-
0400 – Die Nutzlast "Nonce (Nx)" enthält einige pseudozufällige Informationen, die für den Austausch erforderlich sind.
-
0800 – Nutzlast benachrichtigen.
-
1000 – ISAKMP Payload löschen.
-
2000 – Die Nutzlast der Anbieter-ID (VID) kann an beliebiger Stelle in die Verhandlungen der Phase 1 einbezogen werden. Junos OS verwendet es, um die Unterstützung für NAT-T zu kennzeichnen.
Jede ISAKMP-Nutzlast beginnt mit demselben generischen Header, wie in gezeigt.Abbildung 2
Es können mehrere ISAKMP-Nutzlasten miteinander verkettet sein, wobei jeder nachfolgende Nutzlasttyp durch den Wert im Feld Nächster Header angegeben wird. Der Wert von gibt die letzte ISAKMP-Nutzlast an.0000 Siehe für ein Beispiel.Abbildung 3
IPsec-Paketverarbeitung
Nachdem die IKE-Verhandlungen abgeschlossen sind und die beiden IKE-Gateways Sicherheitszuordnungen (SAs) der Phasen 1 und 2 eingerichtet haben, werden alle nachfolgenden Pakete über den Tunnel weitergeleitet. Wenn die Phase-2-Sicherheitszuordnung das Encapsulating Security Protocol (ESP) im Tunnelmodus angibt, sieht das Paket wie in gezeigt aus.Abbildung 4 Das Gerät fügt dem ursprünglichen Paket, das der initiierende Host sendet, zwei zusätzliche Header hinzu.
Wie in gezeigt, enthält das Paket, das der initiierende Host erstellt, die Nutzlast, den TCP-Header und den inneren IP-Header (IP1).Abbildung 4
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 außerdem einen ESP-Header zwischen dem äußeren und dem inneren IP-Header hinzu. Der ESP-Header enthält Informationen, die es dem Remote-Peer ermöglichen, das Paket ordnungsgemäß zu verarbeiten, wenn er es empfängt. Dies wird in gezeigt.Abbildung 5
Das Feld "Nächste Kopfzeile" gibt den Datentyp im Nutzlastfeld an. Im Tunnelmodus ist dieser Wert 4, was darauf hinweist, dass ein IP-Paket in der Nutzlast enthalten ist. Siehe .Abbildung 6
Einführung in IKE in Junos OS
IKE bietet Möglichkeiten zum sicheren Austausch von Schlüsseln für die Verschlüsselung und Authentifizierung über ein ungesichertes Medium wie das Internet. IKE ermöglicht zwei Sicherheits-Gateways für Folgendes: Richten Sie dynamisch einen sicheren Tunnel ein, über den Sicherheits-Gateways Tunnel- und Schlüsselinformationen austauschen können. Richten Sie Tunnel oder SAs auf Benutzerebene ein, einschließlich Tunnelattributverhandlungen und Schlüsselverwaltung. Diese Tunnel können auch auf demselben sicheren Kanal aktualisiert und beendet werden. IKE verwendet Diffie-Hellman-Methoden und ist in IPsec optional (die gemeinsam genutzten Schlüssel können manuell an den Endpunkten eingegeben werden).
IKEv2 bietet Unterstützung für:
Routenbasierte VPNs.
Site-to-Site-VPNs.
Erkennung toter Peers.
Chassis-Cluster.
Authentifizierung mit vorinstalliertem Schlüssel.
Zertifikatsbasierte Authentifizierung.
Untergeordnete Sicherheitszuordnungen. Eine untergeordnete IKEv2-Sicherheitszuordnung wird in IKEv1 als Phase-2-Sicherheitszuordnung bezeichnet. In IKEv2 kann eine untergeordnete Sicherheitszuordnung nicht ohne die zugrunde liegende IKE-Sicherheitszuordnung vorhanden sein.
AutoVPN.
Dynamisches Endpunkt-VPN.
EAP wird für den Remotezugriff mit IKEv2 unterstützt.
Traffic-Selektoren.
IKEv2 unterstützt die folgenden Funktionen nicht:
Richtlinienbasiertes VPN.
VPN-Überwachung.
IP Payload Compression Protocol (IPComp).
- Konfigurieren von IKEv2 in Junos OS
- Grundlegendes zur Nutzlast der IKEv2-Konfiguration
- Grundlegendes zur Bereitstellung von Pico-Zellen
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 Remotepeer die IKEv1-Aushandlung initiiert. Standardmäßig sind Sicherheitsgeräte von Juniper Networks IKEv1-Peers.
Verwenden Sie die configuration-Anweisung auf der Hierarchieebene [], um IKEv2 zu konfigurieren.version v2-only
edit security ike gateway gw-name
Die IKE-Version wird in der Ausgabe des Befehls und des CLI-Befehls angezeigt.show security ike security-associations
show security ipsec security-associations
Geräte von Juniper Networks unterstützen bis zu vier Vorschläge für Phase-2-Aushandlungen, sodass Sie festlegen können, wie restriktiv ein Bereich von Tunnelparametern ist, den Sie akzeptieren. Junos OS bietet vordefinierte standardmäßige, kompatible und grundlegende Phase-2-Vorschlagssätze. Sie können auch benutzerdefinierte Phase-2-Vorschläge definieren.
Grundlegendes zur Nutzlast der IKEv2-Konfiguration
Bei der Konfigurationsnutzlast handelt es sich um eine IKEv2-Option (Internet Key Exchange Version 2), die angeboten wird, um Bereitstellungsinformationen von einem Responder an einen Initiator weiterzugeben. Die IKEv2-Konfigurationsnutzlast 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. beschreibt die IKEv2-Konfigurationsattribute, die von Firewalls der SRX-Serie unterstützt werden.Tabelle 1
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 zu der Anzahl der angeforderten Adressen senden. |
0 oder 4 Oktette |
INTERNAL_IP4_NETMASK |
2 |
Gibt den Netzmaskenwert des internen Netzwerks an. In den Anforderungs- und Antwortnachrichten 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 die 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 antworten. |
0 oder 4 Oktette |
INTERNAL_IP4_NBNS |
4 |
Gibt die Adresse eines NetBIOS-Namenservers (NBNS), z. B. eines WINS-Servers, innerhalb des Netzwerks an. Es können mehrere NBNS-Server angefordert werden. Der Responder kann mit null oder mehr NBNS-Serverattributen antworten. |
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 zu der Anzahl der angeforderten Adressen senden. |
0 oder 17 Oktette |
INTERNAL_IP6_DNS |
10 |
Gibt die 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 antworten. |
0 oder 16 Oktette |
Damit der IKE-Responder dem Initiator Bereitstellungsinformationen zur Verfügung stellen kann, muss er die Informationen aus einer angegebenen Quelle abrufen, z. B. einem RADIUS-Server. 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 wird mithilfe der Konfiguration auf der Hierarchieebene [] an das IKE-Gateway gebunden.aaa access-profile profile-name
edit security ike gateway gateway-name
Beginnend mit Junos OS Version 20.3R1 haben wir auf SRX5000 Linie mit SPC3 und der virtuellen vSRX-Firewall, auf denen iked-Prozesse ausgeführt werden, die IKEv2-Konfigurationsnutzlast wie folgt 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 eine IPv4-Adresse, IPv6-Adresse, DNS-Adresse oder WINS-Adresse vom Responder an. Nachdem der Responder den Initiator erfolgreich authentifiziert hat, weist er eine IP-Adresse entweder aus einem lokalen Adresspool oder über einen RADIUS-Server zu. Je nach Konfiguration wird diese IP-Adresse entweder jedes Mal dynamisch zugewiesen, wenn ein Peer eine Verbindung herstellt, oder als feste IP-Adresse zugewiesen. Wenn der RADIUS-Server mit einem gerahmten Pool antwortet, weist Junos OS eine IP-Adresse oder Informationen basierend auf der Konfiguration aus dem entsprechenden lokalen Pool 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 Anforderung die IP-Adresse zu.
-
Zusätzliche Option, eingeführt für .
none
authentication-order
Weitere Informationen finden Sie unter Authentifizierungsreihenfolge (Zugriffsprofil).authentication-order (Access Profile) -
Start- und Stoppmeldungen der RADIUS-Kontorechnung informieren über den Status des Tunnels oder Peers zum RADIUS-Server. Diese Nachrichten können für Nachverfolgungszwecke oder Benachrichtigungen an Subsysteme wie einen DHCP-Server verwendet werden.
Stellen Sie sicher, dass der RADIUS-Server Start- oder Stoppmeldungen für das Accounting unterstützt. Stellen Sie außerdem sicher, dass sowohl die Firewalls der SRX-Serie als auch der RADIUS-Server über geeignete Einstellungen verfügen, um diese Meldungen zu verfolgen.
-
Die Einführung der IPv6-Unterstützung ermöglicht Dual-Stack-Tunnel unter Verwendung von Konfigurationsnutzlasten. 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-Adresse nicht zugewiesen wird.
In einem routenbasierten VPN werden Secure Tunnel (st0)-Schnittstellen entweder im Punkt-zu-Mehrpunkt- oder im Punkt-zu-Punkt-Modus betrieben. Die Adresszuweisung über die IKEv2-Konfigurationsnutzlast wird jetzt für den Punkt-zu-Mehrpunkt- oder Punkt-zu-Punkt-Modus unterstützt. Bei Punkt-zu-Mehrpunkt-Schnittstellen müssen die Schnittstellen nummeriert sein, und die Adressen in der Konfigurationsnutzlast INTERNAL_IP4_ADDRESS der Attributtyp müssen innerhalb des Teilnetzbereichs der zugeordneten Punkt-zu-Mehrpunkt-Schnittstelle liegen.
Ab Junos OS Version 20.1R1 können Sie ein allgemeines Kennwort für IKEv2-Konfigurationsnutzlastanforderungen für eine IKE-Gateway-Konfiguration konfigurieren. Das allgemeine Kennwort im Bereich von 1 bis 128 Zeichen ermöglicht es dem Administrator, ein allgemeines Kennwort zu definieren. Dieses Kennwort wird zwischen der Firewall der SRX-Serie und dem RADIUS-Server verwendet, wenn die Firewall der SRX-Serie eine IP-Adresse im Namen eines Remote-IPsec-Peers mithilfe der IKEv2-Konfigurationsnutzlast anfordert. Der RADIUS-Server gleicht die Anmeldeinformationen ab, bevor er IP-Informationen an die Firewall der SRX-Serie für die Konfigurationsnutzlastanforderung übermittelt. Sie können das allgemeine Kennwort mithilfe der Konfigurationsanweisung auf der Hierarchieebene [] konfigurieren.config-payload-password configured-password
edit security ike gateway gateway-name aaa access-profile access-profile-name
Sowohl für die Firewall der SRX-Serie als auch für den RADIUS-Server muss dasselbe Kennwort konfiguriert sein, und der RADIUS-Server sollte so konfiguriert sein, dass er das Password Authentication Protocol (PAP) als Authentifizierungsprotokoll verwendet. Ohne sie wird der Tunnelaufbau nicht erfolgreich sein.
Abbildung 7 zeigt einen typischen Workflow für eine IKEv2-Konfigurationsnutzlast.
Die IKEv2-Konfigurationsnutzlastfunktion wird sowohl für Point-to-Multipoint Secure Tunnel (st0)-Schnittstellen als auch für Point-to-Point-Schnittstellen unterstützt. Punkt-zu-Mehrpunkt-Schnittstellen müssen nummeriert sein, und die in der Konfigurationsnutzlast angegebenen Adressen müssen innerhalb des Teilnetzbereichs der zugeordneten Punkt-zu-Mehrpunkt-Schnittstelle liegen.
Ab Junos OS Version 20.1R1 unterstützen wir die IKEv2-Konfigurationsnutzlastfunktion mit Punkt-zu-Punkt-Schnittstellen auf SRX5000 Linie und vSRX Virtual Firewall mit iked.
Grundlegendes zur Bereitstellung von Pico-Zellen
Die IKEv2-Konfigurationsnutzlast kann verwendet werden, um Bereitstellungsinformationen von einem IKE-Responder, z. B. einer Firewall der SRX-Serie, an mehrere Initiatoren, z. B. LTE-Pico-Zellen-Basisstationen in einem Mobilfunknetz, weiterzugeben. Die Pico-Zellen werden ab Werk mit einer Standardkonfiguration ausgeliefert, die eine Verbindung mit der Firewall der SRX-Serie ermöglicht, aber die Pico-Zellen-Bereitstellungsinformationen werden auf einem oder mehreren Provisioning-Servern in einem geschützten Netzwerk gespeichert. Die Pico-Zellen erhalten vollständige Bereitstellungsinformationen, nachdem sie sichere Verbindungen mit den Bereitstellungsservern hergestellt haben.
Der Arbeitsablauf, der erforderlich ist, um eine Pico-Zelle zu booten, bereitzustellen und in Betrieb zu nehmen, umfasst vier verschiedene Phasen:
-
Erwerb der ersten Adressen: Die Pico-Zelle wird ab Werk mit den folgenden Informationen ausgeliefert:
-
Konfiguration für den Secure Gateway-Tunnel zur Firewall der SRX-Serie
-
Digitales Zertifikat, ausgestellt vom Hersteller
-
Vollqualifizierter Domänenname (Fully Qualified Domain Name, FQDN) der Provisioning-Server, die sich im geschützten Netzwerk befinden
Die Pico-Zelle wird hochgefahren und erhält von einem DHCP-Server eine Adresse, die für die IKE-Aushandlung verwendet werden soll. Unter Verwendung dieser Adresse wird dann ein Tunnel zum sicheren Gateway auf der Firewall der SRX-Serie aufgebaut. Eine Adresse für OAM-Datenverkehr (Operation, Administration and Management) wird ebenfalls vom DHCP-Server für die Verwendung im geschützten Netzwerk zugewiesen.
-
Bereitstellung von Pico-Zellen – Unter Verwendung der ihr zugewiesenen OAM-Datenverkehrsadresse fordert die Pico-Zelle ihre Bereitstellungsinformationen – in der Regel Betreiberzertifikat, Lizenz, Software und Konfigurationsinformationen – von Servern innerhalb des geschützten Netzwerks an.
Neustart: Die Pico-Zelle wird neu gestartet und verwendet die erfassten Bereitstellungsinformationen, um sie für das Netzwerk und das Betriebsmodell des Service Providers spezifisch zu machen.
-
Servicebereitstellung – Wenn die Pico-Zelle in Betrieb genommen wird, verwendet sie ein einzelnes Zertifikat, das Werte für den definierten Namen (DN) und alternative Antragstellernamen mit einem FQDN enthält, um zwei Tunnel zum sicheren Gateway auf der Firewall der SRX-Serie aufzubauen: eine für den OAM-Datenverkehr und die andere für den Datenverkehr des Third-Generation Partnership Project (3GPP).
Siehe auch
IKE-Vorschlag
Die IKE-Konfiguration definiert die Algorithmen und Schlüssel, die zum Herstellen der sicheren IKE-Verbindung mit dem Peersicherheitsgateway verwendet werden. Sie können einen oder mehrere IKE-Vorschläge konfigurieren. Jeder Vorschlag ist eine Liste von IKE-Attributen zum Schutz der IKE-Verbindung zwischen dem IKE-Host und seinem Peer.
Um einen IKE-Vorschlag zu konfigurieren, fügen Sie die Anweisung ein, und geben Sie einen Namen auf der Hierarchieebene [] an:proposal
edit security ike
IKE-Richtlinie
Eine IKE-Richtlinie definiert eine Kombination von Sicherheitsparametern (IKE-Vorschlägen), die während der IKE-Aushandlung verwendet werden sollen. Er definiert eine Peer-Adresse und die Vorschläge, die für diese Verbindung erforderlich sind. Je nachdem, welche Authentifizierungsmethode verwendet wird, definiert es den vorinstallierten Schlüssel für den jeweiligen Peer oder das lokale Zertifikat. Während der IKE-Aushandlung sucht IKE nach einer IKE-Richtlinie, die auf beiden Peers identisch ist. Der Peer, der die Aushandlung initiiert, sendet alle seine Richtlinien an den Remotepeer, und der Remotepeer versucht, eine Übereinstimmung zu finden. Eine Übereinstimmung wird vorgenommen, wenn beide Richtlinien der beiden Peers einen Vorschlag haben, der die gleichen konfigurierten Attribute enthält. Wenn die Gültigkeitsdauer nicht identisch ist, wird die kürzere Gültigkeitsdauer zwischen den beiden Richtlinien (vom Host und vom Peer) verwendet. Der konfigurierte vorinstallierte Schlüssel muss auch mit seinem Peer übereinstimmen.
Zuerst 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, schließen Sie die Anweisung ein, und geben Sie einen Richtliniennamen auf der Hierarchieebene [] an:policy
edit security ike
Erneute Schlüsselerstellung und erneute Authentifizierung
Überblick
Bei IKEv2 sind die erneute Schlüsselerstellung und die erneute Authentifizierung getrennte Prozesse. Durch die erneute Schlüsselerstellung werden neue Schlüssel für die IKE-Sicherheitszuordnung (Security Association, SA) erstellt und Nachrichten-ID-Leistungsindikatoren zurückgesetzt, die Peers werden jedoch nicht erneut authentifiziert. Bei der erneuten Authentifizierung wird überprüft, ob VPN-Peers ihren Zugriff auf Authentifizierungsanmeldeinformationen behalten. Bei der erneuten Authentifizierung werden neue Schlüssel für die IKE-Sicherheitszuordnung und die untergeordneten Sicherheitszuordnungen erstellt. Neuschlüssel einer ausstehenden IKE-SA oder untergeordneten SA werden nicht mehr benötigt. Nachdem die neue IKE und die untergeordneten Sicherheitszuordnungen erstellt wurden, werden die alte IKE und die untergeordneten Sicherheitszuordnungen gelöscht.
Die erneute IKEv2-Authentifizierung ist standardmäßig deaktiviert. Sie aktivieren die erneute Authentifizierung, indem Sie einen Wert für die Häufigkeit der erneuten Authentifizierung zwischen 1 und 100 konfigurieren. Die Häufigkeit der erneuten Authentifizierung ist die Anzahl der erneuten IKE-Schlüssel, die vor der erneuten Authentifizierung erfolgen. Wenn z. B. die konfigurierte Häufigkeit der erneuten Authentifizierung 1 ist, erfolgt die erneute Authentifizierung jedes Mal, wenn ein IKE-Neuschlüssel erfolgt. Wenn die konfigurierte Häufigkeit der erneuten Authentifizierung 2 ist, erfolgt die erneute Authentifizierung bei jedem zweiten erneuten IKE-Schlüssel. Wenn die konfigurierte Häufigkeit der erneuten Authentifizierung 3 beträgt, erfolgt die erneute Authentifizierung bei jedem dritten erneuten IKE-Schlüssel usw.
Sie konfigurieren die Häufigkeit der erneuten Authentifizierung mit der Anweisung auf der Hierarchieebene [].reauth-frequency
edit security ike policy policy-name
Die erneute Authentifizierung wird deaktiviert, indem die Häufigkeit der erneuten Authentifizierung auf 0 (Standardeinstellung) festgelegt wird. Die Häufigkeit der erneuten Authentifizierung wird nicht von Peers ausgehandelt, und jeder Peer kann seinen eigenen Wert für die Häufigkeit der erneuten Authentifizierung haben.
Unterstützte Funktionen
Die erneute IKEv2-Authentifizierung wird mit den folgenden Funktionen unterstützt:
IKEv2-Initiatoren oder -Responder
Dead Peer Detection (DPD)
Virtuelle Router und Secure Tunnel (st0)-Schnittstellen in virtuellen Routern
Network Address Translation Traversal (NAT-T)
Chassis-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 Einsetzen einer neuen Services Processing Unit (SPU) unter Verwendung des In-Service-Hardware-Upgrade-Verfahrens (ISHU)
Einschränkungen
Beachten Sie die folgenden Einschränkungen bei Verwendung der erneuten IKEv2-Authentifizierung:
Mit NAT-T kann eine neue IKE-SA mit anderen Ports als 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 einer erneuten Authentifizierung zum Responder werden. Wenn die NAT-Sitzung abläuft, verwirft das NAT-Gerät möglicherweise neue IKE-Pakete, die möglicherweise an einem anderen Port eingehen. NAT-T-Keepalive oder DPD muss aktiviert sein, um die NAT-Sitzung am Leben zu erhalten. Für AutoVPN empfehlen wir, dass die auf den Spokes konfigurierte Häufigkeit der erneuten Authentifizierung kleiner ist als die auf dem Hub konfigurierte Häufigkeit der erneuten Authentifizierung.
Basierend auf der Häufigkeit der erneuten Authentifizierung kann eine neue IKE-SA entweder vom Initiator oder vom Responder der ursprünglichen IKE-SA initiiert werden. Da die EAP-Authentifizierung (Extensible Authentication Protocol)-Authentifizierungs- und Konfigurationsnutzlast erfordert, dass die IKE-SA von derselben Partei wie die ursprüngliche IKE-SA initiiert wird, wird eine erneute Authentifizierung mit EAP-Authentifizierungs- oder Konfigurationsnutzdaten nicht unterstützt.
IKE-Authentifizierung (zertifikatsbasierte Authentifizierung)
Mehrstufige Hierarchie für die Zertifikatsauthentifizierung
Die zertifikatbasierte Authentifizierung ist eine Authentifizierungsmethode, die von Firewalls der SRX-Serie während der IKE-Aushandlung unterstützt wird. In großen Netzwerken können mehrere Zertifizierungsstellen (CAs) Endentitätszertifikate (EE-Zertifikate) für ihre jeweiligen Endgeräte ausstellen. Es ist üblich, separate Zertifizierungsstellen für einzelne Standorte, Abteilungen oder Organisationen zu haben.
Wenn eine einstufige Hierarchie für die zertifikatbasierte Authentifizierung verwendet wird, müssen alle EE-Zertifikate im Netzwerk von derselben Zertifizierungsstelle signiert werden. Für die Überprüfung des Peerzertifikats muss auf allen Firewallgeräten dasselbe CA-Zertifikat registriert sein. Die Zertifikatsnutzlast, die während der IKE-Aushandlung gesendet wird, enthält nur EE-Zertifikate.
Alternativ kann die Zertifikatsnutzlast, die während der IKE-Aushandlung gesendet wird, eine Kette von EE- und CA-Zertifikaten enthalten. Eine Zertifikatskette ist die Liste der Zertifikate, die erforderlich sind, um das EE-Zertifikat eines Peers zu validieren. Die Zertifikatskette umfasst das EE-Zertifikat und alle CA-Zertifikate, die im lokalen Peer nicht vorhanden sind.
Der Netzwerkadministrator muss sicherstellen, dass alle Peers, die an einer IKE-Aushandlung teilnehmen, mindestens eine gemeinsame vertrauenswürdige Zertifizierungsstelle in ihren jeweiligen Zertifikatsketten haben. Die allgemein vertrauenswürdige Zertifizierungsstelle muss nicht die Stammzertifizierungsstelle sein. Die Anzahl der Zertifikate in der Kette, einschließlich der Zertifikate für EEs und der obersten Zertifizierungsstelle 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 erfolgen. Bei Zertifikatketten muss die Stammzertifizierungsstelle mit der vertrauenswürdigen Zertifizierungsstellengruppe oder dem Zertifizierungsstellenserver übereinstimmen, die bzw. der in der IKE-Richtlinie konfiguriert ist
In der Beispiel-Zertifizierungsstellenhierarchie unter Abbildung 8ist die Stammzertifizierungsstelle die allgemeine vertrauenswürdige Zertifizierungsstelle für alle Geräte im Netzwerk. Die Stammzertifizierungsstelle stellt Zertifizierungsstellenzertifikate für die technischen und Vertriebszertifizierungsstellen aus, die als "Eng-CA" bzw. "Sales-CA" bezeichnet werden. Eng-CA stellt CA-Zertifikate für die Entwicklungs- und Qualitätssicherungsstellen aus, die als Dev-CA bzw. Qa-CA bezeichnet werden. Host-A erhält sein EE-Zertifikat von Dev-CA, während Host-B sein EE-Zertifikat von Sales-CA erhält.
Jedes Endgerät muss mit den CA-Zertifikaten in seiner Hierarchie geladen werden. Host-A muss über Root-CA-, Eng-CA- und Dev-CA-Zertifikate verfügen. Sales-CA- und Qa-CA-Zertifikate sind nicht erforderlich. Host-B muss über Root-CA- und Sales-CA-Zertifikate verfügen. Zertifikate können manuell in ein Gerät geladen oder mit dem Simple Certificate Enrollment Process (SCEP) registriert werden.
Jedes Endgerät muss für jede CA in der Zertifikatskette mit einem CA-Profil konfiguriert werden. Die folgende Ausgabe zeigt die auf Host-A konfigurierten Zertifizierungsstellenprofile:
admin@host-A# show security pki { ca-profile Root-CA { ca-identity Root-CA; enrollment { url “www.example.net/scep/Root/”; } } ca-profile Eng-CA { ca-identity Eng-CA; enrollment { url “www.example.net/scep/Eng/”; } } ca-profile Dev-CA { ca-identity Dev-CA; enrollment { url “www.example.net/scep/Dev/”; } } }
Die folgende Ausgabe zeigt die auf Host-B konfigurierten Zertifizierungsstellenprofile:
admin@host-B# show security pki { ca-profile Root-CA { ca-identity Root-CA; enrollment { url “www.example.net/scep/Root/”; } } ca-profile Sales-CA { ca-identity Sales-CA; enrollment { url “www.example.net/scep/Sales/”; } } }
Siehe auch
IKE-Schutz vor DDoS-Angriffen
Denial of S Service (DoS) ist einer der häufigsten und zugleich schwerwiegendsten Angriffe in einem unsicheren IPsec-VPN-Netzwerk. Ein DoS-Angriff bietet eine schnelle und einfache Möglichkeit, sich das Netzwerk zu bemächtigen, da er nicht viel Halt in der Netzwerkinfrastruktur erfordert. Die Cyberangreiferwählen diese Methode, um die Kontrolle über das Netzwerk zu übernehmen.
Was passiert bei einem DoS-Angriff?
Der Angreifer versucht, das Netzwerk mit zu viel Datenverkehr zu überfluten und allmählich zum Absturz zu bringen, wodurch die Netzwerkressourcen erschöpft werden und die Kontrolle über die Geräteressourcen wie Arbeitsspeicher und CPU weiter übernommen wird. Wenn der Angreifer versucht, mehrere orchestrierte Systeme zu kontrollieren und gleichzeitig ein einzelnes Ziel anzugreifen, spricht man von Distributed-DoS-Angriffen (DDoS).
- DDoS-Schwachstellen bei IKE-Implementierungen
- Schutz vor DDoS-Angriffen
- Möglichkeiten zur Überwachung von DDoS-Angriffen
DDoS-Schwachstellen bei IKE-Implementierungen
Wenn der Remotepeer (Initiator) eine SA_INIT Nachricht sendet, antwortet der lokale Peer (Responder) und weist Speicher für die Nachrichtenstruktur zu. Wir bezeichnen die Sitzung als halboffene IKE-Sitzung, bis die Authentifizierung mit der IKE_AUTH Nachricht erfolgt.Nachdem die Peers eine IKE-Sicherheitszuordnung (SA) eingerichtet haben, wird die Sitzung als vollständig offene IKE-Sitzung bezeichnet.
Um die IKEv2 DDoS-Schwachstellen zu verstehen, sehen wir uns einige der Möglichkeiten an, wie ein Angreifer einen einfachen Angriffsvektor gegen die IKE-SAs erstellen kann:
-
Senden Sie große Mengen SA_INIT Nachrichten (ohne IKE_AUTH Nachrichten), für die der Angreifer halboffene IKE-Sicherheitszuordnungsstrukturen erstellen kann. Dies führt dazu, dass das Gerät die Ressourcen nutzt und der Arbeitsspeicher knapp wird.
-
Senden Sie eine große Menge an Junk-IKE_AUTH Paketen mit korrekten SPI_i und SPI_r auf dem Initiator bzw. dem Responder. Dies führt dazu, dass dem Gerät beim Versuch, die Pakete zu entschlüsseln, der Arbeitsspeicher ausgeht.
-
Senden Sie kontinuierlich SA_INIT Pakete. Dies führt dazu, dass dem Gerät beim Versuch, Schlüssel für verschlüsselte Pakete zu generieren, der Arbeitsspeicher ausgeht.
-
Senden Sie eine große Anzahl von Anforderungen zur erneuten Schlüsselerstellung pro Sekunde während vollständig geöffneter IKE-Sitzungen.
-
Senden Sie große Mengen von Nachrichten mit unterschiedlichen Nachrichten-IDs. Dies führt dazu, dass das Gerät alle eingehenden IKE-Nachrichten in die Warteschlange stellt und nicht genügend Speicher zur Verfügung steht.
So schützen Sie die IKE-Implementierungen
Wir bieten eine robuste Infrastruktur zur Abwehr und Überwachung von DDoS-Angriffen sowohl für das IKEv1- als auch für das IKEv2-Protokoll. Sie können sich vor Angriffen auf IKE-Implementierungen schützen, wenn Ihre Firewall den iked-Prozess ( Paket) für den IPsec-VPN-Dienst ausführt.junos-ike
Weitere Informationen zum DDoS-Schutz für IKEv2 finden Sie unter RFC 8019, Schutz von IKEv2-Implementierungen (Internet Key Exchange Protocol Version 2) vor verteilten Denial-of-Service-Angriffen. Der im RFC vorhandene Client-Puzzle-Mechanismus wird nicht unterstützt. Während der IKEv2-DDoS-Schutz auf RFC 8019 basiert, bieten wir einen ähnlichen Schutz für IKEv1, wenn Ihre Firewall den IPsec-VPN-Dienst mit dem iked-Prozess ausführt.
Schutz vor DDoS-Angriffen
Sie können mehrere Schutzmechanismen gegen DDoS-Angriffe während des Erstellungsprozesses der IKE-Sicherheitszuordnung aktivieren. Zu diesen Mechanismen gehören die Konfiguration der Ratenbegrenzung und eines Aufbewahrungszeitraums für die halboffenen IKE-Sicherheitszuordnungen sowie die weitere Verwaltung der eingehenden Wechselkurse für die Anforderungen zur erneuten Schlüsselerstellung. Wir stellen die folgenden Maßnahmen bereit, um den Schutz zu gewährleisten:
- Für halboffene IKE-SAs:
-
Der Responder lässt für eine bestimmte Dauer keine Konfiguration der halb geöffneten IKE-SA zu. Sie können diesen Grenzwert so festlegen, dass der Responder erst konfiguriert wird, wenn er die Timeoutdauer erreicht hat. Weitere Informationen finden Sie unter der Option .session (Security IKE)
timeout
-
Sie können den Grenzwert für die maximal zulässigen halb geöffneten IKE-Sicherheitszuordnungen auf dem Responder festlegen. Wenn die Gesamtzahl der halb geöffneten IKE-Sicherheitszuordnungen die maximale Anzahl erreicht, lehnt der Responder neue Verbindungen sowohl für IKEv1- als auch für IKEv2-Sicherheitszuordnungen ab. Weitere Informationen finden Sie unter der Option .session (Security IKE)
max-count
-
Der Responder erzwingt Schwellenwerte für die Sitzungsanzahl für halb geöffnete IKE-Sicherheitszuordnungen. Wenn die Gesamtzahl der halb geöffneten IKE-Sicherheitseinrichtungen Schwellenwerte erreicht,
-
Im Falle von IKEv2-Sicherheitszuordnungen ruft der Responder den Cookie-Mechanismus für alle neuen Verbindungen auf.
-
Bei IKEv1-Sicherheitszuordnungen lehnt der Responder neue Verbindungen ab.
Weitere Informationen finden Sie unter den Optionen und . session (Security IKE)
thresholds
send-cookie
reduce-timeout
-
-
Der Responder kann doppelte Sitzungen verwerfen. Weitere Informationen finden Sie unter der Option .session (Security IKE)
discard-duplicate
-
Sie können Backoff-Timeouts für Authentifizierungsfehler und Initiierungsfehlerphasen festlegen. Weitere Informationen finden Sie unter den Optionen und . session (Security IKE)
backoff-timeouts
init-phase-failure
auth-phase-failure
-
-
Für vollständig geöffnete IKE-Sicherheitszuordnungen:
-
Sie können die maximalen Raten eingehender Neuschlüsselanforderungen konfigurieren, um die Anforderungen in einem skalierten Szenario zu drosseln. Weitere Informationen finden Sie unter der Option .session (Security IKE)
incoming-exchange-max-rates
-
-
Der Responder kann eine eingehende IKE-Sitzung von Peers basierend auf der Peer-IKE-ID blockieren. Weitere Informationen finden Sie unter .blocklists (Security IKE)RLI41450 Review this entire topic
-
Bei dynamischen Gateways können Sie mit der Option ein Limit für die Anzahl der Verbindungen auf IKE-Gateway-Konfigurationsebene festlegen.
connections-limit
Weitere Informationen finden Sie unter Gateway (Sicherheits-IKE)./documentation/us/en/software/junos/vpn-ipsec/topics/ref/statement/security-edit-gateway-ike.html
Weitere Informationen zum Konfigurieren dieser Optionen finden Sie unterKonfigurieren des Schutzes vor IKE-DDoS-Angriffen.Konfigurieren des Schutzes vor IKE-DDoS-Angriffen
Wir unterstützen nicht:
-
DDoS-Schutz mit IPsec-VPN-Dienst basierend auf dem kmd-Verfahren.
-
Schutz vor Hash- und URL-Zertifikatskodierungsangriffen , da wir diese Kodierungstypen nicht unterstützen.
Möglichkeiten zur Überwachung von DDoS-Angriffen
Wir stellen die folgenden Mechanismen zur Überwachung der DDoS-Angriffe zur Verfügung:
-
Verwenden Sie den Befehl, um alle ausgereiften und nicht ausgereiften IKE-Sicherheitszuordnungen aufzulisten.
show security ike security-associations
Weitere Informationen finden Sie unter show security ike security-associations./documentation/us/en/software/junos/vpn-ipsec/topics/ref/command/show-security-ike-security-associations.html -
Verwenden Sie den Befehl, um globale IKE-Statistiken des IPsec-VPN-Tunnels anzuzeigen, z. B. in Bearbeitung, eingerichtete und abgelaufene Statistiken.
show security ike stats
Weitere Informationen finden Sie unter Anzeigen von Sicherheitsike-Statistiken./documentation/us/en/software/junos/vpn-ipsec/topics/ref/command/show-security-ike-stats.html -
Verwenden Sie den Befehl, um Details der erfolgreichen IKE-Verhandlungen mit den Remote-Peers anzuzeigen.
show security ike active-peer
Weitere Informationen finden Sie unter show security ike active-peer./documentation/us/en/software/junos/vpn-ipsec/topics/ref/command/show-security-ike-active-peer.html -
Verwenden Sie den Befehl , um die Details der in Bearbeitung befindlichen IKE-SAs anzuzeigen, einschließlich der halb geöffneten IKE-SAs.
show security ike peers in-progress
Weitere Informationen finden Sie unter .show security ike peersRLI41450 Mit diesem Befehl können Sie auch die Details der blockierten, fehlgeschlagenen und Backoff-Peers anzeigen. -
Verwenden Sie den Befehl , um die IKE-Peers zu löschen, die zurückgesetzt, blockiert, fehlgeschlagen oder in Bearbeitung sind.
clear security ike peers
Weitere Informationen finden Sie unter .clear security ike peersRLI41450 -
Verwenden Sie den Befehl, um eine vorhandene IKE-Sicherheitszuordnung mit Peers zu löschen, die für die weitere Kommunikation blockiert werden muss.
clear security ike security-associations
Weitere Informationen finden Sie unter clear security ike security-associations./documentation/us/en/software/junos/vpn-ipsec/topics/ref/command/clear-security-ike-security-associations.html -
Die IKED-Syslog-Meldungen IKE_GATEWAY_PEER_BLOCKED, IKE_GATEWAY_PEER_BACKOFF und IKE_GATEWAY_PEER_FAILED enthalten Details zu den blockierten, zurückgesetzten bzw. fehlgeschlagenen IKE-Verhandlungen mit den Remote-Peers.
-
Für zusätzliche Sicherheit stellt Junos OS den Benutzern Services zum Schutz vor paketbasierten Systemangriffen bereit, wie z. B. Filterung, Sitzungsanzahl und Ratenbegrenzung. Weitere Informationen finden Sie unter dem Befehl show firewall und der ids-option-Anweisungauf der Hierarchieebene []./documentation/us/en/software/junos/routing-policy/topics/ref/command/show-firewall-filter.html/documentation/us/en/software/junos/denial-of-service/topics/ref/statement/security-edit-ids-option.html
edit security screen ids-option screen-name
Konfigurieren des Schutzes vor IKE-DDoS-Angriffen
SUMMARY In diesem Abschnitt erfahren Sie, wie Sie den Schutz vor DDoS-Angriffen auf das IKE-Protokoll konfigurieren.
Voraussetzungen
Bevor Sie den Schutz vor IKE-DDoS-Angriffen konfigurieren, stellen Sie sicher, dass Sie die folgenden Voraussetzungen erfüllen:
-
Firewall der SRX-Serie, die ein Paket zum Ausführen des IPsec-VPN-Dienstes mithilfe des iked-Prozesses unterstützt .
junos-ike
-
Die Firewall der SRX-Serie, die als lokaler Endpunkt (Responder) dient, ist für den Remote-IKE-Peer (den Initiator) erreichbar.
-
Eine IKE-Richtlinie, die eine IKE-Sperrliste zuordnen kann.
Die folgenden Aktionen sind an der Konfiguration des Schutzes vor IKE-DDoS-Angriffen beteiligt:
-
Verwalten Sie die eingehenden halboffenen IKE-SAs.
-
Verwalten Sie die eingehenden vollständig geöffneten IKE-Sicherheitszuordnungen.
-
Konfigurieren Sie mehrere Blockierungsmethoden, um die eingehenden IKE-Sitzungen von verschiedenen Peers zu blockieren und eine der Blockierungslisten einem IKE-Peer zuzuordnen.
Informationen zum Konfigurieren dieser Aktionen finden Sie in den folgenden Aufgaben.
- Konfigurieren der IKE-Sitzung für halboffene IKE-Sicherheitszuordnungen
- Konfigurieren der IKE-Sitzung für vollständig geöffnete IKE-Sicherheitszuordnungen
- Konfigurieren der Blocklisten für IKE-Sitzungen
Konfigurieren der IKE-Sitzung für halboffene IKE-Sicherheitszuordnungen
Überblick
Stellen Sie sicher, dass Sie alle oben genannten Voraussetzungen erfüllen.
In diesem Abschnitt erfahren Sie, wie Sie die Timeouts, die maximale Anzahl und die Schwellenwerte für die halb geöffneten IKE-SAs konfigurieren. Die Konfigurationsänderungen gelten für die neuen Sitzungen, während die vorhandenen Sitzungen weiterhin die Standardwerte verwenden, wenn sie nicht explizit zuvor konfiguriert wurden. Der Umfang dieser Konfigurationen auf der Hierarchieebene [] gilt auf globaler Ebene und nicht pro Peerebene.edit security ike session half-open
Konfiguration
-
So legen Sie den Parameter für die Lebensdauer des Responders mit der folgenden Option fest:
timeout seconds
[edit] user@host# set security ike session half-open timeout 150
Während dieses Zeitraums lässt der Responder die Konfiguration halboffener IKE-Sicherheitszuordnungen erst zu, wenn die Timeoutdauer erreicht ist. Der Initiator kann unabhängig von der Konfiguration des Responders weiterhin eine Timeoutdauer von 60 Sekunden haben.
-
So legen Sie den Parameter für die maximale Anzahl des Responders mithilfe der folgenden Option fest:
max-count value
[edit] user@host# set security ike session half-open max-count 1000
Mit dieser Option wird die maximale Anzahl halb geöffneter IKE-Sitzungen auf dem Responder festgelegt. Der Standardwert ist 300, wenn Sie diesen Wert nicht angeben. Die Konfiguration deaktiviert alle Schwellenwerte.
max-count
In solchen Fällen müssen Sie Schwellenwerte explizit konfigurieren, um sie durchzusetzen. -
Geben Sie die verschiedenen Arten von Aktionen an, indem Sie die Option verwenden, wenn die Sitzungsanzahl des Responders das Limit erreicht.
threshold
-
So legen Sie die Mindestanzahl halb geöffneter IKE-Sitzungen fest, um Cookie-Aktionen zu erzwingen, indem Sie die folgende Option verwenden:
send-cookie count
[edit] user@host# set security ike session half-open threshold send-cookie 500
Dies gibt den Schwellenwert an, ab dem der Responder die Remotepeers auffordert, die Sitzungsinitiierung mit einem Cookie zu wiederholen, das in der ersten Antwort an den Peer zurückgesendet wird. Wenn die Begrenzung für die Anzahl der halb geöffneten IKE-Sitzungen 500 erreicht, verwendet der iked-Prozess einen Cookie-Mechanismus für die neuen IKE-Sitzungen.
-
So legen Sie die Mindestanzahl halb geöffneter IKE-Sitzungen fest, um eine Aktion mit reduzierter Zeitüberschreitung zu erzwingen, indem Sie die Option verwenden:
reduced-timeout count timeout seconds
[edit] user@host# set security ike session half-open threshold reduce-timeout 600 timeout 100
Dies gibt den Grenzwert an, ab dem der iked-Prozess die Lebensdauer der neuen halboffenen IKE-Sicherheitszuordnungen reduziert. Sobald die Anzahl der halb geöffneten Responder-IKE-Sitzungen unter den Schwellenwert sinkt, verwenden die halb geöffneten Responder-IKE-Sitzungen wieder den Standardtimeoutwert.
-
-
So legen Sie die Option fest, um die doppelten halb geöffneten IKE-Sitzungen zu verwerfen, ohne eine Antwort an den Initiator zurückzusenden:
discard-duplicate
[edit] user@host# set security ike session half-open discard-duplicate
Bei einer doppelten Sitzungsinitiierungsanforderung (SA_INIT), die vom selben Peer mit einem anderen Initiatorcookie stammt, für das während der Aushandlung keine IKE-SA vorhanden ist, verwirft der Responder das Paket.
-
Sie können die Backoff-Timeouts mit der Option festlegen.
backoff-timeouts
Dies gibt dem Remotepeer etwas Zeit, sich im Falle eines Fehlschlags bei der Sitzungsinitiierung zurückzusetzen, wodurch sichergestellt wird, dass derselbe Peer während dieses Zeitraums keine neue Sitzung initiieren kann. Nach dem Backoff-Timeout kann der Peer eine neue Sitzung initiieren. Die Sitzungsinitiierung kann in zwei Phasen fehlschlagen: in der Initialisierungsphase und in der Authentifizierungsphase.
-
So legen Sie das Backoff-Timeout fest, wenn während der IKE_AUTH-Phase ein Fehler auftritt, indem Sie die Option verwenden:
backoff-timeouts auth-phase-failure value
[edit] user@host# set security ike session half-open backoff-timeouts auth-phase-failure 150
Wenn Sie konfigurieren, werden alle Remotepeers, die auf der Sperrliste stehen, auch dann zurückgesetzt, wenn Sie das Backoff nicht als Aktion für die Zielblocklistenregel konfigurieren.
auth-phase-failure
Das Timeout für das Backoff ist dasjenige, das für konfiguriert ist.auth-phase-failure
In diesem Beispiel startet das Gerät nach 150 Sekunden eine neue Sitzung. Um dieses Backoff-Timeout für eine bestimmte Regel zu überschreiben, können Sie explizit die Aktion für die Blockliste konfigurieren, in der das Timeout bei [.backoff
rule
edit security ike blocklists blocklist1 rule rule-name then backoff timeout-value] hierarchy level
-
So legen Sie das Backoff-Timeout fest, wenn während der SA_INIT-Phase ein Fehler auftritt, indem Sie die Option verwenden:
backoff-timeouts init-phase-failure value
[edit] user@host# set security ike session half-open backoff-timeouts init-phase-failure 160
In diesem Beispiel startet das Gerät nach 160 Sekunden eine neue Sitzung.
-
So legen Sie den Parameter für die Lebensdauer des Responders mit der folgenden Option fest:
timeout seconds
[edit] user@host# set security ike session half-open timeout 150
Während dieses Zeitraums lässt der Responder die Konfiguration halboffener IKE-Sicherheitszuordnungen erst zu, wenn die Timeoutdauer erreicht ist. Der Initiator kann unabhängig von der Konfiguration des Responders weiterhin eine Timeoutdauer von 60 Sekunden haben.
-
Konfigurieren der IKE-Sitzung für vollständig geöffnete IKE-Sicherheitszuordnungen
Überblick
Stellen Sie sicher, dass Sie alle oben genannten Voraussetzungen erfüllen.
In diesem Abschnitt erfahren Sie, wie Sie verschiedene eingehende Anforderungsraten für die vollständig geöffneten IKE-Sicherheitszuordnungen konfigurieren, indem Sie die Option auf der Hierarchieebene [] verwenden.incoming-exchange-max-rates
edit security ike session full-open
Konfiguration
Konfigurieren Sie die Option zum Festlegen der maximalen Raten für verschiedene Austauschvorgänge, die vom Remote-Peer nach dem Einrichten einer IKE-SA initiiert werden.incoming-exchange-max-rates
Sie können drei Arten von Wechselkursen konfigurieren: IKE-Neuschlüssel, IPsec-Neuschlüssel und Keepalive (auch als Dead Peer-Erkennung bezeichnet).
-
So legen Sie die maximale Rate für eingehende Peer-initiierte IKE-Neuschlüssel mithilfe der folgenden Option fest:
incoming-exchange-max-rates ike-rekey value
[edit] user@host# set security ike session full-open incoming-exchange-max-rates ike-rekey 200/60
Die Option gilt für die erneute Schlüsselerstellung von IKEv2 pro Peer mit einem vorhandenen Peer, bei dem bereits eine IKE-SA vorhanden ist.
-
So legen Sie die maximale Rate für die eingehende Peer-initiierte IPsec-SA-Neuschlüsselung mithilfe der folgenden Option fest:
incoming-exchange-max-rates ipsec-rekey value
[edit] user@host# set security ike session full-open incoming-exchange-max-rates ipsec-rekey 100/60
Der Grenzwert gilt für jeden Tunnel.
-
So legen Sie die maximale Keepalive-Rate für eingehende Peer-initiierte Personen mit der folgenden Option fest:
incoming-exchange-max-rates keepalive value
[edit] user@host# set security ike session full-open incoming-exchange-max-rates keepalive 60/60
Das Limit gilt für jeden Peer.
Konfigurieren der Blocklisten für IKE-Sitzungen
Überblick
Stellen Sie sicher, dass Sie alle oben genannten Voraussetzungen erfüllen.
Um eine eingehende IKE-Sitzung von Peers basierend auf der Peer-IKE-ID zu blockieren, müssen Sie eine oder mehrere Blockierlisten konfigurieren. Jede Blockierliste enthält eine oder mehrere Regeln. Jede Regel hat ein Übereinstimmungskriterium und eine Aktion.
Berücksichtigen Sie bei der Konfiguration der Blocklisten die folgenden Kriterien:
-
Sperrlistenregeln gelten für die neuen IKE-Sicherheitszuordnungen, die ausgehandelt werden, und wirken sich nicht auf die vorhandenen IKE-Sicherheitszuordnungen aus. In der Phase der Peerauthentifizierung wendet das Gerät die Sperrlistenregeln an.
-
Die Reihenfolge der Anwendung der Regeln hängt von der Reihenfolge ab, in der diese Regeln aufgeführt sind.
-
Konfigurieren Sie die Übereinstimmungskriterien basierend auf der Rolle (Initiator oder Responder), einem ID-Typ (IPv4- oder IPv6-Adresse, Hostname, Distinguished Name, E-Mail-ID oder eine Schlüssel-ID) und einem ID-Muster, bei dem es sich um einen regulären Ausdruck handelt, der mit der IKE-ID übereinstimmt.
-
Sie können jede Regel mit einem ID-Typ konfigurieren. Auf diese Weise können Sie verschiedene IKE-IDs für verschiedene Regeln innerhalb derselben Blockierliste konfigurieren.
-
Konfigurieren Sie eine Aktion, um die Peerverbindung entweder zu verwerfen oder abzulehnen. Basierend auf der Übereinstimmung wendet das Gerät eine Aktion an. Optional können Sie den Backoff-Timer mit diesen Aktionen festlegen.
-
Verweisen Sie auf die Blockliste in der IKE-Richtlinie, die dem IKE-Gateway zugeordnet ist.
-
Jedes IKE-Gateway unterstützt nur einen Typ von Remote-IKE-ID-Typ . Wenn Sie eine Blockierliste an ein Gateway anhängen und sie mit Regeln konfigurieren, die unterschiedliche IKE-IDs enthalten, wendet das Gateway nur die Regeln an und stimmt mit ihnen überein, deren IKE-ID-Typ mit dem für das IKE-Gateway konfigurierten identisch ist.
-
Die Metriken für die Tunneleinrichtungsrate mit Blocklisten, die an die IKE-Gateways angehängt sind, basieren auf der Anzahl der in den Blocklisten konfigurierten Regeln.
In diesem Abschnitt erfahren Sie, wie Sie Blockierlisten konfigurieren und die Blockierliste einer IKE-Richtlinie zuordnen.
Konfiguration
-
So erstellen Sie eine Blockierliste mit mehreren Regeln:
-
Erstellen Sie eine Blockierliste.
[edit] user@host# set security ike blocklists blocklist1 description block_from_remote
-
Erstellen Sie eine oder mehrere Regeln.
[edit] user@host# set security ike blocklists blocklist1 rule rule1 description rule_1 user@host# set security ike blocklists blocklist1 rule rule2 description rule_2
Sie können mehrere solcher Blocklisten und deren Regeln erstellen.
-
-
So konfigurieren Sie die Übereinstimmungskriterien und geben die Aktion an:
-
Konfigurieren Sie die Übereinstimmungskriterien für die in der Sperrliste .rule1blocklist1
[edit] user@host# set security ike blocklists blocklist1 rule rule1 match role initiator user@host# set security ike blocklists blocklist1 rule rule1 match id-type hostname user@host# set security ike blocklists blocklist1 rule rule1 match id-pattern "peer.*\.example\.net" user@host# set security ike blocklists blocklist1 rule rule2 match role initiator user@host# set security ike blocklists blocklist1 rule rule2 match id-type user-at-hostname user@host# set security ike blocklists blocklist1 rule rule2 match id-pattern "hr.example.com"
Um Blocklisten mit einer Gruppe von IKE-IDs oder partiellen IKE-IDs zu konfigurieren, verwenden Sie das mit einem Suffix oder Präfix.
id-pattern value
Sie können z. B. den Wert *.example.com verwenden, wenn Sie hr.example.com, finance.example.com admin.example.com abgleichen müssen. In der Regel sucht das Gerät nach dem Hostnamen, der dem Muster entspricht.rule1peer.*\.example\.net Hier sind peer.example.net, peer.1.example.net und peer.uplink.example.net einige mögliche Übereinstimmungen. In der Regel sucht das Gerät nach der E-Mail-Adresse, die dem Muster entspricht.rule2hr.example.com Auf ähnliche Weise können Sie ein anderes Übereinstimmungskriterium für die anderen Regeln konfigurieren, das auf anderen oder .id-type
id-pattern
Diese Muster verwenden den regulären Standardausdruck. -
Geben Sie die Aktion für eine Übereinstimmung an:
[edit] user@host# set security ike blocklists blocklist1 rule rule1 then reject user@host# set security ike blocklists blocklist1 rule rule1 then backoff 60 user@host# set security ike blocklists blocklist1 rule rule2 then discard user@host# set security ike blocklists blocklist1 rule rule2 then backoff 100
-
-
So verknüpfen Sie eine Blockierliste mit einem IKE-Peer:
-
Konfigurieren Sie die Sperrliste in der IKE-Richtlinie .blocklist1ike_policy1
[edit] user@host# set security ike policy ike_policy1 blocklist blocklist1
-
Beispiel: Konfigurieren eines Geräts für die Überprüfung der Peerzertifikatskette
In diesem Beispiel wird gezeigt, wie ein Gerät für Zertifikatsketten konfiguriert wird, die zur Überprüfung von Peergeräten während der IKE-Aushandlung verwendet werden.
- Anforderungen
- Überblick
- Konfiguration
- Überprüfung
- IKE- und IPsec-SA-Fehler für ein gesperrtes Zertifikat
Anforderungen
Bevor Sie beginnen, besorgen Sie sich die Adresse der Zertifizierungsstelle (Certificate Authority, CA) und die Informationen, die diese benötigt (z. B. das Abfragekennwort), wenn Sie Anforderungen für lokale Zertifikate übermitteln.
Überblick
In diesem Beispiel wird gezeigt, wie Sie ein lokales Gerät für Zertifikatketten konfigurieren, Zertifizierungsstellen und lokale Zertifikate registrieren, die Gültigkeit registrierter Zertifikate überprüfen und den Sperrstatus des Peergeräts überprüfen.
Topologie
Dieses Beispiel zeigt die Konfigurations- und Betriebsbefehle auf Host-A, wie in Abbildung 9gezeigt. Auf Host-A wird automatisch ein dynamisches CA-Profil erstellt, damit Host-A die CRL von Sales-CA herunterladen und den Sperrstatus des Zertifikats von Host-B überprüfen kann.
In diesem Beispiel wird die IPsec-VPN-Konfiguration für die Aushandlung der Phasen 1 und 2 für Host-A gezeigt. Das Peer-Gerät (Host-B) muss ordnungsgemäß konfiguriert sein, damit die Optionen für Phase 1 und Phase 2 erfolgreich ausgehandelt und Sicherheitszuordnungen (Security Associations, SAs) eingerichtet werden können. Beispiele für die 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:
- Konfigurieren von Zertifizierungsstellenprofilen
- Registrieren von Zertifikaten
- Konfigurieren von IPsec-VPN-Optionen
Konfigurieren von Zertifizierungsstellenprofilen
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 Ihre Netzwerkkonfiguration erforderlich sind, kopieren Sie die Befehle und fügen Sie sie in die CLI auf Hierarchieebene ein, und geben Sie sie dann aus dem Konfigurationsmodus ein .[edit]
commit
set security pki ca-profile Root-CA ca-identity CA-Root set security pki ca-profile Root-CA enrollment url http://198.51.100.230:8080/scep/Root/ set security pki ca-profile Root-CA revocation-check crl set security pki ca-profile Eng-CA ca-identity Eng-CA set security pki ca-profile Eng-CA enrollment url http://198.51.100.230:8080/scep/Eng/ set security pki ca-profile Eng-CA revocation-check crl set security pki ca-profile Dev-CA ca-identity Dev-CA set security pki ca-profile Dev-CA enrollment url http://198.51.100.230:8080/scep/Dev/ set security pki ca-profile Dev-CA revocation-check crl
Schritt-für-Schritt-Anleitung
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Anweisungen hierzu finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus imCLI-Benutzerhandbuch.Verwenden des CLI-Editors im Konfigurationsmodushttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html
So konfigurieren Sie CA-Profile:
Erstellen Sie das Zertifizierungsstellenprofil für die Stammzertifizierungsstelle.
[edit security pki] user@host# set ca-profile Root-CA ca-identity CA-Root user@host# set ca-profile Root-CA enrollment url http://198.51.100.230:8080/scep/Root/ user@host# set ca-profile Root-CA revocation-check crl
Erstellen Sie das CA-Profil für Eng-CA.
[edit security pki] user@host# set ca-profile Eng-CA ca-identity Eng-CA user@host# set ca-profile Eng-CA enrollment url http://198.51.100.230:8080/scep/Eng/ user@host# set ca-profile Eng-CA revocation-check crl
Erstellen Sie das Zertifizierungsstellenprofil für Dev-CA.
[edit security pki] user@host# set ca-profile Dev-CA ca-identity Dev-CA user@host# set ca-profile Dev-CA enrollment url http://198.51.100.230:8080/scep/Dev/ user@host# set ca-profile Dev-CA revocation-check crl
Ergebnisse
Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie den Befehl eingeben.show security pki
Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Konfigurationsanweisungen in diesem Beispiel, um sie zu korrigieren.
[edit] user@host# show security pki ca-profile Root-CA { ca-identity Root-CA; enrollment { url "http:/;/198.51.100.230:8080/scep/Root/"; } revocation-check { crl ; } } ca-profile Eng-CA { ca-identity Eng-CA; enrollment { url "http:/;/198.51.100.230:8080/scep/Eng/"; } revocation-check { crl ; } } ca-profile Dev-CA { ca-identity Dev-CA; enrollment { url "http:/;/198.51.100.230:8080/scep/Dev/"; } revocation-check { crl ; } }
Wenn Sie mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf .commit
Registrieren von Zertifikaten
Schritt-für-Schritt-Anleitung
So registrieren Sie Zertifikate:
Registrieren Sie die CA-Zertifikate.
user@host> request security pki ca-certificate enroll ca-profile Root-CA
user@host> request security pki ca-certificate enroll ca-profile Eng-CA
user@host> request security pki ca-certificate enroll ca-profile Dev-CA
Geben Sie an den Eingabeaufforderungen ein , um das CA-Zertifikat zu laden.yes
Stellen Sie sicher, dass die CA-Zertifikate auf dem Gerät registriert sind.
user@host> show security pki ca-certificate ca-profile Root-CA Certificate identifier: Root-CA Issued to: Root-CA, Issued by: C = us, O = example, CN = Root-CA Validity: Not before: 08-14-2012 22:19 Not after: 08-13-2017 22:19 Public key algorithm: rsaEncryption(2048 bits)
user@host> show security pki ca-certificate ca-profile Eng-CA Certificate identifier: Eng-CA Issued to: Eng-CA, Issued by: C = us, O = example, CN = Root-CA Validity: Not before: 08-15-2012 01:02 Not after: 08-13-2017 22:19 Public key algorithm: rsaEncryption(2048 bits)
user@host> show security pki ca-certificate ca-profile Dev-CA Certificate identifier: Dev-CA Issued to: Dev-CA, Issued by: C = us, O = example, CN = Eng-CA Validity: Not before: 08-15-2012 17:41 Not after: 08-13-2017 22:19 Public key algorithm: rsaEncryption(2048 bits)
Überprüfen Sie die Gültigkeit der registrierten Zertifizierungsstellenzertifikate.
user@host> request security pki ca-certificate verify ca-profile Root-CA CA certificate Root-CA verified successfully
user@host> request security pki ca-certificate verify ca-profile Eng-CA CA certificate Eng-CA verified successfully
user@host> request security pki ca-certificate verify ca-profile Dev-CA CA certificate Dev-CA verified successfully
Generieren Sie ein Schlüsselpaar.
user@host> request security pki generate-key-pair certificate-id Host-A type rsa size 1024
Registrieren Sie das lokale Zertifikat.
user@host> request security pki local-certificate enroll certificate-id Host-A ca-profile Dev-CA challenge-password example domain-name host-a.example.net email host-a@example.net subject DC=example,CN=Host-A, OU=DEV,O=PKI,L=Sunnyvale,ST=CA,C=US
Stellen Sie sicher, dass das lokale Zertifikat auf dem Gerät registriert ist.
user@host> show security pki local-certificate Issued to: Host-A, Issued by: C = us, O = example, CN = Dev-CA Validity: Not before: 09-17-2012 22:22 Not after: 08-13-2017 22:19 Public key algorithm: rsaEncryption(1024 bits)
Überprüfen Sie die Gültigkeit des registrierten lokalen Zertifikats.
user@host> request security pki local-certificate verify certificate-id Host-A Local certificate Host-A verification success
Überprüfen Sie den CRL-Download für konfigurierte Zertifizierungsstellenprofile.
user@host> show security pki crl CA profile: Root-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Root-CA Effective date: 09- 9-2012 13:08 Next update: 09-21-2012 02:55 CA profile: Eng-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Eng-CA Effective date: 08-22-2012 17:46 Next update: 10-24-2015 03:33 CA profile: Dev-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Dev-CA Effective date: 09-14-2012 21:15 Next update: 09-26-2012 11:02
Konfigurieren von IPsec-VPN-Optionen
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 Ihre Netzwerkkonfiguration erforderlich sind, kopieren Sie die Befehle und fügen Sie sie in die CLI auf Hierarchieebene ein, und geben Sie sie dann aus dem Konfigurationsmodus ein .[edit]
commit
set security ike proposal ike_cert_prop_01 authentication-method rsa-signatures set security ike proposal ike_cert_prop_01 dh-group group5 set security ike proposal ike_cert_prop_01 authentication-algorithm sha1 set security ike proposal ike_cert_prop_01 encryption-algorithm aes-256-cbc set security ike policy ike_cert_pol_01 mode main set security ike policy ike_cert_pol_01 proposals ike_cert_prop_01 set security ike policy ike_cert_pol_01 certificate local-certificate Host-A set security ike gateway ike_cert_gw_01 ike-policy ike_cert_pol_01 set security ike gateway ike_cert_gw_01 address 192.0.2.51 set security ike gateway ike_cert_gw_01 external-interface ge-0/0/1.0 set security ike gateway ike_cert_gw_01 local-identity 192.0.2.31 set security ipsec proposal ipsec_prop_01 protocol esp set security ipsec proposal ipsec_prop_01 authentication-algorithm hmac-sha1-96 set security ipsec proposal ipsec_prop_01 encryption-algorithm 3des-cbc set security ipsec proposal ipsec_prop_01 lifetime-seconds 300 set security ipsec policy ipsec_pol_01 proposals ipsec_prop_01 set security ipsec vpn ipsec_cert_vpn_01 bind-interface st0.1 set security ipsec vpn ipsec_cert_vpn_01 ike gateway ike_cert_gw_01 set security ipsec vpn ipsec_cert_vpn_01 ike ipsec-policy ipsec_pol_01
Schritt-für-Schritt-Anleitung
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Anweisungen hierzu finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus imCLI-Benutzerhandbuch.Verwenden des CLI-Editors im Konfigurationsmodushttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html
So konfigurieren Sie IPsec-VPN-Optionen:
Konfigurieren Sie die Optionen für Phase 1.
[edit security ike proposal ike_cert_prop_01] user@host# set authentication-method rsa-signatures user@host# set dh-group group5 user@host# set authentication-algorithm sha1 user@host# set encryption-algorithm aes-256-cbc [edit security ike policy ike_cert_pol_01] user@host# set mode main user@host# set proposals ike_cert_prop_01 user@host# set certificate local-certificate Host-A [edit security ike gateway ike_cert_gw_01] user@host# set ike-policy ike_cert_pol_01 user@host# set address 192.0.2.51 user@host# set external-interface ge-0/0/1.0 user@host# set local-identity 192.0.2.31
Konfigurieren Sie die Optionen für Phase 2.
[edit security ipsec proposal ipsec_prop_01] user@host# set protocol esp user@host# set authentication-algorithm hmac-sha1-96 user@host# set encryption-algorithm 3des-cbc user@host# set lifetime-seconds 300 [edit security ipsec policy ipsec_pol_01] user@host# set proposals ipsec_prop_01 [edit security ipsec vpn ipsec_cert_vpn_01] user@host# set bind-interface st0.1 user@host# set ike gateway ike_cert_gw_01 user@host# set ike ipsec-policy ipsec_pol_01
Ergebnisse
Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie die Befehle und eingeben.show security ike
show security ipsec
Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Konfigurationsanweisungen in diesem Beispiel, um sie zu korrigieren.
[edit] user@host# show security ike proposal ike_cert_prop_01 { authentication-method rsa-signatures; dh-group group5; authentication-algorithm sha1; encryption-algorithm aes-256-cbc; } policy ike_cert_pol_01 { mode main; proposals ike_cert_prop_01; certificate { local-certificate Host-A; } } gateway ike_cert_gw_01 { ike-policy ike_cert_pol_01; address 192.0.2.51; external-interface ge-0/0/1.0; } [edit] user@host# show security ipsec proposal ipsec_prop_01 { protocol esp; authentication-algorithm hmac-sha1-96; encryption-algorithm 3des-cbc; lifetime-seconds 300; } policy ipsec_pol_01 { proposals ipsec_prop_01; } vpn ipsec_cert_vpn_01 { bind-interface st0.1; ike { gateway ike_cert_gw_01; ipsec-policy ipsec_pol_01; } }
Wenn Sie mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf .commit
Überprüfung
Wenn die Zertifikatüberprüfung während der IKE-Aushandlung zwischen Peergeräten erfolgreich ist, werden sowohl IKE- als auch IPsec-Sicherheitszuordnungen (Security Associations, SAs) eingerichtet.
Die IKE SA ist UP, wenn das Zertifikat gültig ist. Die IKE-Sicherheitszuordnung ist nicht verfügbar, und die IPSEC-Sicherheitszuordnung wird gebildet, wenn das Zertifikat gesperrt wird, und zwar nur, wenn die Sperrprüfung auf dem Peer-Gerät konfiguriert ist
Überprüfen des IKE-Phase-1-Status
Zweck
Überprüfen Sie den Status von IKE Phase 1.
Was
Geben Sie den Befehl aus dem Betriebsmodus ein.show security ike security-associations
user@host> show security ike security-associations Index State Initiator cookie Responder cookie Mode Remote Address 2090205 DOWN 285feacb50824495 59fca3f72b64da10 Main 192.0.2.51
Überprüfen des IPsec-Phase-2-Status
Zweck
Überprüfen Sie den IPsec-Phase 2-Status.
Was
Geben Sie den Befehl aus dem Betriebsmodus ein.show security ipsec security-associations
user@host> show security ipsec security-associations Total active tunnels: 1 ID Algorithm SPI Life:sec/kb Mon vsys Port Gateway <131073 ESP:3des/sha1 a4756de9 207/ unlim - root 500 192.0.2.51 >131073 ESP:3des/sha1 353bacd3 207/ unlim - root 500 192.0.2.51
IKE- und IPsec-SA-Fehler für ein gesperrtes Zertifikat
Suchen nach gesperrten Zertifikaten
Problem
Wenn die Zertifikatüberprüfung während der IKE-Aushandlung zwischen Peergeräten fehlschlägt, stellen Sie sicher, dass das Zertifikat des Peers nicht gesperrt wurde. Ein dynamisches Zertifizierungsstellenprofil ermöglicht es dem lokalen Gerät, die Zertifikatsperrliste von der Zertifizierungsstelle des Peers herunterzuladen und den Sperrstatus des Peerzertifikats zu überprüfen. Um dynamische Zertifizierungsstellenprofile zu aktivieren, muss die Option für ein übergeordnetes Zertifizierungsstellenprofil konfiguriert werden.revocation-check crl
Lösung
So überprüfen Sie den Sperrstatus des Zertifikats eines Peers:
Identifizieren Sie das dynamische Zertifizierungsstellenprofil, das die CRL für das Peer-Gerät anzeigt, indem Sie den Befehl aus dem Betriebsmodus eingeben.show security pki crl
user@host> show security pki crl CA profile: Root-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Root-CA Effective date: 09- 9-2012 13:08 Next update: 09-21-2012 02:55 CA profile: Eng-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Eng-CA Effective date: 08-22-2012 17:46 Next update: 10-24-2015 03:33 CA profile: Dev-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Dev-CA Effective date: 09-14-2012 21:15 Next update: 09-26-2012 11:02 CA profile: dynamic-001 CRL version: V00000001 CRL issuer: C = us, O = example, CN = Sales-CA Effective date: 09-14-2012 21:15 Next update: 09-26-2012 11:02
Das Zertifizierungsstellenprofil wird automatisch auf Host A erstellt, sodass Host A die Zertifikatsperrliste von der Zertifizierungsstelle von Host B (Sales-CA) herunterladen und den Sperrstatus des Peerzertifikats überprüfen kann.
dynamic-001
Zeigen Sie CRL-Informationen für das dynamische Zertifizierungsstellenprofil an, indem Sie den Befehl aus dem Betriebsmodus eingeben.show security pki crl ca-profile dynamic-001 detail
Eingabe
user@host> show security pki crl ca-profile dynamic-001 detail CA profile: dynamic-001 CRL version: V00000001 CRL issuer: C = us, O = example, CN = Sub11 Effective date: 09-19-2012 17:29 Next update: 09-20-2012 01:49 Revocation List: Serial number Revocation date 10647C84 09-19-2012 17:29 UTC
Das Zertifikat von Host-B (Seriennummer 10647084) wurde widerrufen.
IKEv2-Fragmentierung
- Nachrichtenfragmentierung
- Konfiguration
- Mögliche Einschränkungen der Aussagekraft der erhobenen Daten
Nachrichtenfragmentierung
Die IKEv2-Nachrichtenfragmentierung, wie in RFC 7383, Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation, beschrieben, ermöglicht IKEv2 den Betrieb in Umgebungen, in denen IP-Fragmente blockiert werden können und Peers keine IPsec-Sicherheitszuordnung (Security Association, SA) einrichten können. Bei der IKEv2-Fragmentierung wird eine große IKEv2-Nachricht in eine Gruppe kleinerer Nachrichten aufgeteilt, sodass es keine Fragmentierung auf IP-Ebene gibt. Die Fragmentierung findet statt, 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 gesammelt, verifiziert, entschlüsselt und mit der ursprünglichen Nachricht zusammengeführt.
Damit eine IKEv2-Fragmentierung auftritt, müssen beide VPN-Peers die Unterstützung der Fragmentierung angeben, indem sie die Nutzlast für die IKEV2_FRAGMENTATION_SUPPORTED Benachrichtigung in den IKE_SA_INIT Austausch einschließen. Wenn beide Peers die Unterstützung für die Fragmentierung angeben, muss der Initiator des Nachrichtenaustauschs bestimmen, ob die IKEv2-Fragmentierung verwendet wird.
Auf Firewalls der SRX-Serie sind maximal 32 Fragmente pro IKEv2-Nachricht zulässig. Wenn die Anzahl der zu sendenden oder zu empfangenden IKEv2-Nachrichtenfragmente 32 überschreitet, werden die Fragmente verworfen, und der Tunnel wird nicht eingerichtet. Die erneute Übertragung einzelner Nachrichtenfragmente wird nicht unterstützt
Konfiguration
Bei Firewalls 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 Anweisung auf der Hierarchieebene [].disable
edit security ike gateway gateway-name fragmentation
Sie können die Anweisung auch verwenden, um die Größe des Pakets zu konfigurieren, bei dem Nachrichten fragmentiert werden. Die Paketgröße liegt zwischen 500 und 1300 Byte.size
Wenn diese Option nicht konfiguriert ist, beträgt die Standardpaketgröße 576 Byte für IPv4-Datenverkehr und 1280 Byte für IPv6-Datenverkehr.size
Ein IKEv2-Paket, das größer als die konfigurierte Paketgröße ist, wird fragmentiert.
Nachdem die IKEv2-Fragmentierung deaktiviert oder aktiviert oder die Paketfragmentgröße geändert wurde, werden die VPN-Tunnel, die auf dem IKE-Gateway gehostet werden, heruntergefahren und die IKE- und IPsec-Sicherheitszuordnungen neu ausgehandelt.
Mögliche Einschränkungen der Aussagekraft der erhobenen Daten
Die folgenden Funktionen werden bei der IKEv2-Fragmentierung nicht unterstützt:
Pfad-MTU-Erkennung.
SNMP.
Siehe auch
IKE-Richtlinie mit einer vertrauenswürdigen Zertifizierungsstelle
In diesem Beispiel wird gezeigt, wie ein vertrauenswürdiger CA-Server an eine IKE-Richtlinie des Peers gebunden wird.
Bevor Sie beginnen, müssen Sie über eine Liste aller vertrauenswürdigen Zertifizierungsstellen verfügen, die Sie der IKE-Richtlinie des Peers zuordnen möchten.
Sie können eine IKE-Richtlinie einem einzelnen vertrauenswürdigen Zertifizierungsstellenprofil oder einer vertrauenswürdigen Zertifizierungsstellengruppe zuordnen. Um eine sichere Verbindung herzustellen, verwendet das IKE-Gateway die IKE-Richtlinie, um sich bei der Überprüfung des Zertifikats auf die konfigurierte Gruppe von Zertifizierungsstellen (CA-Profile) zu beschränken. Ein Zertifikat, das von einer anderen Quelle als der vertrauenswürdigen Zertifizierungsstelle oder der vertrauenswürdigen Zertifizierungsstellengruppe ausgestellt wurde, wird nicht überprüft. Wenn eine Zertifikatüberprüfungsanforderung von einer IKE-Richtlinie ausgeht, wird das Zertifikat vom zugehörigen Zertifizierungsstellenprofil der IKE-Richtlinie validiert. Wenn eine IKE-Richtlinie keiner Zertifizierungsstelle zugeordnet ist, wird das Zertifikat standardmäßig von einem der konfigurierten Zertifizierungsstellenprofile überprüft.
In diesem Beispiel wird ein Zertifizierungsstellenprofil mit dem Namen a erstellt und dem Profil a zugeordnet.root-ca
root-ca-identity
Sie können maximal 20 Zertifizierungsstellenprofile konfigurieren, die Sie einer vertrauenswürdigen Zertifizierungsstellengruppe hinzufügen möchten. Sie können Ihre Konfiguration nicht bestätigen, wenn Sie mehr als 20 Zertifizierungsstellenprofile in einer vertrauenswürdigen Zertifizierungsstellengruppe konfigurieren.
Führen Sie command aus, um die Zertifizierungsstellenprofile und die auf Ihrem Gerät konfigurierten vertrauenswürdigen Zertifizierungsstellengruppen anzuzeigen .show security pki
user@host# show security ike proposal ike_prop { authentication-method rsa-signatures; dh-group group2; authentication-algorithm sha-256; encryption-algorithm aes-256-cbc; } policy ike_policy { proposals ike_prop; certificate { local-certificate SPOKE; trusted-ca ca-profile root-ca; } }
Der Befehl zeigt die Zertifizierungsstellenprofilgruppe unter dem Namen der IKE-Richtlinie und das Zertifikat an, das der IKE-Richtlinie zugeordnet ist.show security ike
ike_policy
Siehe auch
Konfigurieren von "Establish-Tunnel Responder-only" in IKE
In diesem Thema wird gezeigt, wie Sie in Internet Key Exchange (IKE) den Responder nur für die Einrichtung von Tunneln konfigurieren. Initiieren Sie die Tunnel vom Remote-Peer und leiten Sie den Datenverkehr durch alle Tunnel. Gibt an, wann IKE aktiviert ist.
Ab Junos OS Version 19.1R1 unterstützt die Option "Tunnel einrichten" in SRX5000 Zeile die Werte und unter der Hierarchieebene .responder-only
responder-only-no-rekey
[edit security ipsec vpn vpn-name]
Die Optionen und werden auf der SRX5000-Linie mit einer SPC3-Karte nur unterstützt, wenn die installiert ist.responder-only
responder-only-no-rekey
junos-ike-package
Diese Optionen werden nur in einem Site-to-Site-VPN unterstützt. Diese Optionen werden von Auto VPN nicht unterstützt.
Die Option und stellt keinen VPN-Tunnel vom Gerät her, sodass der VPN-Tunnel vom Remotepeer initiiert wird.responder-only
responder-only-no-rekey
Bei der Konfiguration schlüsselt ein eingerichteter Tunnel sowohl IKE als auch IPsec basierend auf den konfigurierten IKE- und IPsec-Lebensdauerwerten neu ein.responder-only
Wenn Sie konfigurieren, wird ein eingerichteter Tunnel nicht vom Gerät neu verschlüsselt und verlässt sich darauf, dass der Remote-Peer die erneute Schlüsselerstellung initiiert.responder-only-no-rekey
Wenn der Remotepeer die erneute Schlüsselerstellung nicht initiiert, erfolgt der Tunnelabbau nach Ablauf der festen 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:
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.