CloudFlare چیست؟

کلادفلر (Cloudflare) یک شبکهٔ جهانی است که چهار نقش را همزمان بازی می‌کند: میزبان DNS معتبر دامنه، پروکسی معکوس (Reverse Proxy)، شبکهٔ توزیع محتوا (CDN) و فایروال لایهٔ اپلیکیشن (WAF). وقتی دامنه‌ای را به آن می‌سپارید، درخواست بازدیدکننده به‌جای اینکه مستقیم به سرور شما برسد، اول به نزدیک‌ترین نقطهٔ حضور کلادفلر می‌رود و از آنجا به سرور اصلی (Origin) هدایت می‌شود؛ نتیجه این است که IP سرور شما در پاسخ DNS دیده نمی‌شود و بخشی از ترافیک اصلاً به سرور نمی‌رسد.

کلادفلر کجای مسیر قرار می‌گیرد

برای فعال شدن کلادفلر، نیم‌سرورهای (Nameserver) دامنه در پنل ثبت‌کننده به نیم‌سرورهای کلادفلر تغییر می‌کند. از آن لحظه کلادفلر مرجع رسمی رکوردهای DNS دامنه است و پاسخ همهٔ پرس‌وجوها را می‌دهد.

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

در پنل کلادفلر هر رکورد A، AAAA یا CNAME یک کلید ابری کنارش دارد. حالت خاکستری (DNS only) یعنی کلادفلر فقط IP واقعی شما را برمی‌گرداند و هیچ دخالتی در ترافیک ندارد. حالت نارنجی (Proxied) یعنی کلادفلر به‌جای IP سرور شما IP خودش را برمی‌گرداند و ترافیک از دل شبکهٔ آن عبور می‌کند. تقریباً همهٔ قابلیت‌های شاخص کلادفلر — کش، WAF، صفحهٔ چالش و آمار ترافیک — فقط در حالت نارنجی معنا دارند.

اگر هدف شما صرفاً یک DNS پایدار است و نمی‌خواهید ترافیک وب از لایهٔ واسط عبور کند، سرویس DNS هاستینگ آنلاین سرور رکوردهای A، AAAA، CNAME، MX و TXT را روی یک کلاستر چهار نیم‌سروری نگه می‌دارد و افزودن و ویرایش رکوردها به‌صورت آنی از پنل انجام می‌شود.

پنهان شدن IP سرور اصلی و جاهایی که لو می‌رود

در حالت پروکسی، پاسخ DNS دامنهٔ شما IP کلادفلر است؛ پس مهاجم مستقیماً نمی‌داند سرور اصلی کجاست و حجم زیادی از حملات به لبهٔ شبکهٔ کلادفلر می‌خورد نه به سرور شما. اما این پنهان‌سازی کامل نیست:

• رکورد MX را نمی‌توان پروکسی کرد. اگر ایمیل روی همان سرور سایت اجرا می‌شود، رکورد MX یا رکورد mail مستقیماً به IP سرور اشاره می‌کند.
• سوابق تاریخی DNS در سرویس‌های ثالث ذخیره شده‌اند؛ IP پیش از فعال‌سازی کلادفلر همچنان قابل بازیابی است.
• هدرهای ایمیل خروجی، پیام‌های خطای اپلیکیشن و گواهی TLS نصب‌شده روی خود IP هم می‌توانند سرور را افشا کنند.

راه‌حل عملی این است که فایروال سرور روی پورت‌های ۸۰ و ۴۴۳ فقط رنج‌های IP کلادفلر را بپذیرد؛ در این حالت حتی اگر IP لو برود، اتصال مستقیم پذیرفته نمی‌شود. برای اینکه ببینید دامنهٔ شما همین حالا چه IP، چه گواهی و چه رکوردهایی را به بیرون نشان می‌دهد، ابزار رایگان چکاپ سایت این موارد را در یک گزارش کنار هم می‌گذارد.

CDN و کش: دقیقاً چه چیزی کش می‌شود

کلادفلر به‌صورت پیش‌فرض فقط فایل‌های ایستا را بر اساس پسوند کش می‌کند: تصاویر، CSS، جاوااسکریپت و فونت. خروجی HTML کش نمی‌شود، چون ممکن است برای کاربر لاگین‌کرده شخصی‌سازی شده باشد. اگر HTML را هم می‌خواهید کش کنید، باید با Page Rules یا Cache Rules صریحاً تعریفش کنید و همزمان مسیرهای پویا مثل سبد خرید، پنل مدیریت و APIها را کنار بگذارید. همین کار را می‌توان روی خود سرور و پیش از خروج ترافیک هم انجام داد؛ نصب و پیکربندی Varnish Cache پاسخ صفحه‌ها را در رم نگه می‌دارد و بار PHP و دیتابیس را کم می‌کند.

ضمناً هدرهای Cache-Control سرور شما نادیده گرفته نمی‌شوند؛ رفتار نهایی حاصل ترکیب تنظیمات کلادفلر و هدرهای Origin است. پس وقتی نسخهٔ به‌روزشده دیده نمی‌شود، اول هدرهای خروجی سرور را بررسی کنید.

WAF و لایهٔ امنیتی

فایروال اپلیکیشن کلادفلر روی ترافیک پروکسی‌شده الگوهای حملهٔ رایج مانند SQL Injection و XSS را تشخیص می‌دهد و بسته به تنظیمات، درخواست را مسدود می‌کند، به چالش می‌کشد یا فقط ثبت می‌کند. در کنار آن Rate Limiting، مدیریت بات‌ها و قوانین مبتنی بر کشور و IP وجود دارد. عمق این قابلیت‌ها بین پلن‌های Free، Pro، Business و Enterprise تفاوت دارد و بخشی از آن‌ها فقط در پلن‌های پولی فعال است.

