למודול ASA FirePOWER אין נתיב ניהול אל FMC

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

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

ציירו את המודול כמארח נפרד

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

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

מצאו היכן נתיב החזרה נשבר

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

קראו את התצוגה של ה-ASA עצמו לפני שמשנים משהו:

show interface ip brief
show route
show running-config interface

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

בדקו מה ASA מחשיב כמחובר

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

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

בחרו תיקון שמשאיר את המודול מחובר

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

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

רשמו רק לאחר שהנתיב עקבי

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

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

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