طراحی SSL Profile در F5 BIG-IP؛ تفاوت Client SSL و Server SSL

یکی از نقاطی که در پیاده‌سازی F5 BIG-IP زیاد باعث خطا می‌شود، طراحی SSL Profile است. خیلی وقت‌ها سرویس از دید Pool سالم است، Monitor هم سبز است، اما کاربر خطای TLS می‌گیرد یا اپلیکیشن رفتار عجیبی نشان می‌دهد. دلیلش معمولاً این است که مسیر SSL درست فهمیده نشده: آیا F5 فقط SSL را Terminate می‌کند؟ آیا ترافیک تا سرور دوباره Encrypt می‌شود؟ آیا سرور پشت F5 به SNI یا Certificate خاصی نیاز دارد؟

برای اینکه طراحی درست باشد، باید تفاوت Client SSL و Server SSL را روشن کنیم. Client SSL سمت کاربر تا F5 است؛ Server SSL سمت F5 تا سرور Backend است. این دو مستقل هستند و هر کدام تنظیمات، ریسک‌ها و خطاهای خودشان را دارند.

Client SSL در F5 چیست؟

Client SSL Profile زمانی استفاده می‌شود که کاربر با HTTPS به Virtual Server وصل می‌شود و F5 باید TLS را از سمت کاربر مدیریت کند. در این حالت Certificate عمومی سرویس، Chain، Cipherها، TLS Version و گاهی SNI روی F5 تنظیم می‌شود.

کاربردهای رایج Client SSL عبارت‌اند از:

• SSL Offload برای کاهش بار سرورهای Backend
• اعمال HTTP Profile، iRule، WAF یا Header-based Routing بعد از Decrypt شدن ترافیک
• مدیریت مرکزی Certificateها روی F5
• کنترل نسخه TLS و Cipherهای مجاز در لبه سرویس

Server SSL در F5 چیست؟

Server SSL Profile برای مسیر بین F5 و سرور Backend استفاده می‌شود. اگر F5 ترافیک را بعد از Decrypt دوباره به شکل HTTPS به سرور بفرستد، به Server SSL نیاز دارید. این مدل معمولاً در سرویس‌های حساس، شبکه‌های Zero Trust، یا محیط‌هایی استفاده می‌شود که ترافیک داخلی هم نباید Plain باشد.

خطای رایج این است که تیم‌ها فقط Client SSL را تنظیم می‌کنند و انتظار دارند ارتباط Backend هم خودکار HTTPS شود. اگر Pool Member روی پورت 443 است و Server SSL ندارید، نتیجه می‌تواند خطای ارتباطی یا پاسخ نامعتبر باشد.

سه مدل رایج پیاده‌سازی SSL

۱. SSL Offload

کاربر با HTTPS به F5 وصل می‌شود، F5 ترافیک را Decrypt می‌کند و به سرور Backend با HTTP می‌فرستد. این مدل ساده‌تر است و برای برخی سرویس‌ها کافی است، اما باید مطمئن باشید مسیر داخلی از نظر امنیتی قابل قبول است.

۲. SSL Bridging یا Re-encryption

کاربر با HTTPS به F5 وصل می‌شود، F5 ترافیک را Decrypt می‌کند، سپس دوباره با HTTPS به سرور Backend وصل می‌شود. این مدل کنترل F5 را حفظ می‌کند و در عین حال ترافیک داخلی را هم رمزنگاری‌شده نگه می‌دارد.

۳. SSL Passthrough

در این مدل F5 ترافیک TLS را باز نمی‌کند و فقط بر اساس TCP Load Balancing عمل می‌کند. این روش کنترل‌های لایه ۷ مثل HTTP Routing، WAF، Header Rewrite و بسیاری از iRuleها را محدود می‌کند. اگر نیاز به کنترل محتوای HTTP دارید، Passthrough معمولاً انتخاب مناسبی نیست.

نکات مهم طراحی Client SSL

• Certificate و Intermediate Chain را کامل و معتبر نصب کنید.
• TLS 1.0 و TLS 1.1 را فقط اگر الزام قدیمی دارید نگه دارید؛ در حالت عادی حذف شوند.
• Cipher Suiteها را با سیاست امنیتی سازمان هماهنگ کنید.
• اگر چند دامنه روی یک Virtual Server دارید، SNI را دقیق طراحی کنید.
• بعد از تغییر Certificate، تست مرورگر کافی نیست؛ با ابزارهایی مثل OpenSSL هم Chain و SNI را بررسی کنید.

نکات مهم طراحی Server SSL

• بررسی کنید سرور Backend به SNI نیاز دارد یا نه.
• اگر سرور Certificate داخلی دارد، سیاست Trust را آگاهانه انتخاب کنید.
• Version و Cipher سمت Backend را با توانایی سرور هماهنگ کنید.
• اگر Health Monitor شما HTTPS است، رفتار آن را با Server SSL اشتباه نگیرید؛ هر دو باید جداگانه بررسی شوند.

خطاهای رایج در SSL Profileهای F5

چند خطا بیشتر از بقیه تکرار می‌شود: نصب ناقص Chain، فراموش کردن Server SSL برای Backend HTTPS، ناسازگاری Cipher، تنظیم نکردن SNI، استفاده از Certificate اشتباه برای دامنه، یا تغییر SSL بدون تست مسیرهای واقعی اپلیکیشن.

برای تغییرهای حساس، قبل از اجرا چک‌لیست تغییر روی F5 BIG-IP در Production را هم کنار دستتان داشته باشید.

جمع‌بندی

در F5 BIG-IP، SSL فقط نصب یک Certificate نیست. باید مسیر کاربر تا F5 و مسیر F5 تا Backend جداگانه طراحی شود. انتخاب بین Offload، Re-encryption و Passthrough باید بر اساس نیاز امنیتی، نیاز اپلیکیشن و قابلیت‌های عملیاتی تیم انجام شود.

اگر سرویس‌های HTTPS شما پشت F5 خطای TLS، مشکل Certificate، رفتار ناپایدار Session یا ابهام در SSL Offload دارند، در صفحه پیاده‌سازی F5 BIG-IP Load Balancer مسیر بررسی و اصلاح طراحی توضیح داده شده است.