Віртуальний міст TAP у pfSense: три місця, де кадр може загинути

Ви вимикаєте правило на інтерфейсі LAN, кадр усе одно зникає, і висновок такий: pfSense ігнорує власний міжмережевий екран. Зазвичай рішення ухвалив інший власник: сам міст, інтерфейс-учасник або віртуальний комутатор поза гостем. Кожен має своє керування та свій журнал.

Три межі нижче варто розділити до зміни налаштування, бо вимкнення однієї не компенсує іншу.

Один кадр, три власники політики

Кадр від клієнта TAP входить через тунельний пристрій, перетинає міст pfSense, виходить через учасник LAN і потім проходить віртуальний комутатор, перш ніж досягти чогось. Усередині гостя фільтрація може відбуватися на мості або на інтерфейсах-учасниках, і те, який із них активний, — це вибір конфігурації, а не фіксована властивість. Поза гостем гіпервізор вирішує, чи може цей віртуальний адаптер передавати кадри з вихідним MAC, який йому не належить. Скидання в будь-якій із цих точок виглядає однаково з боку клієнта.

Запишіть передбачуваний шлях до розслідування: учасник тунелю, міст, учасник LAN, віртуальний комутатор, призначення. Потім запитайте, який власник на цьому шляху побачив би кадр.

Яке керування pfSense фільтрує

pfSense документує для цього два sysctl: один для фільтрації на учасниках моста і один для фільтрації на самому мості, і принаймні один із них має залишатися ввімкненим. Фільтрація на рівні моста застосовується до трафіку, що надходить через учасників моста, тому за напрямком вона вхідна, а не симетрична. Читайте правила на тому інтерфейсі, який справді фільтрує, бо правило, задане на учаснику без ролі фільтрації, не робить нічого. Документація з фільтрації моста пояснює належність.

У інтерфейсу-учасника без IP-адреси немає власного макросу адреси чи підмережі, тому правило, написане проти цього макросу, може описувати щось інше, ніж задумана LAN. Використовуйте навмисно призначені мережеві об'єкти замість макросів для зручності.

Фрагмент — не кадр

Кадри Ethernet переносять пакети IP, а пакет IP може бути фрагментом більшої дейтаграми, тому ці два слова не взаємозамінні. Усередині тунелю є також внутрішній пакет, а ззовні — зовнішній транспортний пакет, і збій може належати будь-якому з них. Малий ping перевіряє один шлях через цей стек і нічого не доводить про велике передавання. Порівняйте невдалий обмін на двох сусідніх межах і прочитайте причину скидання, перш ніж звинувачувати правило.

Якщо фрагменти зникають, відповідь — обмежене виправлення або дослідження розміру пакета, а не рішення повністю вимкнути фільтрацію.

У гіпервізора є власне рішення про допуск

Гість, який мостить трафік для інших машин, передає кадри, вихідні MAC-адреси яких не належать його власному адаптеру, і багато віртуальних комутаторів вважають це підміною, якщо група портів цього не дозволяє. Дозволити таке передавання й дозволити адаптеру приймати кожен кадр — це окремі керування, і вмикати обидва всюди — значно більша зміна, ніж вимагає проблема. Визначте, які кадри міст має приймати і має передавати, а потім надайте лише цю поведінку на тій межі, якій вона належить. Збережіть доступ до консолі перед зміною моста, яким керують віддалено.

Відновлення зв'язності — це половина тесту; друга половина — підтвердити, що потік, який має лишатися заблокованим, досі заблокований.

Запишіть, який власник фільтрував, яке керування змінилося і які два потоки ви перевірили. Цей запис не дає наступному інциденту початися з того самого припущення, що pfSense ігнорує сам себе.