یک هشدار عملی: قوانین سخت‌گیرانه می‌توانند خزندهٔ موتورهای جستجو، وب‌هوک درگاه پرداخت یا کلاینت API خودتان را هم بلاک کنند. هر قانون جدید را اول در حالت فقط‌ثبت (Log) بگذارید و بعد به Block تغییرش دهید.

حالت‌های TLS؛ جایی که بیشترین اشتباه رخ می‌دهد

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

• Flexible: ارتباط کلادفلر تا سرور رمزنگاری نمی‌شود. کاربر قفل امن را می‌بیند، ولی نیمهٔ دوم مسیر HTTP ساده است. این حالت را برای سایت واقعی انتخاب نکنید؛ جدا از ریسک امنیتی، در وردپرس معمولاً حلقهٔ ریدایرکت می‌سازد.
• Full: ارتباط رمزنگاری می‌شود اما گواهی سرور اعتبارسنجی نمی‌شود و گواهی self-signed هم پذیرفته است.
• Full (strict): ارتباط رمزنگاری می‌شود و گواهی سرور باید معتبر و متناسب با دامنه باشد. این حالت درست است.

برای رسیدن به Full (strict) روی سرور اصلی به یک گواهی معتبر نیاز دارید: گواهی رایگان Let’s Encrypt، گواهی Origin CA خود کلادفلر، یا یک گواهی تجاری. اگر گواهی تجاری با گارانتی و امکان صدور مجدد می‌خواهید، گواهی‌های SSL برند Certum در سطوح DV، Wildcard و EV در دسترس است.

IP واقعی بازدیدکننده کجا می‌رود؟

بعد از پروکسی شدن، سرور شما در REMOTE_ADDR فقط IP کلادفلر را می‌بیند. IP واقعی بازدیدکننده در هدر CF-Connecting-IP و همچنین در X-Forwarded-For ارسال می‌شود. تا وقتی وب‌سرور را برای خواندن این هدرها تنظیم نکنید:

• لاگ دسترسی پر از IPهای کلادفلر می‌شود و تحلیل ترافیک بی‌معنا خواهد بود.
• ابزارهایی مثل fail2ban به‌جای مهاجم، IPهای کلادفلر را مسدود می‌کنند و عملاً کل سایت از دسترس خارج می‌شود.
• محدودیت‌های مبتنی بر IP در اپلیکیشن، مثل محدود کردن ورود مدیر به چند آدرس مشخص، کار نمی‌کنند.

راه‌حل در آپاچی ماژول mod_remoteip و در انجین‌ایکس ماژول realip است؛ در هر دو باید رنج IPهای کلادفلر را به‌عنوان پروکسی مورد اعتماد معرفی کنید. این فهرست گاهی تغییر می‌کند، پس بهتر است به‌روزرسانی‌اش خودکار باشد.

محدودیت‌هایی که پیش از فعال‌سازی باید بدانید

• پروکسی فقط روی مجموعه‌ای مشخص از پورت‌های HTTP و HTTPS کار می‌کند. سرویس‌هایی مثل SSH، FTP یا دیتابیس روی پورت‌های دیگر پروکسی نمی‌شوند و به رکورد جداگانه و غیرپروکسی نیاز دارند که خودش IP را افشا می‌کند.
• کلادفلر نقطهٔ حضوری داخل ایران ندارد. اگر سرور اصلی در ایران باشد و بازدیدکننده هم ایرانی، ترافیک اول از کشور خارج می‌شود، به نزدیک‌ترین نقطهٔ حضور می‌رسد و بعد برمی‌گردد؛ این رفت‌وبرگشت می‌تواند تأخیر را بیشتر کند، نه کمتر.
• دسترسی کاربران ایرانی به بخشی از پلن‌ها و امکانات پولی با محدودیت روبه‌رو است؛ پیش از تکیه کردن بر یک قابلیت، در دسترس بودن آن را بررسی کنید.
• هر لایهٔ واسط یک نقطهٔ اتکای تازه است؛ اختلال در شبکهٔ کلادفلر یعنی اختلال در سایت شما، حتی وقتی سرورتان سالم است.

اگر مسئلهٔ اصلی شما هدایت جغرافیایی کاربران است — کاربر ایرانی به سرور ایران و کاربر خارجی به سرور اروپا — سرویس GeoDNS همین کار را در لایهٔ DNS و با ترکیب Anycast و GeoIP، وزن‌دهی رکوردها و مانیتورینگ Ping/HTTP برای حذف خودکار مقصد خراب انجام می‌دهد، بدون اینکه ترافیک وب از یک پروکسی واسط عبور کند.

جمع‌بندی

کلادفلر برای پنهان کردن سرور اصلی، جذب حملات حجمی و کش محتوای ایستا ابزار مفیدی است، به شرط اینکه سه تنظیم را درست انجام دهید: TLS روی Full (strict)، بازیابی IP واقعی بازدیدکننده روی وب‌سرور، و محدود کردن فایروال سرور به رنج IPهای کلادفلر. بدون این سه تنظیم، چیزی که به مسیر اضافه کرده‌اید بیشتر یک لایهٔ پیچیدگی است تا امنیت یا سرعت واقعی. و اگر سرور و مخاطب هر دو داخل ایران هستند، پیش از فعال‌سازی حتماً تأخیر را در دو حالت پروکسی و DNS only با هم مقایسه کنید.