Virtual na TAP bridge ng pfSense: tatlong lugar kung saan maaaring mamatay ang isang frame

Hinihinto mo ang isang panuntunan sa interface ng LAN, nawawala pa rin ang frame, at ang konklusyon ay binabalewala ng pfSense ang sarili nitong firewall. Ang karaniwang nangyari ay ibang may-ari ang nagpasya: ang bridge mismo, ang interface ng miyembro, o ang virtual switch sa labas ng bisita. Bawat isa ay may sariling kontrol at sariling log.

Ang tatlong hangganan sa ibaba ay dapat hiwalayin bago mo baguhin ang isang setting, dahil ang pag-disable ng isa ay hindi makakabawi sa isa.

Isang frame, tatlong may-ari ng patakaran

Ang frame mula sa kliyenteng TAP ay pumapasok sa pamamagitan ng aparato ng tunnel, tumatawid sa bridge ng pfSense, lumalabas sa isang miyembro ng LAN, at pagkatapos ay dumadaan sa isang virtual switch bago ito makarating sa anuman. Sa loob ng bisita, maaaring mangyari ang pag-filter sa bridge o sa mga interface ng miyembro, at kung alin ang aktibo ay pagpili ng pagsasaayos at hindi isang nakapirming katangian. Sa labas ng bisita, nagpapasya ang hypervisor kung maaaring magpadala ang virtual adapter na iyon ng mga frame na may source MAC na hindi pag-aari nito. Ang pagkahulog sa alinman sa mga puntong iyon ay magkamukha mula sa panig ng kliyente.

Isulat ang nilalayong landas bago mag-imbestiga: miyembro ng tunnel, bridge, miyembro ng LAN, virtual switch, destinasyon. Pagkatapos ay itanong kung sinong may-ari sa landas na iyon ang makakakita ng frame.

Aling kontrol ng pfSense ang nagfi-filter

Dokumentado ng pfSense ang dalawang sysctl para dito, isa para sa pag-filter sa mga miyembro ng bridge at isa para sa pag-filter sa bridge mismo, at hindi bababa sa isa sa kanila ang dapat manatiling naka-enable. Ang pag-filter sa antas ng bridge ay nalalapat sa trapikong dumarating sa pamamagitan ng mga miyembro ng bridge, kaya papasok ito sa oryentasyon at hindi simetriko. Basahin ang mga panuntunan sa interface na aktwal na nagfi-filter, dahil ang panuntunang inilagay sa isang miyembrong walang tungkulin sa pag-filter ay walang ginagawa. Ang dokumentasyon ng pag-filter ng bridge ay nagpapaliwanag ng pagmamay-ari.

Ang interface ng miyembrong walang address ng IP ay walang sariling macro ng address o subnet, kaya ang panuntunang isinulat laban sa macro na iyon ay maaaring maglarawan ng iba sa LAN na nilalayon mo. Gumamit ng sadyang itinalagang mga network object sa halip na mga macro para sa kaginhawahan.

Ang fragment ay hindi frame

Nagdadala ang mga frame ng Ethernet ng mga packet ng IP, at ang isang packet ng IP ay maaaring fragment ng mas malaking datagram, kaya hindi mapagpapalit ang dalawang salitang iyon. Mayroon ding panloob na packet sa loob ng tunnel at panlabas na packet ng transportasyon sa labas nito, at ang pagkabigo ay maaaring mapabilang sa alinman. Ang maliit na ping ay nagsasanay ng isang landas sa stack na iyon at walang pinapatunayan tungkol sa malaking paglilipat. Ihambing ang nabigong pagpapalitan sa dalawang magkatabing hangganan at basahin ang dahilan ng pagkahulog bago sisihin ang isang panuntunan.

Kung nawawala ang mga fragment, ang sagot ay isang limitadong pagwawasto o imbestigasyon ng laki ng packet, hindi isang pasyang i-disable nang buo ang pag-filter.

May sariling pasya ang hypervisor sa pagtanggap

Ang bisitang nagbi-bridge ng trapiko para sa ibang makina ay naglalabas ng mga frame na ang source MAC address ay hindi ng sarili nitong adapter, at itinuturing ito ng maraming virtual switch na spoofing maliban kung pinapayagan ng port group. Ang pagpayag sa pagpapadala na iyon at ang pagpayag sa adapter na tumanggap ng bawat frame ay magkahiwalay na kontrol, at ang pag-enable sa pareho sa lahat ng lugar ay mas malaking pagbabago kaysa sa kailangan ng problema. Tukuyin kung aling mga frame ang dapat tanggapin at dapat ilabas ng bridge, pagkatapos ay ibigay lamang ang pag-uugaling iyon sa hangganang nagmamay-ari nito. Panatilihin ang access sa console bago baguhin ang bridge na pinamamahalaan mula sa malayo.

Ang pagpapanumbalik ng koneksyon ay kalahati ng pagsubok; ang kabilang kalahati ay ang kumpirmahin na ang daloy na dapat manatiling naka-block ay naka-block pa rin.

Itala kung sinong may-ari ang nag-filter, aling kontrol ang nagbago at aling dalawang daloy ang na-verify mo. Ang talaang iyon ay pumipigil sa susunod na insidente na magsimula sa parehong palagay na binabalewala ng pfSense ang sarili nito.