Übersicht über das IKE-Schlüsselverwaltungsprotokoll
IKE ist ein Schlüsselverwaltungsprotokoll, das dynamische Sicherheitszuordnungenerstellt. Er handelt Sicherheitszuordnungen für IPsec aus. Eine IKE-Konfiguration definiert die Algorithmen und Schlüssel, die zum Herstellen einer sicheren Verbindung mit einem Peer-Sicherheitsgateway verwendet werden.
IKE macht Folgendes:
Aushandeln und Verwalten von IKE- und IPsec-Parametern
Authentifiziert den sicheren Schlüsselaustausch
Bietet gegenseitige Peer-Authentifizierung mittels gemeinsamer geheimer Schlüssel (keine Kennwörter) und öffentlichen Schlüsseln
Bietet Identitätsschutz (im Hauptmodus)
IKE erfolgt über zwei Phasen. In der ersten Phase werden Sicherheitsattribute ausgehandelt und gemeinsame geheime Schlüssel festgelegt, um die bidirektionale IKE-Sicherheitszuordnung zu bilden. In der zweiten Phase werden eingehende und ausgehende IPsec-Sicherheitszuordnungen eingerichtet. Die IKE SA sichert die Börsen in der zweiten Phase. IKE generiert auch Keying-Material, bietet Perfect Forward Secrency und tauscht Identitäten aus.
Ab Junos OS Version 14.2 wird möglicherweise die Request failed: OID not increasing Fehlermeldung generiert, wenn Sie einen SNMP-Walk des jnxIkeTunnelEntry-Objekts in der jnxIkeTunnelTable-Tabelle ausführen. Dieses Problem tritt nur auf, wenn simultane Internet Key Exchange-Sicherheitszuordnungen (IKE-Sicherheitszuordnungen) erstellt werden, d. h. wenn beide Enden der Sicherheitszuordnung gleichzeitig IKE-Sicherheitszuordnungen initiieren. Wenn ein SNMP-MIB-Walk ausgeführt wird, um IKE-SAs anzuzeigen, erwartet das snmpwalk-Tool, dass die Objektbezeichner (OIDs) in aufsteigender Reihenfolge angezeigt werden. Bei gleichzeitigen IKE-SAs sind die OIDs in der SNMP-Tabelle jedoch möglicherweise nicht in aufsteigender Reihenfolge. Dieses Verhalten tritt auf, weil die Tunnel-IDs, die Teil der OIDs sind, basierend auf dem Initiator der IKE-Sicherheitszuordnung zugewiesen werden, der sich auf beiden Seiten des IKE-Tunnels befinden kann.
Im Folgenden finden Sie ein Beispiel für einen SNMP-MIB-Walk, der auf gleichzeitigen IKE-SAs ausgeführt wird:
jnxIkeTunLocalRole."ipsec_ss_cust554".ipv4."192.0.2.41".47885 = INTEGER: responder(2) >>> This is Initiator SA jnxIkeTunLocalRole."ipsec_ss_cust554".ipv4."192.0.2.41".47392 = INTEGER: initiator(1) >>> This is Responder's SA
Der OID-Vergleich schlägt fehl, wenn der SNMP-Walk die Tunnel-ID (47885 und 47392) ist. Es kann nicht sichergestellt werden, dass bei einem SNMP-Walk die Tunnel-IDs in aufsteigender Reihenfolge angezeigt werden, da Tunnel von beiden Seiten initiiert werden können.
Um dieses Problem zu umgehen, enthält der SNMP-MIB-Walk die Option -Cc, mit der die Überprüfung auf steigende OIDs deaktiviert werden kann. Im Folgenden finden Sie ein Beispiel für den MIB-Walk, der für die Tabelle jnxIkeTunnelEntry mit der Option -Cc ausgeführt wird:
snmpwalk -Os -Cc -c public -v 1 vira jnxIkeTunnelEntry
Tabelle "Änderungshistorie"
Die Funktionsunterstützung hängt von der Plattform und der Version ab, die Sie verwenden. Verwenden Sie den Feature-Explorer , um festzustellen, ob ein Feature auf Ihrer Plattform unterstützt wird.
Request failed: OID not increasing Fehlermeldung generiert, wenn Sie einen SNMP-Walk des jnxIkeTunnelEntry-Objekts in der jnxIkeTunnelTable-Tabelle ausführen.