قانون جدید UFW، اتصال قدیمی: وضعیت established برنده است

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

ترتیب تعیین می‌کند، نه وجود قاعده

UFW یک رابط است که قواعد netfilter را مرحله‌به‌مرحله می‌نویسد: بخش چارچوب که پیش از قواعد کاربر اجرا می‌شود، سپس خود قواعد کاربر، سپس بخشی که پس از آن‌ها اجرا می‌شود. قواعد پیش‌فرض پیشین ترافیک اتصال‌های established و related را می‌پذیرند و این قواعد پیش از هر چیزی که با allow یا deny معمولی اضافه کنید ارزیابی می‌شوند. مرجع دستورهای UFW نحو درج و نمای شماره‌دار وضعیت را که این تغییر به آن وابسته است مستند می‌کند.

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

برای این کار از قواعد route استفاده کنید، زیرا بسته از طریق دروازه فوروارد می‌شود نه اینکه به سرویس‌های خود دروازه نشانه‌روی کند. یک قاعدهٔ ورودی ترافیک اشتباه را فیلتر می‌کرد و به‌نظر می‌رسید هیچ کاری نمی‌کند.

بالای اجازهٔ گسترده درج کنید

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

sudo ufw --dry-run route insert 1 deny in on tun0 proto tcp from 10.88.0.55/32 to 192.0.2.88/32

اگر پیش‌نمایش دقیقاً یک قاعده را در جای مورد انتظار نشان داد، همان دستور را بدون پرچم dry-run اعمال کنید. جایگاه 1 آن را بالای مجوزهای گسترده‌تر کاربر قرار می‌دهد، نه بالای قواعد چارچوب که پیش‌تر بررسی شد. تأیید کنید نام رابط با دستگاه تونل روی این دروازه مطابقت دارد، زیرا قاعده‌ای که به رابطی محدود شده که دیگر وجود ندارد در فهرست می‌ماند و درست به نظر می‌رسد در حالی که با هیچ چیز مطابقت ندارد. ارجاع دستگاه را پیش از اعمال تغییر دهید، نه پس از شکست آزمون.

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

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

جریان‌های established از قاعدهٔ جدید جان سالم به در می‌برند

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

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

مرزها را هم به یاد داشته باشید. این قاعده دربارهٔ ICMP، UDP یا IPv6 چیزی نمی‌گوید، پس یک ping موفق شاهد شکست رد نیست. یک نشانی IPv4 هم وب‌سایت نیست: یک نام می‌تواند به چند نشانی تبدیل شود و تنها همان یکی که نام بردید پوشش داده می‌شود.

با یک جریان تازه بیازمایید

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

sudo ufw status numbered
sudo ufw show raw
# from 10.88.0.55, a new TCP connection to 192.0.2.88 should fail

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

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

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