Virtuální most TAP v pfSense: tři místa, kde může rámec zemřít

Vypnete pravidlo na rozhraní LAN, rámec přesto zmizí, a závěr je, že pfSense ignoruje svůj vlastní firewall. Obvykle se stalo to, že rozhodl jiný vlastník: samotný most, členské rozhraní nebo virtuální přepínač mimo hosta. Každý má své ovládání a svůj záznam.

Tři hranice níže stojí za to oddělit, než změníte nastavení, protože vypnutí jedné nemůže nahradit druhou.

Jeden rámec, tři vlastníci politiky

Rámec od klienta TAP vstupuje přes tunelové zařízení, prochází mostem pfSense, vychází přes člena LAN a poté projde virtuálním přepínačem, než se někam dostane. Uvnitř hosta může filtrování probíhat na mostě nebo na členských rozhraních a to, které je aktivní, je volba konfigurace, nikoli pevná vlastnost. Mimo hosta rozhoduje hypervizor, zda tento virtuální adaptér smí vysílat rámce se zdrojovou MAC, kterou nevlastní. Zahození v kterémkoli z těchto bodů vypadá z pohledu klienta stejně.

Před vyšetřováním si zapište zamýšlenou cestu: tunelový člen, most, člen LAN, virtuální přepínač, cíl. Potom se ptejte, který vlastník na této cestě by rámec viděl.

Které ovládání pfSense filtruje

pfSense dokumentuje dva sysctly, jeden pro filtrování na členech mostu a jeden pro filtrování na samotném mostě, a alespoň jeden z nich musí zůstat zapnutý. Filtrování na úrovni mostu se týká provozu přicházejícího přes členy mostu, takže je orientací vstupní, nikoli symetrické. Čtěte pravidla na rozhraní, které skutečně filtruje, protože pravidlo nastavené na členu bez role filtrování nedělá vůbec nic. Dokumentace filtrování mostu vysvětluje vlastnictví.

Členské rozhraní bez IP adresy nemá vlastní makro adresy ani podsítě, takže pravidlo napsané proti tomuto makru může popisovat něco jiného než zamýšlenou LAN. Používejte záměrně přiřazené síťové objekty místo pohodlných maker.

Fragment není rámec

Rámce Ethernet přenášejí IP pakety a IP paket může být fragmentem většího datagramu, takže ta dvě slova nejsou zaměnitelná. Uvnitř tunelu je také vnitřní paket a vně něj vnější transportní paket a selhání může patřit kterémukoli z nich. Malý ping procvičí jednu cestu přes tento zásobník a nic nedokazuje o velkém přenosu. Porovnejte neúspěšnou výměnu na dvou sousedních hranicích a přečtěte si důvod zahození, než obviníte pravidlo.

Pokud fragmenty mizí, odpovědí je omezená oprava nebo vyšetřování velikosti paketů, ne rozhodnutí filtrování úplně vypnout.

Hypervizor má své vlastní rozhodnutí o přijetí

Host, který mostuje provoz pro jiné stroje, vysílá rámce, jejichž zdrojové MAC adresy nejsou jeho vlastního adaptéru, a mnoho virtuálních přepínačů to považuje za podvrh, pokud to skupina portů nedovolí. Povolit tento přenos a povolit adaptéru přijímat každý rámec jsou oddělená ovládání a zapnutí obou všude je mnohem větší změna, než problém vyžaduje. Určete, které rámce musí most přijímat a musí vysílat, a pak udělte jen toto chování na hranici, která je vlastní. Před změnou vzdáleně spravovaného mostu si ponechte přístup ke konzoli.

Obnovení konektivity je polovina testu; druhá polovina je potvrdit, že tok, který má zůstat blokovaný, stále blokovaný je.

Zaznamenejte, který vlastník filtroval, které ovládání se změnilo a které dva toky jste ověřili. Tento záznam zabrání tomu, aby příští incident začal stejnou domněnkou, že pfSense ignoruje sám sebe.