ASA VPN hairpin: ניתוב שתי מנהרות דרך ממשק אחד

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

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

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

הכתובות שלמטה הן להמחשה, אבל הצורה חשובה: המקור הוא המאגר, לא ה-LAN הפנימי של ה-ASA.

remote client 10.77.0.20
  -> remote-access tunnel, terminated on ASA outside
  -> decrypted, routed, matched against site-to-site policy
  -> site-to-site tunnel, sent from ASA outside
  -> branch host 10.60.20.10

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

הרשאת hairpin היא גלובלית

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

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

היקף ההגנה וה-NAT נפרדים

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

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

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

הצפנה אינה הרשאה

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

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

hairpin או ממשק שני

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

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

אמתו מהלקוח האמיתי

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

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