The latest articles on DEV Community by Dal (@dalroot). https://dev.to/dalroot https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4136780%2F691603e1-0fdb-421c-ac61-832067f47994.jpg https://dev.to/dalroot en Dal Thu, 24 Sep 2026 21:40:38 +0000 https://dev.to/dalroot/njt-srwr-lynwkhs-ps-z-twyd-ip-z-khmwshy-khml-ssh-t-rwtyng-32-b-khnswl-vnc-o4l https://dev.to/dalroot/njt-srwr-lynwkhs-ps-z-twyd-ip-z-khmwshy-khml-ssh-t-rwtyng-32-b-khnswl-vnc-o4l <p>‏تعویض IP عمومی در سرورهای ابری قرار است یک کار روتین باشد؛ اما در ایمیج‌های سبک (Minimized Ubuntu)، این کار به‌راحتی می‌تواند سرور را ساعت‌ها از دسترس خارج کند.</p> <p>‏در این تجربه واقعی، پس از تغییر IP سرور توسط دیتاسنتر، دسترسی SSH به‌طور کامل قطع شد و پینگ سرور به صفر رسید. در ادامه، ریشه‌یابی فنی، تله‌های حین عیب‌یابی و نحوه رساندن شبکه به یک پیکربندی دائمی و پایدار را مرور می‌کنیم.</p> <p>‏### ۱. صورت‌مسئله: چرا بعد از تغییر IP همه‌چیز قطع شد؟<br> ‏* <strong>آی‌پی قبلی:</strong> <code>2.26.48.117/32</code><br> ‏* <strong>آی‌پی جدید:</strong> <code>193.222.99.171/32</code><br> ‏* <strong>گیت‌وی:</strong> <code>10.0.0.1</code></p> <p>‏دیتاسنتر آی‌پی جدید را در سوییچ‌های لایه هایپربایزر ست کرده بود، اما داخل سرور، سیستم‌عامل هنوز آی‌پی مرده قبلی را روی کارت شبکه <code>ens3</code> نگه داشته بود. چون ابزارهایی مثل <code>cloud-init</code>، <code>netplan</code> و <code>NetworkManager</code> روی سیستم نصب نبودند، هیچ سرویسی وجود نداشت که خودکار تغییرات را اعمال کند.</p> <p>‏از طرفی، وقتی ماسک شبکه <code>/32</code> است، گیت‌وی (<code>10.0.0.1</code>) خارج از رنج آی‌پی سرور قرار می‌گیرد و لینوکس خطای <code>Network is unreachable</code> می‌دهد، مگر اینکه صریحاً فلگ <code>onlink</code> تنظیم شود.</p> <p>‏### ۲. ورود اضطراری با VNC (خارج از شبکه / Out-of-Band)<br> ‏وقتی کارت شبکه خوابیده، SSH در دسترس نیست. تنها راه ورود، <strong>کنسول VNC پنل هاستینگ</strong> است؛ یعنی دسترسی مستقیم به خروجی مانیتور و کیبورد سرور در سطح هایپربایزر، بدون نیاز به اینترنتِ داخل سرور.</p> <p>‏با دستور دستی شبکه موقتاً وصل شد:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code>‏ip addr add 193.222.99.171/32 dev ens3 ‏ip route add default via 10.0.0.1 dev ens3 onlink </code></pre> </div> <p>‏اینترنت و SSH بلافاصله وصل شدند، اما این دستورات فقط در رم زنده هستند و با ریبوت مجدد می‌پرند.</p> <p>‏### ۳. تله‌های حین دائمی‌سازی شبکه<br> ‏برای دائمی کردن تنظیمات سراغ <code>systemd-networkd</code> رفتیم، اما دو چالش پیش آمد:<br> ‏1. <strong>خطای ساختاری فایل کانفیگ:</strong> قراردادن دستور <code>GatewayOnLink=yes</code> داخل سکشن <code>[Network]</code> نامعتبر است و توسط هسته نادیده گرفته می‌شود. این دستور حتماً باید زیر سکشن <code>[Route]</code> تعریف شود.<br> ‏2. <strong>تداخل فایل‌های قدیمی:</strong> فایل قدیمی <code>/etc/network/interfaces</code> و <code>/etc/hosts</code> همچنان آی‌پی منسوخ قبلی را صدا می‌زدند و باعث ثبت دو آی‌پی هم‌زمان روی کارت شبکه می‌شدند.</p> <p>‏### ۴. راه‌حل نهایی و استاندارد<br> ‏ساخت فایل کانفیگ مستقل برای <code>systemd-networkd</code>:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight ini"><code><span class="c"># /etc/systemd/network/10-ens3.network </span><span class="err">‏</span><span class="nn">[Match]</span> <span class="err">‏</span><span class="py">Name</span><span class="p">=</span><span class="s">ens3</span> <span class="err">‏</span><span class="nn">[Network]</span> <span class="err">‏</span><span class="py">Address</span><span class="p">=</span><span class="s">193.222.99.171/32</span> <span class="err">‏</span><span class="py">DNS</span><span class="p">=</span><span class="s">8.8.8.8</span> <span class="err">‏</span><span class="py">DNS</span><span class="p">=</span><span class="s">1.1.1.1</span> <span class="err">‏</span><span class="nn">[Route]</span> <span class="err">‏</span><span class="py">Gateway</span><span class="p">=</span><span class="s">10.0.0.1</span> <span class="err">‏</span><span class="py">GatewayOnLink</span><span class="p">=</span><span class="s">yes</span> </code></pre> </div> <p>‏و پاکسازی ردپای آی‌پی قبلی:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code>‏sed <span class="nt">-i</span> <span class="s1">'s/2.26.48.117/193.222.99.171/g'</span> /etc/hosts ‏sed <span class="nt">-i</span> <span class="s1">'s/2.26.48.117/193.222.99.171/g'</span> /etc/network/interfaces ‏ip addr del 2.26.48.117/32 dev ens3 ‏systemctl restart systemd-networkd </code></pre> </div> <p>‏### ۵. معمای عدم پاسخ پینگ در Check-Host<br> ‏بعد از آنلاین شدن سرور و پایداری SSH، سایت‌های تست پینگ (مثل Check-Host) خطای ۱۰۰٪ Packet Loss می‌دادند؛ در حالی که فایروال محلی سرور (<code>iptables</code>) کاملاً باز بود.</p> <p>‏<strong>علت:</strong> فایروال لبه دیتاسنتر (Anti-DDoS Scrubbing) پکت‌های ورودی ICMP (پینگ) را قبل از رسیدن به سرور فیلتر می‌کند تا از حملات Flood جلوگیری کند. اعتبارسنجی واقعی سلامت سرور باید از طریق برقراری کانکشن‌های TCP (مثل پورت ۲۲ برای SSH یا پورت‌های وب) انجام شود که در این حالت تأخیر زیر ۱ میلی‌ثانیه را ثبت کردند.</p> <p>‏### 💡 درس‌های کلیدی برای ادمین‌ها:<br> ‏1. در سیستم‌های Minimized لینوکس فرض نکنید ابزارهای مدیریتی شبکه حاضرند؛ <code>systemd-networkd</code> پایدارترین گزینه بومی است.<br> ‏2. گیت‌وی‌های ناهم‌نام در ساب‌نت <code>/32</code> بدون فلگ <code>onlink</code> مسیریابی نمی‌شوند.<br> ‏3. عدم پاسخ پینگ عمومی (ICMP) لزوماً به معنی قطعی سرور نیست؛ همیشه پورت‌های سرویس (TCP) را تست کنید.</p> linux devops networking Dal Tue, 22 Sep 2026 04:28:42 +0000 https://dev.to/dalroot/integration-test-automated-agent-connection-30b8 https://dev.to/dalroot/integration-test-automated-agent-connection-30b8 <h1> Hello Dev.to </h1> <p>This is an automated connectivity test post from agent integration.</p> test discuss