Virtuel pfSense TAP-bro: tre steder, hvor en ramme kan dø

Du deaktiverer en regel på LAN-interfacet, rammen forsvinder stadig, og konklusionen er, at pfSense ignorerer sin egen firewall. Det, der som regel er sket, er, at en anden ejer traf beslutningen: broen selv, medlemsinterfacet eller den virtuelle switch uden for gæsten. Hver har sin egen kontrol og sin egen log.

De tre grænser nedenfor er værd at skelne, før du ændrer en indstilling, fordi deaktivering af den ene ikke kan kompensere for den anden.

Én ramme, tre politikejere

En ramme fra en TAP-klient kommer ind gennem tunnelanordningen, krydser pfSense-broen, forlader gennem et LAN-medlem og passerer derefter en virtuel switch, før den når noget som helst. Inde i gæsten kan filtrering ske på broen eller på medlemsinterfaces, og hvilken der er aktiv, er et konfigurationsvalg og ikke en fast egenskab. Uden for gæsten afgør hypervisoren, om den virtuelle adapter må sende rammer med en kilde-MAC, den ikke ejer. Et drop på et af disse punkter ser identisk ud fra klienten.

Skriv den tilsigtede vej ned, før du undersøger: tunnelmedlem, bro, LAN-medlem, virtuel switch, destination. Spørg derefter, hvilken ejer på den vej der ville have set rammen.

Hvilken pfSense-kontrol filtrerer

pfSense dokumenterer to sysctl'er til dette, en til filtrering på bromedlemmerne og en til filtrering på broen selv, og mindst en af dem skal forblive aktiveret. Filtrering på broniveau gælder trafik, der ankommer gennem bromedlemmerne, så det er indgående i orientering og ikke symmetrisk. Læs reglerne på det interface, der faktisk filtrerer, fordi en regel på et medlem uden filtreringsrolle overhovedet intet gør. Dokumentationen for brofiltrering redegør for ejerskabet.

Et medlemsinterface uden en IP-adresse har ingen adresse- eller subnetsmakro af sin egen, så en regel skrevet mod den makro kan beskrive noget andet end det LAN, du mente. Brug bevidst tildelte netværksobjekter i stedet for bekvemmelighedsmakroer.

Et fragment er ikke en ramme

Ethernet-rammer bærer IP-pakker, og en IP-pakke kan være et fragment af en større datagram, så de to ord kan ikke bruges i flæng. Der er også en indre pakke inde i tunnelen og en ydre transportpakke uden for den, og en fejl kan høre til begge. En lille ping prøver én vej gennem den stak og beviser intet om en stor overførsel. Sammenlign den fejlende udveksling ved to tilstødende grænser og læs dropårsagen, før du bebrejder en regel.

Hvis fragmenter forsvinder, er svaret en afgrænset rettelse eller en undersøgelse af pakkestørrelse, ikke en beslutning om at deaktivere filtrering helt.

Hypervisoren har sin egen adgangsbeslutning

En gæst, der broer trafik for andre maskiner, udsender rammer, hvis kilde-MAC-adresser ikke er dens egen adapters, og mange virtuelle switche betragter det som spoofing, medmindre portgruppen tillader det. At tillade den transmission og at tillade adapteren at modtage hver ramme er separate kontroller, og at aktivere begge overalt er en meget større ændring, end problemet kræver. Find ud af, hvilke rammer broen skal modtage og skal udsende, og giv derefter kun den adfærd på den grænse, der ejer den. Behold konsoladgang, før du ændrer en fjernstyret bro.

At genoprette forbindelsen er halvdelen af testen; den anden halvdel er at bekræfte, at en strøm, der skal forblive blokeret, stadig er det.

Notér, hvilken ejer der filtrerede, hvilken kontrol der blev ændret, og hvilke to strømme du verificerede. Den note forhindrer den næste hændelse i at begynde med den samme antagelse om, at pfSense ignorerer sig selv.