תכנון גישה פרטית ב-IKEv2 דו-מחסנית עם strongSwan

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

שלושה סוגי כתובות, שנקבעים בנפרד

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

תעבורה חיצונית ב-IPv4 בלבד עם תעבורה פנימית דו-מחסנית היא סידור רגיל ונתמך היטב.

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

הקצו כתובת וירטואלית בכל משפחה

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

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

vips = 0.0.0.0, ::

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

תארו יעדים בנפרד מהמאגרים

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

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

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

הפכו את ה-DNS ומסלולי החזור למכוונים

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

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

אחר כך כתבו את התוכנית בשש שורות: נקודת קצה חיצונית, מאגר IPv4, מאגר IPv6, קידומת שירות IPv4, קידומת שירות IPv6, והנתב שמחזיק בתשובות לכל אחד. תוכנית בצורה הזו עונה על השאלות שמפעיל באמת שואל בשלוש לפנות בוקר. כל דבר קצר יותר משאיר את הדו-מחסנית ככתובת שנייה שמוברגת למדיניות IPv4 בלבד, וכך היא בדרך כלל מסתיימת בעבודה חלקית.