Virtuell pfSense TAP-bru: tre stader der ei ramme kan døy

Du slår av ein regel på LAN-grensesnittet, ramma forsvinn framleis, og konklusjonen er at pfSense ignorerer sin eigen brannmur. Det som vanlegvis har skjedd, er at ein annan eigar tok avgjerda: brua sjølv, medlemsgrensesnittet eller den virtuelle svitsjen utanfor gjesten. Kvar har sin eigen kontroll og si eiga logg.

Dei tre grensene nedanfor er verde å skilje før du endrar ei innstilling, fordi å slå av den eine ikkje kan kompensere for den andre.

Éi ramme, tre policyeigarar

Ei ramme frå ein TAP-klient kjem inn gjennom tunneleininga, kryssar pfSense-brua, går ut gjennom eit LAN-medlem og passerer deretter ein virtuell svitsj før ho når noko som helst. Inne i gjesten kan filtrering skje på brua eller på medlemsgrensesnitta, og kva for ei som er aktiv er eit konfigurasjonsval og ikkje ein fast eigenskap. Utanfor gjesten avgjer hypervisoren om den virtuelle adapteren kan senda rammer med ein kjelde-MAC han ikkje eig. Eit dropp på eit av desse punkta ser identisk ut frå klienten.

Skriv ned den tiltenkte vegen før du undersøkjer: tunnelmedlem, bru, LAN-medlem, virtuell svitsj, mål. Spør deretter kva eigar på den vegen som ville ha sett ramma.

Kva pfSense-kontroll som filtrerer

pfSense dokumenterer to sysctl for dette, éin for filtrering på brumedlemmene og éin for filtrering på brua sjølv, og minst éin av dei må halde fram med å vere slått på. Filtrering på brunivå gjeld trafikk som kjem inn gjennom brumedlemmene, så ho er inngåande i orientering og ikkje symmetrisk. Les reglane på grensesnittet som faktisk filtrerer, fordi ein regel sett på eit medlem utan filtreringsrolle gjer ikkje noko som helst. Dokumentasjonen for brufiltrering forklarer eigarskapet.

Eit medlemsgrensesnitt utan IP-adresse har ingen eigen adresse- eller subnettmakro, så ein regel skriven mot den makroen kan skildre noko anna enn LAN-et du meinte. Bruk medvite tildelte nettverksobjekt i staden for komfortmakroar.

Eit fragment er ikkje ei ramme

Ethernet-rammer ber IP-pakkar, og ein IP-pakke kan vere eit fragment av eit større datagram, så dei to orda er ikkje utbyttbare. Det finst òg ein indre pakke inne i tunnelen og ein ytre transportpakke utanfor han, og ein feil kan høyre til begge. Ein liten ping prøver éin veg gjennom den stakken og beviser ingenting om ei stor overføring. Samanlikn utvekslinga som feilar ved to tilstøytande grenser og les droppårsaka før du gir ein regel skulda.

Viss fragment forsvinn, er svaret ein avgrensa korreksjon eller ei undersøking av pakkestorleik, ikkje ei avgjerd om å slå av filtrering heilt.

Hypervisoren har si eiga tilgangsavgjerd

Ein gjest som bruar trafikk for andre maskiner, sender ut rammer der kjelde-MAC-adressene ikkje er hans eigen adapters, og mange virtuelle svitsjar handsamar det som spoofing med mindre portgruppa tillèt det. Å tillate den overføringa og å tillate adapteren å ta imot kvar ramme er separate kontrollar, og å slå på begge overalt er ei mykje større endring enn problemet krev. Finn ut kva rammer brua må ta imot og må sende ut, og gi deretter berre den åtferda på grensa som eig henne. Hald på konsolltilgang før du endrar ei bru som blir administrert eksternt.

Å gjenopprette tilkoplinga er halve testen; den andre halvdelen er å stadfeste at ein straum som skal halde fram med å vere blokkert, framleis er det.

Noter kva eigar som filtrerte, kva kontroll som vart endra og kva to straumar du verifiserte. Den notata hindrar neste hending i å byrje med den same føresetnaden om at pfSense ignorerer seg sjølv.