ارتباط بین
شعبات

نیاز سرویس‌های شعب؛ پیش از انتخاب اتصال

برنامهٔ مالی، فایل، تماس، مدیریت تجهیزات و سرویس ابری ممکن است مقصد و نیاز متفاوتی داشته باشند. مشخص کنید چه فرد یا سایت، به کدام منبع و در چه زمان دسترسی لازم دارد. عبارت «همه مثل یک شبکه» دامنهٔ امن و قابل تحویل را روشن نمی‌کند.

تعداد شعب و کاربران هم‌زمان، حجم انتقال، اهمیت خدمت و اثر قطع ارتباط ثبت شوند. نیاز شعبهٔ کوچک با مرکز پردازش یکسان نیست. اگر برنامه به تأخیر یا قطع نشست حساس است، آن را پیش از انتخاب خط در معیار پذیرش قرار دهید.

• مبدأ، مقصد و سرویس مجاز هر ارتباط
• اهمیت و وابستگی برنامه‌ها
• مصرف دو جهت و زمان پرترافیک
• مالک سایت و مسئول تأیید تغییر

توپولوژی مرکزی، مستقیم و مسیرهای جایگزین

در طرح مرکزی، شعب به مرکز متصل می‌شوند؛ این می‌تواند مدیریت سیاست را ساده‌تر کند، اما ظرفیت و وابستگی مرکز مهم‌اند. مسیر مستقیم بین سایت‌ها ممکن است برای بعضی سرویس‌ها مفید باشد و در عوض تعداد مسیر و پیچیدگی نگهداری را افزایش دهد.

انتخاب باید با جریان ترافیک، کنترل و رشد سازمان سازگار باشد. اینترنت محلی شعب و عبور از مرکز نیز شرایط متفاوتی دارند. نام‌هایی مانند WAN یا SD-WAN به‌تنهایی، ظرفیت، امنیت یا افزونگی واقعی را تضمین نمی‌کنند.

آدرس‌دهی شعب و جلوگیری از تداخل شبکه‌ها

شبکه‌های تکراری در شعب می‌توانند مسیریابی به مقصد را مبهم کنند. فهرست محدوده‌ها، سرویس‌ها و مسیرهای مدیریت را تهیه و برای رشد برنامه داشته باشید. آدرس جدید بدون هماهنگی با بقیهٔ سازمان تعیین نشود.

RFC 1918 دربارهٔ نشانی خصوصی مبنای استفاده از نشانی داخلی را بیان می‌کند؛ خصوصی‌بودن نشانی، تداخل میان دو سایت را حل نمی‌کند. تغییر آدرس یا NAT برای رفع تداخل باید با وابستگی برنامه و مستندات بررسی شود، نه صرفاً برای عبور یک Ping.

مسیر رفت‌وبرگشت، DNS و برنامهٔ واقعی

در هر سایت، مقصد و مسیر برگشت باید با سیاست هماهنگ باشند. یک مسیر خروجی درست، پاسخ را خودکار از مسیر صحیح برنمی‌گرداند. NAT و فایروال و تفاوت مسیرها در بررسی خطا دیده شوند.

DNS و دسترسی به سرویس‌های نام‌گذاری و حساب‌ها ممکن است برای کار برنامه لازم باشند. تست IP و تست نام، ورود و عملیات واقعی را جدا انجام دهید. پیام پاسخ شبکه، سرعت و صحت کار برنامهٔ سازمانی را تأیید نمی‌کند.

رمزنگاری و دسترسی محدود میان سایت‌ها

بستر خصوصی را خودکار معادل محرمانگی انتهابه‌انتها ندانید. نیاز حفاظت داده و هویت دو سر و نگهداری کلیدها مشخص شوند. معماری IPsec در RFC 4301 نمونهٔ مبنای حفاظت ترافیک IP است، نه دستور انتخاب تنظیمات روز برای همهٔ تجهیزات.

قواعد فایروال سازمانی باید فقط سرویس لازم را عبور دهند. شعبهٔ دارای مشکل نباید بی‌دلیل به همهٔ منابع مرکز دسترسی داشته باشد. آزمون مسیر مجاز و منع مسیر غیرضروری با اختیار روشن انجام شود.

ظرفیت، کیفیت و سربار مسیر

آپلود یک سایت می‌تواند دانلود مؤثر سایت دیگر را محدود کند. تأخیر، تغییر آن، از دست‌رفتن بسته و توان تجهیزات هنگام حفاظت نیز مهم‌اند. ظرفیت مرکز در طرح مرکزی با مجموع نیاز شعب سنجیده شود، نه فقط تعداد خطوط.

سربار تونل و اندازهٔ بسته می‌توانند نیاز به بررسی تنظیمات مسیر ایجاد کنند. کندی یا کارنکردن انتقال بزرگ را با شاهد بررسی کنید؛ تغییر گستردهٔ MTU یا حذف حفاظت، نسخهٔ عمومی رفع مشکل نیست. مدیریت پهنای باند دامنهٔ کنترل خود را دارد.

خط پشتیبان و رفتار هنگام خرابی سایت

خرابی خط، دروازه، مرکز یا برق را با دامنهٔ طراحی تطبیق دهید. خط دوم فقط بخشی از مشکل را پوشش می‌دهد. Failover اینترنت باید با تونل، مسیر و ظرفیت اضطراری هماهنگ باشد.

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

چک‌لیست تحویل و هزینه اتصال شعب

ابتدا یک سایت نماینده را با بکاپ، مجوز و دسترسی بازگشت وارد طرح کنید. پس از بررسی برنامه و سیاست، سایت‌های بعدی اضافه شوند. مستندات باید با وضع واقعی هماهنگ بمانند و تغییر شعب، بازبینی مسیر را فعال کند.

تعداد سایت، بستر ارتباط، تجهیزات، حفاظت، برنامه‌ها و دامنهٔ نگهداری بر هزینه اثر دارند. خط و نصب و ابزار و پشتیبانی جدا مشخص شوند. این مقاله زمان پاسخ ثابت یا اتصال بدون قطعی عمومی وعده نمی‌دهد.

• نقشهٔ سایت و محدوده آدرس و جریان سرویس ثبت
• مسیر رفت‌وبرگشت و نام‌گذاری درست
• دسترسی مجاز و منع مسیر غیرضروری آزموده
• برنامهٔ واقعی و کیفیت زیر بار مجاز بررسی
• خرابی و بازیابی و محدودیت نشست ثبت
• بکاپ و نقشه و مسئول نگهداری تحویل

طراحی ارتباط شعب در ویوان نت

تعداد سایت‌ها، سرویس‌های مشترک و مشکل فعلی را مشخص کنید تا دامنهٔ معماری و معیار آزمون تعریف شوند. تعداد کاربران و هدف بررسی را در بخش پشتیبانی ویوان نت توضیح دهید؛ رمز، کلید یا تنظیمات محرمانه را در درخواست معمولی نفرستید.