بسته دیوار آتش نصب شد، قواعد پس از راه‌اندازی مجدد ناپدید شدند

بسته بی‌دردسر نصب شد، قواعد آزمایش شدند و پس از راه‌اندازی مجدد بعدی، دروازه کاملاً باز بود. هیچ چیز در این تراکنش شکست نخورد؛ خطا در فرضی بود درباره آنچه باقی می‌ماند. نصب ابزارهای دیوار آتش، تصمیم درباره اینکه کدام قواعد باید بمانند و بازیابی آن‌ها در لحظه درست، سه کار جدا هستند.

نشانه در واقع چه می‌گوید

مجموعه قواعدی که با راه‌اندازی مجدد ناپدید می‌شود یکی از سه صاحب را دارد: هیچ‌چیز آن را ذخیره نکرد، چیز دیگری آن را جایگزین کرد، یا پیش از وجود چیزی که به آن وابسته است بازیابی شد. دو مورد نخست در پیکربندی دیده می‌شوند؛ سومین تنها در ترتیب آشکار می‌شود. به همین دلیل راه‌اندازی مجدد می‌تواند مانند از دست رفتن داده به نظر برسد، در حالی که در واقع مسئله ترتیب است.

با نوشتن آنچه پیش از راه‌اندازی مجدد درست بود شروع کنید: کدام سرویس قواعد را نگه می‌داشت، در آغاز کدام فایل یا پایگاه داده را می‌خواند و آیا هرگز در آن منبع نوشته شده بود. مجموعه قواعد فعالی که کسی ذخیره نکرده باشد توضیح معتبری است و رایج‌ترین.

با نصب دوباره بسته شروع نکنید.

ابزار ماندگاری را پیش از استفاده بخوانید

ابزارهای دبیان ماندگاری را مسئله افزونه می‌دانند: هر افزونه می‌داند قواعد خود را چگونه بنویسد و یک پوشش آن‌ها را فرا می‌خواند. کنش ذخیره آن هر چیزی را که در آن لحظه بارگذاری شده نگه می‌دارد و کنش شروع آن همان تصویر لحظه‌ای را بازمی‌گرداند. هیچ‌کدام از دو کنش بازبینی نمی‌کند که چه چیزی ذخیره می‌شود.

این یک تصویر لحظه‌ای است، نه بازبینی. یک اجازه باقی‌مانده از نشست اشکال‌زدایی، یک آزمایش نیمه‌تمام یا یک قاعده آسان‌گیر که ابزار کمکی دیگری وارد کرده، همگی در کنار سیاستی که می‌خواستید نگه دارید دائمی می‌شوند. ذخیره وضعیت و تأیید وضعیت فعالیت‌های متفاوتی هستند و تنها یکی از آن‌ها داوری می‌خواهد. نخست مجموعه بارگذاری‌شده را بخوانید، سپس تصمیم بگیرید کدام خطوط شایسته ماندن هستند.

آگاهانه ذخیره کنید، پس از خواندن آنچه بارگذاری شده.

تصمیم بگیرید چه چیزی باید بماند

برخی قواعد به چرخه عمر یک واسط تعلق دارند و باید با آن ناپدید شوند. برخی دیگر باید از تونل بیشتر بمانند و روشن‌ترین نمونه محدودیتی است که جلوگیری می‌کند از بازگشت ترافیک کارخواه به واسط فیزیکی هنگام افتادن تونل. این دو دسته به محرک‌های بازیابی متفاوت نیاز دارند، نه یک تصویر لحظه‌ای مشترک.

نتیجه مورد نظر را برای سه لحظه بنویسید: راه‌اندازی، فعال‌سازی VPN و از دست رفتن تونل. سپس بررسی کنید آیا ابزاری که انتخاب کرده‌اید می‌تواند هر یک را بیان کند. بسته ماندگاری که یک تصویر لحظه‌ای ایستا را دوباره بار می‌کند اولی را پوشش می‌دهد و شاید هیچ‌یک از بقیه را، زیرا تصویر لحظه‌ای نمی‌داند وضعیت تونل چه زمانی تغییر کرده است. اگر نتواند آن‌ها را بیان کند، شکاف به مؤلفه دیگری تعلق دارد.

سیاست، نه بسته، پاسخ را تعیین می‌کند.

ترتیب بازیابی را بررسی کنید

بازیابی فایل همانند مالکیت نتیجه نیست. مدیر دیگری می‌تواند قواعد را جایگزین کند، یک اجازه پیشین می‌تواند آن‌ها را تحت‌الشعاع قرار دهد، یا کارخواهان می‌توانند پیش از اعمال محدودیت ارسال را آغاز کنند. رفتار راه‌اندازی و اتصال دوباره را بازبینی کنید، نه فقط وجود یک فایل ذخیره‌شده.

systemctl status netfilter-persistent
iptables -S

فرض نکنید که توقف سرویس ماندگاری بی‌خطر است، زیرا بسته هنگام توقف یک تخلیه شرطی را مستند می‌کند. پیش از استفاده از توقف یا راه‌اندازی مجدد به‌عنوان آزمایش روی دروازه‌ای که از راه دور مدیریت می‌کنید، پیکربندی واقعی سرویس را مشخص کنید. یک نشست کنسول و یک بازگشت مستند، حداقل پیش از آن آزمایش است.

ترتیب ویژگی سیستم در حال اجراست، نه فایل روی دیسک.

سه نتیجه جدا را بپذیرید

نصب بسته، مجموعه قواعد بارگذاری‌شده و سیاست اعمال‌شده را واقعیت‌های جدا ثبت کنید. نام بسته در یک رشته پشتیبانی تنها به اولی پاسخ می‌دهد و همان چیزی است که به‌ندرت اهمیت دارد.

nft list ruleset

سپس یک عملیات مجاز و یک رد الزامی را آزمایش کنید.

اگر رد پس از راه‌اندازی مجدد و پس از افتادن تونل پابرجا بماند، سیاست زنده می‌ماند. اگر تنها در یکی از این وضعیت‌ها پابرجا بماند، مسئله ترتیب را یافته‌اید نه اینکه آن را اصلاح کرده باشید.