چرا این موضوع مهم است؟
firewalld مفهوم zone، service و runtime/permanent را ارائه می‌کند و ruleها را روی backend packet filtering اعمال می‌کند. zone باید بیانگر trust level interface/source باشد، نه صرفاً نام دلخواه.
در یک سیستم واقعی، قبل از انتخاب ابزار باید مدل ذهنی درستی از لایه‌ها داشته باشید. هر بار که یک مشکل را فقط با یک command یا تنظیم حفظی حل می‌کنیم، دانش به نسخه و محیط خاص گره می‌خورد. روش بهتر این است که ورودی، state، policy، مسیر داده و خروجی را مشخص کنیم. بعد ابزار را برای مشاهدهٔ یکی از این لایه‌ها انتخاب کنیم. این رویکرد باعث می‌شود وقتی نسخه یا توزیع عوض شد، هنوز بدانیم دنبال چه evidenceای هستیم.
مدل معماری
در موضوع مدیریت firewall در Linux با firewalld و nftables، componentها را روی یک مسیر ساده بکشید و مرز مسئولیت هرکدام را مشخص کنید. state پایدار، state runtime، dependency بیرونی و نقطهٔ اعمال policy را جدا کنید. وقتی diagram ساده دارید، خطا از یک «سیستم بزرگ و مبهم» به چند مرحلهٔ قابل آزمون تبدیل می‌شود.
روش عملی کار
ابتدا active zone و interface mapping را بررسی کنید، serviceهای لازم را به‌جای portهای پراکنده تعریف کنید و تغییر runtime را قبل از permanent شدن تست کنید. برای rule پیچیده direct/rich rule را با مستندات دقیق استفاده کنید.
برای Production، تغییر باید قابل اندازه‌گیری و قابل برگشت باشد. baseline قبل از تغییر شامل نسخه، config مؤثر، log سالم، metric اصلی و یک تست end-to-end است. rollout را با canary شروع کنید؛ بعد از هر مرحله هم تست مثبت و هم تست منفی داشته باشید. اگر success criterion از قبل نوشته نشده باشد، بعد از اجرا به‌سادگی هر نتیجه‌ای را می‌توان «موفق» تفسیر کرد. rollback هم باید تمرین شود، نه اینکه فقط یک دستور روی کاغذ باشد.
از دید امنیت
تغییر فقط runtime بعد از reboot از بین می‌رود و تغییر permanent بدون reload فوراً فعال نیست. بازکردن service روی zone اشتباه نیز یکی از خطاهای معمول است.
از دید امنیت، کم‌کردن سطح دسترسی مهم است اما availability و قابلیت عیب‌یابی هم جزو امنیت عملیاتی‌اند. secretها، tokenها، capabilityها، network path و logهای حساس را جدا بررسی کنید. هر exception باید owner، دلیل و تاریخ بازبینی داشته باشد. کنترل‌هایی که هیچ‌کس نمی‌تواند اثرشان را مشاهده یا علتشان را توضیح دهد، در زمان incident به مانع تبدیل می‌شوند.
آزمایشگاه پیشنهادی
دو interface یا source network را در zoneهای متفاوت قرار دهید، SSH را فقط در zone مدیریت باز کنید و packet path را با nft list ruleset و firewall-cmd مقایسه کنید.
برای هر مرحله timestamp و خروجی را ذخیره کنید. یک failure کنترل‌شده ایجاد کنید تا مطمئن شوید monitoring واقعاً failure را می‌بیند. سپس سیستم را به baseline برگردانید و زمان recovery را ثبت کنید.
عیب‌یابی بر پایهٔ Evidence
Troubleshooting را با تغییر config شروع نکنید. اول محل دقیق failure را پیدا کنید: آیا ورودی وارد سیستم می‌شود؟ آیا state مورد انتظار ساخته شده؟ آیا policy اجازه می‌دهد؟ آیا خروجی از component خارج می‌شود؟ log، packet capture، metric و state API باید به یک timeline مشترک وصل شوند. نبودن event نیز evidence است؛ اگر request قبل از یک component دیده می‌شود و بعد از آن نه، دامنهٔ مسئله کوچک شده است.
Performance و ظرفیت
عملکرد را فقط با average نسنجید. p95/p99 latency، saturation، queue depth، retry و resource pressure تصویر بهتری می‌دهند. تغییری که در lab کوچک سریع است ممکن است زیر concurrency یا dataset واقعی bottleneck متفاوتی نشان دهد. capacity limitها را قبل از rollout بزرگ شناسایی کنید و alert را به thresholdهای قابل اقدام وصل کنید.
Production readiness
قبل از rollout نهایی، owner، change window، blast radius، success metric و rollback trigger باید مشخص باشند. اگر dependency خارجی دارید، رفتار هنگام timeout یا unavailable شدن آن را تست کنید. اگر config به چند host می‌رود، rollout مرحله‌ای و inventory دقیق لازم است. یک تغییر خوب باید observable، explainable و reversible باشد.
Runbook و انتقال دانش
در مستندسازی، فقط «چه دستورهایی اجرا شد» را ننویسید. سؤال، فرضیه، evidence مورد انتظار، نتیجه و دلیل تصمیم را ثبت کنید. اگر همکار دیگری بتواند با همان ورودی آزمایش را تکرار کند و به نتیجهٔ مشابه برسد، runbook ارزش عملیاتی دارد. اگر فقط نویسنده می‌داند چرا مرحله‌ای لازم است، دانش هنوز منتقل نشده است.
قبل از Production چه چیزی را اعتبارسنجی کنیم؟
نتیجهٔ Lab را مستقیم به Production تعمیم ندهید. یک change plan کوتاه بسازید که در آن دامنهٔ تغییر، owner، زمان اجرا، dependencyها، success metric و rollback trigger مشخص باشد. ابتدا روی canary یا درصد کوچکی از workload اجرا کنید و حداقل یک چرخهٔ واقعی restart، credential rotation یا deploy دوم را ببینید؛ بسیاری از خطاها در اولین اجرای سالم ظاهر نمی‌شوند. رفتار هنگام unavailable شدن dependency خارجی، پر شدن disk، timeout شبکه و ورودی نامعتبر را نیز بررسی کنید. اگر feature امنیتی است، test منفی باید نشان دهد مسیر غیرمجاز واقعاً بسته است؛ اگر feature performance است، benchmark باید با load و dataset نزدیک به واقعیت اجرا شود. در پایان، تصمیم rollout را با evidence ثبت کنید، نه با جملهٔ مبهم «به‌نظر خوب است».
نگهداری بلندمدت و بازبینی دوره‌ای
معماری بعد از deploy ثابت نمی‌ماند. نسخهٔ سیستم‌عامل، dependency، policy سازمان، certificate، endpoint و حجم workload تغییر می‌کنند. برای همین باید بازبینی دوره‌ای تعریف شود: نسخه‌های پشتیبانی‌نشده را پیدا کنید، exceptionهای قدیمی را ببندید، alertهای بی‌ارزش را حذف کنید و recovery را دوباره تمرین کنید. اگر configuration در Git نگهداری می‌شود، drift میان state واقعی و repository را اندازه بگیرید. اگر ابزار SaaS یا سرویس خارجی است، تغییر API، pricing، limit و مدل permission را دنبال کنید. مستندات باید تاریخ review داشته باشند تا تیم بداند کدام فرض‌ها هنوز معتبرند. نگهداری خوب یعنی سیستم بعد از شش ماه هم قابل توضیح و قابل بازیابی باشد، نه اینکه فقط روز اول deploy موفق بوده باشد.
جمع‌بندی
هدف این مقاله دربارهٔ مدیریت firewall در Linux با firewalld و nftables ارائهٔ یک دستور جادویی نیست؛ هدف ساختن مدل ذهنی است. وقتی معماری را بفهمید، baseline داشته باشید و تغییر را با evidence کوچک کنید، ابزارها قابل تعویض می‌شوند اما روش حل مسئله باقی می‌ماند. منبع اصلی این مقاله از Red Hat انتخاب شده تا جزئیات فنی قابل پیگیری باشند.
چک‌لیست سریع
- مسئله را در یک جمله تعریف کن.
- component و مرز اعتماد را مشخص کن.
- baseline را قبل از تغییر ذخیره کن.
- یک test مثبت و یک test منفی بساز.
- تغییر را با canary شروع کن.
- evidence را timestampدار نگه دار.
- rollback را واقعاً تمرین کن.
- نتیجه و exceptionها را در runbook ثبت کن.
مسیر بسته تعیین می‌کند کدام سیاست مهم است
پیش از افزودن یک درگاه، مشخص کنید بسته برای خود میزبان است یا باید از آن عبور کند. دسترسی به خدمت وب روی همان سرور با عبور ترافیک میان دو شبکه مسئله یکسانی نیست. همچنین ارتباطی که از خود میزبان شروع می‌شود با اتصال ورودی تفاوت دارد. در یک ماشین دارای چند رابط، نام ناحیه به تنهایی چیزی را تضمین نمی‌کند؛ نگاشت واقعی رابط یا مبدأ به ناحیه است که اهمیت دارد. خروجی ناحیه‌های فعال را کنار نشانی‌های رابط‌ها بگذارید و روشن کنید درخواست آزمایشی از کدام مسیر وارد می‌شود.
فرض کنید رابط مدیریت باید فقط دسترسی مدیریتی بدهد و رابط عمومی خدمت وب را ارائه کند. اگر خدمت مدیریت را در ناحیه پیش‌فرض باز کنید اما رابط مورد نظر در ناحیه دیگری باشد، نتیجه با انتظار متفاوت خواهد شد. برعکس، باز کردن خدمت روی ناحیه عمومی ممکن است سطح دسترسی را بیش از نیاز افزایش دهد. برای هر تغییر، مبدأ آزمایش را ثبت کنید. موفقیت اتصال از خود سرور یا از شبکه مدیریت ثابت نمی‌کند که رفتار اینترنت عمومی هم مطابق سیاست است.
نام خدمت به معنی اجرای خدمت نیست
تعریف یک service در firewalld مجموعه‌ای از نیازهای شبکه‌ای را توصیف می‌کند؛ افزودن آن برنامه مربوط را نصب یا اجرا نمی‌کند. اگر درگاه مجاز است ولی اتصال شکست می‌خورد، ابتدا بررسی کنید فرایند روی نشانی و درگاه درست گوش می‌دهد. گوش دادن فقط روی نشانی حلقه محلی مانع اتصال بیرونی می‌شود، حتی اگر فایروال اجازه دهد. پس از آن مسیر شبکه و سیاست‌های دیگر میزبان، مانند کنترل دسترسی اجباری، را بررسی کنید. خاموش کردن کامل فایروال برای تشخیص معمولاً اطلاعات کمتری از مشاهده دقیق مسیر بسته می‌دهد و دامنه تغییر بزرگ‌تری دارد.
نام خدمت را نیز بدون بررسی محتوا نپذیرید. ممکن است تعریف بسته توزیع یا تعریف سفارشی شامل چند درگاه یا پروتکل باشد. هنگام نیاز به یک خدمت داخلی خاص، توضیح کوتاهی درباره هدف و مالک آن ثبت کنید. این کار از انباشته شدن درگاه‌های بی‌نام جلوگیری می‌کند. اگر نیاز فقط برای یک آزمون کوتاه است، امکان تغییر موقت و زمان‌دار را در نسخه نصب‌شده بررسی کنید تا مجوز آزمایشی فراموش نشود. موفقیت آزمون نباید به طور خودکار به مجوز دائمی تبدیل شود.
آزمون ماندگاری را با آزمون دسترسی ترکیب کنید
تنظیم زمان اجرا برای ارزیابی فوری مفید است، اما پس از بارگذاری مجدد ممکن است از بین برود. تنظیم دائمی نیز تا زمانی که وارد وضعیت فعال نشده، شاهدی برای رفتار جاری نیست. بنابراین دو پرسش جدا بپرسید: اکنون چه سیاستی اجرا می‌شود و پس از راه‌اندازی دوباره چه سیاستی اجرا خواهد شد؟ قبل از ذخیره همه تغییرات فعال، بررسی کنید آیا تغییر موقت همکار دیگری نیز در آن مجموعه وجود دارد. تبدیل کورکورانه وضعیت فعال به دائمی می‌تواند استثناهای آزمایشی را ماندگار کند.
روی سرور دوردست، پیش از محدود کردن دسترسی مدیریت یک نشست دوم و راه دسترسی جایگزین آماده داشته باشید. تغییر را ابتدا روی نمونه آزمایشگاهی یا رابط غیرحیاتی امتحان کنید. سپس یک اتصال تازه برقرار کنید؛ زنده ماندن نشست قبلی کافی نیست، زیرا حالت اتصال برقرار ممکن است رفتار متفاوتی از اتصال جدید داشته باشد. پس از ثبت دائمی و بارگذاری مجدد، دوباره همان اتصال تازه را از مبدأ مجاز و غیرمجاز آزمایش کنید. این توالی هم رفتار سیاست و هم دوام آن را بررسی می‌کند.
تعامل با ابزارهای دیگر میزبان
نرم‌افزارهای کانتینری، شبکه مجازی و ابزارهای مدیریت دیگر ممکن است قواعد خود را ایجاد کنند. پیش از پاک کردن جدول‌ها، مالک هر بخش را شناسایی کنید. مشاهده ruleset برای فهم نتیجه مفید است، اما ویرایش مستقیم قواعدی که یک سرویس مدیریتی تولید می‌کند ممکن است در بارگذاری بعدی از بین برود. نسخه و backend فعال را نیز بررسی کنید؛ نباید از نام firewalld نتیجه گرفت که همه توزیع‌ها و نصب‌های تاریخی دقیقاً رفتار یکسان دارند. سیاست باید تا حد امکان در همان لایه‌ای ثبت شود که مسئول نگهداری آن است. اگر دو مدیر مستقل یک مسیر را کنترل می‌کنند، مستند کردن ترتیب و مرز مسئولیت‌ها شرط عیب‌یابی قابل اعتماد است.
