ASA hairpin: יציאה לאינטרנט או רגל VPN בין אתרים?

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

שתי רגליים, ממשק אחד

החליטו איזו רגל אתם בונים לפני שאתם מקלידים כלל NAT, כי הכללים אינם ניתנים להחלפה. רגל A היא מלקוח לאינטרנט: כתובת המאגר נכנסת, כתובת ציבורית מתורגמת יוצאת, וחזרה דרך אותו ממשק. רגל B היא מלקוח לקידומת פרטית בצדו השני של עמית IPsec אחר: כתובת המאגר נשמרת, מוצפנת מחדש ונמסרת לעמית שחייב לדעת איך לענות למאגר.

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

same-security-traffic permit intra-interface

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

רגל A: הלקוח רוצה את האינטרנט

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

object network VPN_POOL
 subnet 10.80.0.0 255.255.255.0
nat (outside,outside) after-auto source dynamic VPN_POOL interface route-lookup

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

שאר הרגל רגיל: מסלול ברירת מחדל או ספציפי שמיש מהממשק החיצוני, מדיניות גישה שמתירה את הזרימה, ו-DNS שמטופל לפי מדיניות הפותר שבחרתם. הוסיפו route-lookup כאן מאותה סיבה כמו למטה, מכיוון שממשק הכניסה והיציאה זהים.

רגל B: הלקוח רוצה אתר פרטי

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

nat (outside,outside) source static VPN_POOL VPN_POOL
    destination static SITE_PREFIX SITE_PREFIX route-lookup

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

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

הבדיקה שאומרת לכם איזו רגל בניתם

השתמשו בהערכת הנתיב של ה-ASA עצמו במקום לקרוא את התצורה ולקוות. packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed מציג את החלטת ה-NAT, את המסלול ואת תוצאת ה-ACL עבור זרימה אחת; חזרו על זה עם יעד פרטי. אם שלב ה-NAT כותב מחדש זרימה מפרטי לפרטי, בניתם רגל A לחבילה שהייתה צריכה רגל B.

שתי פקודות נוספות סוגרות את הפער. show nat detail מדפיס את סדר הכללים ש-packet-tracer עקב אחריו, ו show crypto ipsec sa מראה אם קיים בורר עבור הזוג שאתם מצפים לו. SA חסר הוא עניין של תצורת בורר או עמית, לא משהו שכלל NAT יכול לתקן.

אמתו כל רגל עם התעבורה שהיא משרתת

קבלו את רגל A בבקשה ציבורית רגילה מהלקוח, ואת רגל B בבקשה למשאב פרטי שקיים באמת. אחר כך חזרו על כל אחת עם משאב שנדחה, כי „מותר“ ו„מאושר על ידי מדיניות הגישה“ אינם אותה ראיה, ופינג שמקורו במרכז אינו מתרגל אף אחד מנתיבי הלקוח.

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