המנהרה נופלת עבור יישום אחד, מישהו מריץ clear של IPsec המוגבל ל-peer, והכרטיס נסגר כי הפקודה התקבלה. שום דבר ברצף הזה לא מראה שהתקלה תוקנה. ב-ASA המילה reset מכסה שלושה תחומים נפרדים, וה-clear המוגבל ל-peer נוגע בדיוק באחד מהם, ולכן אותה מנהרה לעתים קרובות כבר חזרה למעלה לפני שהמפעיל סיים לקרוא את הפלט.

שלושה תחומים מסתתרים מאחורי מילה אחת

צמד SA של IPsec הוא נתיב הנתונים עצמו, שיוך אחד לכל כיוון, עם מספרי רצף ומונים. SA של IKE הוא ערוץ המשא ומתן שיצר את השיוכים האלה ועדיין מחזיק את הקשר עם ה-peer. הפעלת VPN היא הרשומה במסד הנתונים של ההפעלות עבור משתמש, peer מאתר לאתר או חיבור ללא לקוח.

ScopeWhat a clear removesWhat usually survives
IPsec SAData-path associations for the matching peer or selectorIKE SA, session records, crypto-map or tunnel-group config
IKE SANegotiation channel and the IPsec children derived from itSession records until they age out or are cleared
VPN sessionSession-database entry for that user or peer typeConfiguration, and any SA that is not tied to the session

התחומים עצמאיים מספיק כדי שניקוי של אחד יותיר את האחרים פועלים, והעצמאות הזו יוצרת את רוב הבלבול. נקו את ה-SA של IPsec כשהשכבה של IKE בריאה, והתעבורה תיצור שיוכים חדשים בתוך שניות, כך שהמנהרה נראית כאילו ריפאה את עצמה. אבל אי-ההתאמה בהצעה, הפער בנתיב או כשל האימות עדיין שם.

אם התקלה נמצאת במשא ומתן, clear של IPsec לא משנה דבר שאפשר לראות.

קראו את המצב כל עוד הוא קיים

רשמו את כתובת ה-peer, גרסת IKE שבשימוש, הרשתות המוגנות והמונים הכיווניים לפני שנוגעים במשהו. התצוגות הנתמכות משתנות בין גרסאות, אבל הצורות יציבות: show crypto ipsec sa peer, show crypto ikev2 sa detailed או המקבילה ל-IKEv1, ו-show vpn-sessiondb עבור שכבת ההפעלות.

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

תעדו קודם את הראיות. ה-clear מסיר אותן, וצילום מסך שנעשה אחר כך אומר לכם מה נבנה מחדש, לא מה היה שבור.

מה ה-clear המוגבל ל-peer באמת עושה

מדריך פקודות ה-clear של Cisco מתעד את הצורה המוגבלת ל-peer. עם כתובת תיעוד מוחלפת, זה נראה כך:

clear crypto ipsec sa peer 198.51.100.42

הפקודה הזו מפרקת את שיוכי ה-IPsec המתאימים ל-peer. היא לא מסירה את ה-SA של IKE, לא מוחקת תצורה ולא מאפסת את מסד ההפעלות. הריצו אותה מנתיב ניהול שאינו תלוי במנהרה שאתם משנים, כי הפעלת SSH שנישאת בתוך המנהרה הזו תמות יחד איתה ואולי לא תחזור מעצמה. כל השאר במכשיר ממשיך לפעול, וזו בדיוק הסיבה שהפקודה מרגישה לא מזיקה.

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

אמתו את השכבה שרציתם לתקן

אחרי ה-clear, אשרו שהשיוכים חזרו עם מונים חדשים במקום להניח שהאיפוס עבד כי רשימת ה-peers התמלאה מחדש. אחר כך בדקו את היישום שנקרא בכרטיס, כי ping מוצלח לא אומר דבר על הרשאת שירות או על הפעלה שפגה.

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

הסלימו עם שתי התמונות, לפני ואחרי, במקום לנקות שוב.

כשה-reset מאריך את ההשבתה

clear-ים חוזרים מסתירים את התקלות שאיפוס לא יכול לתקן: נתיב חסר, בורר שכבר לא מתאים לתת-הרשת החדשה, מפתח משותף מראש ששונה בצד אחד, או חידוש מפתח שנכשל שוב ושוב בהצעה שה-peer לא יקבל. כל clear קוטע תעבורה בריאה בכל בורר של אותו peer בזמן שהסיבה האמיתית נשארת בלי מגע. כך חקירה של חמש דקות הופכת לחלון שינוי.

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

סדר העבודה: תעדו peer, גרסה, בוררים ומונים; אשרו לאיזה תחום שייכת התקלה; הריצו את ה-clear הצר ביותר שמתאים; אמתו שיוכים ואת היישום; הסלימו עם ראיות אם השכבה התאוששה אבל התסמין לא.

מאמרים קשורים