VPN בין אתרים עובד, אבל יומני ASA לא מגיעים: בדקו את כתובת המקור

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

מה מגיע ומה לא

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

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

הודעה מיוצרת אינה תעבורה מועברת

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

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

איזה מקור ה-ASA שם על הרשת

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

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

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

התאימו את הבורר לזרם הרשומות

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

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

אמתו אצל האספן ואז תעדו את המקור

ודאו שההודעה מגיעה, ואז רשמו את כתובת המקור שה-ASA השתמש בה, את הבורר שנשא אותה ואת חומרת הבדיקה שבה השתמשתם.

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

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

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