Check Point VSX VPN: בחירת קישור או אי-התאמת עמית?

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

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

שלושה תנאים שמפרידים בין שני המקרים

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

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

בנו תחילה את רשומת העמית החיצוני

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

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

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

קראו מה באמת מפרידה בחירת הקישור

המדריך של Check Point לבחירת קישור ב-R81.20 מפריד שלושה דברים שאנשים ממזגים לאחד: כיצד העמית המרוחק מפענח כתובת שער, איזה מסלול נושא את התעבורה היוצאת, ואיזו כתובת IP מקור משמשת. כל אחד עונה על שאלה אחרת. אף אחד מהם אינו משנה את הזהות שהעמית מאמת.

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

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

החליטו לפי ראיות, לא לפי חלונית ההגדרות

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

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

יישרו את שני הקצוות ושמרו את הרשומה

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

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