¿La aceleración NAT por hardware rompe tus reglas de enrutamiento de VPN?

Activar la aceleración NAT por hardware puede hacer más rápida una configuración de VPN, y también puede hacer que una política de enrutamiento deje de aplicarse a algunos paquetes sin ningún error. Cuál de las dos cosas ocurre depende de lo que se salte la ruta rápida, y eso varía entre el firmware, la versión del kernel y el tipo de aceleración empleado. El menú de ajustes rara vez te dice cuál acabas de activar.

Dos afirmaciones merecen separarse antes de culpar al acelerador: que una regla dejó de aplicarse y que un contador dejó de actualizarse. No son la misma observación.

Tres aceleraciones distintas se mezclan

La descarga de reenvío, la aceleración criptográfica y la descarga del canal de datos del túnel son mecanismos separados que a menudo comparten un solo conmutador. La descarga de reenvío permite que los flujos establecidos se salten parte de la pila normal, la aceleración criptográfica abarata el trabajo de cifrado y la descarga del túnel lleva la encapsulación al hardware. Un enrutador que acelera el tráfico enrutado ordinario puede dejar el tráfico del túnel por completo en la ruta lenta, lo que es un resultado de rendimiento y no un cambio de política. También existe el caso inverso, en el que el tráfico del túnel se descarga mientras la política circundante todavía se evalúa.

Las flowtables de Linux son el caso documentado que más vale la pena leer, ya que los flujos establecidos pueden entregarse a una ruta rápida. Su contabilidad y gestión de estado difieren entonces del reenvío clásico, y por eso los contadores empiezan a parecer extraños.

Un contador que deja de moverse demuestra poco

Los contadores de reglas cuentan los paquetes que pasan por la regla, y un flujo descargado puede no volver a pasar por ella nunca después del primer paquete. Eso produce un contador que se congela mientras el tráfico continúa, y parece exactamente un bypass si confías en el número. Vigilar el contador sigue siendo útil como indicio de que el flujo abandonó la ruta contada. El resto del diagnóstico tiene que venir de adónde van realmente los paquetes.

La inferencia opuesta falla igual de mal. Una descarga rápida no demuestra que tus reglas de excepción y el tratamiento de fallos sigan aplicándose, porque ejercita un flujo y no la política.

Tres condiciones deciden si la descarga rompe la política

La primera condición es si la ruta rápida consulta el gancho del que depende tu política, ya que una política expresada como marcas y rutas sobrevive más a menudo que una construida con filtrado por paquete. La segunda es si el firmware permite siquiera esa combinación, porque algunas compilaciones desactivan la descarga automáticamente cuando hay un túnel o una función de cortafuegos activa. La tercera es si el tráfico es elegible, ya que la aceleración suele vincularse a flujos establecidos y puede excluir paquetes fragmentados o inusuales. Donde las tres favorecen la aceleración, la política sigue aplicándose, y donde falla la primera, ninguna cantidad de ajuste la restaura.

Lee la documentación del fabricante para la combinación que ejecutas, no para el modelo de enrutador en general. Las versiones de firmware cambian estas respuestas en silencio.

Prueba la política, no el rendimiento

Mide qué debe garantizar la política antes de medir lo rápida que es. Los comandos siguientes muestran si hay una flowtable instalada, qué ve el seguimiento de conexiones y desde qué dirección sale el cliente. Compara una conexión nueva después del cambio, ya que una establecida puede conservar su ruta antigua.

nft list flowtables
conntrack -L | head -n 20
curl -sS --max-time 8 https://api.ipify.org; echo
ping -c 3 192.168.50.20

Una entrada de flowtable que cubre el tráfico del túnel te dice que la ruta rápida está en juego, y la tabla de conexiones muestra si el flujo se rastrea como esperas. La comprobación de dirección confirma la salida cuando la política afecta al acceso a internet, mientras que el ping confirma un destino privado que debe seguir siendo alcanzable. Ejecuta el mismo conjunto con la aceleración desactivada y luego activada, y compara los resultados en lugar de los tiempos.

Anota la configuración anterior para que el experimento siga siendo reversible. Una instrucción genérica de desactivar la descarga en todas partes cuenta como un apaño, no como un hallazgo.