Dalتعویض IP عمومی در سرورهای ابری قرار است یک کار روتین باشد؛ اما در ایمیجهای سبک (Minimized Ubuntu)،...
تعویض IP عمومی در سرورهای ابری قرار است یک کار روتین باشد؛ اما در ایمیجهای سبک (Minimized Ubuntu)، این کار بهراحتی میتواند سرور را ساعتها از دسترس خارج کند.
در این تجربه واقعی، پس از تغییر IP سرور توسط دیتاسنتر، دسترسی SSH بهطور کامل قطع شد و پینگ سرور به صفر رسید. در ادامه، ریشهیابی فنی، تلههای حین عیبیابی و نحوه رساندن شبکه به یک پیکربندی دائمی و پایدار را مرور میکنیم.
### ۱. صورتمسئله: چرا بعد از تغییر IP همهچیز قطع شد؟
* آیپی قبلی: 2.26.48.117/32
* آیپی جدید: 193.222.99.171/32
* گیتوی: 10.0.0.1
دیتاسنتر آیپی جدید را در سوییچهای لایه هایپربایزر ست کرده بود، اما داخل سرور، سیستمعامل هنوز آیپی مرده قبلی را روی کارت شبکه ens3 نگه داشته بود. چون ابزارهایی مثل cloud-init، netplan و NetworkManager روی سیستم نصب نبودند، هیچ سرویسی وجود نداشت که خودکار تغییرات را اعمال کند.
از طرفی، وقتی ماسک شبکه /32 است، گیتوی (10.0.0.1) خارج از رنج آیپی سرور قرار میگیرد و لینوکس خطای Network is unreachable میدهد، مگر اینکه صریحاً فلگ onlink تنظیم شود.
### ۲. ورود اضطراری با VNC (خارج از شبکه / Out-of-Band)
وقتی کارت شبکه خوابیده، SSH در دسترس نیست. تنها راه ورود، کنسول VNC پنل هاستینگ است؛ یعنی دسترسی مستقیم به خروجی مانیتور و کیبورد سرور در سطح هایپربایزر، بدون نیاز به اینترنتِ داخل سرور.
با دستور دستی شبکه موقتاً وصل شد:
ip addr add 193.222.99.171/32 dev ens3
ip route add default via 10.0.0.1 dev ens3 onlink
اینترنت و SSH بلافاصله وصل شدند، اما این دستورات فقط در رم زنده هستند و با ریبوت مجدد میپرند.
### ۳. تلههای حین دائمیسازی شبکه
برای دائمی کردن تنظیمات سراغ systemd-networkd رفتیم، اما دو چالش پیش آمد:
1. خطای ساختاری فایل کانفیگ: قراردادن دستور GatewayOnLink=yes داخل سکشن [Network] نامعتبر است و توسط هسته نادیده گرفته میشود. این دستور حتماً باید زیر سکشن [Route] تعریف شود.
2. تداخل فایلهای قدیمی: فایل قدیمی /etc/network/interfaces و /etc/hosts همچنان آیپی منسوخ قبلی را صدا میزدند و باعث ثبت دو آیپی همزمان روی کارت شبکه میشدند.
### ۴. راهحل نهایی و استاندارد
ساخت فایل کانفیگ مستقل برای systemd-networkd:
# /etc/systemd/network/10-ens3.network
[Match]
Name=ens3
[Network]
Address=193.222.99.171/32
DNS=8.8.8.8
DNS=1.1.1.1
[Route]
Gateway=10.0.0.1
GatewayOnLink=yes
و پاکسازی ردپای آیپی قبلی:
sed -i 's/2.26.48.117/193.222.99.171/g' /etc/hosts
sed -i 's/2.26.48.117/193.222.99.171/g' /etc/network/interfaces
ip addr del 2.26.48.117/32 dev ens3
systemctl restart systemd-networkd
### ۵. معمای عدم پاسخ پینگ در Check-Host
بعد از آنلاین شدن سرور و پایداری SSH، سایتهای تست پینگ (مثل Check-Host) خطای ۱۰۰٪ Packet Loss میدادند؛ در حالی که فایروال محلی سرور (iptables) کاملاً باز بود.
علت: فایروال لبه دیتاسنتر (Anti-DDoS Scrubbing) پکتهای ورودی ICMP (پینگ) را قبل از رسیدن به سرور فیلتر میکند تا از حملات Flood جلوگیری کند. اعتبارسنجی واقعی سلامت سرور باید از طریق برقراری کانکشنهای TCP (مثل پورت ۲۲ برای SSH یا پورتهای وب) انجام شود که در این حالت تأخیر زیر ۱ میلیثانیه را ثبت کردند.
### 💡 درسهای کلیدی برای ادمینها:
1. در سیستمهای Minimized لینوکس فرض نکنید ابزارهای مدیریتی شبکه حاضرند؛ systemd-networkd پایدارترین گزینه بومی است.
2. گیتویهای ناهمنام در سابنت /32 بدون فلگ onlink مسیریابی نمیشوند.
3. عدم پاسخ پینگ عمومی (ICMP) لزوماً به معنی قطعی سرور نیست؛ همیشه پورتهای سرویس (TCP) را تست کنید.