IKEv2-profiel gedefinieer maar nie aangeheg nie: volg die ketting
Die IKEv2-profiel is 'n objek, nie 'n pad nie. Volg die sleutelring, die profiel, die kriptokaart of IPsec-profiel en die koppelvlakaanhegting voordat jy fase 2 ontfout.
Die IKEv2-profiel staan in die gestoorde konfigurasie, die sleutelring is ook daar, en die tonnel kom steeds nie op nie. Op Cisco IOS XE is 'n profiel 'n objek wat identiteitspassing en verifikasiemiddels dra, en 'n objek doen niks totdat 'n ander objek daarna verwys en 'n koppelvlak daardie objek aan 'n pad heg. Die meeste mislukte ontfoutingsessies vir fase 1 slaan een van daardie verwysings oor. Lees die ketting van die sleutelring af uitwaarts voordat jy enige voorstel of beleid verander.
Wat 'n profielobjek werklik is
Die IKEv2-profiel hou die afgeleë identiteitspassing, die plaaslike en afgeleë verifikasiemetodes en 'n verwysing na 'n sleutelring vir ontwerpe met voorafgedeelde sleutels. Dit beskryf hoe 'n eweknie herken word en hoe hy homself bewys, en dit noem geen koppelvlak nie.
Die sleutelring is 'n aparte objek wat die voorafgedeelde sleutels hou. Die kriptokaart of IPsec-profiel is 'n derde objek wat na die IKEv2-profiel verwys en die beskermingsinstellings verskaf. Die koppelvlakaanhegting is die vierde stap, waar 'n kriptokaart toegepas of tonnelbeskerming geaktiveer word. Elke stap is 'n afsonderlike verwysing, en 'n ontbrekende stap laat elke objek in isolasie korrek lyk.
Volg die verwysingsketting in volgorde
Begin by die sleutelring wat die profiel noem, bevestig dan die profielnaam waarna die kriptokaart of IPsec-profiel verwys, en vind dan die koppelvlak wat daardie laaste objek gebruik. Skryf elke naam langs die objek wat dit gebruik; daardie kort lys is nuttiger as om te kontroleer dat elke verwagte blok êrens in die konfigurasie bestaan.
Die gewone onderbrekings is meganies. 'n Profielnaam verskil met een karakter van die een waarna die kriptokaart verwys. Die kriptokaart bestaan, maar is nooit op die koppelvlak toegepas nie. Die tonnelbeskermingsopdrag wys na 'n IPsec-profiel wat na 'n ander IKEv2-profiel verwys. 'n Respondent sonder uitdruklike aanhegting is 'n gedokumenteerde geval, maar 'n inisieerder sonder aanhegting is bloot nie vir die pad opgestel nie.
crypto ikev2 keyring KR-SITE
peer SITE-B
address 203.0.113.9
crypto ikev2 profile IKEV2-SITE
match identity remote address 203.0.113.9 255.255.255.255
keyring local KR-SITE
crypto ipsec profile IPSEC-SITE
set ikev2-profile IKEV2-SITE
interface Tunnel100
tunnel protection ipsec profile IPSEC-SITELees die brokkie as 'n ketting, nie as 'n sjabloon nie. Die koppelvlak noem die IPsec-profiel, die IPsec-profiel noem die IKEv2-profiel, en die IKEv2-profiel noem die sleutelring. Breek enigeen van daardie name en die konfigurasie ontleed steeds, daarom aanvaar die roeteerder dit en bly die tonnel af.
Kriptokaart en tonnelbeskerming is alternatiewe
Cisco dokumenteer twee aanhegtingsreëlings. 'n Kriptokaart kan op 'n koppelvlak toegepas word en kan deur sy set-opdrag na die IKEv2-profiel verwys. Tonnelbeskerming heg 'n IPsec-profiel aan 'n tonnelkoppelvlak. Albei is geldig, en hulle is nie bedoel om saam as 'n dubbel-slot-maatreël geïnstalleer te word nie.
Die tonnel se bron en bestemming identifiseer die buitenste afleweringsreëling, en hulle is apart van die beskermingsaanhegting. 'n LAN-koppelvlak, die tonnelkoppelvlak en die buitenste bronkoppelvlak speel drie verskillende rolle. 'n Kriptokaart op die LAN-koppelvlak beskerm nie die tonnel nie, en 'n tonnel met beskerming geaktiveer maar geen bereikbare bronadres stuur nooit 'n pakket na sy eweknie nie.
Ondersoek die gelaaide toestand, nie net die teks nie. Die geïnstalleerde weergawe het opdragte wat die opgestelde objekte aan die onderhandelde sessie koppel, en dit is diegene om in 'n kaartjie aan te haal. 'n Stoor konfigurasie bewys bedoeling; 'n sessietabel bewys die pad.
Die respondent-uitsondering is nie 'n reël vir insieerders nie
Die IOS XE-gids noem dat 'n uitdruklike IKEv2-profielaanhegting op 'n respondent opsioneel kan wees. Daardie uitsondering verwyder nie verifikasie- of identiteitskontroles nie, en dit maak die profiel nie opsioneel aan die kant wat die verbinding begin nie.
As jou roeteerder insieer, beskou die aanhegting as verpligtend en volg dit van punt tot punt. As jou roeteerder net antwoord, bevestig watter profiel werklik by die inkomende eweknie gepas het, want 'n respondent kan 'n profiel volgens identiteit eerder as volgens koppelvlakverwysing kies.
Kontroleer die pad, nie die gestoorde konfigurasie nie
Nadat die aanhegtings opeenstem, toets een toegelate toepassing en teken sy innerlike bron, bestemming en roete aan. 'n Versoek wat deur die roeteerder ontstaan, kan 'n ander bronadres gebruik as verkeer wat van die LAN af aangestuur word, en die beskermingsomvang dek moontlik net een van hulle.
'n Korrek aangehegte definisie bewys nie dat die keurders, die terugroete en die koppelvlakbeleid jou vloei dek nie. Stuur werklike verkeer en lees die onderhandelde toestand, en herhaal dit na 'n herverbinding sodat jy weet die ketting oorleef 'n nuwe onderhandeling. Hou die verduideliking binne IOS XE IKEv2; 'n historiese IKEv1-kriptokaart-ontplooiing het 'n ander objekmodel en moet nie met hierdie ketting ontfout word nie.
Skryf die vier name in die veranderingsrekord wanneer die tonnel werk. Die volgende persoon wat aan die kriptokaart raak, sal hulle nodig hê, en die ketting is die deel van die ontwerp wat die lopende konfigurasie nie verduidelik nie.