برای سرور اختصاصی چند IP لازم داریم؟ راهنمای تصمیم با مثال واقعی

قرار است چند سایت را به سرور اختصاصی منتقل کنید و فروشنده می‌پرسد چند IP نیاز دارید. آیا برای هر دامنه یک IP جدا لازم است؟ آیا بدون IP جداگانه نمی‌توان گواهی SSL نصب کرد؟ در بسیاری از سناریوهای معمول، چند سایت می‌توانند از یک IP عمومی استفاده کنند؛ اما بعضی محدودیت‌های نرم‌افزاری، قراردادی یا روش اتصال ممکن است آدرس جدا لازم داشته باشند.

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

دامنه نامی مثل example.com است که کاربر می‌بیند. IP نشانی شبکه‌ای است که اتصال به سمت آن می‌رود. پورت راه مشخصی برای رسیدن به یک سرویس روی آن نشانی است؛ مثلاً وب‌سایت HTTPS معمولاً از پورت ۴۴۳ استفاده می‌کند.

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

برای سایت‌های HTTPS، فناوری SNI به کلاینت کمک می‌کند نام دامنه درخواستی را هنگام برقراری TLS اعلام کند تا سرور گواهی مناسب را انتخاب کند. در بسیاری از مرورگرها و وب‌سرورهای امروزی، چند سایت با گواهی‌های متفاوت می‌توانند از یک IP و پورت استفاده کنند. دستگاه‌های قدیمی یا نرم‌افزارهای خاص ممکن است محدودیت داشته باشند؛ نیاز واقعی کاربران خود را بسنجید.

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

| سرویس | نمونه نیاز | پرسش تعیین‌کننده | | --- | --- | --- | | سه سایت شرکتی | هر کدام دامنه و HTTPS جدا | آیا وب‌سرور و کلاینت‌ها از میزبانی نام‌محور و SNI پشتیبانی می‌کنند؟ | | ایمیل سازمانی | یک یا چند دامنه ارسال و دریافت | ارائه‌دهنده ایمیل، IP خروجی، نام میزبان و PTR را چگونه مدیریت می‌کند؟ | | API شریک تجاری | درخواست از سامانه شریک | آیا شریک فقط IP مشخصی را در فهرست مجاز خود می‌پذیرد؟ | | پنل مدیریت | دسترسی محدود مدیران | آیا VPN یا محدودیت شبکه لازم است و IP مجزا واقعاً الزامی است؟ |

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

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

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

اگر یکی از مشتریان یا یک دستگاه قدیمی SNI را پشتیبانی نمی‌کند یا نرم‌افزار قراردادی شما فقط اتصال به IP مشخص را می‌پذیرد، ممکن است طراحی متفاوت یا IP جدا لازم شود. این استثنا را با آزمون همان کلاینت و راهنمای نرم‌افزار اثبات کنید، نه فقط با فرض اینکه هر SSL الزاماً یک IP می‌خواهد.

ارسال ایمیل نیازهایی فراتر از تعداد دامنه دارد. یک سرور ایمیل ممکن است برای چند دامنه پیام بفرستد، اما باید بدانید IP واقعی خروجی چیست، چه کسی PTR یا reverse DNS را مدیریت می‌کند و آیا تنظیمات احراز هویت و سیاست‌های سرویس گیرنده رعایت شده‌اند.

از ارائه‌دهنده یا مدیر ایمیل این‌ها را مشخص بخواهید:

۱. ایمیل واقعاً از همین سرور می‌رود یا از سرویس جدا؟ ۲. IP خروجی برای ارسال کدام است و آیا بین سرویس‌های دیگر مشترک است؟ ۳. چه کسی می‌تواند PTR را برای آن IP تنظیم کند و نام میزبان باید چه باشد؟ ۴. SPF، DKIM و DMARC برای دامنه‌ها با روش ارسال هماهنگ شده‌اند؟ ۵. برنامه پایش اعتبار ارسال و رسیدگی به خطا یا سوءاستفاده چیست؟

IP جدا ممکن است در بعضی طراحی‌ها به تفکیک مسیر ارسال کمک کند، اما به‌تنهایی تضمین ورود ایمیل به Inbox یا اعتبار خوب نیست. اگر سرویس خبرنامه، فاکتور و ایمیل عادی از مسیرهای متفاوت استفاده می‌کنند، برای هر مسیر آزمون ارسال و تحویل جدا لازم است. قبل از سفارش IP اضافی، معماری ایمیل را با مسئول آن طراحی کنید.

گاهی یک API یا سرویس مالی فقط درخواست‌هایی را می‌پذیرد که از IPهای ثبت‌شده بیایند. در این حالت مهم است بدانید اتصال خروجی شما واقعاً از کدام IP خارج می‌شود. داشتن چند IP روی سرور به این معنی نیست که برنامه به‌طور خودکار از IP جدید خارج خواهد شد؛ مسیریابی، NAT و تنظیم برنامه یا شبکه می‌توانند تعیین‌کننده باشند.

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

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

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

اگر شریک تجاری، درگاه یا فایروال IP خروجی قبلی را مجاز کرده است، آدرس جدید باید پیش از انتقال هماهنگ شود. DNS وب‌سایت، ایمیل، PTR، گواهی‌ها و مانیتورینگ را جداگانه در فهرست مهاجرت بگذارید. انتقال IP یا تغییر DNS به‌تنهایی داده سایت و پایگاه داده را منتقل نمی‌کند.

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

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

از ارائه‌دهنده پیش از سفارش بپرسید چه تعداد IP در پلن وجود دارد، هزینه و شرایط آدرس اضافی چیست، IPv4 و IPv6 چگونه ارائه می‌شوند، PTR قابل تنظیم است یا نه و چه کسی تنظیم شبکه و بازگشت را انجام می‌دهد. آدرس‌های IPv4 و IPv6 دو قالب متفاوت‌اند و وجود یکی لزوماً جای دیگری را برای همه مشتریان یا سامانه‌ها نمی‌گیرد.

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

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