Por qué nftables no ve el tráfico entre clientes de OpenVPN

Dos clientes en un mismo servidor intercambian archivos, la transferencia tiene éxito y cada regla de reenvío que apuntáis al túnel informa de cero paquetes. Las reglas no están rotas y la cadena no está mal colocada. Con el reenvío entre pares activado, el paquete se entrega dentro del proceso del servidor y la pila del host nunca se convierte en el enrutador, así que el cortafuegos del núcleo no tiene nada que contar. Entender esa separación decide si conserváis el atajo o reconstruís la ruta a través del núcleo.

Siga un paquete a través del servidor

En un túnel enrutado, el demonio entrega el paquete descifrado de cada cliente al dispositivo de túnel. Desde allí el host lo enruta, se ejecuta el gancho de reenvío y una regla que coincida con el dispositivo de túnel puede contar o descartar el tráfico. Ese es el camino que suponen la mayoría de los ejemplos de cortafuegos.

El atajo saca al host del medio. El paquete descifrado de una sesión se entrega a otra sesión dentro del demonio, y el paquete interior nunca se emite en el dispositivo de túnel ni lo enruta el host. El tráfico encapsulado sigue cruzando la interfaz física, así que una captura externa parece ocupada mientras las reglas internas callan. Una captura tomada en el dispositivo de túnel no muestra absolutamente nada, lo que sorprende a quien espera ver allí la transferencia. Esa asimetría es la forma más rápida de reconocer el atajo desde fuera del demonio.

La prueba del contador que decide qué camino se recorrió

Añada un contador a la regla que debería aplicarse, ejecute una transferencia entre dos clientes que esa regla debería bloquear y lea el contador después.

sudo nft list ruleset
sudo nft add rule inet filter forward iifname "tun0" oifname "tun0" counter accept
sudo nft list chain inet filter forward

Si la transferencia tiene éxito y el contador sigue en cero, el núcleo nunca gestionó esos paquetes, y ninguna cantidad de edición de reglas lo cambiará. Repita la misma prueba contra un servicio del propio servidor, porque ese flujo sí atraviesa la pila del host y su contador se mueve. Comparar los dos resultados es lo que produce la respuesta.

Dos detalles evitan una lectura falsa. Un nombre de interfaz escrito en una etiqueta de cadena no filtra nada por sí solo, porque la coincidencia ocurre en los campos de interfaz dentro de las reglas. Y un diseño puente de capa 2 se comporta de forma distinta otra vez: allí los clientes comparten un dominio de difusión, así que el descubrimiento de pares es lo esperado y no un fallo de enrutamiento.

Un conmutador no es una lista de acceso

Esta es la parte que cuesta una tarde. El reenvío entre pares es un único ajuste de encendido o apagado, y mientras está encendido el demonio es el único punto de reenvío. El cortafuegos del host no puede expresar quién puede llegar a quién, y los archivos por cliente no convierten el conmutador en una matriz de políticas.

Si necesita reglas por par, la elección es entre renunciar al atajo y renunciar al cortafuegos del host como control. Apagarlo restaura el reenvío del núcleo, que exige reenvío IP en el servidor y reglas explícitas para los flujos que desea. Mantenerlo encendido significa que la política vive en la configuración del demonio, que en la práctica es todos los pares o ninguno.

Procesos de servidor separados con sus propios rangos de direcciones y puertos son el término medio viable. Cada proceso lleva exactamente una decisión de acceso, así que dos grupos pueden tener reglas distintas sin una matriz de políticas. El host puede enrutar entre los rangos cuando eso es lo previsto, y entonces el cortafuegos ve esos flujos porque cruzan el host. El coste son puertos extra, certificados extra y un perfil por grupo.

Elegir el punto de reenvío

Elija el reenvío del núcleo cuando el cortafuegos sea el motor de políticas, cuando necesite registro por flujo o cuando la contabilidad importe. El coste es el rendimiento a través de la pila del host y más reglas que mantener. La ventaja es que cada herramienta existente, de los contadores a los exportadores de flujos, vuelve a describir el tráfico. En un servidor pequeño ese coste es invisible; en un repetidor ocupado no lo es.

Elija el reenvío dentro del proceso cuando el tráfico entre pares esté todo permitido o todo denegado y el servidor esté dimensionado para ello. El coste es que los contadores, las disciplinas de cola y el seguimiento de conexiones ya no describen los flujos internos; eso solo es aceptable si después nadie depende de ellos.

Elija lo que elija, anótelo junto a las reglas del cortafuegos. Un conjunto de reglas que parece permitir el tráfico entre pares mientras el demonio decide igualmente engaña a la siguiente persona que depure una transferencia fallida. Quien solo lea las reglas asumirá que el núcleo es la puerta.

Qué comprobar antes de cambiar reglas

Lea la configuración que el servidor cargó realmente, no el archivo que recuerda haber editado, y confirme si la opción de pares está presente. Si la ha cambiado, asegúrese de que el servicio se recargó y no solo reescribió un archivo en disco.

Después repita la prueba con un flujo de cliente a servidor para demostrar que la regla coincide siquiera, y revise las rutas enviadas, porque una ruta ausente parece exactamente un bloqueo del cortafuegos desde el lado del cliente. Cambie el orden de las reglas solo cuando sepa qué punto de reenvío posee la decisión.