IPsec בתוך IPsec: אילו כתובות המנהרה החיצונית חייבת לשאת

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

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

השערים החיצוניים A ו-B בונים את המנהרה הראשונה בין שני האתרים. מאחורי A נמצא השער הפנימי C עם כתובת מעבר 10.60.0.2; מאחורי B נמצא השער הפנימי D עם כתובת מעבר 10.70.0.2. רשתות האפליקציות נמצאות מאחורי C ו-D, וכל כתובת בדוגמה אינה חופפת בכוונה.

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

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

כל שכבה מסירה רק את ההגנה של עצמה

C מצפין חבילת אפליקציה עבור D. התוצאה ממוענת מ-C ל-D, וזה מה שמגיע ל-A. כל מה שבהמשך תלוי בשכתוב הזה.

A מצפין אותה שוב עבור B. B מפענח את השכבה החיצונית, רואה חבילה מ-C ל-D ומעביר אותה הלאה כשהיא עדיין מוצפנת. D מסיר את ההגנה הפנימית ומעביר את חבילת האפליקציה.

כך A ו-B רואים את נקודות הקצה הפנימיות ואת המטא-נתונים שלהן, אך אינם הצדדים שמפענחים את מטען האפליקציה. זו תכונה אמיתית של התכנון ולא טענה ש-C, D או מארחי האפליקציות מהימנים.

הבוררים החיצוניים נוקבים בשערים הפנימיים

כאן נכשלות רוב הבניות האלה. עבור מנהרה חיצונית מבוססת מדיניות, הבוררים שאתם מנהלים משא ומתן עליהם חייבים להכיל את הכתובות ש-A ו-B באמת מטפלים בהן: 10.60.0.2/32 ו- 10.70.0.2/32, בסדר המקומי והמרוחק הנכון.

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

אל תצרו את ההרשאה החיצונית ל-UDP 500 בלבד. לחיבור הפנימי יש נתיב נתונים משלו, שמשתמש ב-ESP או בהצפנת UDP בהתאם למה שנוהל, והמדיניות החיצונית חייבת לאפשר את הפרוטוקול הזה.

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

העברה ומלכודת הרקורסיה

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

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

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

בחנו תרגום לפני הוספת שכבות

הביטו בכל NAT מקור ב-A וב-B לפני שתכווננו משהו אחר. כלל שמשכתב את הכתובת של C לפני שהמדיניות IPsec חלה יכול לשבור את הבוררים המוסכמים, והוא יכול גם לשנות את מה ש-D מקבל בצד השני.

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

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

הוכיחו fail-closed ובדקו את ה-MTU

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

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

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