בחירת מקור רישום יציב לחברי GET VPN

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

מה כתובת הרישום מזהה

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

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

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

loopback טוב רק כמו המסלול שלו

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

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

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

הפרד בין בקרה לתעבורה מוגנת

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

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

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

בדוק זהות לאורך המעבר

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

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

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

מה מקור יציב לא מתקן

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

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

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