VPN یا SD-WAN؟ راهنمای ارتباط امن شعب با FortiGate

برای ارتباط امن شعب شرکت VPN کافی است یا SD-WAN؟ راهنمای طراحی با FortiGate

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

در گذشته، بسیاری از شرکت‌ها یک تونل VPN بین دو نقطه ایجاد می‌کردند و مسئله را حل‌شده می‌دانستند.

برای یک ساختار ساده با دفتر مرکزی و یک شعبه، این روش ممکن است کاملاً مناسب باشد.

اما زمانی که تعداد شعب افزایش پیدا می‌کند، چند اینترنت در هر سایت وجود دارد، سرویس‌های Cloud وارد معماری می‌شوند و کاربران برای اجرای ERP، CRM، VoIP و سایر سرویس‌های حیاتی به ارتباط پایدار نیاز دارند، مسئله دیگر فقط ساختن یک Tunnel نیست.

سؤال اصلی تغییر می‌کند:

اگر یکی از لینک‌ها ضعیف یا قطع شد، ترافیک چه مسیری را انتخاب می‌کند؟

اگر ERP از روی لینک نامناسب عبور کند چه اتفاقی می‌افتد؟

آیا تماس VoIP باید همان مسیری را طی کند که Backup حجیم شبانه استفاده می‌کند؟

اگر سازمان ۱۰ شعبه داشته باشد، مدیریت ده‌ها Tunnel و Policy چگونه انجام می‌شود؟

در چنین محیطی، طراحی ارتباط شعب باید فراتر از جمله ساده «VPN داریم» انجام شود.

ارتباط شعب از چه اجزایی تشکیل می‌شود؟

یک معماری شعبه‌ای معمولاً چند بخش مختلف دارد:

ارتباط اینترنت،

تجهیز امنیتی،

VPN،

Routing،

کنترل دسترسی،

انتخاب مسیر،

Failover،

مانیتورینگ،

و مدیریت متمرکز.

ضعف در هرکدام از این بخش‌ها می‌تواند روی کل تجربه کاربران اثر بگذارد.

فرض کنید ارتباط VPN برقرار است، اما لینک اینترنت شعبه Packet Loss دارد.

از نظر Dashboard ممکن است Tunnel همچنان Up باشد، اما کاربران ERP کندی شدیدی تجربه کنند.

یا ممکن است شعبه دو اینترنت داشته باشد، اما Failover به‌درستی طراحی نشده باشد.

در این شرایط، وجود لینک دوم لزوماً به معنی داشتن افزونگی واقعی نیست.

معماری حرفه‌ای باید هم Connectivity را ببیند و هم Quality را.

VPN چه کاری انجام می‌دهد؟

VPN امکان ایجاد ارتباط محافظت‌شده بین دو یا چند نقطه را فراهم می‌کند.

در سناریوی Site-to-Site، دفتر مرکزی و شعبه می‌توانند از طریق اینترنت عمومی یک ارتباط امن ایجاد کنند.

در سناریوی Remote Access نیز کاربران می‌توانند از بیرون سازمان به منابع مجاز دسترسی داشته باشند.

مستندات Fortinet برای FortiGate سناریوهای مختلف IPsec شامل Site-to-Site، Remote Access، VPNهای Aggregate و Redundant و معماری‌های پیشرفته‌تر را پوشش می‌دهند.

اما VPN فقط بخشی از مسئله است.

VPN مشخص می‌کند ارتباط چگونه امن شود.

در حالی که در یک شبکه چندشعبه‌ای، سؤال‌های دیگری هم مطرح هستند:

کدام لینک استفاده شود؟

چه زمانی مسیر تغییر کند؟

کدام Application اولویت داشته باشد؟

اگر کیفیت لینک کاهش پیدا کرد چه اتفاقی رخ دهد؟

ترافیک Cloud باید از مرکز عبور کند یا مستقیماً از شعبه خارج شود؟

این همان جایی است که موضوع SD-WAN وارد معماری می‌شود.

SD-WAN چیست؟

