Virtuell pfSense TAP-bro: tre steder der en ramme kan dø

Du deaktiverer en regel på LAN-grensesnittet, rammen forsvinner fortsatt, og konklusjonen er at pfSense ignorerer sin egen brannmur. Det som vanligvis har skjedd, er at en annen eier tok avgjørelsen: broen selv, medlemsgrensesnittet eller den virtuelle svitsjen utenfor gjesten. Hver har sin egen kontroll og sin egen logg.

De tre grensene nedenfor er verdt å skille før du endrer en innstilling, fordi å deaktivere den ene ikke kan kompensere for den andre.

Én ramme, tre policyeiere

En ramme fra en TAP-klient kommer inn gjennom tunnelenheten, krysser pfSense-broen, går ut gjennom et LAN-medlem og passerer deretter en virtuell svitsj før den når noe som helst. Inne i gjesten kan filtrering skje på broen eller på medlemsgrensesnittene, og hvilken som er aktiv er et konfigurasjonsvalg og ikke en fast egenskap. Utenfor gjesten avgjør hypervisoren om den virtuelle adapteren kan sende rammer med en kilde-MAC den ikke eier. En dropp på et av disse punktene ser identisk ut fra klienten.

Skriv ned den tiltenkte banen før du undersøker: tunnelmedlem, bro, LAN-medlem, virtuell svitsj, mål. Spør deretter hvilken eier på den banen som ville ha sett rammen.

Hvilken pfSense-kontroll som filtrerer

pfSense dokumenterer to sysctl for dette, én for filtrering på bromedlemmene og én for filtrering på broen selv, og minst én av dem må forbli aktivert. Filtrering på bronivå gjelder trafikk som kommer inn gjennom bromedlemmene, så den er inngående i orientering og ikke symmetrisk. Les reglene på grensesnittet som faktisk filtrerer, fordi en regel satt på et medlem uten filtreringsrolle ikke gjør noe som helst. Dokumentasjonen for brofiltrering forklarer eierskapet.

Et medlemsgrensesnitt uten IP-adresse har ingen egen adresse- eller subnettmakro, så en regel skrevet mot den makroen kan beskrive noe annet enn LAN-et du mente. Bruk bevisst tildelte nettverksobjekter i stedet for bekvemmelighetsmakroer.

Et fragment er ikke en ramme

Ethernet-rammer bærer IP-pakker, og en IP-pakke kan være et fragment av et større datagram, så de to ordene er ikke utbyttbare. Det finnes også en indre pakke inne i tunnelen og en ytre transportpakke utenfor den, og en feil kan tilhøre begge. En liten ping prøver én bane gjennom den stakken og beviser ingenting om en stor overføring. Sammenlign utvekslingen som feiler ved to tilstøtende grenser og les droppårsaken før du gir en regel skylden.

Hvis fragmenter forsvinner, er svaret en avgrenset korreksjon eller en undersøkelse av pakkestørrelse, ikke en beslutning om å deaktivere filtrering helt.

Hypervisoren har sin egen adgangsbeslutning

En gjest som broer trafikk for andre maskiner, sender ut rammer der kilde-MAC-adressene ikke er dens egen adapters, og mange virtuelle svitsjer behandler det som spoofing med mindre portgruppen tillater det. Å tillate den overføringen og å tillate adapteren å motta hver ramme er separate kontroller, og å aktivere begge overalt er en mye større endring enn problemet krever. Finn ut hvilke rammer broen må motta og må sende ut, og gi deretter bare den atferden på grensen som eier den. Behold konsolltilgang før du endrer en eksternt administrert bro.

Å gjenopprette tilkoblingen er halve testen; den andre halvparten er å bekrefte at en strøm som skal forbli blokkert, fortsatt er det.

Noter hvilken eier som filtrerte, hvilken kontroll som ble endret og hvilke to strømmer du verifiserte. Den noten hindrer neste hendelse i å begynne med den samme antakelsen om at pfSense ignorerer seg selv.