اینکه زیرشبکه 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 را منتشر نمی‌کند.

فرض رشد پشت هر بلوک را ثبت کنید، زیرا این همان بخشی است که هیچ خواننده بعدی نمی‌تواند تنها از نشانی‌ها بازسازی کند.

سپس طرح را با موارد دشوار بیازمایید: سایتی که با پیشوندی می‌آید که شما از قبل استفاده می‌کنید، پیوندی که سر دورش را شخص دیگری مدیریت می‌کند، و منطقه‌ای که الزام ارائه‌دهنده‌اش با نخستین موردی که مستند کردید فرق دارد. اگر هر یک از این‌ها بازطراحی را تحمیل کند، آنچه داشتید نمودار بود نه سیاست. طرحی که از آن‌ها جان سالم به در می‌برد به‌قدری کوتاه است که در مخزن کنار پیکربندی تونل بنشیند، و دقیقاً همان‌جایی است که نفر بعدی به دنبالش می‌گردد.

مقالات مرتبط