به زبان ساده، SD-WAN به سازمان کمک می‌کند چند مسیر ارتباطی را بر اساس سیاست و وضعیت شبکه مدیریت کند.

برای مثال، یک شعبه ممکن است دو ارتباط داشته باشد:

اینترنت فیبر،

و ارتباط LTE یا سرویس ISP دوم.

در یک طراحی ساده ممکن است لینک دوم فقط زمانی فعال شود که لینک اول کاملاً قطع شده باشد.

اما در طراحی پیشرفته‌تر، تصمیم‌گیری می‌تواند بر اساس معیارهای بیشتری انجام شود.

برای مثال:

Latency،

Jitter،

Packet Loss،

نوع Application،

مقصد ترافیک،

یا سیاست سازمان.

اسناد Secure SD-WAN خود Fortinet بخش‌های مستقلی برای Application Performance، Traffic Steering، QoS، High Availability، Overlay VPN و طراحی‌های Enterprise در نظر گرفته‌اند. (Fortinet Document Library)

نکته مهم این است که SD-WAN نباید به‌عنوان یک دکمه جادویی دیده شود.

اگر طراحی WAN ضعیف باشد، Policyها اشتباه باشند یا ظرفیت لینک‌ها متناسب نباشد، صرف فعال کردن SD-WAN مشکل را حل نمی‌کند.

چه زمانی VPN ساده کافی است؟

برای همه شرکت‌ها لازم نیست معماری پیچیده طراحی شود.

VPN ساده در بسیاری از سناریوها کاملاً منطقی است.

برای مثال:

یک دفتر مرکزی و یک شعبه،

تعداد محدود سرویس،

یک یا دو لینک اینترنت،

ترافیک قابل پیش‌بینی،

و نیاز پایین به انتخاب مسیر پویا.

در چنین محیطی، ممکن است یک طراحی Site-to-Site VPN به‌همراه Failover مناسب کاملاً نیاز سازمان را پوشش دهد.

هدف مهندسی همیشه استفاده از پیچیده‌ترین فناوری نیست.

هدف ایجاد معماری متناسب است.

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

چه زمانی SD-WAN جدی می‌شود؟

SD-WAN زمانی ارزش بیشتری پیدا می‌کند که پیچیدگی ارتباطات افزایش یابد.

برای مثال:

تعداد شعب زیاد شده است.

هر شعبه چند لینک ارتباطی دارد.

برنامه‌های SaaS و Cloud نقش مهمی پیدا کرده‌اند.

VoIP و Video Conference حساس به کیفیت هستند.

ترافیک Backup سنگین است.

سرویس‌های حیاتی باید مسیر پایدار داشته باشند.

مدیریت تک‌تک Siteها زمان زیادی می‌گیرد.

در چنین محیطی، تصمیم‌گیری صرفاً براساس Up یا Down بودن یک Interface کافی نیست.

ممکن است لینک Up باشد ولی کیفیت آن برای یک Application خاص مناسب نباشد.

مثال واقعی؛ ERP و Backup نباید همیشه رفتار یکسانی داشته باشند

فرض کنید یک شرکت دارای دفتر مرکزی و پنج شعبه است.

ERP در دیتاسنتر مرکزی اجرا می‌شود.

هر شعبه باید دائماً به ERP دسترسی داشته باشد.

هم‌زمان در ساعات مشخص، اطلاعات Backup بین سایت‌ها منتقل می‌شوند.

اگر ترافیک ERP و Backup بدون هیچ سیاستی از یک مسیر مشترک عبور کنند، انتقال حجیم اطلاعات می‌تواند تجربه کاربران را تحت تأثیر قرار دهد.

در طراحی مناسب می‌توان درباره مواردی مثل این تصمیم گرفت:

ERP روی مسیر با کیفیت بهتر حرکت کند.

Backup در ساعات کم‌ترافیک انجام شود.

VoIP اولویت مناسب داشته باشد.

در صورت افت کیفیت لینک اصلی، Application حساس به مسیر جایگزین هدایت شود.

اصل موضوع این است که همه ترافیک‌ها اهمیت و رفتار یکسان ندارند.

