پل TAP مجازی pfSense: سه جایی که یک قاب می‌تواند بمیرد
پل، اعضای آن و سوئیچ مجازی هر یک جداگانه تصمیم می‌گیرند. پیش از غیرفعال کردن کنترلی که هرگز در مسیر نبوده است، پیدا کنید کدام مالک فیلتر کرده است.
شما قاعده‌ای را روی رابط LAN غیرفعال می‌کنید، قاب همچنان ناپدید می‌شود و نتیجه‌گیری این است که pfSense دیوار آتش خودش را نادیده می‌گیرد. آنچه معمولاً رخ داده این است که مالک دیگری تصمیم را گرفته است: خود پل، رابط عضو، یا سوئیچ مجازی بیرون از مهمان. هر کدام کنترل و گزارش خودش را دارد.
سه مرزی که در ادامه می‌آید ارزش جدا کردن دارند پیش از آنکه تنظیمی را تغییر دهید، زیرا غیرفعال کردن یکی نمی‌تواند دیگری را جبران کند.
یک قاب، سه مالک سیاست
قابی از یک کلاینت TAP از دستگاه تونل وارد می‌شود، از پل pfSense می‌گذرد، از یک عضو LAN خارج می‌شود و سپس پیش از رسیدن به هر چیزی از یک سوئیچ مجازی عبور می‌کند. درون مهمان، فیلتر کردن می‌تواند روی پل یا روی رابط‌های عضو رخ دهد و اینکه کدام فعال است انتخابی از پیکربندی است نه ویژگی ثابت. بیرون از مهمان، هایپروایزر تصمیم می‌گیرد که آیا آن آداپتور مجازی می‌تواند قاب‌هایی با MAC مبدأ که مالکش نیست بفرستد. حذف در هر یک از آن نقاط از دید کلاینت یکسان به نظر می‌رسد.
پیش از بررسی، مسیر مورد نظر را بنویسید: عضو تونل، پل، عضو LAN، سوئیچ مجازی، مقصد. سپس بپرسید کدام مالک روی آن مسیر قاب را می‌دید.
کدام کنترل pfSense در حال فیلتر کردن است
pfSense برای این کار دو sysctl مستند می‌کند، یکی برای فیلتر کردن روی اعضای پل و یکی برای فیلتر کردن روی خود پل، و دست‌کم یکی از آنها باید فعال بماند. فیلتر کردن در سطح پل بر ترافیکی اعمال می‌شود که از اعضای پل می‌رسد، پس از نظر جهت ورودی است و متقارن نیست. قاعده‌ها را روی رابطی بخوانید که واقعاً فیلتر می‌کند، زیرا قاعده‌ای که روی عضوی بدون نقش فیلتر نوشته شده باشد هیچ کاری نمی‌کند. مستندات فیلتر کردن پل مالکیت را روشن می‌کند.
رابط عضوی که نشانی IP ندارد ماکروی نشانی یا زیرشبکه خودش را ندارد، پس قاعده‌ای که بر ضد آن ماکرو نوشته شود می‌تواند چیزی جز LAN مورد نظر شما را توصیف کند. به جای ماکروهای راحتی از اشیای شبکه‌ای که آگاهانه تخصیص داده شده‌اند استفاده کنید.
یک قطعه قاب نیست
قاب‌های اترنت بسته‌های IP را حمل می‌کنند و یک بسته IP می‌تواند قطعه‌ای از یک دیتاگرام بزرگ‌تر باشد، پس این دو واژه قابل جابه‌جایی نیستند. همچنین بسته‌ای درونی درون تونل و بسته‌ای بیرونی حمل‌ونقل بیرون آن وجود دارد و شکست می‌تواند به هر یک تعلق داشته باشد. یک ping کوچک یک مسیر را در آن پشته می‌آزماید و درباره انتقال بزرگ چیزی ثابت نمی‌کند. تبادل ناموفق را در دو مرز مجاور مقایسه کنید و پیش از سرزنش یک قاعده دلیل حذف را بخوانید.
اگر قطعه‌ها ناپدید می‌شوند، پاسخ یک اصلاح محدود یا بررسی اندازه بسته است، نه تصمیم به غیرفعال کردن کامل فیلتر کردن.
هایپروایزر تصمیم پذیرش خودش را دارد
مهمانی که ترافیک ماشین‌های دیگر را پل می‌کند قاب‌هایی می‌فرستد که نشانی‌های MAC مبدأشان مال آداپتور خودش نیست، و بسیاری از سوئیچ‌های مجازی آن را جعل می‌دانند مگر اینکه گروه پورت اجازه دهد. اجازه دادن به آن ارسال و اجازه دادن به آداپتور برای دریافت هر قاب دو کنترل جداگانه‌اند و فعال کردن هر دو در همه جا تغییری بسیار بزرگ‌تر از نیاز مسئله است. مشخص کنید پل کدام قاب‌ها را باید دریافت و کدام را باید ارسال کند، سپس تنها همان رفتار را در مرزی که مالک آن است اعطا کنید. پیش از تغییر پلی که از راه دور مدیریت می‌شود دسترسی کنسول را نگه دارید.
بازگرداندن اتصال نیمی از آزمون است؛ نیم دیگر تأیید این است که جریانی که باید مسدود بماند هنوز مسدود است.
ثبت کنید کدام مالک فیلتر کرد، کدام کنترل تغییر کرد و کدام دو جریان را بررسی کردید. این ثبت مانع می‌شود که رخداد بعدی با همان گمانه‌زنی درباره نادیده گرفتن خود توسط pfSense آغاز شود.