מנהרה מפוצלת אינה מחריגה מארח ציבורי מכללי NAT של ASA

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

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

המיתוס: מנהרה מפוצלת מוציאה את חומת האש מהנתיב

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

הלקוח לא הפך לנתב. הוא פעל לפי המדיניות שנתת לו.

מה מסלול split-include באמת עושה

בהתקנת גישה מרחוק של Cisco ASA, מדיניות הקבוצה נושאת split-tunnel-policy tunnelspecified ו-split-tunnel-network-list שמציין ACL סטנדרטי. כל שורת permit ב-ACL הזה היא יעד שהלקוח צריך לשלוח אל המנהרה, וכל השאר ממשיך להשתמש בנתיב ברירת המחדל המקומי.

הוספת מארח אחד היא שורה אחת, וזה החלק היחיד בשינוי שהלקוח יכול לראות: access-list RA-SPLIT standard permit host 203.0.113.20.

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

החבילה מגיעה ויוצאת באותו ממשק

כעת עקוב אחר הזרימה לאחר הפענוח. החבילה נכנסה דרך הממשק החיצוני דרך מנהרת ה-VPN, היעד שלה הוא כתובת ציבורית, וטבלת הניתוב שולחת אותה חזרה דרך אותו ממשק חיצוני אל האינטרנט. תעבורה שנכנסת ויוצאת בממשק אחד נזרקת אלא אם ה-ASA מורשה לאפשר אותה, וזה מה ש-same-security-traffic permit intra-interface עושה. בלעדיו החיבור נכשל באופן שנראה כמו בעיית ניתוב ואינו כזה.

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

למה PAT מוגבל ליעד אינו אופציונלי

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

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

same-security-traffic permit intra-interface

object network RA_POOL
 subnet 10.77.0.0 255.255.255.0
object network PARTNER_HOST
 host 203.0.113.20

nat (outside,outside) source dynamic RA_POOL interface destination static PARTNER_HOST PARTNER_HOST

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

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

הוכח זאת עם יעד הבדיקה הנכון

השתמש במארח השותף עצמו, לא בעמוד what-is-my-ip גנרי. העמוד הזה כמעט בוודאות מחוץ לרשימת ה-split, כך שהוא מדווח את כתובת האינטרנט המקומית שלך ואינו אומר דבר על הנתיב הזה. פתח חיבור חדש לשירות השותף ושאל אותם איזה מקור ראו, או הרץ packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed וקרא את שלבי ה-NAT והניתוב שורה אחר שורה. traceroute מהלקוח הוא בדיקה חלשה יותר, כי הוא מראה את הנתיב שכבר קרה ולא את המדיניות שבחרה בו.

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

הגרסה שעובדת של העיצוב הזה קצרה: מארח אחד ב-ACL split, הרשאת hairpin, כלל PAT אחד מוגבל ליעד. כל השאר בסיפור הוא המיתוס.