دو اینترنت داشتن با Failover واقعی فرق دارد

یکی از جملات رایج این است:

«ما دو اینترنت داریم، پس قطعی نداریم.»

اما این نتیجه‌گیری همیشه درست نیست.

باید بررسی شود:

آیا لینک دوم واقعاً قابل استفاده است؟

تغییر مسیر چقدر زمان می‌برد؟

Tunnelهای VPN روی مسیر دوم چگونه رفتار می‌کنند؟

DNS چه وضعیتی دارد؟

Sessionهای فعال چه می‌شوند؟

آیا لینک دوم ظرفیت ترافیک حیاتی را دارد؟

آیا Failover واقعاً تست شده است؟

وجود کابل ISP دوم به‌تنهایی Business Continuity ایجاد نمی‌کند.

Failover باید طراحی و آزمایش شود.

چرا کیفیت مسیر مهم‌تر از صرفاً روشن بودن آن است؟

در شبکه، Up بودن یک Interface لزوماً به معنی سالم بودن تجربه کاربر نیست.

ممکن است ارتباط وجود داشته باشد ولی:

Latency بالا باشد،

Packet Loss اتفاق بیفتد،

Jitter شدید وجود داشته باشد،

یا پهنای باند اشباع شده باشد.

برای Browsing ساده ممکن است این مشکلات کمتر دیده شوند.

اما برای سرویس‌هایی مانند VoIP، Remote Desktop، ERP یا Video Conference شرایط متفاوت است.

به همین دلیل، معماری ارتباط شعب باید Quality of Experience را نیز در نظر بگیرد.

انتخاب FortiGate باید براساس کل معماری انجام شود

در پروژه‌های شعبه‌ای، انتخاب دستگاه فقط با تعداد کاربر کافی نیست.

باید درباره این موارد اطلاعات داشته باشیم:

تعداد شعب،

تعداد لینک‌های WAN،

حجم ترافیک بین شعب،

تعداد VPN Tunnelها،

سرعت اینترنت،

Applicationهای حیاتی،

نیاز به SSL Inspection،

سرویس‌های امنیتی فعال،

نوع SD-WAN،

ترافیک Cloud،

و رشد آینده.

صفحه تجاری خرید فایروال Fortinet FortiGate امکان بررسی خانواده‌ها و مدل‌های مختلف را برای سناریوهای متفاوت سازمانی فراهم می‌کند؛ اما انتخاب نهایی باید پس از مشخص شدن وضعیت واقعی کاربران، ترافیک، VPN، شعب و نیازهای امنیتی انجام شود.

این تنها لینک مستقیم مقاله به صفحه هدف است.

دفتر مرکزی و شعبه نیاز یکسانی ندارند

یکی از اشتباهات رایج این است که برای همه Siteها دستگاه مشابه در نظر گرفته شود.

در حالی که نقش‌ها ممکن است متفاوت باشند.

دفتر مرکزی احتمالاً:

ترافیک بیشتری دارد،

VPNهای بیشتری Terminate می‌کند،

سرویس‌های Published بیشتری دارد،

لاگ بیشتری تولید می‌کند،

و نقش مرکزی‌تری در Routing دارد.

اما شعبه کوچک ممکن است فقط:

چند کاربر،

یک اینترنت،

تعدادی دوربین،

Wi-Fi،

و VPN به مرکز داشته باشد.

بنابراین Sizing باید براساس نقش واقعی هر Site انجام شود.

Hub-and-Spoke یا ارتباط مستقیم بین شعب؟

یکی از تصمیم‌های مهم معماری این است که ترافیک شعب چگونه حرکت کند.

در مدل Hub-and-Spoke، معمولاً دفتر مرکزی یا دیتاسنتر نقش Hub دارد و شعب به آن متصل می‌شوند.

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

در برخی معماری‌های بزرگ‌تر، استفاده از Overlayهای پیشرفته‌تر یا ارتباط پویا بین Siteها بررسی می‌شود.

