مقدمه

تغییر IP از SSH می‌تواند management، DNS و مسیر backup را هم‌زمان قطع کند. Netplan باید با مالکیت روشن فایل‌ها، preflight و تأیید از یک کلاینت مستقل اعمال شود.

مثال عملی

VM برنامه در VLAN 30 از DHCP به 10.20.30.10/24 منتقل می‌شود؛ IP در NetBox رزرو شده و تیم شبکه trunk و ACL را تأیید کرده است.

پیش‌نیازها

Ubuntu Server 24.04 LTS، Bash 5، systemd؛ package patch را پیش از تغییر با dpkg-query ثبت کنید.

سخت‌افزار و ظرفیت: برای مثال یک VM با ۲ vCPU، ۲ GiB RAM و ۲۰ GiB دیسک؛ این ظرفیت پیشنهادی آزمایشگاه است و sizing سرویس به بار واقعی وابسته است.

نرم‌افزار و دسترسی: netplan.io و systemd-networkd؛ sudo، console و رزرو IP در IPAM. ens160، 10.20.30.10، gateway و DNS زیر نمونه کامل آزمایشگاه‌اند.

Architecture / Design

Netplan YAML → generator → systemd-networkd → NIC/VLAN → gateway. systemd-resolved مالک DNS است. فایل‌های چندگانه merge می‌شوند؛ نوشتن فایل جدید لزوماً تنظیم قبلی را حذف نمی‌کند.

Installation / Configuration

از console وضعیت را ثبت و کل پوشه را backup کنید.

ip -br address
ip route
resolvectl status
sudo netplan get
sudo cp -a /etc/netplan /root/netplan-before-change

نمونه زیر فقط برای VM تک NIC و یک فایل مالک شبکه است. فایل فعال قبلی را شناسایی کنید؛ YAML متداخل باقی نگذارید. اگر cloud-init آن را تولید می‌کند ابتدا مالکیت را از cloud به سیستم منتقل کنید یا تغییر را در منبع cloud انجام دهید.

sudo tee /etc/netplan/01-production.yaml >/dev/null <<'EOF'
network:
  version: 2
  renderer: networkd
  ethernets:
    ens160:
      dhcp4: false
      addresses: [10.20.30.10/24]
      routes:
        - to: default
          via: 10.20.30.1
      nameservers:
        addresses: [10.20.30.53, 10.20.30.54]
        search: [corp.example.com]
EOF
sudo chmod 600 /etc/netplan/01-production.yaml
sudo netplan generate
sudo netplan try --timeout 120

پیش از تأیید try از کلاینت دوم gateway، SSH و DNS را آزمایش کنید. انتظار: آدرس مشخص روی ens160 و فقط default route طراحی‌شده؛ generate بدون خطا. بازگشت timeout را روی محیط هدف آزمایش کنید و به آن به‌تنهایی برای بازیابی تکیه نکنید.

ip -br address show ens160
ip route get 10.20.30.53
resolvectl query corp.example.com
ping -c 3 10.20.30.1

Security Hardening

chmod 600 مانع خواندن اطلاعات حساس YAML توسط کاربران معمولی می‌شود. IP ثابت جای firewall نیست. DNS داخلی و route مدیریت را نگه دارید؛ پاسخ ping به معنی بازبودن همه سرویس‌ها نیست. IPv6 را با policy سازمان پیکربندی کنید و مسیرهای آن را نیز ارزیابی کنید.

Monitoring

Zabbix availability، packet loss و تغییر IP را پایش کند؛ node_exporter خطاهای interface را به Prometheus می‌دهد. تغییر route یا قطع بیش از دو poll متوالی به تیم شبکه alert شود. health check برنامه از subnet مصرف‌کننده اجرا شود.

Troubleshooting

خطای YAML معمولاً از indentation یا tab است؛ generate محل را نشان می‌دهد. چند default route می‌تواند حاصل merge یا DHCP باقی‌مانده باشد.

sudo netplan --debug generate
networkctl status ens160
sudo journalctl -u systemd-networkd -n 100 --no-pager
resolvectl status ens160

IP درست ولی gateway unreachable: VLAN، ماسک و ARP را بررسی کنید. DNS خراب با route سالم: resolver و ACL/53 را بررسی کنید. بازگشت تنظیم بعد reboot: cloud-init یا automation هنوز مالک فایل است؛ منبع تولید را اصلاح کنید.

Backup / Recovery

از console فایل جدید را خارج و YAML قبلی را از backup بازگردانید؛ فایل‌های هم‌نام backup را کورکورانه merge نکنید.

sudo mv /etc/netplan/01-production.yaml /root/01-production.yaml.failed
sudo cp -a /root/netplan-before-change/. /etc/netplan/
sudo netplan generate
sudo netplan apply

مدارک IPAM، VLAN و route باید خارج VM نگهداری شوند. بعد rollback از subnet مدیریت و برنامه آزمون کنید.

Best Practices

تغییر NIC، VLAN و IP را در یک مرحله جمع نکنید. کنترل تداخل IP پیش از تغییر، console فعال و canary از شروط پذیرش‌اند.

نسخه‌های قدیمی و Compatibility

gateway4 در مثال‌های قدیمی با routes جایگزین شود. renderer دسکتاپ ممکن است NetworkManager باشد؛ این نمونه برای networkd است. netplan try در برخی ساختارهای virtual link محدودیت rollback دارد.

پرسش‌های متداول

آیا netplan try تضمین بازیابی است؟

خیر؛ محدودیت‌های rollback را بررسی کنید و console مستقل داشته باشید.

چرا تغییر بعد reboot برمی‌گردد؟

معمولاً cloud-init یا ابزار مدیریت پیکربندی هنوز فایل را تولید می‌کند.

منابع رسمی

تاریخ بررسی منابع: 2026-09-30. اعتبارسنجی عملی روی محیط هدف باید پیش از انتشار تغییر زیرساخت انجام شود.

Share