تصویر کلی
فایل‌های .network با Match روی Interface اعمال می‌شوند و Address، Route، Gateway و گزینه‌های Link را تعریف می‌کنند.
برای فهم این موضوع بهتر است اجزا را به‌عنوان یک مسیر ببینیم، نه مجموعه‌ای از گزینه‌های مستقل. در Production معمولاً مشکل زمانی شکل می‌گیرد که تنظیم روی دیسک، وضعیت Runtime و فرض تیم درباره رفتار سیستم با هم یکی نیستند. به همین دلیل مشاهده وضعیت مؤثر، Log و Metric باید کنار Configuration بررسی شود.
اجزای اصلی و مرز مسئولیت
ترتیب فایل و Match می‌تواند تعیین کند کدام تنظیم واقعاً انتخاب شود؛ صرف وجود فایل روی دیسک تضمین اعمال آن نیست.
در طراحی عملی، برای هر جزء یک سؤال روشن بنویسید: چه ورودی می‌گیرد، چه خروجی تولید می‌کند، چه Stateای نگه می‌دارد و در خرابی چه کسی مسئول Recovery است. این مدل ساده کمک می‌کند خطاهای شبکه، هویت، ذخیره‌سازی یا Replication به‌اشتباه به جزء دیگری نسبت داده نشوند.
خطاهای رایج
بعد از تغییر، وضعیت ip addr، ip route، networkctl و resolvectl باید با انتظار مقایسه شود؛ DNS و Route دو مسیر مستقل‌اند.
خطای دیگر، فعال‌کردن قابلیت پیشرفته بدون تعریف معیار موفقیت است. قبل از تغییر، Baseline بگیرید؛ بعد از تغییر همان Signalها را مقایسه کنید. اگر سیستم توزیع‌شده است، Failure Modeهای قطع شبکه، Restart، Lag، Timeout و از دست‌رفتن Dependency را نیز آزمایش کنید.
چک‌لیست عملی
- نسخه و Configuration مؤثر را ثبت کنید، نه فقط فایل مورد انتظار را.
- مسیر داده و کنترل را جدا رسم کنید.
- Health، Latency، Error Rate و ظرفیت را قبل و بعد از تغییر مقایسه کنید.
- برای تغییرات Stateful، Backup/Restore یا Rollback واقعی را آزمایش کنید.
- دسترسی مدیریتی را حداقل کنید و Log تصمیم‌ها را نگه دارید.
- مستندات همان نسخه محصول را مرجع نهایی قرار دهید.
تمرین IROSG
یک محیط کوچک آزمایشی بسازید و فقط یک Failure را تزریق کنید؛ مثلاً قطع Upstream، حذف یک Replica، خطای DNS یا تغییر Route. قبل از آزمایش بنویسید انتظار دارید کدام Metric و Log تغییر کند. بعد نتیجه واقعی را با انتظار مقایسه کنید. این تمرین معمولاً سریع‌تر از حفظ‌کردن Optionها، مدل ذهنی سیستم را اصلاح می‌کند.
مرجع
این راهنما بر پایه مستندات رسمی systemd نوشته شده و مثال‌های عملی تحریریه برای آموزش دفاعی و عملیاتی هستند.
تفاوت Link و Network در عمل
یک رابط شبکه ابتدا باید وجود داشته باشد و ویژگی‌های پایه آن شناخته شود؛ سپس تنظیمات شبکه مانند آدرس و مسیر روی آن اعمال می‌شود. فایل‌های با پسوند network برای تطبیق با رابط‌ها و تعیین این تنظیمات به کار می‌روند. فایل‌های link و netdev مسئولیت‌های متفاوتی دارند و نباید صرف شباهت نام‌ها جای یکدیگر استفاده شوند. برای شروع، فهرست رابط‌های واقعی ماشین را ببینید و مشخص کنید کدام فیزیکی، کدام مجازی و کدام متعلق به سازوکار دیگری مانند کانتینر است.
در یک ماشین با چند کارت شبکه، نام رابط را از روی آموزش اینترنتی حدس نزنید. نام‌گذاری می‌تواند با سخت‌افزار، محیط مجازی و سیاست سیستم تغییر کند. پیش از نوشتن بخش تطبیق، خروجی وضعیت همان ماشین را ثبت کنید. اگر قاعده بیش‌ازحد گسترده باشد، ممکن است تنظیمی که برای شبکه مدیریت نوشته‌اید روی رابط دیگری نیز اعمال شود. در تمرین، ابتدا فقط یک رابط آزمایشی را هدف بگیرید و نتیجه تطبیق فایل را از وضعیت مؤثر بررسی کنید.
انتخاب فایل و تقدم تنظیمات
وجود چند فایل شبکه با قواعد هم‌پوشان می‌تواند تشخیص رفتار را دشوار کند. فقط آخرین فایلی را که خودتان ساخته‌اید نگاه نکنید؛ فایل‌های ارائه‌شده توسط بسته، ابزار نصب یا مدیر پیکربندی نیز ممکن است وجود داشته باشند. مستندات همان نسخه را برای ترتیب انتخاب و قواعد جایگزینی بخوانید و وضعیت مؤثر را بررسی کنید. یک نام فایل آشنا دلیل نمی‌شود آن فایل برای رابط انتخاب شده باشد. گزارش عملیات باید نام فایل واقعاً تطبیق‌یافته را شامل شود.
اگر ابزار دیگری مانند NetworkManager همان رابط را مدیریت می‌کند، نخست مالک مدیریت را روشن کنید. دو مدیر هم‌زمان ممکن است آدرس یا مسیر یکدیگر را تغییر دهند و رفتار ناپایدار بسازند. انتقال مالکیت باید طرح مشخص داشته باشد، به ویژه اگر اتصال مدیریتی شما از همان رابط عبور می‌کند. در محیط آزمایش، پس از تغییر مدیر، راه‌اندازی دوباره سیستم را نیز امتحان کنید. تنظیمی که فقط تا reboot کار می‌کند هنوز پایدار و قابل اتکا نیست.
آدرس ثابت و DHCP چه تعهدی می‌سازند؟
آدرس ثابت باید با طرح شبکه هماهنگ باشد و با دستگاه دیگر تداخل نداشته باشد. انتخاب یک آدرس آزاد در لحظه، تضمین نمی‌کند آن آدرس در سامانه تخصیص برای میزبان دیگری رزرو نشده است. پیش از اعمال، محدوده، پیشوند و دروازه را از مرجع شبکه بگیرید. در آزمایش، آدرس رابط را با مسیرهای ایجادشده مقایسه کنید. داشتن آدرس روی رابط به تنهایی به معنی دسترسی به اینترنت یا شبکه دوردست نیست.
DHCP می‌تواند علاوه بر آدرس، اطلاعات دیگری مانند مسیر و DNS ارائه کند. تصمیم بگیرید کدام داده‌های دریافتی باید پذیرفته شوند. اگر هم آدرس ثابت و هم تنظیم پویا دارید، رفتار ترکیب آنها را در محیط خود بررسی کنید. یک مسیر پیش‌فرض ناخواسته از رابط دوم می‌تواند ترافیک مدیریت را از مسیر دیگری خارج کند. پس از تمدید اجاره و پس از راه‌اندازی دوباره نیز وضعیت را ببینید؛ مسئله ممکن است تنها هنگام رویداد پویا ظاهر شود.
Route را از Address جدا عیب‌یابی کنید
آدرس مشخص می‌کند رابط چگونه در شبکه شناخته می‌شود، ولی جدول مسیر تعیین می‌کند بسته برای مقصد معین از کجا برود. اگر همسایه محلی قابل دسترس است ولی مقصد دوردست نه، مسیر پیش‌فرض و دروازه را بررسی کنید. اگر چند مسیر وجود دارد، معیار انتخاب و سیاست مسیریابی اهمیت پیدا می‌کند. برای یک مقصد آزمایشی، مسیر انتخاب‌شده سیستم را مشاهده کنید تا حدس درباره خروج از رابط خاص با واقعیت مقایسه شود.
در یک میزبان دوشبکه‌ای، رفت و برگشت ممکن است از مسیرهای متفاوت عبور کنند. این حالت می‌تواند با سیاست فایروال یا بررسی مسیر برگشت تداخل داشته باشد. قبل از تغییر تنظیمات امنیتی، مسیر واقعی هر دو سمت را بررسی کنید. مشکل را با افزودن چند مسیر تصادفی پنهان نکنید. برای هر مسیر جدید، مقصد، دروازه، رابط و دلیل وجود را ثبت کنید. این مستند کوچک هنگام حذف یک شبکه قدیمی یا تغییر دروازه ارزش زیادی دارد.
DNS یک زنجیره مستقل است
تنظیم DNS در فایل شبکه به معنای پاسخ دادن خود systemd-networkd به پرس‌وجوهای نام نیست. در بسیاری از استقرارها، همکاری با resolver سیستم و اجزایی مانند systemd-resolved مطرح است. باید ببینید برنامه‌ها واقعاً از چه مسیر حل نام استفاده می‌کنند و تنظیم دریافت‌شده کجا مصرف می‌شود. اگر آدرس مستقیم کار می‌کند ولی نام نه، وضعیت resolver و فایل یا پیوند مربوط به تنظیمات نام را بررسی کنید. صرف وجود مقدار DNS در یک فایل کافی نیست.
برای آزمایش، یک نام داخلی و یک نام بیرونی مورد نیاز محیط را جدا بررسی کنید. ممکن است شبکه سازمانی به دامنه‌های داخلی از resolver خاصی نیاز داشته باشد. ارسال همه پرس‌وجوها به یک DNS عمومی می‌تواند دسترسی داخلی را بشکند یا اطلاعات نام‌ها را بیرون بفرستد. سیاست دامنه و مسیر حل نام باید با معماری سازمان سازگار باشد. در گزارش، نتیجه نام داخلی و بیرونی را جدا بنویسید تا مشکل محدود به یک حوزه با قطع کامل شبکه اشتباه نشود.
تغییر از راه دور را قابل بازیابی طراحی کنید
اگر رابطی که تغییر می‌دهید مسیر SSH شماست، احتمال قطع جلسه را در طرح لحاظ کنید. دسترسی کنسول یا مسیر مدیریتی جایگزین باید پیش از تغییر معلوم باشد. نسخه قبلی فایل را نگه دارید و روش بازگشت را در ماشین آزمایشی تمرین کنید. اتکا به اینکه «اگر قطع شد دوباره وصل می‌شوم» برای تغییر آدرس یا مسیر کافی نیست. بهتر است تغییر ابتدا در محیطی با دسترسی مستقیم و داده غیرحساس آزموده شود.
اعمال تنظیم و reload رفتار وابسته به نسخه و نوع تغییر دارد. مستندات ابزارهای همان سیستم را بخوانید و فرض نکنید هر ویرایش فایل بلافاصله وضعیت فعال را تغییر می‌دهد. پس از اعمال، آدرس، مسیر، DNS و وضعیت سرویس را مستقل بررسی کنید. سپس یک اتصال تازه باز کنید؛ سالم ماندن یک اتصال قدیمی ممکن است همه مسیرهای ایجاد اتصال جدید را ثابت نکند. آزمون نهایی باید شامل reboot برنامه‌ریزی‌شده در محیط آزمایش نیز باشد.
نشانه‌های خرابی را به لایه مربوط وصل کنید
نبودن carrier یا قطع فیزیکی با نداشتن آدرس فرق دارد. نداشتن آدرس با نبود مسیر فرق دارد و نبود مسیر نیز با خطای حل نام یکسان نیست. یک چک ساده از پایین به بالا انجام دهید: رابط موجود است، لینک برقرار است، آدرس درست دارد، مسیر مناسب انتخاب می‌شود، مقصد با آدرس قابل دسترس است و سپس نام حل می‌شود. هر مرحله را با شاهد ثبت کنید. این ترتیب از تغییر DNS برای مشکل کابل یا تغییر مسیر برای خطای برنامه جلوگیری می‌کند.
اگر فقط یک برنامه مشکل دارد، تنظیمات پراکسی، فضای نام شبکه یا محدودیت سرویس آن را نیز بررسی کنید. ممکن است پوسته مدیر اتصال داشته باشد ولی برنامه در محیط محدود دیگری اجرا شود. نتیجه تست از حساب یا محیط متفاوت را به برنامه تعمیم ندهید. برای بازتولید، همان هویت اجرا و همان مسیر شبکه را تا حد امکان استفاده کنید. این نکته به ویژه در سرویس‌های دارای sandbox یا کانتینر اهمیت دارد.
نگهداری فایل‌های شبکه به عنوان پیکربندی زیرساخت
برای هر فایل، هدف رابط، منبع آدرس و وابستگی‌های مهم را توضیح دهید. اطلاعات حساس یا رمز را در توضیحات عمومی قرار ندهید. تغییرات را با بازبینی و نسخه‌بندی نگه دارید تا معلوم باشد مسیر یا DNS چرا اضافه شده است. پس از تغییر سخت‌افزار یا مهاجرت ماشین مجازی، قواعد تطبیق را دوباره بررسی کنید؛ پیکربندی قدیمی ممکن است دیگر رابط مورد نظر را انتخاب نکند. نتیجه مطلوب یک اتصال تصادفاً سالم نیست، بلکه وضعیتی است که پس از راه‌اندازی دوباره قابل بازسازی و برای همکار بعدی قابل توضیح باشد.