مستندات Fortinet برای معماری‌های VPN علاوه بر Site-to-Site ساده، سناریوهای Redundant، Aggregate و مدل‌های Overlay مختلف را نیز پوشش می‌دهند.

اما دوباره باید گفت: تکنولوژی پیچیده باید برای حل مسئله واقعی استفاده شود، نه برای زیباتر شدن دیاگرام شبکه.

Local Internet Breakout چیست؟

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

این مدل در بعضی ساختارها دلایل امنیتی و مدیریتی دارد.

اما با افزایش استفاده از سرویس‌های Cloud و SaaS، ممکن است ارسال همه ترافیک به مرکز باعث ایجاد مسیر طولانی‌تر یا مصرف منابع بیشتر شود.

در برخی معماری‌ها، بخشی از ترافیک اینترنت می‌تواند مستقیماً از شعبه خارج شود؛ البته با سیاست‌های امنیتی مشخص.

این تصمیم باید براساس موارد زیر انجام شود:

سیاست امنیتی سازمان،

نوع سرویس‌ها،

نیاز به Inspection،

ساختار Logging،

و معماری مدیریت.

هیچ نسخه یکسانی برای همه شرکت‌ها وجود ندارد.

SD-WAN جای Firewall Policy را نمی‌گیرد

گاهی تصور می‌شود با فعال‌کردن SD-WAN بخش امنیت خودکار حل می‌شود.

این تصور اشتباه است.

SD-WAN روی انتخاب و مدیریت مسیر تمرکز دارد.

در حالی که سیاست امنیتی باید همچنان مشخص کند:

چه مبدأیی،

به چه مقصدی،

روی چه سرویسی،

با چه سطحی از Inspection،

اجازه ارتباط دارد.

انتخاب مسیر و کنترل امنیتی باید هماهنگ باشند.

فناوری NGFW FortiGate نیز در کنار قابلیت‌های شبکه از سرویس‌های امنیتی FortiGuard برای لایه‌های مختلف حفاظت استفاده می‌کند.

تفاوت Appliance و Subscription را جدی بگیرید

یکی از اشتباهات خرید FortiGate این است که دو پیشنهاد قیمت فقط با نام سخت‌افزار مقایسه شوند.

ممکن است هر دو پیش‌فاکتور نام یک مدل مشابه را داشته باشند، اما تفاوت مهمی در سرویس‌های همراه وجود داشته باشد.

باید بررسی شود:

Appliance تنها است یا Bundle؟

مدت Subscription چقدر است؟

چه سرویس‌هایی فعال هستند؟

نوع FortiCare چیست؟

تمدید آینده چه هزینه‌ای دارد؟

راهنمای رسمی سفارش NGFW فورتی‌نت نیز بین Appliance، FortiGuard Security Services و FortiCare Technical Support تمایز قائل می‌شود و Bundleها را به‌صورت ترکیبی ارائه می‌کند. 

بنابراین مقایسه فقط براساس قیمت نهایی می‌تواند گمراه‌کننده باشد.

آیا هر شعبه باید فایروال مستقل داشته باشد؟

پاسخ به معماری سازمان بستگی دارد.

در بسیاری از شبکه‌ها، وجود Gateway امنیتی در هر Site مزایایی دارد:

اعمال Policy محلی،

ایجاد VPN،

مدیریت WAN،

کنترل ترافیک اینترنت،

و جداسازی امنیتی شعب.

اما نوع و ظرفیت دستگاه باید متناسب باشد.

شعبه پنج‌نفره با کارخانه یا دفتر ۲۰۰ نفره یکسان نیست.

در پروژه بزرگ، مدل‌های مختلف می‌توانند در Siteهای متفاوت استفاده شوند، مشروط بر اینکه معماری مدیریت و Policy درست طراحی شود.

ارتباط کارخانه و شبکه OT شرایط متفاوتی دارد

در صنایع، مسئله فقط اتصال کاربران اداری نیست.

ممکن است در کنار IT، شبکه OT نیز وجود داشته باشد.

PLCها،

سیستم‌های کنترل،

HMI،

SCADA،

و سایر تجهیزات صنعتی معمولاً حساسیت‌های خاصی دارند.

