Ponte TAP virtual en pfSense: tres puntos onde unha trama pode morrer

Desactivas unha regra na interface LAN, a trama segue desaparecendo e a conclusión é que pfSense ignora o seu propio cortafuegos. O que adoita ocorrer é que a decisión a tomou outro propietario: a propia ponte, a interface membro ou o conmutador virtual fóra do convidado. Cada un ten o seu control e o seu rexistro.

Paga a pena separar os tres límites seguintes antes de cambiar un axuste, porque desactivar un non compensa o outro.

Unha trama, tres propietarios de política

Unha trama dun cliente TAP entra polo dispositivo de túnel, cruza a ponte de pfSense, sae por un membro LAN e despois pasa por un conmutador virtual antes de chegar a calquera sitio. Dentro do convidado, o filtrado pode ocorrer na ponte ou nas interfaces membro, e cal está activa é unha elección de configuración, non unha propiedade fixa. Fóra do convidado, o hipervisor decide se ese adaptador virtual pode transmitir tramas cunha MAC de orixe que non posúe. Un descarte en calquera deses puntos vese idéntico desde o cliente.

Anota a ruta prevista antes de investigar: membro de túnel, ponte, membro LAN, conmutador virtual, destino. Despois pregunta que propietario desa ruta tería visto a trama.

Que control de pfSense filtra

pfSense documenta dous sysctl para isto, un para filtrar nos membros da ponte e outro para filtrar na propia ponte, e polo menos un deles debe permanecer activado. O filtrado a nivel de ponte aplícase ao tráfico que chega polos membros da ponte, así que é de entrada como orientación, non simétrico. Le as regras na interface que filtra realmente, porque unha regra posta nun membro sen papel de filtrado non fai absolutamente nada. A documentación de filtrado da ponte explica a propiedade.

Unha interface membro sen enderezo IP non ten macro de enderezo ou subrede propia, así que unha regra escrita contra esa macro pode describir algo distinto da LAN que pretendías. Usa obxectos de rede asignados deliberadamente en lugar de macros de comodidade.

Un fragmento non é unha trama

As tramas Ethernet transportan paquetes IP, e un paquete IP pode ser un fragmento dun datagrama maior, así que as dúas palabras non son intercambiables. Tamén hai un paquete interno dentro do túnel e un paquete de transporte externo fóra del, e un fallo pode pertencer a calquera dos dous. Un ping pequeno exercita unha ruta por esa pila e non demostra nada sobre unha transferencia grande. Compara o intercambio fallido en dous límites adxacentes e le o motivo do descarte antes de culpar unha regra.

Se os fragmentos desaparecen, a resposta é unha corrección acoutada ou unha investigación do tamaño de paquete, non unha decisión de desactivar o filtrado por completo.

O hipervisor ten a súa propia decisión de admisión

Un convidado que fai ponte de tráfico para outras máquinas emite tramas cuxas MAC de orixe non son as do seu propio adaptador, e moitos conmutadores virtuais trátano como suplantación salvo que o grupo de portos o permita. Permitir esa transmisión e permitir que o adaptador reciba cada trama son controis separados, e activar ambos en todas partes é un cambio moito maior do que esixe o problema. Determina que tramas debe recibir e debe emitir a ponte, e despois concede só ese comportamento no límite que o posúe. Mantén o acceso á consola antes de cambiar unha ponte xestionada de forma remota.

Restaurar a conectividade é a metade da proba; a outra metade é confirmar que un fluxo que debería seguir bloqueado segue estando.

Rexistra que propietario filtrou, que control se cambiou e que dous fluxos verificaches. Ese rexistro impide que o seguinte incidente comece coa mesma suposición de que pfSense se ignora a si mesmo.