SSH אל ASA מרוחק דרך VPN של האתר: שלב אחר שלב

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

בחרו את הכתובת שאתם באמת מנהלים

שלושה עיצובים נראים דומה ומתנהגים אחרת: הגעה לכתובת הציבורית של ה-ASA הפונה ל-VPN, הגעה לממשק פנימי דרך IPsec, והגעה לממשק ניהול ייעודי. רשמו את כתובת המקור של המנהל, את כתובת היעד המדויקת ואת TCP 22 לפני שאתם נוגעים בהרשאה. כל מה שבהמשך תלוי בצמד הזה.

מנהרה שנושאת שני VLAN של שרתים עשויה לא לשאת כלל את כתובת הממשק של חומת האש או את תת-הרשת לניהול של המנהל. בדקו את רשימת התעבורה המעניינת של מדיניות האתר לאתר וודאו שכתובת ה-ASA עצמה מופיעה כיעד, ולא רק תת-הרשתות שעוברות דרכו.

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

management-access ספציפי לממשק

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

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

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

בין הלקוח לבקשת שם המשתמש ניצבים ארבעה שערים עצמאיים: התאמת מסלול ומנהרה לצמד הניהול, ACL של ממשק שמתיר TCP 22 לכתובת ה-ASA, הרשאת ssh שמכסה את מקור המנהל, ואימות AAA לאותו משתמש. כל אחד מהם יכול להפיל את החבילה בלי לומר ללקוח איזה שער נסגר.

השתמשו ב-packet-tracer כדי לראות איזה שער נכשל לפני שאתם משנים משהו: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. העקבה מציינת את ה-ACL, את שלב ה-NAT ואת החלטת to-the-box, וזה בדרך כלל מספיק כדי להפריד בעיית ניתוב מבעיית קבלה.

כתבו את ההרשאה הצרה, לא הרחבה

הגבילו את ההרשאה לתת-הרשת הניהולית המאושרת ולממשק שמקבל את תעבורת המנהרה: ssh 10.10.5.0 255.255.255.0 inside. צמדו אותה לשיטת אימות כמו aaa authentication ssh console LOCAL ולחשבון מקומי נקוב, במקום לפתוח כל מקור בממשק החיצוני.

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

אמתו מהמארח הנקוב, ואז צמצמו שוב

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

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