Virtuele pfSense TAP-brug: drie plekken waar een frame kan sterven

Je schakelt een regel op de LAN-interface uit, het frame verdwijnt nog steeds, en de conclusie is dat pfSense zijn eigen firewall negeert. Wat meestal is gebeurd, is dat een andere eigenaar de beslissing nam: de brug zelf, de lid-interface of de virtuele switch buiten de gast. Elk heeft zijn eigen besturing en zijn eigen logboek.

De drie grenzen hieronder zijn het waard om te scheiden voordat je een instelling wijzigt, want het uitschakelen van de ene kan de andere niet compenseren.

Eén frame, drie beleidseigenaren

Een frame van een TAP-client komt binnen via het tunnelapparaat, steekt de pfSense-brug over, verlaat het via een LAN-lid en passeert dan een virtuele switch voordat het iets bereikt. Binnen de gast kan filtering op de brug of op de lid-interfaces plaatsvinden, en welke actief is, is een configuratiekeuze en geen vaste eigenschap. Buiten de gast bepaalt de hypervisor of die virtuele adapter frames mag verzenden met een bron-MAC die niet van hem is. Een drop op een van die punten ziet er vanuit de client identiek uit.

Schrijf het bedoelde pad op voordat je onderzoek doet: tunnellid, brug, LAN-lid, virtuele switch, bestemming. Vraag dan welke eigenaar op dat pad het frame zou hebben gezien.

Welke pfSense-besturing filtert

pfSense documenteert hiervoor twee sysctls, één voor filtering op de brugleden en één voor filtering op de brug zelf, en ten minste één ervan moet ingeschakeld blijven. Filtering op brugniveau geldt voor verkeer dat via de brugleden binnenkomt, dus het is inkomend van oriëntatie en niet symmetrisch. Lees de regels op de interface die daadwerkelijk filtert, want een regel op een lid zonder filterrol doet helemaal niets. De documentatie over brugfiltering legt het eigenaarschap uit.

Een lid-interface zonder IP-adres heeft geen eigen adres- of subnetmacro, dus een regel die tegen die macro is geschreven kan iets anders beschrijven dan het bedoelde LAN. Gebruik bewust toegewezen netwerkobjecten in plaats van gemaksmacro's.

Een fragment is geen frame

Ethernet-frames dragen IP-pakketten, en een IP-pakket kan een fragment van een groter datagram zijn, dus de twee woorden zijn niet uitwisselbaar. Er is ook een binnenpakket in de tunnel en een buitenste transportpakket erbuiten, en een storing kan bij beide horen. Een kleine ping beproeft één pad door die stapel en bewijst niets over een grote overdracht. Vergelijk de mislukkende uitwisseling op twee aangrenzende grenzen en lees de dropreden voordat je een regel de schuld geeft.

Als fragmenten verdwijnen, is het antwoord een gerichte correctie of een onderzoek naar de pakketgrootte, niet een beslissing om filtering volledig uit te schakelen.

De hypervisor heeft zijn eigen toelatingsbeslissing

Een gast die verkeer voor andere machines overbrugt, zendt frames uit waarvan de bron-MAC-adressen niet van zijn eigen adapter zijn, en veel virtuele switches beschouwen dat als spoofing tenzij de poortgroep het toestaat. Die overdracht toestaan en de adapter toestaan elk frame te ontvangen zijn afzonderlijke besturingen, en beide overal inschakelen is een veel grotere wijziging dan het probleem vereist. Bepaal welke frames de brug moet ontvangen en moet uitzenden, en verleen dan alleen dat gedrag op de grens die het bezit. Behoud consoletoegang voordat je een op afstand beheerde brug wijzigt.

Connectiviteit herstellen is de helft van de test; de andere helft is bevestigen dat een stroom die geblokkeerd moet blijven dat nog is.

Noteer welke eigenaar filterde, welke besturing is gewijzigd en welke twee stromen je hebt geverifieerd. Dat verslag voorkomt dat het volgende incident begint met dezelfde veronderstelling dat pfSense zichzelf negeert.