Ponte TAP virtual no pfSense: três pontos onde um quadro pode morrer

Desativa uma regra na interface LAN, o quadro continua a desaparecer, e a conclusão é que o pfSense ignora a sua própria firewall. O que normalmente aconteceu é que a decisão foi tomada por outro proprietário: a própria ponte, a interface membro ou o comutador virtual fora do convidado. Cada um tem o seu controlo e o seu registo.

Vale a pena separar as três fronteiras abaixo antes de alterar uma definição, porque desativar uma não compensa a outra.

Um quadro, três proprietários de política

Um quadro de um cliente TAP entra pelo dispositivo de túnel, atravessa a ponte pfSense, sai por um membro LAN e depois passa por um comutador virtual antes de chegar a qualquer coisa. Dentro do convidado, a filtragem pode acontecer na ponte ou nas interfaces membro, e qual está ativa é uma escolha de configuração e não uma propriedade fixa. Fora do convidado, o hipervisor decide se esse adaptador virtual pode transmitir quadros com um MAC de origem que não possui. Um descarte em qualquer um desses pontos parece idêntico do lado do cliente.

Anote o caminho pretendido antes de investigar: membro do túnel, ponte, membro LAN, comutador virtual, destino. Depois pergunte qual proprietário nesse caminho teria visto o quadro.

Que controlo do pfSense está a filtrar

O pfSense documenta dois sysctl para isto, um para filtragem nos membros da ponte e outro para filtragem na própria ponte, e pelo menos um deles tem de permanecer ativo. A filtragem ao nível da ponte aplica-se ao tráfego que chega pelos membros da ponte, por isso é de entrada na orientação e não simétrica. Leia as regras na interface que realmente filtra, porque uma regra colocada num membro sem papel de filtragem não faz absolutamente nada. A documentação de filtragem da ponte explica a propriedade.

Uma interface membro sem endereço IP não tem macro de endereço ou sub-rede própria, por isso uma regra escrita contra essa macro pode descrever algo diferente da LAN que pretendia. Use objetos de rede atribuídos deliberadamente em vez de macros de conveniência.

Um fragmento não é um quadro

Os quadros Ethernet transportam pacotes IP, e um pacote IP pode ser um fragmento de um datagrama maior, por isso as duas palavras não são intermutáveis. Também existe um pacote interno dentro do túnel e um pacote de transporte externo fora dele, e uma falha pode pertencer a qualquer um dos dois. Um ping pequeno exercita um caminho por essa pilha e não prova nada sobre uma transferência grande. Compare a troca que falha em duas fronteiras adjacentes e leia o motivo do descarte antes de culpar uma regra.

Se os fragmentos desaparecerem, a resposta é uma correção limitada ou uma investigação do tamanho do pacote, não uma decisão de desativar a filtragem por completo.

O hipervisor tem a sua própria decisão de admissão

Um convidado que faz ponte de tráfego para outras máquinas emite quadros cujos MAC de origem não são os do seu próprio adaptador, e muitos comutadores virtuais tratam isso como falsificação a menos que o grupo de portas o permita. Permitir essa transmissão e permitir que o adaptador receba cada quadro são controlos separados, e ativar ambos em todo o lado é uma alteração muito maior do que o problema exige. Determine que quadros a ponte tem de receber e de emitir, e depois conceda apenas esse comportamento na fronteira que o possui. Mantenha o acesso à consola antes de alterar uma ponte gerida remotamente.

Restaurar a conetividade é metade do teste; a outra metade é confirmar que um fluxo que deve continuar bloqueado ainda está.

Registe qual proprietário filtrou, que controlo mudou e que dois fluxos verificou. Esse registo impede o próximo incidente de começar com a mesma suposição de que o pfSense se ignora a si próprio.