failback ב-ASA: מה באמת זז כשהמסלול חוזר
חזרת מסלול למסלול הראשי אינה אומרת שהזרימות הישנות עברו. יש להביט יחד ב-uplink, במנהרה, בטבלת החיבורים ובתוצאת היישום.
ב-ASA עם שני uplink-ים, failback אינו ההפך של failover. המסלול אל ה-peer משתנה, ואחר כך הפלטפורמה חייבת ליישב שלוש מכונות מצב נפרדות: טבלת המסלולים, אסוציאציות האבטחה של IKE ו-IPsec, וטבלת החיבורים. כל אחת מהן עלולה לפגר אחרי האחרות, והפיגור הזה הוא מה שרוב האנשים מתארים כמנהרה שאינה חוזרת.
מה failback באמת משנה
חיפוש המסלול הוא החלק הנראה לעין. כשהאובייקט במעקב מתאושש, המסלול במעקב אל הכתובת החיצונית של ה-peer חוזר, והחבילה הבאה שה-ASA שולח יוצאת שוב בקישור הראשי. כל מה שאחרי זה תלוי בשאלה אם המצב הקיים מתיישב עם המסלול החדש.
ARP ו-NAT הם התלויות השקטות. next hop חדש זקוק לשער שאפשר לפתור ולממפה שעדיין מתאימה לקצה המרוחק, אחרת החבילות הראשונות אחרי failback לא הולכות לשום מקום והמסלול נראה תקין בעוד שום דבר לא עובד.
ארבע נקודות מבט על ציר זמן אחד
תעדו את אותם ארבעה דברים לפני המעבר, בזמן המעבר ואחריו, כי תמונת מצב אחת אינה יכולה לומר איזו שכבה זזה.
| View | What to record |
|---|---|
| Uplink and route | Interface state, the tracked object result, the route selected for the outer peer address |
| IKE and IPsec | The live peer, IKE version, security associations, protected-traffic counters |
| Connection table | Interface and endpoint pair for old flows and for flows created after the change |
| Application | One pre-existing operation and one fresh request, each marked success, reset, stall or recovered |
מסלול שלא השתנה מעולם ומסלול שהשתנה בזמן שחיבור ותיק יותר שמר על מצב ההעברה שלו מייצרים את אותה תלונה וראיות שונות לחלוטין.
מדוע חיבורים ישנים נשארים במסלול הגיבוי
ה-ASA אינו מפרק זרימה מפני שמסלול השתנה. חיבורים מבוססים שומרים על החלטת ההעברה שאיתה נוצרו, והפלטפורמה מציגה בקרות נפרדות לכמה זמן זה מותר: floating-connection timeout ו-connection holddown. ה-מדריך הגדרות החיבור של ASA 9.24 של Cisco מתייחס אליהם כאל שאלות נפרדות, וזה בדיוק איך שהם מתנהגים. האחד שולט בהישרדותה של זרימה קיימת, והשני שולט מתי זרימות חדשות רשאיות להשתמש במסלול המועדף.
קראו את הערכים התקפים בגרסה שלכם לפני שתשנו מי מהם. הורדתם סוגרת הפעלות שאנשים עדיין משתמשים בהן. העלאתם גורמת ל-failback להיראות כאילו מעולם לא קרה, כי חיבורים חדשים ממשיכים לקחת את המסלול הישן כל אותו הזמן.
מנהרה אינה מנהלת מחדש מפתחות מפני שמסלול חזר
אסוציאציות האבטחה של IPsec נושאות אורך חיים מנוהל משלהן, והן שורדות את שינוי המסלול שנשא אותן. לכן מנהרה יכולה להישאר למעלה לאורך failback בשעה שהמיעון החיצוני שלה אינו תואם עוד את המסלול שבשימוש, וזו הטענה בעד DPD ובעד תכנונים שמקבעים את כתובת ה-peer במקום לתת לה לצוף.
תכנוני crypto-map ו-VTI מתנהגים כאן אחרת, והתיעוד של Cisco ל-9.24 VTI מתאר את האפשרות המבוססת מסלול. הטענה הישנה והגורפת ש-ASA אינו יכול להריץ VPN מבוסס מסלול אינה תקפה לגרסאות הנתמכות.
קראו את הראיות בסדר הזה
התחילו במישור הבקרה: show route למסלול הנבחר, show interface למצב הקישור, ומוני ה-SLA monitor עבור האובייקט במעקב. אחר כך קראו show crypto ikev2 sa, או המקבילה ל-IKEv1, כדי לראות איזה peer חי, ואחריו show crypto ipsec sa עבור הזרימות המוגנות. לאחר מכן צמצמו את טבלת החיבורים בעזרת show conn address <host> והשוו את עמודת הממשק בין רשומות ישנות לחדשות. רשמו את הפלטים עם חותמות זמן, כי הסדר שלהם הוא האבחון.
סיימו בבדיקת יישום: זרימה אחת שכבר הייתה קיימת ואחת שנוצרה אחרי שהמסלול חזר. אם הזרימה הישנה נכשלת והחדשה עובדת, יש לכם סיפור של מצב חיבור. אם שתיהן נכשלות, המנהרה או המדיניות שגויות וטבלת החיבורים היא הסחת דעת.
שמרו את התיעוד באותה צורה בכל שלושת השלבים ורשמו את הגרסה המדויקת. כשציר הזמן ממשיך להצביע על מעבר אחד בלבד, שלחו את התיעוד לתמיכה במקום לנחש מזהה באג.