Virtuell pfSense TAP-brygga: tre ställen där en ram kan dö
Bryggan, dess medlemmar och den virtuella växeln beslutar var för sig. Ta reda på vilken ägare som filtrerade innan du stänger av en kontroll som aldrig låg i vägen.
Du inaktiverar en regel på LAN-gränssnittet, ramen försvinner fortfarande, och slutsatsen är att pfSense ignorerar sin egen brandvägg. Det som vanligtvis har hänt är att en annan ägare fattade beslutet: bryggan själv, medlemsgänssnittet eller den virtuella växeln utanför gästen. Var och en har sin egen kontroll och sin egen logg.
De tre gränserna nedan är värda att skilja på innan du ändrar en inställning, eftersom att stänga av den ena inte kan kompensera för den andra.
En ram, tre principägare
En ram från en TAP-klient kommer in genom tunnelenheten, korsar pfSense-bryggan, lämnar genom en LAN-medlem och passerar sedan en virtuell växel innan den når något. Inuti gästen kan filtrering ske på bryggan eller på medlemsgänssnitten, och vilken som är aktiv är ett konfigurationsval och inte en fast egenskap. Utanför gästen avgör hypervisorn om den virtuella adaptern får skicka ramar med en käll-MAC som den inte äger. Ett dropp vid någon av dessa punkter ser identiskt ut från klienten.
Skriv ner den avsedda vägen innan du undersöker: tunnelmedlem, brygga, LAN-medlem, virtuell växel, destination. Fråga sedan vilken ägare på den vägen som skulle ha sett ramen.
Vilken pfSense-kontroll som filtrerar
pfSense dokumenterar två sysctl för detta, en för filtrering på bryggmedlemmarna och en för filtrering på bryggan själv, och minst en av dem måste förbli aktiverad. Filtrering på bryggnivå gäller trafik som kommer in via bryggmedlemmarna, så den är inkommande till orienteringen och inte symmetrisk. Läs reglerna på det gränssnitt som faktiskt filtrerar, eftersom en regel på en medlem utan filtreringsroll inte gör någonting alls. Dokumentationen för bryggfiltrering förklarar ägarskapet.
Ett medlemsgänssnitt utan IP-adress har ingen egen adress- eller subnätmakro, så en regel skriven mot det makrot kan beskriva något annat än det avsedda LAN-et. Använd medvetet tilldelade nätverksobjekt i stället för bekvämlighetsmakron.
Ett fragment är inte en ram
Ethernet-ramar bär IP-paket, och ett IP-paket kan vara ett fragment av ett större datagram, så de två orden är inte utbytbara. Det finns också ett inre paket inne i tunneln och ett yttre transportpaket utanför den, och ett fel kan tillhöra båda. En liten ping prövar en väg genom den stacken och bevisar ingenting om en stor överföring. Jämför det misslyckade utbytet vid två angränsande gränser och läs dropporsaken innan du skyller på en regel.
Om fragment försvinner är svaret en avgränsad korrigering eller en undersökning av paketstorleken, inte ett beslut att stänga av filtreringen helt.
Hypervisorn har sitt eget tillträdesbeslut
En gäst som bryggar trafik för andra maskiner sänder ut ramar vars käll-MAC-adresser inte är den egna adapterns, och många virtuella växlar behandlar det som spoofing om inte portgruppen tillåter det. Att tillåta den överföringen och att tillåta adaptern att ta emot varje ram är separata kontroller, och att aktivera båda överallt är en mycket större ändring än problemet kräver. Ta reda på vilka ramar bryggan måste ta emot och måste sända ut, och bevilja sedan bara det beteendet vid den gräns som äger det. Behåll konsolåtkomst innan du ändrar en fjärradministrerad brygga.
Att återställa anslutningen är halva testet; den andra halvan är att bekräfta att ett flöde som ska förbli blockerat fortfarande är det.
Anteckna vilken ägare som filtrerade, vilken kontroll som ändrades och vilka två flöden du verifierade. Den anteckningen hindrar nästa incident från att börja med samma antagande att pfSense ignorerar sig själv.