Cómo configurar el enrutamiento basado en políticas para separar el tráfico de copias de seguridad y de usuarios

Eva Wong es la Redactora técnica y manitas residente en ZimaSpace. Una geek de toda la vida con pasión por los homelabs y el software de código abierto, se especializa en traducir conceptos técnicos complejos en guías accesibles y prácticas. Eva cree que el autoalojamiento debe ser divertido, no intimidante. A través de sus tutoriales, empodera a la comunidad para desmitificar las configuraciones de hardware, desde construir su primer NAS hasta dominar los contenedores Docker.

Separa el tráfico de las copias de seguridad con una dirección de origen explícita o una marca de paquete, una tabla de enrutamiento dedicada y una regla con un alcance limitado. No reemplaces la ruta predeterminada principal ni supongas que las métricas de interfaz pueden clasificar dos cargas de trabajo del mismo host.

Este diseño es útil cuando los usuarios interactivos necesitan el enlace ascendente rápido o de baja latencia, mientras que las copias de seguridad programadas utilizan una puerta de enlace secundaria. El riesgo es el enrutamiento asimétrico: las respuestas salen por una interfaz distinta de aquella por la que llegó la solicitud, lo que puede hacer que los firewalls con estado o los pares remotos rechacen la sesión. Mantén el acceso a la consola, registra las reglas originales y crea la ruta alternativa antes de dirigir el tráfico hacia ella.

Elige un clasificador estable

Usa una IP de origen dedicada cuando el servicio de copias de seguridad pueda vincularse a una dirección. Es más fácil de inspeccionar y resiste mejor los reinicios del servicio que las reglas basadas en direcciones de destino cambiantes.

Si ambas cargas de trabajo comparten una dirección, clasifica las conexiones de copia de seguridad con una marca de firewall y conserva esa marca para la conexión. El enrutamiento basado en políticas de Linux evalúa las reglas antes de consultar la tabla seleccionada; por tanto, la base de datos de políticas de enrutamiento es la capa de decisión, mientras que cada tabla contiene las rutas.

No clasifiques únicamente según el rango de IP de un proveedor de nube, a menos que controles y mantengas esa lista. Si ningún origen, destino, puerto, usuario o espacio de nombres estable identifica el flujo de copia de seguridad, detente y separa primero la carga de trabajo en el nivel del contenedor o de la interfaz de red.

Crea la tabla de copias de seguridad antes de añadir su regla

Crea una tabla con nombre que contenga la ruta de la subred conectada y la ruta predeterminada de la puerta de enlace de copias de seguridad. Sin la ruta conectada, es posible que la propia puerta de enlace no sea accesible aunque la entrada predeterminada parezca correcta.

Consulta la decisión propuesta con una búsqueda de ruta que proporcione la misma dirección de origen o marca que utilizará el servicio. Un resultado que muestre la interfaz de copias de seguridad y el origen esperado indica que todo está correcto; si la búsqueda recurre a la tabla principal, el clasificador o la prioridad son incorrectos.

Añade la regla específica con una prioridad que preceda a la regla genérica de la tabla principal, pero que no anule las rutas locales. Mantén un comando de reversión explícito en la misma sesión de terminal y nunca realices la primera prueba a través de la ruta que estás modificando.

Conserva la simetría de las respuestas y el acceso local

Confirma que el enrutador ascendente sabe cómo devolver el tráfico a la red de origen seleccionada, o aplica NAT de origen únicamente en el límite de salida correcto. Una regla de políticas puede elegir una ruta de salida, pero no puede hacer que una puerta de enlace remota entienda una subred privada desconocida.

Comprueba el filtrado de rutas inversas cuando las respuestas válidas llegan por una interfaz que Linux no seleccionaría usando la tabla principal. Utiliza un modo adecuado para el diseño multihomed en lugar de desactivar la validación globalmente, y verifica la elección mediante capturas de paquetes en ambas interfaces.

Mantén el tráfico de administración, DNS y LAN en la tabla principal, a menos que la separación requiera lo contrario. La guía de ZimaSpace sobre el uso fiable de recursos compartidos de red es un complemento útil cuando la copia de seguridad enrutada también depende de una ruta de almacenamiento montada.

-15% OFF

Prueba tanto los fallos como el funcionamiento correcto

Inicia una transferencia interactiva y una copia de seguridad, y después inspecciona los contadores de las interfaces y el estado de las conexiones. Los bytes de la copia de seguridad deberían aumentar únicamente en la salida de copias de seguridad, mientras la sesión del usuario permanece en la ruta principal.

Bloquea o desconecta temporalmente la puerta de enlace de copias de seguridad durante un intervalo controlado. Si el diseño debe cerrarse ante fallos, la copia de seguridad debería detenerse sin migrar silenciosamente al enlace del usuario; si se pretende realizar una conmutación por error, documenta ese comportamiento y limita su ancho de banda.

Reinicia una vez y repite la carga de trabajo simultánea original para demostrar que el orden de las reglas y las marcas persisten. Detente cuando las búsquedas, las capturas de paquetes y los registros de la aplicación coincidan; revierte los cambios si el acceso de administración cambia, las respuestas se vuelven asimétricas o tráfico no relacionado entra en la tabla de copias de seguridad.

Soporte y Consejos

Más para leer

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.