פרופיל IKEv2 מוגדר אך לא מחובר: עקבו אחר השרשרת

פרופיל ה-IKEv2 נמצא בתצורה השמורה, גם טבעת המפתחות שם, והמנהרה עדיין לא עולה. ב-Cisco IOS XE פרופיל הוא אובייקט שנושא בחירות של התאמת זהות ואימות, ואובייקט לא עושה דבר עד שאובייקט אחר מפנה אליו וממשק מחבר אותו לנתיב. רוב הפעלות איתור התקלות הכושלות של שלב 1 מפספסות אחת מההפניות האלה. קראו את השרשרת מטבעת המפתחות החוצה לפני שאתם משנים הצעה או מדיניות.

מהו למעשה אובייקט פרופיל

פרופיל ה-IKEv2 מחזיק בהתאמת הזהות המרוחקת, בשיטות האימות המקומיות והמרוחקות, ובהפניה לטבעת מפתחות לעיצובים עם מפתח משותף מראש. הוא מתאר איך מזהים עמית ואיך הוא מוכיח את עצמו, והוא אינו נוקב בשם של ממשק.

טבעת המפתחות היא אובייקט נפרד שמחזיק את המפתחות המשותפים מראש. ה-crypto map או פרופיל ה-IPsec הוא אובייקט שלישי שמפנה לפרופיל ה-IKEv2 ומספק את הגדרות ההגנה. החיבור לממשק הוא הצעד הרביעי, שבו מיושם crypto map או מופעל tunnel protection. כל דילוג הוא הפניה נפרדת, ודילוג חסר משאיר כל אובייקט נראה תקין כשהוא לבדו.

עקבו אחר שרשרת ההפניות לפי הסדר

התחילו בטבעת המפתחות שהפרופיל נוקב בשמה, אחר כך ודאו את שם הפרופיל שאליו מפנה ה-crypto map או פרופיל ה-IPsec, ואז מצאו את הממשק שצורך את האובייקט האחרון הזה. כתבו כל שם לצד האובייקט שצורך אותו; הרשימה הקצרה הזאת שימושית יותר מלבדוק שכל בלוק צפוי קיים איפשהו בתצורה.

השבירות הרגילות מכניות. שם פרופיל שונה בתו אחד מזה שאליו מפנה ה-crypto map. ה-crypto map קיים אבל מעולם לא הוחל על הממשק. פקודת tunnel protection מצביעה על פרופיל IPsec שמפנה לפרופיל IKEv2 אחר. responder בלי חיבור מפורש הוא מקרה מתועד, אבל initiator בלי חיבור פשוט אינו מוגדר לנתיב.

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-SITE

קראו את הקטע כשרשרת ולא כתבנית. הממשק נוקב בשם פרופיל ה-IPsec, פרופיל ה-IPsec נוקב בשם פרופיל ה-IKEv2, ופרופיל ה-IKEv2 נוקב בשם טבעת המפתחות. שברו כל אחד מהשמות האלה והתצורה עדיין מנותחת, ולכן הנתב מקבל אותה והמנהרה נשארת למטה.

crypto map ו-tunnel protection הם חלופות

Cisco מתעדת שתי דרכי חיבור. אפשר להחיל crypto map על ממשק והוא יכול להפנות לפרופיל ה-IKEv2 דרך פקודת ה-set שלו. tunnel protection מחבר פרופיל IPsec לממשק מנהרה. שניהם תקפים, והם לא נועדו להיות מותקנים יחד כאמצעי הגנה כפול.

המקור והיעד של המנהרה מזהים את סידור המסירה החיצוני, והם נפרדים מחיבור ההגנה. ממשק LAN, ממשק המנהרה וממשק המקור החיצוני ממלאים שלושה תפקידים שונים. crypto map על ממשק ה-LAN לא מגן על המנהרה, ומנהרה שההגנה שלה מופעלת אבל אין לה כתובת מקור נגישה לעולם לא שולחת מנה לעמית שלה.

בדקו את המצב הטעון, לא רק את הטקסט. בגרסה המותקנת יש פקודות שמחברות את האובייקטים המוגדרים למושב המנוהל, ואותן יש לצטט בכרטיס. תצורה שמורה מוכיחה כוונה; טבלת מושבים מוכיחה את הנתיב.

החריג של ה-responder אינו כלל ל-initiators

מדריך IOS XE מציין שחיבור מפורש של פרופיל IKEv2 יכול להיות אופציונלי ב-responder. החריג הזה לא מסיר בדיקות אימות או זהות, והוא לא הופך את הפרופיל לאופציונלי בצד שמתחיל את החיבור.

אם הנתב שלכם יוזם, התייחסו לחיבור כחובה ועקבו אחריו מקצה לקצה. אם הנתב שלכם רק עונה, ודאו איזה פרופיל באמת התאים לעמית הנכנס, כי responder יכול לבחור פרופיל לפי זהות ולא לפי הפניית ממשק.

בדקו את הנתיב, לא את התצורה השמורה

אחרי שהחיבורים מסתדרים, בדקו יישום אחד מורשה ורשמו את המקור, היעד והנתיב הפנימיים שלו. בקשה שהנתב יזם יכולה להשתמש בכתובת מקור אחרת מזו של תעבורה שמועברת מה-LAN, והיקף ההגנה עשוי לכסות רק אחת מהן.

הגדרה שמחוברת כראוי אינה מוכיחה שהבוררים, נתיב החזרה ומדיניות הממשק מכסים את הזרימה שלכם. שלחו תעבורה אמיתית וקראו את המצב המנוהל, ואז חזרו על כך אחרי חיבור מחדש כדי לדעת שהשרשרת שורדת משא ומתן חדש. שמרו על ההסבר בתחום IOS XE IKEv2; פריסה היסטורית של crypto map ב-IKEv1 יש לה מודל אובייקטים אחר ולא צריך לאתר בה תקלות עם השרשרת הזאת.

כתבו את ארבעת השמות ברשומת השינוי כשהמנהרה עובדת. האדם הבא שיגע ב-crypto map יזדקק להם, והשרשרת היא החלק בעיצוב שהתצורה הרצה לא מסבירה.