איך לתכנן את מרחב הכתובות ל־VPN בין אתרים

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

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

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

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

ip -br addr show
ip route show | head -40

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

ספרו קישורים וטופולוגיה, לא התקנים

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

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

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

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

הרחיקו את תת־הרשת של השער ממאגר ה־LAN

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

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

aws ec2 describe-vpn-connections --query "VpnConnections[].{Id:VpnConnectionId,Tunnels:Tunnels[].OutsideIpAddress}" --output table

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

תעדו תפקיד, בעלים וצמיחה לכל קידומת

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

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

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