Virtuala pfSense TAP-ponto: tri lokoj, kie kadro povas morti

Vi malŝaltas regulon sur la LAN-interfaco, la kadro tamen malaperas, kaj la konkludo estas, ke pfSense ignoras sian propran fajroŝirmilon. Kutime okazis, ke alia posedanto faris la decidon: la ponto mem, la membra interfaco aŭ la virtuala ŝaltilo ekster la gasto. Ĉiu havas sian propran regilon kaj sian propran registron.

La tri limoj sube indas esti apartigitaj antaŭ ol vi ŝanĝos agordon, ĉar malŝalti unu ne povas kompensi alian.

Unu kadro, tri posedantoj de politiko

Kadro de TAP-kliento eniras tra la tunela aparato, transiras la pfSense-ponton, eliras tra LAN-membro kaj poste trapasas virtualan ŝaltilon antaŭ ol ĝi atingas ion ajn. Ene de la gasto, filtrado povas okazi sur la ponto aŭ sur la membraj interfacoj, kaj kiu estas aktiva estas elekto de agordo, ne fiksa eco. Ekster la gasto, la hipervidilo decidas, ĉu tiu virtuala adaptilo rajtas sendi kadrojn kun fonta MAC, kiun ĝi ne posedas. Forĵeto ĉe iu ajn el tiuj punktoj aspektas idente de la klienta flanko.

Skribu la celitan vojon antaŭ ol esplori: tunela membro, ponto, LAN-membro, virtuala ŝaltilo, celloko. Poste demandu, kiu posedanto sur tiu vojo estus vidinta la kadron.

Kiu pfSense-regilo filtras

pfSense dokumentas du sysctl por tio, unu por filtrado sur la pontaj membroj kaj unu por filtrado sur la ponto mem, kaj almenaŭ unu el ili devas resti ŝaltita. Filtrado je ponta nivelo aplikiĝas al trafiko alvenanta tra la pontaj membroj, do ĝi estas ena laŭ orientiĝo, ne simetria. Legu la regulojn sur la interfaco, kiu efektive filtras, ĉar regulo metita sur membron sen filtra rolo faras tute nenion. La dokumentaro pri ponta filtrado klarigas la posedantecon.

Membra interfaco sen IP-adreso ne havas propran adresan aŭ subretan makroon, do regulo skribita kontraŭ tiu makroo povas priskribi ion alian ol la LAN, kiun vi celis. Uzu intence asignitajn retajn objektojn anstataŭ komfortaj makrooj.

Fragmento ne estas kadro

Ethernet-kadroj portas IP-paketojn, kaj IP-paketo povas esti fragmento de pli granda datagramo, do la du vortoj ne estas interŝanĝeblaj. Estas ankaŭ interna paketo ene de la tunelo kaj ekstera transporta paketo ekster ĝi, kaj paneo povas aparteni al ambaŭ. Malgranda ping provas unu vojon tra tiu stako kaj pruvas nenion pri granda transigo. Komparu la malsukcesan interŝanĝon ĉe du apudaj limoj kaj legu la kialon de forĵeto antaŭ ol kulpigi regulon.

Se fragmentoj malaperas, la respondo estas limigita korekto aŭ esploro de paketa grandeco, ne decido malŝalti filtradon tute.

La hipervidilo havas sian propran akceptan decidon

Gasto, kiu pontas trafikon por aliaj maŝinoj, elsendas kadrojn, kies fontaj MAC-adresoj ne estas de sia propra adaptilo, kaj multaj virtualaj ŝaltiloj traktas tion kiel falsadon, se la porthrupo ne permesas tion. Permesi tiun transsendon kaj permesi al la adaptilo ricevi ĉiun kadron estas apartaj regiloj, kaj ŝalti ambaŭ ĉie estas multe pli granda ŝanĝo, ol la problemo postulas. Determinu, kiujn kadrojn la ponto devas ricevi kaj devas elsendi, poste donu nur tiun konduton ĉe la limo, kiu posedas ĝin. Konservu konsolan aliron antaŭ ol ŝanĝi distance administritan ponton.

Restarigi konektecon estas duono de la testo; la alia duono estas konfirmi, ke fluo, kiu devus resti blokita, ankoraŭ estas tia.

Notu, kiu posedanto filtris, kiu regilo ŝanĝiĝis kaj kiujn du fluojn vi kontrolis. Tiu noto malhelpas, ke la sekva incidento komenciĝu per la sama supozo, ke pfSense ignoras sin mem.