Виртуальный мост TAP в pfSense: три места, где кадр может погибнуть

Вы отключаете правило на интерфейсе LAN, кадр всё равно исчезает, и вывод такой: pfSense игнорирует собственный межсетевой экран. Обычно решение принял другой владелец: сам мост, интерфейс-участник или виртуальный коммутатор вне гостя. У каждого своё управление и свой журнал.

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

Один кадр, три владельца политики

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

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

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

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

У интерфейса-участника без IP-адреса нет собственного макроса адреса или подсети, поэтому правило, написанное против этого макроса, может описывать нечто иное, чем задуманная LAN. Используйте намеренно назначенные сетевые объекты вместо макросов для удобства.

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

Кадры Ethernet переносят пакеты IP, а пакет IP может быть фрагментом большей дейтаграммы, поэтому эти два слова не взаимозаменяемы. Внутри туннеля есть также внутренний пакет, а снаружи — внешний транспортный пакет, и сбой может относиться к любому из них. Небольшой ping проверяет один путь через этот стек и ничего не доказывает о большой передаче. Сравните неудачный обмен на двух соседних границах и прочитайте причину сброса, прежде чем винить правило.

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

У гипервизора есть собственное решение о допуске

Гость, который мостит трафик для других машин, передаёт кадры, исходные MAC-адреса которых не принадлежат его собственному адаптеру, и многие виртуальные коммутаторы считают это подменой, если группа портов этого не разрешает. Разрешить такую передачу и разрешить адаптеру принимать каждый кадр — это отдельные управления, и включать оба везде — гораздо большее изменение, чем требует проблема. Определите, какие кадры мост должен принимать и должен передавать, а затем предоставьте только это поведение на той границе, которой оно принадлежит. Сохраните доступ к консоли перед изменением моста, управляемого удалённо.

Восстановление связности — это половина теста; вторая половина — подтвердить, что поток, который должен оставаться заблокированным, всё ещё заблокирован.

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