اتصال بی‌برنامه شبکه اداری و صنعتی می‌تواند ریسک ایجاد کند.

Fortinet برای محیط‌های OT نیز سرویس‌ها و امضاهای امنیتی تخصصی ارائه می‌کند، اما طراحی شبکه صنعتی باید با شناخت دقیق فرایند، تجهیزات Legacy و الزامات Availability انجام شود. (Fortinet)

در محیط OT، تغییر Policy بدون شناخت فرایند صنعتی می‌تواند خود منبع اختلال باشد.

مدیریت مرکزی چه زمانی ضروری می‌شود؟

وقتی سازمان فقط یک یا دو FortiGate دارد، مدیریت مستقل ممکن است قابل‌قبول باشد.

اما با افزایش تعداد Siteها، چالش بیشتر می‌شود.

باید درباره این مسائل فکر کرد:

هماهنگی Policyها،

نسخه Configuration،

Firmware Management،

Change Control،

مانیتورینگ،

گزارش‌گیری،

و Troubleshooting.

در این مرحله ابزارهای مدیریت و تحلیل متمرکز اهمیت بیشتری پیدا می‌کنند.

اما باز هم صرف خرید ابزار مدیریت مرکزی، فرایند مدیریتی ایجاد نمی‌کند.

باید مشخص باشد:

چه کسی Change را تأیید می‌کند؟

چه زمانی Update انجام می‌شود؟

Rollback چگونه انجام می‌شود؟

Configuration Backup کجا قرار دارد؟

چه رخدادی نیازمند Escalation است؟

تکنولوژی باید روی فرایند صحیح قرار بگیرد.

چرا Firmware Planning مهم است؟

یکی از اشتباهات رایج در تجهیزات امنیتی، به‌روزرسانی بدون برنامه یا برعکس، سال‌ها به‌روزرسانی نکردن است.

هر دو رویکرد می‌توانند مشکل‌ساز باشند.

Upgrade باید با بررسی مواردی مانند این انجام شود:

Compatibility،

Release Notes،

Feature Changes،

Known Issues،

Backup Configuration،

Maintenance Window،

و برنامه Rollback.

در شبکه چندشعبه‌ای، انجام Upgrade بدون طراحی می‌تواند ریسک گسترده‌تری ایجاد کند.

به‌خصوص زمانی که Siteهای مختلف وابستگی عملیاتی دارند.

High Availability برای چه سازمانی لازم است؟

هر سازمانی الزاماً نیاز به HA ندارد.

اما در محیطی که فایروال Single Point of Failure است و قطع آن هزینه جدی ایجاد می‌کند، باید موضوع HA بررسی شود.

قبل از تصمیم باید پرسید:

اگر دستگاه از کار بیفتد، چند کاربر متوقف می‌شوند؟

چه سرویس‌هایی قطع خواهند شد؟

آیا شعب به مرکز دسترسی خواهند داشت؟

مدت تهیه دستگاه جایگزین چقدر است؟

هزینه Downtime چقدر است؟

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

اسناد Secure SD-WAN فورتی‌نت نیز طراحی HA را به‌عنوان یکی از سناریوهای معماری پیشرفته پوشش می‌دهند. 

مسیر Backup را جداگانه ببینید

فرض کنید شرکت بین شعبه و دفتر مرکزی Replication دارد.

نباید فرض کرد این ترافیک همیشه باید مانند ERP یا VoIP رفتار کند.

Backup معمولاً:

حجم بالا،

حساسیت کمتر به Latency،

و انعطاف زمانی بیشتری دارد.

ممکن است منطقی باشد:

در ساعات کم‌ترافیک اجرا شود،

Rate Limit داشته باشد،

یا از مسیر خاصی استفاده کند.

در مقابل ERP و VoIP ممکن است نیازمند کیفیت پایدارتر باشند.

طراحی شبکه باید تفاوت Workloadها را بشناسد.

امنیت VPN به رمزگذاری محدود نیست

