Pont TAP virtual a pfSense: tres llocs on una trama pot morir

Desactiveu una regla a la interfície LAN, la trama continua desapareixent, i la conclusió és que pfSense ignora el seu propi tallafoc. El que sol haver passat és que la decisió l'ha pres un altre propietari: el pont mateix, la interfície membre o el commutador virtual fora del convidat. Cadascun té el seu control i el seu registre.

Val la pena separar les tres fronteres següents abans de canviar un paràmetre, perquè desactivar-ne una no pot compensar l'altra.

Una trama, tres propietaris de política

Una trama d'un client TAP entra pel dispositiu de túnel, travessa el pont de pfSense, surt per un membre LAN i després passa per un commutador virtual abans d'arribar a qualsevol lloc. Dins del convidat, el filtratge pot passar al pont o a les interfícies membres, i quina és activa és una elecció de configuració, no una propietat fixa. Fora del convidat, l'hipervisor decideix si aquest adaptador virtual pot transmetre trames amb una MAC d'origen que no posseeix. Un descart en qualsevol d'aquests punts sembla idèntic des del client.

Escriviu el camí previst abans d'investigar: membre de túnel, pont, membre LAN, commutador virtual, destinació. Després pregunteu quin propietari d'aquest camí hauria vist la trama.

Quin control de pfSense filtra

pfSense documenta dos sysctl per a això, un per filtrar als membres del pont i un per filtrar al pont mateix, i almenys un d'ells ha de romandre activat. El filtratge a nivell de pont s'aplica al trànsit que arriba pels membres del pont, així que és d'entrada com a orientació, no simètric. Llegiu les regles a la interfície que realment filtra, perquè una regla posada en un membre sense paper de filtratge no fa absolutament res. La documentació de filtratge del pont explica la propietat.

Una interfície membre sense adreça IP no té cap macro d'adreça o subxarxa pròpia, així que una regla escrita contra aquesta macro pot descriure una cosa diferent de la LAN que volíeu. Feu servir objectes de xarxa assignats deliberadament en lloc de macros de comoditat.

Un fragment no és una trama

Les trames Ethernet porten paquets IP, i un paquet IP pot ser un fragment d'un datagrama més gran, així que les dues paraules no són intercanviables. També hi ha un paquet intern dins del túnel i un paquet de transport extern fora d'ell, i un error pot pertànyer a qualsevol dels dos. Un ping petit exercita un camí per aquesta pila i no demostra res sobre una transferència gran. Compareu l'intercanvi fallit a dues fronteres adjacents i llegiu el motiu del descart abans de culpar una regla.

Si els fragments desapareixen, la resposta és una correcció acotada o una investigació de la mida del paquet, no una decisió de desactivar el filtratge del tot.

L'hipervisor té la seva pròpia decisió d'admissió

Un convidat que fa pont de trànsit per a altres màquines emet trames les MAC d'origen de les quals no són les del seu propi adaptador, i molts commutadors virtuals ho tracten com a suplantació tret que el grup de ports ho permeti. Permetre aquesta transmissió i permetre que l'adaptador rebi cada trama són controls separats, i activar tots dos a tot arreu és un canvi molt més gran del que el problema requereix. Determineu quines trames ha de rebre i ha d'emetre el pont, i després concediu només aquest comportament a la frontera que el posseeix. Conserveu l'accés a la consola abans de canviar un pont gestionat remotament.

Restablir la connectivitat és la meitat de la prova; l'altra meitat és confirmar que un flux que hauria de continuar bloquejat encara ho està.

Registreu quin propietari ha filtrat, quin control s'ha canviat i quins dos fluxos heu verificat. Aquest registre evita que el proper incident comenci amb la mateixa suposició que pfSense s'ignora a si mateix.