iptables/nftables: ¿cómo excluir todo el tráfico reenviado del seguimiento de conexiones en un enrutador?

Question

Una máquina Linux tiene múltiples interfaces de red. El reenvío de IP está habilitado para IPv4 e IPv6.

Me gustaría proteger los servicios que se ejecutan en el enrutador a través de un firewall con estado. Para eso, es necesario habilitar el seguimiento de conexiones. Al mismo tiempo, me gustaría excluir del seguimiento de la conexión todo el tráfico que se reenvía de una interfaz a otra.

Para el firewall con estado, normalmente usaría las cadenas de ENTRADA y SALIDA de la tabla de filtros. El tráfico reenviado iría a la cadena FORWARD. Pero AFAIK no hay forma de marcar el tráfico como sin seguimiento en la cadena FORWARD. Dicha lógica tiene que ir a la cadena PREROUTING en la tabla sin formato. Pero creo que en la cadena PREROUTING aún no se ha decidido si el tráfico se reenvía o no.

El seguimiento de conexiones tiene muchas desventajas, como la caída de paquetes cuando la lista de conexiones rastreadas ha alcanzado su tamaño máximo.

¿Cuál es la forma más sencilla de excluir el tráfico reenviado (y solo ese tráfico reenviado) del seguimiento de la conexión?

Answer 1

Para un conjunto de reglas genérico, uno puede preguntarnftablespara hacer una búsqueda de ruta por adelantado usando elfibexpresión en lugar de esperar a que la pila de enrutamiento lo haga. Esto permite involucrar al (futuro)produccióninterfaz a pesar de no existir todavía (la decisión de enrutamiento no se produjo), a costa de una búsqueda adicional. Luego, si los resultados indican que el paquete será enrutado, evite que se realice el seguimiento utilizando unnotrackdeclaración.

EXPRESIONES FIB

fib {saddr | daddr | mark | iif | oif} [. ...] {oif | oifname | type}

Amentiraexpresión consulta elmentira(base de información de reenvío) para obtener información como el índice de interfaz de salida que usaría una dirección particular. La entrada es una tupla de elementos que se utiliza como entrada para elmentirafunciones de búsqueda.

DECLARACIÓN DE NOTRACK

La declaración notrack permite deshabilitar el seguimiento de conexiones para ciertos paquetes.

notrack

Tenga en cuenta que para que esta declaración sea efectiva, debe aplicarse a los paquetes antes de queconectarocurre la búsqueda. Por lo tanto, necesita estar en una cadena con cualquiera de los dos.preenrutamientooproduccióngancho y una prioridad de gancho de -300 o menos.

Entonces uno debería hacer una verificación de ruta "simple" desdepreenrutamiento, utilizando solo la dirección de destino como selector y verifique la existencia de una interfaz de salida (los paquetes no enrutables o los paquetes destinados al host no resolverán ninguna). Hay una excepción para elmira(bucle invertido) para mantenerlo rastreado: si bien representa el tráfico local, un paquete enviado (a través delproducciónruta) desde el host hacia sí mismo regresa a travéspreenrutamientoruta y tiene una interfaz de salida demiratambién. Como el paquete saliente ya creó unconectarentrada, será mejor mantener esto consistente.

nft add table ip stateless
nft add chain ip stateless prerouting '{ type filter hook prerouting priority -310; policy accept; }'
nft add rule ip stateless prerouting iif != lo fib daddr oif exists notrack

Reemplazar la ipfamilia con la inetfamilia combinada debería extender el mismo comportamiento genérico a IPv4+IPv6.

Para ser más específico, se podría especificar la futura interfaz de salida con, fib daddr oif eth1por ejemplo, que es más o menos equivalente a oif eth1, pero también está disponible enpreenrutamiento.

Por supuesto, si la topología se conoce de antemano, es posible evitar una búsqueda de FIB utilizando una o varias reglas basadas en pruebas de direcciones, ya que el administrador conoce las rutas de antemano. Es posible que sea necesario realizar una evaluación comparativa de los resultados para saber si esto es más interesante que mantener un método genérico.

Por ejemplo, con la información proporcionada por el OP, reemplazando la regla anterior por:

nft add rule ip stateless prerouting 'ip daddr != { 192.168.1.1, 192.168.2.1, 127.0.0.0/8 } notrack'

debería tener un efecto casi equivalente. 127.0.0.0/8 está presente por las mismas razones que arriba con elmirainterfaz.

Manejo de transmisión (como 192.168.1.255 recibido eneth0) y la multidifusión (como el enlace local 224.0.0.1 recibido en una interfaz) podrían no funcionar igual en ambos métodos ni como se esperaba y posiblemente requerirían reglas adicionales para necesidades específicas, especialmente con el segundo método. Como el seguimiento de la transmisión y la multidifusión rara vez es útil, debido a que una fuente de respuesta no será (y no puede) ser el destino de la dirección de transmisión o multidifusión original, por lo que la entrada conntrack nunca "verá" el tráfico bidireccional, por lo general no importa mucho para reglas con estado.

---

Notas

• Por lo general, esto no será compatible con NAT con estado.

  Tengo entendido que DNAT hacia un host remoto hará que su tráfico de respuesta no se desNAT y falle, y que SNAT reenviado no se activará ya que no huboconectarentrada creada. SNAT rara vez usado en la ruta de entrada debería estar bien, y una combinación de DNAT+SNAT (usando una fuente de dirección local) también podría funcionar, ya que tanto en la dirección original como en la de respuesta hay un destino local involucrado, por lo queconectarLa entrada siempre debe crearse o buscarse correctamente.

• conjunto de reglas estándar

  Reglas reales usandoiptablesonftables(en su propia tabla diferente) se puede hacer como de costumbre, incluidas reglas con estado para el propio host. Como el tráfico enrutado no crearáconectarlas entradas, las reglas, si las hay, que involucren dicho tráfico, deben limitarse a ser sin estado y no usar ninguna ctexpresión porque nunca coincidirían.

• verificando el comportamiento

  Se puede comprobar el comportamiento general incluso sin las reglas de firewall adecuadas:

  • usando una ctregla ficticia para asegurarse de queconectarLa instalación se registra en el espacio de nombres de la red actual.

    nft add table ip mytable
    nft add chain ip mytable mychain '{ type filter hook prerouting priority -150; policy accept; }'
    nft add rule ip mytable mychain ct state new
    

  • utilizar elconntrackherramienta para seguir eventos:

    conntrack -E
    

  • generar tráfico desde remoto

    NUEVOconectarLuego se crearán entradas para el tráfico que recibirá el enrutador, pero no para el tráfico enrutado.