Виртуален TAP мост в pfSense: три места, където кадърът може да загине

Изключвате правило на интерфейса LAN, кадърът все още изчезва, и заключението е, че pfSense пренебрегва собствения си филтър. Обикновено се е случило друго: решение е взел различен собственик — самият мост, интерфейсът-член или виртуалният комутатор извън госта. Всеки има свое управление и свой журнал.

Трите граници по-долу си струва да се разделят, преди да промените настройка, защото изключването на една не компенсира друга.

Един кадър, три собственика на политика

Кадър от TAP клиент влиза през тунелното устройство, преминава моста на pfSense, излиза през член на LAN и след това преминава виртуален комутатор, преди да стигне до нещо. Вътре в госта филтрирането може да се случва на моста или на интерфейсите-членове и кой от тях е активен е избор на конфигурация, а не фиксирано свойство. Извън госта хипервизорът решава дали този виртуален адаптер може да предава кадри с MAC източник, който не притежава. Отпадане в която и да е от тези точки изглежда еднакво от страна на клиента.

Запишете предвидения път, преди да разследвате: член на тунела, мост, член на LAN, виртуален комутатор, местоназначение. След това попитайте кой собственик на този път би видял кадъра.

Кое управление на pfSense филтрира

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

Интерфейс-член без IP адрес няма собствен макрос за адрес или подмрежа, така че правило, написано срещу този макрос, може да описва нещо различно от LAN, която имате предвид. Използвайте умишлено зададени мрежови обекти вместо макроси за удобство.

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

Ethernet кадрите пренасят IP пакети, а IP пакетът може да е фрагмент от по-голяма дейтаграма, така че двете думи не са взаимозаменяеми. Има също вътрешен пакет в тунела и външен транспортен пакет извън него, и отказ може да принадлежи на всеки от тях. Малък ping изпитва един път през този стек и не доказва нищо за голям трансфер. Сравнете неуспешния обмен на две съседни граници и прочетете причината за отпадането, преди да обвините правило.

Ако фрагментите изчезват, отговорът е ограничена корекция или разследване на размера на пакета, а не решение да изключите филтрирането изцяло.

Хипервизорът има свое решение за допускане

Гост, който мостово предава трафик за други машини, излъчва кадри, чиито MAC адреси на източника не са на собствения му адаптер, и много виртуални комутатори приемат това за подправяне, освен ако групата портове го позволява. Разрешаването на това предаване и разрешаването на адаптера да приема всеки кадър са отделни управления и включването на двете навсякъде е много по-голяма промяна, отколкото проблемът изисква. Определете кои кадри мостът трябва да приема и трябва да предава, след което дайте само това поведение на границата, която го притежава. Запазете достъп до конзолата, преди да промените отдалечено управляван мост.

Възстановяването на свързаността е половината от теста; другата половина е да потвърдите, че поток, който трябва да остане блокиран, все още е блокиран.

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