Fehlerbehebung bei IOS IKEv2-Debuggern für Site-to-Site-VPN mit PSKs
Download-Optionen
-
ePub (95.1 KB)
In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
Inklusive Sprache
In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Informationen zu dieser Übersetzung
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
Einleitung
Dieses Dokument beschreibt Internet Key Exchange Version 2 (IKEv2)-Debugging-Vorgänge unter Cisco IOS® bei Verwendung eines nicht freigegebenen Schlüssels (Unshared Key, PSK).
Voraussetzungen
Anforderungen
Cisco empfiehlt, dass Sie über Kenntnisse des Paketaustauschs für IKEv2 verfügen. Weitere Informationen finden Sie unter Debuggen auf IKEv2-Paketaustausch- und Protokollebene.
Verwendete Komponenten
Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:
- Internet Key Exchange Version 2 (IKEv2)
- Cisco IOS 15.1(1)T oder spätere Version
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Konventionen
Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).
Hintergrundinformationen
Dieses Dokument enthält Informationen zur Übersetzung bestimmter Debugzeilen in einer Konfiguration.
Kernproblem
Der Paketaustausch in IKEv2 unterscheidet sich grundlegend vom Paketaustausch in IKEv1. In IKEv1 gab es einen klar abgegrenzten Phase-1-Austausch, der aus sechs (6) Paketen bestand, gefolgt von einem Phase-2-Austausch, der aus drei (3) Paketen bestand. Der IKEv2-Austausch ist variabel. Weitere Informationen zu den Unterschieden und eine Erläuterung des Paketaustauschs finden Sie unter Debuggen auf IKEv2-Paket- und Protokollebene.
Router-Konfiguration
In diesem Abschnitt werden die in diesem Dokument verwendeten Konfigurationen aufgeführt.
Router 1
interface Loopback0
ip address 192.168.1.1 255.255.255.0
!
interface Tunnel0
ip address 172.16.0.101 255.255.255.0
tunnel source Ethernet0/0
tunnel mode ipsec ipv4
tunnel destination 10.0.0.2
tunnel protection ipsec profile phse2-prof
!
interface Ethernet0/0
ip address 10.0.0.1 255.255.255.0
crypto ikev2 proposal PHASE1-prop
encryption 3des aes-cbc-128
integrity sha1
group 2
!
crypto ikev2 policy site-pol
proposal PHASE1-prop
!
crypto ikev2 keyring KEYRNG
peer peer1
address 10.0.0.2 255.255.255.0
hostname host1
pre-shared-key local cisco
pre-shared-key remote cisco
!
crypto ikev2 profile IKEV2-SETUP
match identity remote address 0.0.0.0
authentication remote pre-share
authentication local pre-share
keyring local KEYRNG
lifetime 120
!
crypto ipsec transform-set TS esp-3des esp-sha-hmac
!
crypto ipsec profile phse2-prof
set transform-set TS
set ikev2-profile IKEV2-SETUP
!
ip route 0.0.0.0 0.0.0.0 10.0.0.2
ip route 192.168.2.1 255.255.255.255 Tunnel0
Router 2
crypto ikev2 proposal PHASE1-prop
encryption 3des aes-cbc-128
integrity sha1
group 2
!
crypto ikev2 keyring KEYRNG
peer peer2
address 10.0.0.1 255.255.255.0
hostname host2
pre-shared-key local cisco
pre-shared-key remote cisco
!
crypto ikev2 profile IKEV2-SETUP
match identity remote address 0.0.0.0
authentication remote pre-share
authentication local pre-share
keyring local KEYRNG
lifetime 120
!
crypto ipsec transform-set TS esp-3des esp-sha-hmac
!
!
crypto ipsec profile phse2-prof
set transform-set TS
set ikev2-profile IKEV2-SETUP
!
interface Loopback0
ip address 192.168.2.1 255.255.255.0
!
interface Ethernet0/0
ip address 10.0.0.2 255.255.255.0
!
interface Tunnel0
ip address 172.16.0.102 255.255.255.0
tunnel source Ethernet0/0
tunnel mode ipsec ipv4
tunnel destination 10.0.0.1
tunnel protection ipsec profile phse2-prof
!
ip route 0.0.0.0 0.0.0.0 10.0.0.1
ip route 192.168.1.1 255.255.255.255 Tunnel0
Fehlerbehebung
Router-Fehlerbehebung
Die folgenden Debug-Befehle werden in diesem Dokument verwendet:
deb crypto ikev2 packet
deb crypto ikev2 internal
| Router 1 (Initiator) - Beschreibung der Nachricht | Fehlerbehebung | Router 2 (Responder) - Beschreibung der Nachricht | |
|---|---|---|---|
| Router 1 empfängt ein Paket, das mit der Crypto-ACL für Peer-ASA 10.0.0.2 übereinstimmt. Initiiert SA-Erstellung | * 11. November 20:28:34.03: IKEv2:Paket vom Verteiler erhalten |
||
| Das erste Nachrichtenpaar ist der IKE_SA_INIT-Austausch. Diese Nachrichten handeln kryptografische Algorithmen aus, tauschen Unzen aus und führen einen Diffie-Hellman-Austausch durch. Relevante Konfiguration: crypto ikev2 vorschlag PHASE1-prop verschlüsselung 3des aes-cbc-128 integrität sha1 gruppe 2crypto ikev2 keyring KEYRNG peer1 address 10.0.0.2 255.255.255.0 hostname host1 preshared-key local cisco preshared-key remote cisco |
*11. November 19:30:34.811: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=F074D8BD5A59F0B R_SPI=0000000000000000 (I) MsgID = 00000000 CurState: IDLE Ereignis: EV_INIT_SA *11. November 19:30:34.811: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=F074D8BD5A59F0B R_SPI=0000000000000000 (I) MsgID = 00000000 CurState: I_BLD_INIT Ereignis: EV_GET_IKE_POLICY * 11. November 19:30:34.811: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=F074D8BD5A59F0B R_SPI=0000000000000000 (I) MsgID = 00000000 CurState: I_BLD_INIT Event EV_SET_POLICY * 11. November 19:30:34.811: IKEv2:(SA-ID = 1):Festlegen konfigurierter Richtlinien *11. November 19:30:34.811: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=F074D8BD5A59F0B R_SPI=0000000000000000 (I) MsgID = 00000000 CurState: I_BLD_INIT Ereignis: EV_CHK_AUTH4PKI * 11. November 19:30:34.811: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=F074D8BD5A59F0B R_SPI=0000000000000000 (I) MsgID = 00000000 CurState: I_BLD_INIT Event EV_GEN_DH_KEY *11. November 19:30:34.811: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=F074D8BD5A59F0B R_SPI=0000000000000000 (I) MsgID = 00000000 CurState: I_BLD_INIT Ereignis: EV_NO_EVENT *11. November 19:30:34.811: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=F074D8BD5A59F0B R_SPI=0000000000000000 (I) MsgID = 00000000 CurState: I_BLD_INIT Ereignis: EV_OK_RECD_DH_PUBKEY_RESP *11. November 19:30:34.811: IKEv2:(SA-ID = 1):Aktion: Action_Null *11. November 19:30:34.811: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=F074D8BD5A59F0B R_SPI=0000000000000000 (I) MsgID = 00000000 CurState: I_BLD_INIT Ereignis: EV_GET_CONFIG_MODE *11. November 19:30:34.811: IKEv2:IKEv2-Initiator - keine Konfigurationsdaten zum Senden in IKE_SA_INIT-Exchange *11. November 19:30:34.811: IKEv2:Keine Konfigurationsdaten zum Senden an Toolkit: *11. November 19:30:34.811: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=F074D8BD5A59F0B R_SPI=0000000000000000 (I) MsgID = 00000000 CurState: I_BLD_INIT Ereignis: EV_BLD_MSG *11. November 19:30:34.811: IKEv2:Aufbau anbieterspezifischer Payload: LÖSCHEN-GRUND *11. November 19:30:34.811: IKEv2:Aufbau anbieterspezifischer Payload: (BENUTZERDEFINIERT) *11. November 19:30:34.811: IKEv2:Construct Notify Payload: NAT_DETECTION_SOURCE_IP *11. November 19:30:34.811: IKEv2:Construct Notify Payload: NAT_DETECTION_DESTINATION_IP |
||
| Initiator erstellt IKE_INIT_SA-Paket. Es enthält: ISAKMP-Header (SPI/Version/Flags), SAi1 (kryptografischer Algorithmus, der vom IKE-Initiator unterstützt wird), KEi (öffentlicher DH-Schlüsselwert des Initiators) und N (Initiator Nonce). | *11. November 19:30:34.811: IKEv2:(SA ID = 1):Nächste Nutzlast: SA, Version: 2.0 Austauschtyp: IKE_SA_INIT, Flags: INITIATOR Nachrichtenkennung: 0, Länge: 344 Payload-Inhalte: SA Nächste Nutzlast: KE, reserviert: 0x0, Länge: 56 letztes Angebot: 0x0, reserviert: 0x0, Länge: 52 Vorschlag: 1, Protokoll-ID: IKE, SPI-Größe: 0, #trans: 5 letzte Transformation: 0x3, reserviert: 0x0: Länge: 8 Typ: 1, reserviert: 0x0, ID: 3DES letzte Transformation: 0x3, reserviert: 0x0: Länge: 12 Typ: 1, reserviert: 0x0, ID: AES-CBC letzte Transformation: 0x3, reserviert: 0x0: Länge: 8 Typ: 2, reserviert: 0x0, ID: SHA1 letzte Transformation: 0x3, reserviert: 0x0: Länge: 8 Typ: 3, reserviert: 0x0, ID: SHA96 letzte Transformation: 0x0, reserviert: 0x0: Länge: 8 Typ: 4, reserviert: 0x0, ID: DH_GROUP_1024_MODP/Gruppe 2 KE Nächste Nutzlast: N, reserviert: 0x0, Länge: 136 DH-Gruppe: 2, Reserviert: 0x0 N Nächste Nutzlast: VID, reserviert: 0x0, Länge: 24 VID Nächste Nutzlast: VID, reserviert: 0x0, Länge: 23 VID Nächste Nutzlast: NOTIFY, reserviert: 0x0, Länge: 21 NOTIFY(NAT_DETECTION_SOURCE_IP) Nächste Nutzlast: NOTIFY, reserviert: 0x0, Länge: 28 Sicherheitsprotokoll-ID: IKE, SPI-Größe: 0, Typ: NAT_DETECTION_SOURCE_IP NOTIFY(NAT_DETECTION_DESTINATION_IP) Nächste Nutzlast: KEINE, reserviert: 0x0, Länge: 28 Sicherheitsprotokoll-ID: IKE, SPI-Größe: 0, Typ: NAT_DETECTION_DESTINATION_IP |
||
|
|
|||
| *11. November 19:30:34.814: IKEv2:Paket vom Verteiler erhalten |
Responder empfängt IKE_INIT_SA. | ||
| *Nov 11 19:30:34.814: IKEv2:Next payload: SA, version: 2.0 Exchange type: IKE_SA_INIT, flags: INITIATOR Message id: 0, length: 344 |
Der Responder initiiert die SA-Erstellung für diesen Peer. | ||
| *11. November 19:30:34.814: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=F074D8BD5A59F0B R_SPI=F94020DD8CB4B9C4 (R) MsgID = 00000000 Cur Status: IDLE-Ereignis:EV_RECV_INIT |
Der Responder verifiziert und verarbeitet die IKE_INIT-Nachricht: (1) Wählt die Crypto-Suite aus den vom Initiator bereitgestellten, (2) berechnet ihren eigenen DH-Geheimschlüssel, und (3) er berechnet einen skeyid-Wert, von dem alle Schlüssel für diese IKE_SA abgeleitet werden können. Alle Nachrichten bis auf die Header der nachfolgenden Nachrichten werden verschlüsselt und authentifiziert. Die für die Verschlüsselung und den Integritätsschutz verwendeten Schlüssel werden von SKEYID abgeleitet und heißen SK_e (Verschlüsselung), SK_a (Authentifizierung), SK_d wird abgeleitet und für die Ableitung von weiterem Schlüsselmaterial für CHILD_SAs verwendet, und für jede Richtung wird ein separater SK_e und SK_a berechnet. Relevante Konfiguration: crypto ikev2 offer PHASE1-prop encryption 3des aes-cbc-128 integrität sha1 group 2 crypto ikev2 keyring KEYRNG peer2 address 10.0.0.1 255.255.255.0 hostname host2 pre-shared-key local cisco pre-shared-key remote cisco |
||
| *11. November 19:30:34.822: IKEv2:(SA ID = 1):Nächste Nutzlast: SA, Version: 2.0 Austauschtyp: IKE_SA_INIT, Flags: RESPONDER MSG-RESPONSE Nachrichtenkennung: 0, Länge: 449 |
Router 2 erstellt die Responder-Nachricht für den IKE_SA_INIT-Austausch, die von ASA1 empfangen wird. Dieses Paket enthält: ISAKMP-Header (SPI/Version/Flags), SAr1 (kryptografischer Algorithmus, den der IKE-Responder auswählt), KEr(öffentlicher DH-Schlüsselwert des Responders) und Responder Nonce. | ||
| *11. November 19:30:34.822: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=F074D8BD5A59F0B R_SPI=F94020DD8CB4B9C4 (R) MsgID = 00000000 Cur Status: INIT_DONE-Ereignis: EV_DONE |
Router 2 sendet die Responder-Nachricht an Router 1. | ||
|
|
|||
| Router 1 empfängt das IKE_SA_INIT-Antwortpaket von Router 2. | *11. November 19:30:34.823: IKEv2:Paket vom Verteiler erhalten |
I_SPI=F074D8BBD5A59F0B R_SPI=F94020DD8CB4B9C4 (R) MsgID = 00000000 CurState: INIT_DONE Ereignis:EV_START_TMR |
Der Responder startet den Timer für den Auth-Prozess. |
| Router1 verifiziert und verarbeitet die Antwort: (1) Der geheime DH-Schlüssel des Initiators wird berechnet, und (2) die Schlüsselkennung des Initiators wird ebenfalls generiert. | *11. November 19:30:34.823: IKEv2:(SA ID = 1):Nächste Nutzlast: SA, Version: 2.0 Austauschtyp: IKE_SA_INIT, Flags: RESPONDER MSG-RESPONSE Nachrichten-ID: 0, Länge: 449 *11. November 19:30:34.824: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=F074D8BD5A59F0B R_SPI=F94020DD8CB4B9C4 (I) MsgID = 00000000 Cur Status: I_WAIT_INIT-Ereignis: EV_RECV_INIT |
||
| Der Initiator startet den IKE_AUTH-Austausch und generiert die Authentifizierungsnutzlast. Das IKE_AUTH-Paket enthält: ISAKMP-Header (SPI/Version/Flags), IDi (Initiator-Identität), AUTH-Nutzlast, SAi2 (initiiert das SA ähnlich dem Phase-2-Transformationssatzaustausch in IKEv1) und TSi und TSr (Initiator- und Responder-Datenverkehrsauswahl). Sie enthalten die Quell- und Zieladresse des Initiators bzw. des Responders für die Weiterleitung/den Empfang von verschlüsseltem Datenverkehr. Der Adressbereich gibt an, dass der gesamte Datenverkehr zu und von diesem Bereich getunnelt wird. Wenn der Vorschlag für den Beantworter akzeptabel ist, sendet er identische TS-Payloads zurück. Die erste CHILD_SA wird für das Proxy_ID-Paar erstellt, das mit dem Triggerpaket übereinstimmt. Relevante Konfiguration: crypto ipsec transform-set TS esp-3des esp-sha-hmac crypto ipsec profile phse2-prof set transformation-set TS set ikev2-profile IKEV2-SETUP |
*11. November 19:30:34.831: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=F074D8BD5A59F0B R_SPI=F94020DD8CB4B9C4 (I) MsgID = 00000000 Cur Status: I_BLD_AUTH-Ereignis:EV_GEN_AUTH *11.11.19:30:34.831: SA Nächste Nutzlast: TSi, reserviert: 0x0, Länge: 40 NOTIFY(INITIAL_CONTACT) Nächste Nutzlast: NOTIFY, reserviert: 0x0, Länge: 8 |
||
|
|
|||
| *11. November 19:30:34.832: IKEv2:Paket vom Verteiler erhalten |
Router 2 empfängt und verifiziert die von Router 1 empfangenen Authentifizierungsdaten. Relevante Konfiguration: crypto ipsec ikev2 ipsec-vorschlag AES256 protokoll esp verschlüsselung aes-256 protokoll esp integrität sha-1 md5 |
||
| *11. November 19:30:34.832: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=F074D8BD5A59F0B R_SPI=F94020DD8CB4B9C4 (R) MsgID = 00000001 Cur Status: R_WAIT_AUTH-Ereignis: EV_RECV_AUTH |
Router 2 erstellt die Antwort auf das IKE_AUTH-Paket, das von Router 1 empfangen wurde. Dieses Antwortpaket enthält: ISAKMP-Header (SPI/Version/Flags), IDr.(Responder-Identität), AUTH-Nutzlast, SAr2(initiiert das SA ähnlich dem Phase-2-Transformationssatzaustausch in IKEv1) und TSi und TSr(Initiator- und Responder-Traffic-Selektoren). Sie enthalten die Quell- und Zieladresse des Initiators bzw. des Responders für die Weiterleitung/den Empfang von verschlüsseltem Datenverkehr. Der Adressbereich gibt an, dass der gesamte Datenverkehr zu und von diesem Bereich getunnelt wird. Diese Parameter sind mit denen identisch, die von ASA1 empfangen wurden. | ||
| *11. November 19:30:34.833: IKEv2:(SA ID = 1):Nächste Nutzlast: ENCR, Version: 2.0 Austauschtyp: IKE_AUTH, Flags: RESPONDER MSG-RESPONSE Nachrichtenkennung: 1, Länge: 252 |
Der Responder sendet die Antwort für IKE_AUTH. | ||
|
|
|||
| Initiator erhält Antwort von Responder. | *11. November 19:30:34.834: IKEv2:Paket vom Verteiler erhalten |
*11. November 19:30:34.840: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=F074D8BD5A59F0B R_SPI=F94020DD8CB4B9C4 (R) MsgID = 00000001 Cur Status: AUTH_DONE-Ereignis: EV_OK_RECD_LOAD_IPSEC |
Der Responder fügt einen Eintrag in die SAD ein. |
| Router 1 überprüft und verarbeitet die Authentifizierungsdaten in diesem Paket. Router 1 fügt diese SA dann in seine SAD ein. | *11. November 19:30:34.834: IKEv2:(SA ID = 1):Nächste Nutzlast: ENCR, Version: 2.0 Austauschtyp: IKE_AUTH, Flags: RESPONDER MSG-RESPONSE Nachrichtenkennung: 1, Länge: 252 |
||
| Der Tunnel ist auf dem Initiator aktiv, und der Status zeigt READY an. | *11. November 19:30:34.841: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=F074D8BD5A59F0B R_SPI=F94020DD8CB4B9C4 (I) MsgID = 00000001 Cur Status: BEREITvent: EV_CHK_IKE_ONLY |
*11. November 19:30:34.840: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=F074D8BD5A59F0B R_SPI=F94020DD8CB4B9C4 (R) MsgID = 00000001 CurState: READY-Ereignis: EV_R_OK |
Tunnel ist auf dem Responder. Der Responder-Tunnel wird normalerweise vor dem Initiator angezeigt. |
CHILD_SA-Debugger
Dieser Austausch besteht aus einem einzelnen Anforderung/Antwort-Paar und wurde in IKEv1 als Phase-2-Austausch bezeichnet. Sie kann von beiden Seiten der IKE_SA initiiert werden, nachdem die ersten Austauschvorgänge abgeschlossen sind.
| Router 1 CHILD_SA - Beschreibung der Nachricht | Fehlerbehebung | Router 2 CHILD_SA - Beschreibung der Nachricht |
|---|---|---|
Router 1 initiiert den CHILD_SA-Austausch. Dies ist die CREATE_CHILD_SA-Anforderung. Das Paket CHILD_SA enthält normalerweise:
|
*11. November 19:31:35.873: IKEv2:Paket vom Verteiler erhalten |
|
| *11. November 19:31:35.869: IKEv2:(SA ID = 2):Nächste Nutzlast: ENCR, Version: 2.0 Austauschtyp: CREATE_CHILD_SA, Flags: INITIATOR Nachrichten-ID: 2, Länge: 460 *11. November 19:31:35.873: IKEv2:Construct Notify Payload: SET_WINDOW_SIZE |
Dieses Paket wird von Router 2 empfangen. | |
| *11. November 19:31:35.882: IKEv2:(SA ID = 2):Nächste Nutzlast: ENCR, Version: 2.0 Austauschtyp: CREATE_CHILD_SA, Flags: RESPONDER MSG-RESPONSE Nachrichtenkennung: 3, Länge: 300 |
Router 2 erstellt nun die Antwort für den CHILD_SA-Austausch. Dies ist die CREATE_CHILD_SA-Antwort. Das Paket CHILD_SA enthält normalerweise:
|
|
| Router 1 empfängt das Antwortpaket von Router 2 und schließt die Aktivierung von CHILD_SA ab. | *11. November 19:31:35.882: IKEv2:(SA ID = 2):Nächste Nutzlast: ENCR, Version: 2.0 Austauschtyp: CREATE_CHILD_SA, Flags: RESPONDER MSG-RESPONSE Meldungs-ID: 3, Länge: 300 |
Tunnelüberprüfung
ISAKMP
Command
show crypto ikev2 sa detailed
Router 1-Ausgabe
Router1#show crypto ikev2 sa detailed
IPv4 Crypto IKEv2 SA
Tunnel-id Local Remote fvrf/ivrf Status
1 10.0.0.1/500 10.0.0.2/500 none/none READY
Encr: AES-CBC, keysize: 128,
Hash: SHA96, DH Grp:2,
Auth sign: PSK, Auth verify: PSK
Life/Active Time: 120/10 sec
CE id: 1006, Session-id: 4
Status Description: Negotiation done
Local spi: E58F925107F8B73F Remote spi: AFD098F4147869DA
Local id: 10.0.0.1
Remote id: 10.0.0.2
Local req msg id: 2 Remote req msg id: 0
Local next msg id: 2 Remote next msg id: 0
Local req queued: 2 Remote req queued: 0
Local window: 5 Remote window: 5
DPD configured for 0 seconds, retry 0
NAT-T is not detected
Cisco Trust Security SGT is disabled
Initiator of SA : Yes
Router 2-Ausgabe
Router2#show crypto ikev2 sa detailed
IPv4 Crypto IKEv2 SA
Tunnel-id Local Remote fvrf/ivrf Status
2 10.0.0.2/500 10.0.0.1/500 none/none READY
Encr: AES-CBC, keysize: 128, Hash: SHA96,
DH Grp:2, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 120/37 sec
CE id: 1006, Session-id: 4
Status Description: Negotiation done
Local spi: AFD098F4147869DA Remote spi: E58F925107F8B73F
Local id: 10.0.0.2
Remote id: 10.0.0.1
Local req msg id: 0 Remote req msg id: 2
Local next msg id: 0 Remote next msg id: 2
Local req queued: 0 Remote req queued: 2
Local window: 5 Remote window: 5
DPD configured for 0 seconds, retry 0
NAT-T is not detected
Cisco Trust Security SGT is disabled
Initiator of SA : No
IPsec
Command
show crypto ipsec sa
Hinweis: In dieser Ausgabe wird der PFS-DH-Gruppenwert im Gegensatz zu IKEv1 während der ersten Tunnelaushandlung als "PFS (Y/N): N, DH-Gruppe: none" angezeigt. Nach einem erneuten Abgleich werden jedoch die richtigen Werte angezeigt. Dies ist kein Bug, obwohl das Verhalten in Cisco Bug-ID CSCug67056 beschrieben wird. (Nur registrierte Cisco Benutzer können auf interne Cisco Tools oder Informationen zugreifen.)
Der Unterschied zwischen IKEv1 und IKEv2 besteht darin, dass in letzterem die untergeordneten SAs als Teil des AUTH-Austauschs selbst erstellt werden. Die unter der Crypto Map konfigurierte DH-Gruppe wird nur während des erneuten Schlüsselvorgangs verwendet. Daher würden Sie bis zum ersten rekey 'PFS (Y/N): N, DH-Gruppe: none' sehen.
Bei IKEv1 wird ein anderes Verhalten angezeigt, da die Erstellung der untergeordneten SA im Schnellmodus erfolgt und die CREATE_CHILD_SA-Nachricht über eine Bestimmung verfügt, die die Schlüsselaustausch-Nutzlast enthält, die die DH-Parameter zur Ableitung eines neuen gemeinsamen geheimen Schlüssels angibt.
Router 1-Ausgabe
Router1#show crypto ipsec sa
interface: Tunnel0
Crypto map tag: Tunnel0-head-0,
local addr 10.0.0.1
protected vrf: (none)
local ident (addr/mask/prot/port):
(0.0.0.0/0.0.0.0/256/0)
remote ident (addr/mask/prot/port):
(0.0.0.0/0.0.0.0/256/0)
current_peer 10.0.0.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 10, #pkts encrypt:
10, #pkts digest: 10
#pkts decaps: 10, #pkts decrypt:
10, #pkts verify: 10
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 10.0.0.1,
remote crypto endpt.: 10.0.0.2
path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0
current outbound spi: 0xF6083ADD(4127734493)
PFS (Y/N): N, DH group: none
inbound esp sas:
spi: 0x6B74CB79(1802816377)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 18, flow_id: SW:18,
sibling_flags 80000040,
crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec):
(4276853/3592)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xF6083ADD(4127734493)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 17, flow_id: SW:17,
sibling_flags 80000040,
crypto map: Tunnel0-head-0
sa timing: remaining key
lifetime (k/sec): (4276853/3592)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
outbound ah sas:
outbound pcp sas:
Router 2-Ausgabe
Router2#show crypto ipsec sa
interface: Tunnel0
Crypto map tag: Tunnel0-head-0, local addr 10.0.0.2
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/256/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/256/0)
current_peer 10.0.0.1 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
#pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 10.0.0.2,
remote crypto endpt.: 10.0.0.1
path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0
current outbound spi: 0x6B74CB79(1802816377)
PFS (Y/N): N, DH group: none
inbound esp sas:
spi: 0xF6083ADD(4127734493)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 17, flow_id: SW:17,
sibling_flags 80000040,
crypto map: Tunnel0-head-0
sa timing: remaining key lifetime
(k/sec): (4347479/3584)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x6B74CB79(1802816377)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 18, flow_id: SW:18,
sibling_flags 80000040,
crypto map: Tunnel0-head-0
sa timing: remaining key
lifetime (k/sec): (4347479/3584)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
outbound ah sas:
outbound pcp sas:
Sie können auch die Ausgabe des Befehls show crypto session auf beiden Routern überprüfen. Diese Ausgabe zeigt den Tunnelsitzungsstatus als UP-ACTIVE an.
Router1#show crypto session
Crypto session current status
Interface: Tunnel0
Session status: UP-ACTIVE
Peer: 10.0.0.2 port 500
IKEv2 SA: local 10.0.0.1/500 remote 10.0.0.2/500 Active
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
Active SAs: 2, origin: crypto map
Router2#show cry session
Crypto session current status
Interface: Tunnel0
Session status: UP-ACTIVE
Peer: 10.0.0.1 port 500
IKEv2 SA: local 10.0.0.2/500 remote 10.0.0.1/500 Active
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
Active SAs: 2, origin: crypto map
Zugehörige Informationen
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
2.0 |
12-Apr-2023 |
Formatierung aktualisieren. Rezertifizierung. |
1.0 |
28-Jan-2013 |
Erstveröffentlichung |
Beiträge von Cisco Ingenieuren
- Anu M ChackoCisco Technical Marketing Leader
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)