מסלולים סטטיים או פרוטוקול ניתוב מעל VPN מאתר לאתר?
תנודתיות הקידומות, התנהגות המעבר ומידת הנכונות התפעולית מכריעות. שקלו מה עולה להשאיר כל אפשרות נכונה, ואז בדקו את נתיב הכשל.
שתי האפשרויות מעבירות מנות בין אתרים, ולכן ההחלטה אינה בשאלה איזה פרוטוקול חדש יותר, וגם גודל המנהרה אינו מכריע אותה. שלושה תנאים מכריעים אותה: כמה קידומות משתנות ובאיזו תדירות, אם התכנון זקוק למעבר אוטומטי בין נתיבים, וכמה מכונות של שכבת הבקרה הצוות יכול להפעיל בשלוש לפנות בוקר. ענו על אלה בכנות והבחירה בדרך כלל נעשית מעצמה. שאר הטקסט הזה הוא מה שעולה כל תשובה.
שלושה תנאים מכריעים
התנאי הראשון הוא תנודתיות. קומץ תת-רשתות יציבות עם בעלות ברורה אפשר לתחזק ביד במשך שנים, וכל מסלול נשאר שורה שמישהו יכול לקרוא ולבדוק. עשרות קידומות שזזות עם בואם ולכתם של פרויקטים הן בעיה אחרת, כי כל תזוזה חייבת להגיע לכל התקן שעדיין זוכר את הנתיב הישן.
השני הוא התנהגות בכשל. כשנתיב גיבוי חייב להפוך לפעיל בלי שאדם ישים לב, משהו חייב לזהות את הכשל ולהסיר את המסלול. ניתוב סטטי יכול לעשות זאת רק באמצעות מעקב או התקנה מותנית, ורק לכשלים שחשבתם עליהם מראש.
השלישי הוא תיאבון לשכבת בקרה שנייה. פרוטוקול ניתוב מוסיף הפעלות, אימות, מסננים ומדיניות בחירה, וכל אחד מאלה דורש ניטור ותהליך שינוי. זו עלות תפעולית קבועה, לא משימת תצורה חד-פעמית.
| Condition | Points to static | Points to dynamic |
|---|---|---|
| Prefix churn | Rare, few, stable | Frequent, many, moving |
| Failover | Manual or tracked | Automatic withdrawal |
| Operations | No routing staff | Protocol monitoring exists |
הטבלה שמתחת לפסקה השלישית היא הגרסה הקצרה, ושלושת החלקים שאחריה מסבירים למה כל שורה נמצאת במקום שלה. קראו את השורות מול מספר האתרים שלכם לפני הבחירה, כי החלטה שמתעלמת מן העלות התפעולית היא רק חצי החלטה.
מה באמת עולה ניתוב סטטי
מסלול סטטי חייב להיות נכון בשני צדי המנהרה. הוספת תת-רשת פירושה עריכת השער המרוחק, השער המקומי ובדרך כלל נתיב החזרה, ושכחה של אחד מהם יוצרת כשל חד-כיווני שנראה כמו תקלה ביישום. צוות היישום רואה פסקי זמן בעוד צוות הרשת רואה מסלול שקיים ולכאורה תקין. אף צוות אינו טועה, ולכן כל כך קשה לאתר את הכשל הזה.
רשומה סטטית גם נשארת מותקנת אחרי שהנתיב שמתחתיה נעלם. אלא אם הפלטפורמה מספקת מעקב, המסלול ממשיך להצביע על קפיצה הבאה שאינה מעבירה עוד, והתנועה נעלמת במקום לעבור. הדממה הזו היא ההוצאה שאתם מקבלים על עצמכם כשבוחרים באפשרות הפשוטה.
כתבו את שיטת המעקב ליד כל מסלול, ציינו אילו כשלים היא מכסה, ושמרו את הרשימה עם תצורת המנהרה. אחרת את התקלה הבאה יגלה משתמש ולא הרשת, וזו תמיד הגילוי היקר יותר.
מה באמת עולה ניתוב דינמי
פרוטוקול מכריז על קידומות חדשות, מסיר כאלה שאינן נגישות ומביע העדפה בין נתיבים. זה מועיל באמת כשכמה אתרים או מנהרות עודפות היו זקוקים אחרת לעריכות מתואמות בכל שינוי. זו גם הסיבה שהפרוטוקול יכול להפתיע אתכם ברגע הגרוע ביותר. כל אחת מן הפעולות האלה היא שינוי מצב שלא עשיתם בעצמכם.
הוא יוצר שני מצבים שיכולים לחלוק. המנהרה יכולה להיות למעלה בעוד הפעלת הניתוב למטה, וההפעלה יכולה להיות למעלה בעוד ההכרזות שלה מדלגות על תת-הרשת שהיישום זקוק לה. שניהם נראים כמו רשת שעובדת חצי, ואף אחד מהם אינו נראה מדף מצב של מנהרה.
לכן מסננים ומדיניות הופכים לחלק מן התכנון ולא למחשבה שלאחר מעשה. פרוטוקול שמכריז על הכול יכריז בסופו של דבר על משהו שגוי, והקידומת השגויה נוסעת מהר יותר מן האדם שיכול לתקן אותה. כתבו את המסננים לפני שההפעלה הראשונה תופעל, כדי שההכרזה הראשונה תהיה כבר מכוונת.
שלטו במה שהפעלת הניתוב רשאית לומר
החליטו על רשימת הקידומות המותרת לכל עמית ואכפו אותה בכניסה, כי מסנן יוצא אינו יכול למנוע מעמית לשלוח לכם נתיב ברירת מחדל. נתיבי ברירת מחדל וצבירים הם הטעויות היקרות כאן: הם יכולים להחליף בשקט נתיבים לא קשורים ברשומה נלמדת אחת שנראית לגיטימית. דחו אותם במפורש אלא אם התכנון באמת רוצה אותם.
כתבו את האתר הבעלים ליד כל רשת לפני שההפעלה הראשונה עולה, כי המיפוי הזה הוא מקור רשימת המסננים ולא קישוט תיעודי. בלעדיו, מי שעורך מסנן צריך לנחש איזה אתר אמור להכריז על הקידומת.
הפצה מחדש בין שני פרוטוקולים היא המקום שבו מתחילות לולאות, ושבו אותה קידומת מגיעה פעמיים עם מאפיינים שאינם ניתנים להשוואה נקייה. החזיקו את ההפצה מחדש מחוץ לתכנון עד שדרישה מסוימת תכריח אותה, ואם היא חייבת להתקיים, סמנו וסננו את המסלולים בגבול.
ממשקי מנהרה מבוססי מסלולים מקלים על הצגת ניתוב דינמי, כי המנהרה הופכת לממשק עם מסלולים במקום למדיניות שמתאימה בוררים. זה אינו מסיר את שאלת היקף העמית: הבוררים של IPsec עדיין חייבים להתיר את התנועה שאתם מתכוונים לנתב.
בדקו את נתיב הכשל, לא את הנתיב המאושר
מה שתבחרו, הורידו קישור אחד למעלה וודאו שהתנועה עוברת, או שהיא נכשלת כפי שתיעדתם. תכנון שנבדק רק כששני הנתיבים תקינים הוא תכנון שלא נבדק כלל. מדדו את זמן הזיהוי בעודכם שם, כי המספר שמדדתם הוא המספר שהמשתמשים יחוו.
אחר כך ודאו את נתיב החזרה באופן עצמאי, כי ניתוב א-סימטרי מעל VPN נפוץ ובלתי נראה עד שהתקן עם מצב מפיל את התשובות. זרימה שעובדת בכיוון אחד מוכיחה רק חצי מן הנתיב.
סדר העבודה: ספרו את הקידומות, החליטו כיצד יש לזהות כשלים, בדקו מי יכול להפעיל את הפרוטוקול, שלטו במה שמוכרז, ואז בדקו הפסקה אחת מקצה לקצה. כל שלב מייצר עובדה שהשלב הבא זקוק לה.