محتوای آموزشی وبلاگ نت‌آرام
آدرس IP یا DNS سرور اوبونتو را تنظیم می‌کنید، همه‌چیز کار می‌کند، اما بعد از ریبوت تغییرات ناپدید می‌شود. یکی از علت‌های ممکن این است که شبکه از اطلاعات پلتفرم یا چند فایل تنظیم ساخته می‌شود و شما فایل یا محلی را تغییر داده‌اید که مرجع نهایی نیست. البته هر بازگشت تنظیماتی تقصیر cloud-init نیست؛ DHCP، ابزار ارائه‌دهنده یا ادغام فایل‌های Netplan هم می‌تواند دخیل باشد.
این راهنما برای سرورهای Ubuntu دارای Netplan و در صورت وجود cloud-init نوشته شده است. مثال‌ها را با اطلاعات واقعی سرور خودتان تطبیق دهید. چون تغییر اشتباه شبکه ممکن است SSH را قطع کند، قبل از شروع باید کنسول سرور در پنل ارائه‌دهنده یا مسیر دسترسی مستقل دیگری داشته باشید و از تنظیمات فعلی نسخه پشتیبان بگیرید.
۱. اول مشخص کنید چه چیزی برگشته است
قبل از هر تغییر، آدرس‌ها و مسیرهای فعلی را در ترمینال خود سرور ببینید:
کد / دستورip -br address
خروجی، نام کارت شبکه و آدرس‌های فعلی آن را نشان می‌دهد؛ برای مثال نام رابط ممکن است
کد / دستورens160 باشد، ولی نام سرور شما می‌تواند متفاوت باشد. این نام را یادداشت کنید. سپس مسیرهای پیش‌فرض را ببینید:ip route show default
وجود
default via ... dev ... معمولاً نشان می‌دهد کدام دروازه و رابط برای مسیر پیش‌فرض IPv4 استفاده می‌شود. آدرس‌ها و دروازه را از این خروجی و اطلاعات ارائه‌دهنده یادداشت کنید، نه از نمونه‌های سایت‌های دیگر.اگر فقط نام دامنه‌ها حل نمی‌شوند ولی IP سرور عوض نشده است، وضعیت DNS را نیز ببینید:
کد / دستورresolvectl status
این دستور روی سیستم‌هایی که
systemd-resolved دارند اطلاعات DNS رابط‌ها را نشان می‌دهد. اگر دستور موجود نیست، ابتدا روش مدیریت DNS همان سیستم را مشخص کنید. برای راهنمای اختصاصی حل‌نشدن نام‌ها می‌توانید عیب‌یابی DNS سرور را بخوانید.۲. فایل‌های مؤثر Netplan را پیدا کنید
کد / دستورfor dir in /lib/netplan /etc/netplan /run/netplan; do [ ! -d "$dir" ] || ls -l "$dir"; done
Netplan می‌تواند تنظیمات را از هر سه مسیر بخواند. نامی مانند
50-cloud-init.yaml سرنخی از تولید فایل توسط cloud-init است، اما ثابت نمی‌کند فایل در هر ریبوت بازنویسی شده است. فایل‌هایی با نام‌های متفاوت طبق ترتیب نام با هم ترکیب می‌شوند؛ برای بعضی مقدارهای فهرستی، مقادیر جدید به قبلی اضافه می‌شوند. بنابراین صرف ساختن یک فایل جدید با شماره بالاتر همیشه همه آدرس‌ها یا DNSهای قبلی را پاک نمی‌کند.برای دیدن تنظیم نهایی که Netplan از فایل‌ها می‌سازد، در نسخه‌هایی که این فرمان را دارند:
کد / دستورsudo netplan get
خروجی ممکن است جزئیات محرمانه شبکه داشته باشد. نام رابط،
کد / دستورdhcp4، addresses، routes و nameservers را با تنظیم مورد انتظار مقایسه کنید. اگر آنچه در خروجی می‌بینید با یک فایل منفرد فرق دارد، فایل‌های دیگر را هم بخوانید. برای مشاهده فایل نمونه:sudo cat /etc/netplan/50-cloud-init.yaml
اگر نام فایل شما فرق دارد، نام موجود در فهرست را جایگزین کنید. درباره ترتیب و ترکیب فایل‌ها به مستندات رسمی Netplan مراجعه کنید.
۳. بررسی کنید cloud-init یا پلتفرم در تنظیم شبکه نقش دارد
کد / دستورcloud-init status --long
اگر cloud-init نصب است، وضعیت اجرا و معمولاً اطلاعاتی درباره منبع داده را می‌بینید.
done به معنی کامل شدن فرایند است، نه اثبات اینکه همان ابزار بعد از ریبوت فایل شما را تغییر داده است. اگر دستور موجود نیست، علت را در ابزار مدیریت شبکه یا پیکربندی پلتفرم سرور دنبال کنید.برای جست‌وجوی رخدادهای مرتبط با شبکه در گزارش cloud-init:
کد / دستورsudo grep -i -E 'network|netplan|datasource' /var/log/cloud-init.log | tail -n 80
زمان خطوط و نام فایل‌های مطرح‌شده را با زمان تغییر مقایسه کنید. وجود یک خط درباره شبکه لزوماً به معنی بازنویسی فایل نیست. گزارش می‌تواند اطلاعات خصوصی داشته باشد. همچنین در برخی محیط‌ها تغییر شناسه ماشین یا داده‌های پلتفرم باعث اجرای دوباره بخش‌هایی از تنظیم اولیه می‌شود؛ ریبوت ساده در همه پلتفرم‌ها چنین اثری ندارد.
اگر آدرس موردنظر را پلتفرم با DHCP یا تنظیمات خودکار تحویل می‌دهد، نخست از ارائه‌دهنده بپرسید تغییر باید در پنل انجام شود یا داخل سیستم‌عامل. اگر منبع اصلی اطلاعات پنل است، اصلاح آن منبع معمولاً از ویرایش مکرر فایل تولیدشده ماندگارتر است.
۴. قبل از تغییر، نسخه بازگشت آماده کنید
یک ترمینال SSH را باز نگه دارید و کنسول پنل را جداگانه امتحان کنید. اگر نمونه شما فایل
کد / دستور50-cloud-init.yaml دارد، با دستور زیر یک کپی با نام مشخص می‌سازید:sudo cp -an /etc/netplan/50-cloud-init.yaml /root/50-cloud-init.yaml.before-network-change
اگر نام فایل شما متفاوت است، آن را جایگزین کنید. گزینه
-n فایل هم‌نام موجود را بازنویسی نمی‌کند؛ پس اگر قبلاً بکاپی با این نام ساخته‌اید، نام تازه‌ای انتخاب و وجود نسخه جدید را بررسی کنید. از سایر فایل‌های مؤثر Netplan و تنظیمات cloud-init هم با نام‌های مشخص بکاپ بگیرید. این کپی روی همان سرور است؛ برای بازیابی پس از خرابی دیسک، نسخه‌ای خارج از سرور نیز لازم است.۵. راه‌حل اول: تنظیم را در منبعی که ارائه‌دهنده پشتیبانی می‌کند اصلاح کنید
اگر پنل یا سامانه پیکربندی سرور شما اجازه ثبت IP، دروازه یا DNS را می‌دهد، همان مقادیر اختصاص‌داده‌شده به این سرور را در آنجا اصلاح کنید و مطابق راهنمای ارائه‌دهنده اعمال کنید. هر IP یا Gateway پیشنهادی اینترنتی برای سرور شما معتبر نیست. در یک سرور دارای DHCP نیز ممکن است تنظیم IP ثابت داخل مهمان، با روش واگذاری شبکه پلتفرم ناسازگار شود.
پس از اعمال،
ip -br address، ip route show default و در صورت استفاده resolvectl status را تکرار کنید. با یک اتصال جداگانه SSH و یک مقصد واقعی، ارتباط را بررسی کنید. اگر تغییر پس از ریبوت دوباره برگشت، زمان تغییر و گزارش مرحله ۳ را برای شناسایی ابزار بازنویس‌کننده نگه دارید.۶. راه‌حل دوم: مدیریت دستی شبکه، فقط در صورت پشتیبانی ارائه‌دهنده
اگر پلتفرم صراحتاً اجازه می‌دهد شبکه را خودتان مدیریت کنید، می‌توان تولید تنظیم شبکه توسط cloud-init را غیرفعال کرد و یک پیکربندی معتبر Netplan نگه داشت. این تصمیم را بدون تأیید سازگاری زیرساخت نگیرید: برخی پلتفرم‌ها برای تنظیم آدرس‌ها یا بازیابی ماشین به پیکربندی خودکار وابسته‌اند.
ابتدا ببینید فایلی با نام نمونه زیر وجود ندارد؛ اگر وجود داشت، محتوا و کاربردش را بررسی کنید و آن را کورکورانه جایگزین نکنید:
کد / دستورsudo ls -l /etc/cloud/cloud.cfg.d/99-netaram-network.cfg
در صورت نبود فایل و بعد از تأیید روش دستی، آن را باز کنید:
کد / دستورsudo nano /etc/cloud/cloud.cfg.d/99-netaram-network.cfg
این دو خط را با فاصله‌های نشان‌داده‌شده بنویسید:
کد / دستورnetwork:
config: disabled
با Ctrl+O و Enter ذخیره و با Ctrl+X خارج شوید. این گزینه فقط تولید تنظیم شبکه توسط cloud-init را غیرفعال می‌کند؛ فایل Netplan فعلی را پاک نمی‌کند و به‌تنهایی IP یا Gateway جدید نمی‌سازد. پس باید پیش از ریبوت، تنظیم معتبر شبکه در Netplan وجود داشته باشد. تعریف این گزینه در مستندات cloud-init آمده است.
نمونه برای رابطی که واقعاً DHCP دارد
اگر ارائه‌دهنده تأیید کرده این رابط باید از DHCP استفاده کند، یک مثال ساده تک‌رابطی چنین است:
کد / دستورnetwork:
version: 2
ethernets:
ens160:
dhcp4: true
ens160 را با نام واقعی رابط عوض کنید. این قطعه نمونه است، نه نسخه آماده برای جایگزینی تمام فایل‌های شما: اگر سرور چند رابط، آدرس ثابت، VLAN، bridge یا مسیر خاص دارد، آن جزئیات باید حفظ شوند. برای یک آدرس ثابت، مقدار دقیق IP همراه پیشوند، Gateway و DNS را از ارائه‌دهنده بگیرید و مطابق مستندات و شبکه واقعی وارد کنید؛ مقدار فرضی می‌تواند ارتباط را قطع کند.فایل مؤثر را با ویرایشگر باز کنید، بخش موردنظر را اصلاح کنید و بقیه تنظیمات لازم را حفظ کنید. به‌عنوان نمونه، اگر فایل مؤثر شما همان فایل زیر است:
کد / دستورsudo nano /etc/netplan/50-cloud-init.yaml
فاصله‌گذاری YAML را با Space انجام دهید و از Tab استفاده نکنید. قبل از تست، دوباره
sudo netplan get را بخوانید تا ببینید فایل‌های دیگر چه چیزی به تنظیم اضافه کرده‌اند.۷. تغییر را با مسیر بازگشت آزمایش کنید
در حالی که کنسول مستقل سرور آماده است، این دستور را اجرا کنید:
کد / دستورsudo netplan try
Netplan تنظیم را آزمایشی اعمال می‌کند و معمولاً برای تأیید زمان محدودی می‌دهد. از یک اتصال جداگانه، SSH، IP، مسیر پیش‌فرض و در صورت نیاز DNS را آزمایش کنید. فقط وقتی همه موارد موردنیاز درست هستند در همان پنجره دستور، تغییر را تأیید کنید. اگر تأیید نکنید، ابزار تلاش می‌کند تنظیم قبلی را بازگرداند؛ طبق مستندات، در بعضی پیکربندی‌ها از جمله برخی دستگاه‌های مجازی، بازگشت ممکن است کامل نباشد. به همین دلیل کنسول و بکاپ ضروری‌اند.
اگر ارتباط قطع شد، از کنسول وارد شوید، فایل تغییرکرده را با نسخه پشتیبان خود برگردانید و دوباره تنظیمات را آزمایش کنید. برای برگرداندن تصمیم مربوط به cloud-init، فایل
99-netaram-network.cfg را باز و دو خطی را که خودتان افزوده‌اید غیرفعال کنید؛ سپس روش شبکه پشتیبانی‌شده توسط ارائه‌دهنده را بازگردانید. حذف کلی cloud-init یا اجرای cloud-init clean راه‌حل تشخیص این مشکل نیست و می‌تواند تنظیمات اولیه دیگری را تحت تأثیر قرار دهد.۸. بعد از ریبوت چه چیزی را بررسی کنیم؟
در زمان مناسب و پس از داشتن بکاپ، سرور را به روش معمول ریبوت کنید. از کنسول و سپس از یک اتصال جدید SSH وارد شوید و همان دستورهای ابتدای مقاله را تکرار کنید. آدرس‌ها، مسیر و DNS را با مقادیر مورد انتظار مقایسه کنید و یک سرویس واقعی را امتحان کنید. اگر تغییر فقط در فایل دیده می‌شود اما روی رابط اعمال نشده است، وضعیت renderer شبکه و گزارش خطا را هم بررسی کنید؛ وجود فایل صحیح به‌تنهایی اثبات اتصال نیست.
برای انتخاب محیط مناسب و اطلاع از روش واگذاری آدرس، صفحه سرور مجازی ایران نت‌آرام را ببینید و درباره پشتیبانی شبکه پلن موردنظر سؤال کنید.
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام