سرور را ریبوت کرده‌اید و سایت بالا نمی‌آید. ip a را می‌زنید و IP اضافه‌ای که دیروز با ip addr add بالا آورده بودید غیب شده. یا بدتر: IP سرجایش هست، ping جواب میدهد، ولی مرورگر روی آن دامنه خطای SSL_ERROR_NO_CYPHER_OVERLAP یا NET::ERR_CERT_COMMON_NAME_INVALID میدهد. این دو مشکل ریشه‌ی مشترکی دارند: IP اضافه فقط یک آدرس روی کارت شبکه نیست، یک موجودیت است که باید در چند لایه ثبت شود.
در این متن مسیر کامل را می‌رویم: از بالا آوردن IP اضافه به شکل پایدار، تا bind کردن سرویس به آن، تا گواهی SSL و رکوردهای ایمیل. تمرکز روی لینوکس است چون تقریباً همه‌ی سرورهای وب همین‌جا هستند.
IP اضافه را طوری بالا بیاورید که بعد از ریبوت بماند
اولین کاری که اکثر افراد می‌کنند این است:
ip addr add 203.0.113.45/29 dev eth0این دستور کار میکند و بلافاصله IP پاسخ میدهد. ولی موقتی است. با اولین reboot یا حتی restart شدن سرویس شبکه، پاک میشود و شما دوباره پشت همان خطا هستید. اگر روی Ubuntu با netplan کار می‌کنید، باید بلوک را در فایل YAML بنویسید:
network:
version: 2
ethernets:
eth0:
addresses:
- 203.0.113.44/29
- 203.0.113.45/29
routes:
- to: default
via: 203.0.113.41روی RHEL و AlmaLinux و Rocky، فایل /etc/sysconfig/network-scripts/ifcfg-eth0 را با IPADDR1=203.0.113.45 و PREFIX1=29 ویرایش می‌کنید. روی Debian خالص، بلوک iface eth0 inet static را در /etc/network/interfaces تکرار می‌کنید. تفاوت توزیع‌ها اینجا واقعی است و اگر اشتباه حدس بزنید، بعد از ریبوت سرور را از دست می‌دهید؛ انتخاب توزیع لینوکس سرور را قبل از دست زدن به فایل شبکه یک نگاه بیندازید.
نکته‌ای که در دیتاسنتر فرق میکند
IP اضافه‌ای که از ارائهدهنده میگیرید معمولاً در همان سابنت اصلی است، پس نیازی به gateway جدا ندارد. ولی اگر سابنت متفاوتی باشد (مثلاً یک /29 جدا روی VLAN دیگر)، باید route مشخص اضافه کنید وگرنه بسته‌ها از سرور بیرون می‌روند و برنمی‌گردند. نشانه‌اش این است که از خود سرور ping 8.8.8.8 جواب میدهد ولی از بیرون هیچ‌کس به IP جدید نمی‌رسد. این را با tcpdump -i eth0 icmp روی سرور چک کنید: اگر بسته‌ی ورودی می‌بینید ولی خروجی ندارید، مشکل route است نه فایروال.
اتصال IP اضافه به وبسرور
حالا که IP پایدار است، باید سرویس روی آن گوش بدهد. اگر Nginx دارید و کانفیگ را روی listen 80; گذاشته‌اید، Nginx روی همه‌ی آدرس‌ها گوش میدهد و IP اضافه هم خودکار سرو میشود. این رفتار پیش‌فرض است و برای اکثر سایت‌ها درست. ولی وقتی می‌خواهید IP اضافه فقط به یک سایت خاص خدمت کند، باید صریح بنویسید:
server {
listen 203.0.113.45:443 ssl;
server_name shop.example.com;
ssl_certificate /etc/letsencrypt/live/shop.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/shop.example.com/privkey.pem;
}Apache کمی متفاوت است. آنجا Listen 203.0.113.45:443 را در ports.conf اضافه می‌کنید و بعد در VirtualHost با <VirtualHost 203.0.113.45:443> به آن اشاره می‌کنید. اگر این خط را جا بیندازید، Apache روی IP جدید هیچ پاسخی نمی‌دهد و در لاگ چیزی نمی‌بینید، چون اصلاً به آن سوکت bind نشده. برای پیدا کردن اینکه هر سرویس روی کدام پورت و کدام آدرس نشسته، مرجع پورت سرویسهای پرکاربرد نقطه‌ی شروع خوبی است.
اینجا اشتباه می‌کنند
خطای رایجی که زیاد دیده‌ام: فرد IP اضافه را بالا میآورد، سایت را روی آن ست میکند، همه‌چیز کار میکند، و بعد چند ساعت بعد کاربران گزارش می‌دهند که «سایت روی موبایل باز نمی‌شود ولی روی وای‌فای شرکت باز میشود». علت معمولاً این است که IP اضافه در فایروال باز نشده. ufw status را بزنید؛ اگر فقط پورت 443 روی IP اصلی allow شده باشد، ترافیک روی IP جدید drop میشود و از دید کاربر یک timeout خاموش است، نه خطای واضح. دستور ufw allow 443/tcp بدون ذکر آدرس، همه‌ی IPها را پوشش میدهد. اگر با iptables خام کار می‌کنید، دستورات فایروال لینوکس را برای سینتکس دقیق زنجیره‌ها ببینید.
گواهی SSL روی IP اضافه: جایی که SNI غافلگیر میکند
اینجا نقطه‌ای است که خیلی‌ها گیر می‌کنند. گواهی SSL به دامنه بسته میشود، نه به IP. پس وقتی IP اضافه میگیرید، باید مطمئن شوید رکورد A دامنه به IP جدید اشاره میکند و بعد گواهی بگیرید. اگر با Certbot کار می‌کنید:
certbot certonly --webroot -w /var/www/shop -d shop.example.comCertbot قبل از صدور، یک فایل چالش روی دامنه می‌گذارد و از بیرون آن را می‌خواند. اگر DNS هنوز به IP قدیمی اشاره میکند، چالش شکست می‌خورد و پیام Timeout during connect میگیرید. TTL رکورد A را قبل از شروع به 300 ثانیه کاهش دهید تا propagate سریع‌تر شود.
نکته‌ی مهم‌تر: اگر روی یک IP چند دامنه با گواهی‌های مختلف سرو می‌کنید، به SNI وابسته‌اید. کلاینت‌های قدیمی که SNI نمی‌فرستند، اولین گواهی روی آن IP را میبینند و خطای نام دامنه می‌گیرند. راه‌حل تمیز این است که هر دامنهی حساس IP اختصاصی خودش را داشته باشد. اینجا انتخاب بین IP مشترک و اختصاصی واقعی است: برای سایت‌های معمولی IP مشترک کافی است و هزینه و مدیریت کمتری دارد، ولی اگر مشتری سازمانی دارید یا سرویس‌هایی مثل پرداخت و ایمیل تراکنشی می‌دهید، IP اختصاصی را انتخاب کنید. روی زیرساخت ابری، جدا کردن این بار ساده‌تر است؛ سرور ابری اجازه میدهد IP را جدا از ماشین مدیریت کنید و موقع مهاجرت دوباره پیکربندی نکنید.
IP اضافه و ایمیل: رکورد SPF را فراموش نکنید
اگر IP اضافه را برای ارسال ایمیل استفاده می‌کنید، فقط بالا آوردنش کافی نیست. باید در رکورد SPF دامنه ثبت شود، وگرنه گیرندگان ایمیل شما را جعل‌شده میبینند و به spam میرود:
example.com. IN TXT "v=spf1 ip4:203.0.113.44 ip4:203.0.113.45 -all"اگر از DKIM استفاده می‌کنید، کلید امضا هم باید روی همان دامنه‌ای که از IP جدید می‌فرستد ست باشد. یک اشتباه رایج: IP اضافه را برای ارسال ست می‌کنید ولی rDNS آن را تنظیم نمی‌کنید. اکثر ارائه‌دهنده‌ها اجازه می‌دهند PTR را از پنل ست کنید؛ اگر این کار را نکنید، Gmail ایمیل شما را با هشدار «این فرستنده تأیید نشده» نشان میدهد. PTR باید به همان دامنه‌ای اشاره کند که در HELO اعلام می‌کنید.
چطور مطمئن شوید همه‌چیز درست نشسته
قبل از اینکه بگویید تمام شد، این چک‌لیست را از بیرون سرور اجرا کنید، نه از روی خودش:
ping 203.0.113.45از یک ماشین دیگر. اگر جواب نداد، مشکل route یا فایروال upstream است.curl -I --resolve shop.example.com:443:203.0.113.45 https://shop.example.comتا مطمئن شوید وبسرور روی همان IP پاسخ میدهد.openssl s_client -connect 203.0.113.45:443 -servername shop.example.comتا گواهی درست را ببینید.dig +short TXT example.comبرای تأیید SPF.
و در آخر، سرور را یک بار ریبوت کنید. همین حالا، نه شب که ترافیک کم است. اگر IP بعد از ریبوت برنگشت، بهتر است الان بفهمید تا فردا صبح که مشتری زنگ می‌زند. برای سرویس‌هایی که باید خودکار بالا بیایند، مطمئن شوید unit مربوطه enabled است؛ فایل unit در systemd توضیح میدهد کدام بخش مسئول وابستگی و ری‌استارت خودکار است. اگر بعد از ریبوت سرویس بالا نیامد و نفهمیدید چرا، محل لاگ لینوکس را ببینید تا بدانید کدام فایل را باز کنید.
اگر روی هاست اشتراکی هستید و به IP اختصاصی نیاز دارید، این کار از پنل مدیریت انجام میشود و دسترسی root لازم نیست؛ هاست لینوکس گزینه‌ی IP اختصاصی را در همان پنل ارائه میدهد. ولی روی سرور اختصاصی، همه‌ی مراحل بالا وظیفه‌ی خودتان است.
پرسش‌های پرتکرار
چرا IP اضافه بعد از ریبوت از بین میرود؟
چون با دستور ip addr add فقط در حافظهی کرنل ثبت شده و در هیچ فایل پیکربندی نوشته نشده. سیستمعامل موقع بوت فقط چیزی را بالا میآورد که در netplan، ifcfg یا interfaces نوشته شده باشد. باید همان IP را در فایل پیکربندی توزیع اضافه کنید تا پایدار بماند.
آیا برای IP اضافه به گواهی SSL جداگانه نیاز دارم؟
خیر، گواهی به دامنه بسته میشود نه به IP. اگر دامنهتان با رکورد A به IP جدید اشاره کند، همان گواهی کار میکند. فقط باید مطمئن شوید وبسرور روی آن IP گوش میدهد و فایروال پورت 443 را باز گذاشته است.
چطور بفهمم IP اضافه واقعاً از بیرون قابل دسترسی است؟
از یک سرور دیگر یا سرویس آنلاین، ping و بعد curl روی همان IP بزنید. اگر از خود سرور جواب میگیرید ولی از بیرون نه، مشکل تقریباً همیشه route یا فایروال است، نه پیکربندی وبسرور.
برای ایمیل، فقط ست کردن IP اضافه کافی است؟
نه. باید رکورد SPF را با ip4: جدید بهروز کنید، rDNS را از پنل ارائهدهنده ست کنید و اگر DKIM دارید، کلید را روی همان دامنهی فرستنده نگه دارید. بدون rDNS، اکثر سرویسهای ایمیل بزرگ پیام شما را مشکوک میبینند.