איך לתקצב מרחב כתובות ל-VPN רב-אתרי

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

ארבעה תפקידים, ארבע שאלות שונות

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

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

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

ספירת בלוקים: מה באמת עולה /30

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

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

ipcalc -n 10.44.12.0/30
ipcalc -n 10.44.12.4/31

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

תת-הרשת של השער המנוהל אינה מאגר לקוחות

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

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

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

תעדו את התוכנית כדי שתשרוד את האתר השני

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

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

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