تغییر قاعده فایروال کار نمی‌کند: ترتیب قواعد و وضعیت اتصال
قاعده ویرایش‌شده ممکن است پشت یک پذیرش قبلی بماند یا توسط ردیابی اتصال نادیده گرفته شود. دو آزمون را جدا کنید، از یک جریان تازه استفاده کنید و راه بازگشت را حفظ کنید.
قاعده را ویرایش کردید، مجموعه قواعد را دوباره بارگذاری کردید و تونل دقیقاً مثل قبل رفتار می‌کند. این نتیجه دو علت رایج دارد و به آزمون‌های متفاوتی نیاز دارند. یا قاعده جدید پس از قاعده‌ای قبلی قرار دارد که بسته را قبلاً پذیرفته است، یا تبادلی که تماشا می‌کنید یک اتصال ردیابی‌شده است که تغییر هرگز آن را دوباره ارزیابی نمی‌کند. قاعده در یک فایل نیت را بیان می‌کند؛ آنچه سرنوشت بسته را تعیین می‌کند مسیر فعالی است که با آن روبه‌رو می‌شود. بررسی‌های زیر را به ترتیب انجام دهید و در این حین یک راه بازگشت را باز نگه دارید.
ترتیب قواعد و وضعیت اتصال دو عیب متفاوت‌اند
زنجیره‌های مرتب از بالا به پایین ارزیابی می‌شوند و نخستین قاعده‌ای که به حکم نهایی برسد، پیمایش آن زنجیره را پایان می‌دهد. یک پذیرش گسترده را بالای قاعده‌ای محافظه‌کارانه برای قفل‌کردن بگذارید و آن قاعده به مستندات تبدیل می‌شود: در مجموعه قواعد هست، شمارنده‌اش صفر است و هیچ بسته‌ای هرگز به آن نمی‌رسد. همان متن روی زنجیره‌ای دیگر هم چیزی را اثبات نمی‌کند. در nftables زنجیره‌های پایه با اولویت‌ها به هوک‌ها متصل می‌شوند، پس یک پذیرش در یک زنجیره مانع دیدن همان بسته توسط زنجیره‌ای دیگر روی هوک یا اولویت متفاوت نمی‌شود.
ردیابی اتصال دومین نشانه را می‌سازد و از بیرون کاملاً یکسان به نظر می‌رسد. وقتی جریانی در جدول وضعیت است، یک پذیرش برای established-or-related نزدیک بالای زنجیره پیش از آنکه قاعده جدید شما بررسی شود بازمی‌گردد. نگاشت‌های NAT همین ویژگی را دارند: ترجمه هنگام آغاز جریان تثبیت شد، پس قاعده ویرایش‌شده در postrouting نشستی را که در حال اجراست بازنویسی نمی‌کند. به همین دلیل است که یک تغییر در ساعت 09:00 برای اتصال تازه کار می‌کند و برای نشستی که کسی در ساعت 08:55 باز کرده هیچ کاری نمی‌کند.
گروه‌های امنیتی ابری مدل سومی اضافه می‌کنند که کسانی را که با iptables یاد گرفته‌اند گرفتار می‌کند. قواعد ورودی آن‌ها فهرست مجاز است که به‌صورت مجموعه ارزیابی می‌شود نه پیمایش نخستین تطابق، حالت‌دار هستند و حذف یک قاعده مجاز جریان‌هایی را که در حال ردیابی‌اند پایان نمی‌دهد. فرض کردن معنای نخستین تطابق روی سکویی که آن را ندارد به نتیجه‌گیری‌های مطمئن و نادرست می‌انجامد.
مجموعه قواعد فعال را بخوانید، نه فایلی را که ویرایش کردید
با آنچه هسته همین حالا اعمال می‌کند شروع کنید. پیکربندی ذخیره‌شده‌ای که هرگز اعمال نشده، شمار شگفت‌انگیزی از رفتارهای بدون تغییر را توضیح می‌دهد و رد کردنش تنها یک فرمان هزینه دارد:
nft list ruleset
iptables-saveسپس بپرسید آیا قاعده شما اصلاً به اجرا می‌رسد. شمارنده‌های بسته مستقیماً پاسخ می‌دهند و بهتر از هر استدلالی درباره نیت پاسخ می‌دهند:
iptables -L FORWARD -v -n --line-numbers
nft list chain inet filter forwardقاعده قفل‌کننده با صفر بسته پس از یک تلاش آزمون واقعی مسئله سیاست نیست، مسئله موقعیت است. جابه‌جایی آن تغییری یک‌خطی است و نحو دقیقاً همان چیزی است که باگ اصلی را ایجاد کرد. با iptables -I درج می‌کند و -A در پایان می‌افزاید؛ با nftables insert قاعده را در ابتدای زنجیره قرار می‌دهد و add در پایان می‌افزاید. وقتی قاعده‌ای باید برنده شود، آن را صریح بگویید به‌جای اعتماد به ترتیبی که تصادفاً بارگذاری شده است.
اثبات کنید که جریان ردیابی می‌شود یا نه
پیش از سرزنش قاعده، بررسی کنید که ترافیک اصلاً اتصال ردیابی‌شده است. از جدول وضعیت جریان مشخص را بپرسید به‌جای آنکه همه‌اش را خالی کنید:
conntrack -L -p tcp --dport 1194
conntrack -E -p tcp --dport 1194فهرست وضعیت و مهلت باقی‌مانده را نشان می‌دهد و با همین نشانه نشست برقرارشده را از تلاش تازه تشخیص می‌دهید؛ حالت رویداد به‌روزرسانی‌ها را همان‌طور که رخ می‌دهند چاپ می‌کند که هنگام اتصال دوباره یک کلاینت مفید است. اگر جریان پیش از آنکه چیزی را لمس کنید با وضعیت برقرارشده حاضر باشد، هیچ ویرایشی در قواعد فیلتر سرنوشتش را تغییر نمی‌دهد. این باگ فایروال نیست، این قرارداد فیلتر حالت‌دار است.
در برابر میان‌بر خالی‌کردن کل جدول روی یک دروازه تولیدی مقاومت کنید. conntrack -F در دسترس است و هر جریان ردیابی‌شده روی ماشین را هم نابود می‌کند، از جمله نشست مدیریتی که از آن کار می‌کنید و تونلی که پوسته شما را حمل می‌کند. ورودی‌های تک‌تک را وقتی واقعاً لازم دارید می‌توان حذف کرد، اما جریان تازه از یک پورت مبدأ تازه معمولاً آزمایش پاک‌تری است.
برخی مسیرها ردیابی نمی‌شوند و برعکس رفتار می‌کنند. ترافیکی که در جدول raw با notrack علامت خورده است، برخی تونل‌ها که هوک‌های معمول را دور می‌زنند و مسیریابی نامتقارن که جریانی را بین دو دروازه تقسیم می‌کند، همه بسته‌هایی می‌سازند که یک‌به‌یک ارزیابی می‌شوند، یا وضعیتی که هرگز در دو سر ایجاد نمی‌شود. اگر شمارنده‌ها برای هر بسته حرکت می‌کنند، پیش از ترتیب به چنین مسیری مشکوک شوید.
از جریان تازه با راه بازگشت آزمون کنید
پیش از آزمودن قاعده‌ای که می‌تواند دسترسی راه دور را قطع کند، یک مسیر بازیابی ایجاد کنید: کنسول ارائه‌دهنده، کنسول سریال، نشانی مدیریت خارج از باند، یا رابط دومی که قاعده نتواند با آن تطبیق یابد. تایمر بازگشت همراه معقولی است، چون مجموعه قواعد پیشین را حتی اگر نشست شما در میانه آزمون بمیرد بازمی‌گرداند.
سپس با تبادلی آزمون کنید که وضعیت نمی‌توانسته قبلاً پوشش داده باشد. کلاینت را قطع و دوباره وصل کنید تا پنج‌تایی تازه‌ای ساخته شود و هنگام وقوع این کار هر دو سر را ببینید:
tcpdump -ni eth0 'tcp port 1194'
journalctl -k -n 50 --no-pagerآزمون را در هر دو جهت اجرا کنید. قاعده‌ای که دست‌دادن ورودی تازه را مسدود می‌کند هنوز می‌تواند مسیر پاسخ را مجاز کند، یا برعکس، و نتیجه یک‌طرفه دلیل معمول نیمه‌کاره کار کردن یک قفل است. پس از آزمون یک بار دیگر وصل شوید تا وضعیت پایدار را تأیید کنید و بررسی کنید که دسترسی مدیریتی مشروع زنده مانده است؛ قاعده‌ای که برای یک پورت نوشته شده عادت دارد با گستره‌ای وسیع‌تر از آنچه قصد شده تطبیق یابد.
هدف و موقعیت را همراه با قاعده ثبت کنید
قاعده‌ای که هدف ثبت‌شده ندارد قاعده‌ای است که هیچ‌کس جرئت حذفش را ندارد. در کنار هر مدخل قفل، جریانی که محافظت می‌کند، زنجیره و هوکی که در آن زندگی می‌کند، موقعیتی که باید نسبت به پذیرش‌های گسترده‌تر حفظ کند و آزمونی که آن را اثبات کرد را نگه دارید. وقتی کسی شش ماه بعد مجموعه قواعد پیرامون را ویرایش می‌کند، آن یادداشت تنها هشدار است که موقعیت عمدی بوده است.
پیش از بستن تغییر، چهار چیز را تأیید کنید: مجموعه قواعد در حال اجرا با فایل می‌خواند، قاعده جدید پس از یک تلاش تازه شمارنده‌های غیرصفر دارد، جهت معکوس و دسترسی مدیریتی هنوز کار می‌کنند، و یک بار دوباره وصل شده‌اید تا وضعیت پایدار را اثبات کنید نه وضعیت نشستی که از تغییر قدیمی‌تر است. اگر هر یک از این‌ها تأیید نشده باشد، تغییر تمام نشده است، هر چه تونل بکند.