מאגרי VPN בדו-מחסנית: כתובת לשתי המשפחות ב-strongSwan

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

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

שתי משפחות בפנים, נתיב אחד בחוץ

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

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

תנו ללקוח כתובת בכל משפחה

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

pools {
  pool4 { addrs = 10.90.0.0/24 }
  pool6 { addrs = fd42:90::/64 }
}
connections {
  private-access {
    version = 2
    pools = pool4, pool6
    local  { auth = pubkey  certs = gateway.pem  id = vpn.example.com }
    remote { auth = pubkey  cacerts = ca.pem  vips = 0.0.0.0, :: }
    children {
      private { local_ts = 10.60.0.0/16, fd42:60::/48  remote_ts = dynamic }
    }
  }
}

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

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

בוררים מתארים יעדים, לא מקורות

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

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

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

DNS ונתיב התשובה קובעים אם זה מרגיש גמור

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

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

אמתו את שתי המשפחות לפני שאתם מכריזים שזה גמור

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

swanctl --list-sas
swanctl --list-pools
ip -6 addr show scope global
ip -6 route get fd42:60::10

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

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