Ponte TAP virtuale in pfSense: tre punti in cui una trama può morire

Disattivi una regola sull'interfaccia LAN, la trama scompare lo stesso, e la conclusione è che pfSense ignora il proprio firewall. Quello che di solito è successo è che un altro proprietario ha preso la decisione: il ponte stesso, l'interfaccia membro o lo switch virtuale fuori dall'ospite. Ognuno ha il proprio controllo e il proprio registro.

Vale la pena separare i tre confini seguenti prima di cambiare un'impostazione, perché disattivarne uno non compensa l'altro.

Una trama, tre proprietari di politica

Una trama di un client TAP entra dal dispositivo tunnel, attraversa il ponte pfSense, esce da un membro LAN e poi passa per uno switch virtuale prima di raggiungere qualsiasi cosa. Dentro l'ospite il filtraggio può avvenire sul ponte o sulle interfacce membro, e quale sia attiva è una scelta di configurazione e non una proprietà fissa. Fuori dall'ospite l'hypervisor decide se quell'adattatore virtuale può trasmettere trame con un MAC sorgente che non possiede. Uno scarto in uno di quei punti è identico dal punto di vista del client.

Scrivi il percorso previsto prima di indagare: membro del tunnel, ponte, membro LAN, switch virtuale, destinazione. Poi chiedi quale proprietario su quel percorso avrebbe visto la trama.

Quale controllo di pfSense filtra

pfSense documenta due sysctl per questo, uno per il filtraggio sui membri del ponte e uno per il filtraggio sul ponte stesso, e almeno uno dei due deve restare attivo. Il filtraggio a livello di ponte si applica al traffico che arriva attraverso i membri del ponte, quindi è entrante come orientamento e non simmetrico. Leggi le regole sull'interfaccia che filtra davvero, perché una regola impostata su un membro senza ruolo di filtraggio non fa assolutamente nulla. La documentazione sul filtraggio del ponte chiarisce la proprietà.

Un'interfaccia membro senza indirizzo IP non ha una propria macro di indirizzo o sottorete, quindi una regola scritta contro quella macro può descrivere qualcosa di diverso dalla LAN che intendevi. Usa oggetti di rete assegnati deliberatamente invece di macro di comodo.

Un frammento non è una trama

Le trame Ethernet trasportano pacchetti IP, e un pacchetto IP può essere un frammento di un datagramma più grande, quindi le due parole non sono intercambiabili. C'è anche un pacchetto interno dentro il tunnel e un pacchetto di trasporto esterno fuori di esso, e un guasto può appartenere a entrambi. Un ping piccolo esercita un percorso attraverso quello stack e non dimostra nulla su un trasferimento grande. Confronta lo scambio che fallisce su due confini adiacenti e leggi il motivo dello scarto prima di dare la colpa a una regola.

Se i frammenti scompaiono, la risposta è una correzione mirata o un'indagine sulla dimensione dei pacchetti, non una decisione di disattivare del tutto il filtraggio.

L'hypervisor ha la propria decisione di ammissione

Un ospite che fa da ponte per il traffico di altre macchine emette trame i cui indirizzi MAC sorgente non sono quelli del proprio adattatore, e molti switch virtuali lo trattano come spoofing a meno che il gruppo di porte lo consenta. Permettere quella trasmissione e permettere all'adattatore di ricevere ogni trama sono controlli separati, e attivare entrambi ovunque è un cambiamento molto più grande di quanto richieda il problema. Determina quali trame il ponte deve ricevere e deve emettere, poi concedi solo quel comportamento al confine che lo possiede. Mantieni l'accesso alla console prima di modificare un ponte gestito da remoto.

Ripristinare la connettività è metà della prova; l'altra metà è confermare che un flusso che dovrebbe restare bloccato lo è ancora.

Annota quale proprietario ha filtrato, quale controllo è cambiato e quali due flussi hai verificato. Quella nota impedisce al prossimo incidente di iniziare con la stessa supposizione che pfSense ignori se stesso.