נתיב ברירת המחדל המנהרה ב-Cisco ASA: מתי הוא באמת חל

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

התחילו מהסימפטום, לא מהתצורה

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

המנהרה נראית תקינה ב-show vpn-sessiondb, וזו בדיוק הסיבה שאנשים ממשיכים לנפות שגיאות ב-IKE.

מה שמבדיל את זה מהפלת ACL הוא הכיוון. הפלת ACL נרשמת ונספרת, בעוד נתיב חסר מייצר כשל חיפוש בלי רשומה מתאימה. הריצו show route עבור היעד של הלקוח וקראו מה ASA בחרה בפועל, כולל אם נבחר נתיב ברירת מחדל ואיזה.

במה שונה החיפוש המנהרה

מדריך Cisco לניתוב סטטי ב-ASA 9.23 מתעד נתיב ברירת מחדל נפרד לתעבורת VPN מפוענחת שאין לה נתיב סטטי או נלמד. מילת המפתח tunneled מסמנת את הנתיב הזה, כך שחבילה מפוענחת יכולה לנפול לקפיצה הבאה שונה מזו ש-ASA משתמשת בה לתעבורה של עצמה. נתיבים ספציפיים יותר עדיין מנצחים, ולכן לקוח יכול להגיע ל-10.0.0.0/8 דרך השער הפנימי ולאבד את כל השאר.

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

route outside 0.0.0.0 0.0.0.0 198.51.100.1
route outside 0.0.0.0 0.0.0.0 10.20.30.1 tunneled

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

ההגבלות שקובעות אם זה יעבוד

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

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

מעקב אחר נתיבים הוא מלכודת נפרדת: האובייקט הנעקב מגן בדרך כלל על נתיב ברירת המחדל הרגיל, לא על המנהרה.

מה מילת המפתח לא עושה

היא לא בוחרת את כתובת המקור ש-ASA משתמשת בה לבניית IKE. נקודת הקצה החיצונית של המנהרה עוקבת אחר בחירת הממשק והמקור של הפלטפורמה עצמה, ולנתיב ברירת המחדל המנהרה אין חלק בהחלטה הזו. שינוי שלו לא יתקן phase 1 שמגיע מהכתובת הלא נכונה.

היא גם לא הופכת את הקפיצה הבאה לפרוקסי. אם היעד מצפה לחליפת HTTP CONNECT, שליחת חבילות IP גלמיות למארח פרוקסי נותנת לכם רק מארח שאינו מנתב אותן. תצרו במקום זאת את מנגנון הפרוקסי שהלקוח תומך בו.

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

אמתו את המסלול מקצה לקצה

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

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

תעדו את הגרסה שעליה אימתתם, משום שרשימת ההגבלות תלוית גרסה ועיצוב שעובד על סדרה אחת עשוי להזדקק למסלול אחר באחרת. ההערה הזו שורדת יותר מקטע התצורה.