איזה כלל ב-ASA רואה את התעבורה אחרי שה-VPN מפענח אותה

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

ה-ACL של ההצפנה עונה על שאלה אחרת

ACL של הצפנה הוא רשימת התאמה. הוא אומר למנהרה מה להצפין בין שני עמיתים; חבילה שאינה תואמת אותו פשוט אינה מוגנת. הרחבתו משנה את היקף ההגנה ולא דבר אחר.

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

מה שהגדרת העקיפה באמת מדלגת עליו

sysopt connection permit-vpn מאפשר לתעבורה מוגנת לדלג על בדיקת ה-ACL של הממשק שהייתה חלה אחרת בצד הנכנס. זה נוחות לפריסות VPN, והיא גלובלית. היא אינה נוגעת במדיניות הקבוצה ואינה נוגעת במסנן הרשאה לכל משתמש.

קראו את הערך בפועל ולא את ההנחה: show running-config all sysopt מדפיס את ההגדרה גם כשהיא מעולם לא הוגדרה במפורש, ומשם מתחיל הרבה בלבול.

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

קראו את המסנן בכיוון הפענוח

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

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

ודאו איזה מסנן מחובר באמת: show running-config group-policy ו-show vpn-sessiondb detail l2l יחד אומרים לכם מה הירש החיבור. עריכת ACL שאף מדיניות לא מפנה אליו לא משנה דבר.

אל תשתמשו באובייקט ACL אחד לשתי משימות

access-group של ממשק ו-vpn-filter נראים כמו אותו סוג אובייקט ומוערכים בנקודות שונות עם כיווני כתובת שונים. הקצאת רשימה אחת לשניהם מזמינה שינוי שמתקן את המנהרה ומרפה בשקט את הממשק הפיזי.

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

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

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

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

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