שני שערי IPsec ללא IP משותף: מה באמת עושה מעבר כשל

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

הכינו את הבמה: שתי כתובות, בלי IP צף

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

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

עברו על הכשל: לזהות, ואז לבחור מחדש

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

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

מה B יכול לרשת ומה לא

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

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

כינון יחס חדש

כש-B נבחר, הלקוח מבצע חילופי IKE חדשים: ערכי nonce חדשים, ערכי Diffie-Hellman חדשים, מזהים חדשים לאגודות הנוצרות. האימות מתרחש שוב ב-B. אם התכנון נשען על אישורי מכונה, ההתחברות מחדש יכולה להיות ללא השגחה; אם הוא דורש גורם אנושי, מישהו חייב להיות נוכח כדי שמעבר הכשל יושלם.

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

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

שני מנהרות במקביל הם תכנון אחר

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

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

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