Virtuele pfSense TAP-brug: drie plekke waar 'n raam kan sterf

Jy skakel 'n reël op die LAN-koppelvlak uit, die raam verdwyn steeds, en die gevolgtrekking is dat pfSense sy eie firewall ignoreer. Wat gewoonlik gebeur het, is dat 'n ander eienaar die besluit geneem het: die brug self, die lid-koppelvlak, of die virtuele skakelaar buite die gas. Elkeen het sy eie beheer en sy eie logboek.

Die drie grense hieronder is die moeite werd om te skei voordat jy 'n instelling verander, want om een uit te skakel kan nie 'n ander vergoed nie.

Een raam, drie beleidseienaars

'n Raam van 'n TAP-kliënt kom deur die tonneltoestel in, kruis die pfSense-brug, verlaat deur 'n LAN-lid, en gaan dan deur 'n virtuele skakelaar voordat dit enigiets bereik. Binne die gas kan filtering op die brug of op die lid-koppelvlakke plaasvind, en watter een aktief is, is 'n konfigurasiekeuse eerder as 'n vaste eienskap. Buite die gas besluit die hipervisor of daardie virtuele adapter rame mag stuur met 'n bron-MAC wat nie sy eie is nie. 'n Val op enige van daardie punte lyk identies van die kliënt se kant.

Skryf die beoogde pad neer voordat jy ondersoek instel: tonnellid, brug, LAN-lid, virtuele skakelaar, bestemming. Vra dan watter eienaar op daardie pad die raam sou gesien het.

Watter pfSense-beheer filtreer

pfSense dokumenteer twee sysctls hiervoor, een vir filtering op die bruglede en een vir filtering op die brug self, en ten minste een van hulle moet aktief bly. Filtering op brugvlak geld vir verkeer wat deur die bruglede aankom, dus is dit inkomend van oriëntasie eerder as simmetries. Lees die reëls op die koppelvlak wat werklik filtreer, want 'n reël op 'n lid sonder 'n filterrol doen heeltemal niks. Die dokumentasie oor brugfiltering verduidelik die eienaarskap.

'n Lid-koppelvlak sonder 'n IP-adres het geen adres- of subnetmakro van sy eie nie, so 'n reël wat teen daardie makro geskryf is, kan iets anders beskryf as die LAN wat jy bedoel het. Gebruik doelbewus toegewysde netwerkobjekte eerder as geriefsmakro's.

'n Fragment is nie 'n raam nie

Ethernet-rame dra IP-pakkette, en 'n IP-pakket kan 'n fragment van 'n groter datagram wees, dus is die twee woorde nie uitruilbaar nie. Daar is ook 'n binnerpakket binne die tonnel en 'n buitenste vervoerpakket daarbuite, en 'n fout kan aan enigeen behoort. 'n Klein ping oefen een pad deur daardie stapel en bewys niks oor 'n groot oordrag nie. Vergelyk die mislukkende uitruiling by twee aangrensende grense en lees die valrede voordat jy 'n reël blameer.

As fragmente verdwyn, is die antwoord 'n gerigte regstelling of 'n ondersoek na pakketgrootte, nie 'n besluit om filtering heeltemal uit te skakel nie.

Die hipervisor het sy eie toelatingsbesluit

'n Gas wat verkeer vir ander masjiene brug, stuur rame waarvan die bron-MAC-adresse nie dié van sy eie adapter is nie, en baie virtuele skakelaars beskou dit as vervalsing tensy die poortgroep dit toelaat. Om daardie oordrag toe te laat en om die adapter toe te laat om elke raam te ontvang, is afsonderlike beheermaatreëls, en om albei oral te aktiveer is 'n veel groter verandering as wat die probleem vereis. Bepaal watter rame die brug moet ontvang en moet stuur, en verleen dan net daardie gedrag by die grens wat dit besit. Hou konsoltoegang voordat jy 'n op afstand bestuurde brug verander.

Om verbinding te herstel is die helfte van die toets; die ander helfte is om te bevestig dat 'n vloei wat geblokkeer moet bly, steeds geblokkeer is.

Teken aan watter eienaar gefiltreer het, watter beheer verander is en watter twee vloeie jy geverifieer het. Daardie rekord verhoed die volgende voorval om met dieselfde vermoede te begin dat pfSense homself ignoreer.