strongSwan vips: בקשת כתובת וירטואלית מ-IKEv2

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

מה vips מבקש, ומה הוא לא יכול להבטיח

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

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

הקטע swanctl והיכן מקומו

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

connections {
  net {
    local_addrs = 192.0.2.10
    remote_addrs = 203.0.113.5
    vips = 10.77.0.31
    children {
      net { local_ts = dynamic remote_ts = 10.77.0.0/24 }
    }
  }
}

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

swanctl --load-all --file /etc/swanctl/swanctl.conf
swanctl --initiate --child net
swanctl --list-sas

local_ts בוחר תעבורה, הוא לא יוצר כתובת

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

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

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

בדקו מה המגיב הקצה בפועל

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

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

שמרו את התכנון הסטטי בנפרד

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

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