یکی دیگر از اشتباهات این است که تصور شود چون Tunnel رمزگذاری شده، همه مسائل امنیتی حل شده‌اند.

باید مشخص شود:

کدام شبکه‌ها اجازه عبور دارند؟

چه Portهایی باز هستند؟

آیا هر شعبه به همه منابع مرکز دسترسی دارد؟

کاربر Remote به کدام Segment می‌رسد؟

Credentialها چگونه محافظت می‌شوند؟

MFA در کجا استفاده می‌شود؟

Logها بررسی می‌شوند یا فقط ذخیره می‌شوند؟

VPN یک مسیر امن ایجاد می‌کند، اما Policy مشخص می‌کند چه چیزی اجازه عبور دارد.

شبکه Flat در معماری چندشعبه‌ای خطرناک‌تر می‌شود

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

برای مثال، لازم نیست:

شبکه Guest شعبه،

دوربین‌ها،

کاربران عمومی،

و سرورهای مالی

همگی دسترسی آزاد به یکدیگر داشته باشند.

بهتر است هر دسترسی بر اساس نیاز واقعی تعریف شود.

اصل کمترین دسترسی فقط برای User Account نیست.

در طراحی Network نیز کاربرد دارد.

سه سناریوی عملی

سناریوی اول؛ شرکت با دو دفتر

ساختار:

دفتر مرکزی،

یک شعبه،

دو اینترنت در مرکز،

یک اینترنت در شعبه،

ERP مرکزی،

و ۲۰ کاربر Remote.

در این ساختار ممکن است طراحی Site-to-Site VPN مناسب به همراه Failover و Remote Access کنترل‌شده پاسخ‌گو باشد.

پیچیدگی غیرضروری لازم نیست.

سناریوی دوم؛ شرکت با هشت شعبه

ساختار:

هشت Branch،

ERP در مرکز،

VoIP،

سرویس‌های SaaS،

دو ISP در شعب اصلی،

و Backup بین Siteها.

در این سناریو، مدیریت مسیر، اولویت Application و مانیتورینگ Quality اهمیت بیشتری پیدا می‌کند.

SD-WAN می‌تواند جدی‌تر بررسی شود.

سناریوی سوم؛ سازمان چندسایتی بزرگ

ساختار:

دفتر مرکزی،

دیتاسنتر،

DR Site،

چندین شعبه،

کاربران Remote،

Cloud Workload،

و نیاز Availability بالا.

در چنین ساختاری، موضوع دیگر انتخاب یک مدل فایروال نیست.

باید معماری کامل شامل:

Routing،

Overlay،

Security Policy،

HA،

Management،

Logging،

Upgrade Process،

و Disaster Recovery طراحی شود.

۱۰ اشتباه رایج در پروژه ارتباط شعب

۱. خرید دستگاه قبل از طراحی توپولوژی

اول معماری، بعد مدل.

۲. انتخاب فقط براساس تعداد کاربر

تعداد Site و ترافیک بین آن‌ها نیز مهم است.

۳. فرض اینکه دو اینترنت یعنی Failover کامل

Failover باید تست شود.

۴. توجه نکردن به کیفیت مسیر

Up بودن لینک کافی نیست.

۵. یکسان دیدن تمام Applicationها

ERP، VoIP و Backup نیاز مشابهی ندارند.

۶. نبود برنامه برای رشد

اضافه شدن شعب می‌تواند معماری را تغییر دهد.

۷. مقایسه FortiGate فقط براساس Appliance

Bundle و Subscription باید بررسی شوند.

۸. Policyهای بیش‌ازحد باز

VPN نباید به معنی Full Access باشد.

۹. نبود Configuration Backup و Rollback Plan

در شبکه چندسایتی این اشتباه گران‌تر است.

۱۰. استفاده از فناوری پیچیده بدون نیاز واقعی

طراحی پیچیده همیشه طراحی بهتر نیست.

قبل از خرید FortiGate برای پروژه شعب چه اطلاعاتی آماده کنیم؟

برای پیشنهاد دقیق‌تر، این اطلاعات باید مشخص باشند:

تعداد شعب،

تعداد کاربران هر Site،

سرعت اینترنت هر شعبه،

تعداد ISPها،

تعداد VPN Tunnelها،

حجم ترافیک بین شعب،

سرویس‌های حیاتی،

محل ERP و دیتابیس،

وجود VoIP،

میزان ترافیک Cloud،

نیاز Remote Access،

نوع Authentication،

نیاز به SSL Inspection،

سطح Availability،

نیاز HA،

سیستم Logging،

و برنامه رشد سه‌ساله.

بدون این اطلاعات، انتخاب مدل بیشتر شبیه حدس خواهد بود.

FortiGate برای شعبه کوچک با مرکز اصلی یکسان نیست

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

ممکن است Branch کوچک نیاز محدودی داشته باشد.

اما Hub اصلی باید حجم بیشتری از:

VPN،

Session،

Traffic Inspection،

و ارتباطات مرکزی

را مدیریت کند.

به همین دلیل، Sizing باید برای هر نقش انجام شود.

هزینه واقعی طراحی ضعیف چیست؟

مشکل طراحی ضعیف فقط کندی اینترنت نیست.

ممکن است:

ERP قطع شود،

تماس‌های سازمانی کیفیت خود را از دست بدهند،

کاربران Remote نتوانند کار کنند،

Backup ناقص بماند،

فروش شعب متوقف شود،

یا تیم IT ساعت‌ها صرف Troubleshooting کند.

در این شرایط، اختلاف قیمت اولیه تجهیزات ممکن است کوچک‌ترین بخش هزینه باشد.

به همین دلیل، قبل از خرید باید هزینه Downtime نیز دیده شود.

آیا باید همه‌چیز را از روز اول Enterprise طراحی کرد؟

خیر.

این هم اشتباه دیگری است.

یک شرکت با دو دفتر کوچک الزاماً نیازمند معماری بسیار پیچیده نیست.

طراحی باید بتواند:

نیاز امروز را پوشش دهد،

رشد منطقی را تحمل کند،

قابل مدیریت باشد،

و هزینه آن با اهمیت سرویس‌ها تناسب داشته باشد.

Overdesign نیز می‌تواند مشکل ایجاد کند.

هر قابلیت جدید:

هزینه،

پیچیدگی،

نیاز به دانش،

و سطح بیشتری از مدیریت

اضافه می‌کند.

جمع‌بندی

برای ارتباط شعب شرکت، پاسخ همیشه «VPN» یا همیشه «SD-WAN» نیست.

VPN پایه ارتباط امن را ایجاد می‌کند.

SD-WAN زمانی ارزش بیشتری پیدا می‌کند که سازمان نیاز داشته باشد چند مسیر را مدیریت کند، کیفیت لینک‌ها را در تصمیم‌گیری دخالت دهد و ترافیک‌های مختلف را براساس نیاز واقعی هدایت کند. معماری Secure SD-WAN فورتی‌نت نیز دقیقاً مجموعه‌ای از موضوعات مانند Overlay VPN، Application Performance، Steering، QoS، HA و طراحی Enterprise را پوشش می‌دهد.

انتخاب صحیح باید از سؤال‌های واقعی آغاز شود:

چند شعبه داریم؟

چه سرویس‌هایی حیاتی‌اند؟

اگر اینترنت اصلی ضعیف شود چه اتفاقی می‌افتد؟

ERP چه مسیری را طی می‌کند؟

VoIP چه اولویتی دارد؟

Backup چه زمانی انجام می‌شود؟

Cloud Traffic از کجا خارج می‌شود؟

چه تعداد Tunnel وجود خواهد داشت؟

و معماری در سه سال آینده چقدر رشد می‌کند؟

بعد از پاسخ به این سؤال‌هاست که می‌توان درباره مدل مناسب FortiGate، نوع Subscription، طراحی VPN، SD-WAN و معماری مدیریت تصمیم گرفت.

در نهایت، ارتباط شعب فقط ساختن چند Tunnel نیست.

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

این تفاوت میان یک VPN ساده و یک معماری ارتباطی مهندسی‌شده است.