Configurar y comprobar un grupo de conexiones SD-WAN en Sophos Fusion

Un grupo de conexiones SD-WAN permite a Sophos Fusion (antes Sophos Central) crear conexiones IPsec basadas en rutas entre varios firewalls administrados. Así se evita repetir gran parte de la configuración en topologías hub-and-spoke o full mesh. Sophos Fusion puede generar túneles, interfaces XFRM, rutas, objetos de red y, si se selecciona la opción, las reglas de firewall correspondientes.

La automatización no sustituye la planificación de la red ni la validación por parte del administrador. Un estado verde del grupo confirma principalmente que los firewalls participantes están conectados. No demuestra que un cliente concreto pueda acceder al destino remoto mediante la regla, la ruta y el tratamiento NAT esperados.

Ruta rápida hacia un grupo de conexiones funcional

Comprobar el rol Admin o Super Admin, SFOS 20.0 o posterior, la licencia Central Orchestration, la administración desde Sophos Fusion y la pertenencia de todos los firewalls a un grupo; en AWS o Azure debe utilizarse BYOL en lugar de PAYG.
Documentar las redes locales, direcciones WAN, condiciones NAT, redundancia y topología prevista.
Asegurarse de que los grupos de direcciones XFRM no se solapan con ninguna red de producción.
Crear un grupo en My Products > Firewall Management > SD-WAN Connection Groups.
Seleccionar los firewalls, recursos accesibles de forma compartida, servicios y, de forma opcional, la regla de firewall automática.
Resolver de forma individual cada conflicto de red y WAN que detecte Sophos Fusion.
Supervisar Tasks Queue y el estado del grupo hasta que se hayan procesado todos los firewalls participantes.
Comprobar los túneles, objetos Central_, direcciones XFRM, rutas y reglas en cada firewall.
Generar tráfico bidireccional real y comprobar Firewall Rule ID, ruta, NAT y ruta de retorno.
Añadir más recursos o firewalls solo después de completar la validación correctamente.

⚠️ No se debe eliminar sin control un grupo de conexiones existente ni anular el registro de un firewall en Sophos Fusion durante el funcionamiento normal. Al anular el registro, Sophos Fusion elimina el grupo de conexiones asociado y sus túneles generados automáticamente. Antes de estos cambios se necesita una copia de seguridad actual, una ventana de mantenimiento y una vía de recuperación documentada.

Qué crea Sophos Fusion automáticamente

Un grupo de conexiones SD-WAN utiliza VPN IPsec basada en rutas. En función de la topología, Sophos Fusion crea las conexiones y los objetos de configuración necesarios en los firewalls miembros. Los objetos generados automáticamente utilizan nombres con el prefijo Central_ en la configuración local. Entre ellos se incluyen conexiones IPsec, interfaces XFRM, objetos de red y rutas.

En una topología Hub-and-Spoke, se publican los recursos compartidos situados detrás del firewall hub. Normalmente, el hub responde como Remote Gateway a los túneles iniciados por los spokes. Esto resulta adecuado, por ejemplo, para una sede central con redes de servidores y varias sucursales. Los roles suelen derivarse de los recursos compartidos: el firewall que proporciona un recurso es el Responder. Existe una excepción cuando se utiliza una dirección WAN dinámica con una sobrescritura mediante comodín: en ese caso, el firewall que proporciona los recursos también sigue siendo Initiator; los requisitos se explican en el apartado Resolver conflictos de red y WAN.

En una topología Full Mesh, cuando ambos firewalls proporcionan recursos, Sophos Fusion asigna el Responder por orden alfabético del hostname. Si los nombres coinciden, utiliza el orden alfabético de los ID de firewall. Esto puede permitir trayectos directos entre sedes, pero crea muchos más túneles y dependencias. Por tanto, los hostnames deben ser estables y únicos; los roles no se eligen libremente para cada túnel.

La opción de crear reglas de firewall automáticamente es práctica, pero no sustituye la revisión de los orígenes, destinos y servicios permitidos. Si no se selecciona, las reglas necesarias deben existir localmente o en la política de grupo de Sophos Fusion correspondiente. Si se selecciona, también hay que comprobar el orden, el alcance y el registro de las reglas generadas. Los principios se explican en Planificar y crear reglas de firewall en Sophos Firewall.

Planificar la topología y los valores de ejemplo

Para ofrecer un ejemplo fácil de seguir, el grupo de conexiones enlaza tres firewalls:

FW-HQ comparte la red de servidores 10.10.0.0/16.
Detrás de FW-BE se encuentra la red de la sucursal 10.20.0.0/16, que debe acceder al recurso compartido.
Detrás de FW-ZH se encuentra la red de la sucursal 10.30.0.0/16, que también debe acceder a él.
Al principio solo se requieren HTTPS y RDP hacia sistemas seleccionados de la red de servidores.
El ejemplo utiliza hub-and-spoke con FW-HQ como hub.

Estos nombres y redes son únicamente valores de documentación. Deben sustituirse por los nombres reales de los firewalls, los recursos locales y los servicios. La planificación debe abarcar más que los solapamientos directos entre las tres sedes. También deben compararse las redes remotas de nube, socios, clientes VPN, RED y administración con los recursos y grupos de direcciones XFRM previstos.

Entender los grupos de direcciones XFRM

Sophos Fusion utiliza redes /30 para las interfaces XFRM. Si no se configura un grupo propio, Sophos Fusion utiliza de forma predeterminada 10.252.0.0/15 y 10.254.0.0/16. Si estas redes ya existen en el entorno, hay que elegir un grupo personalizado libre antes de la primera implementación. Pueden añadirse varios grupos; cuando se agota el primero, Sophos Fusion utiliza el siguiente.

La opción se encuentra en:

My Products > Firewall Management > SD-WAN Connection Groups > Add IP Pool

Un cambio del grupo de direcciones solo afecta a los grupos de conexiones nuevos. Los grupos existentes conservan sus direcciones XFRM asignadas. Por tanto, cambiar el grupo de direcciones no es una reparación retroactiva para un grupo de conexiones de producción.

Requisitos antes de la creación

El proceso de Orchestration descrito aquí requiere que todos los firewalls participantes ejecuten SFOS 20.0 o posterior, estén administrados desde Sophos Fusion y dispongan de una licencia Central Orchestration válida. El requisito mínimo anterior de SFOS 18.5 MR1 no implica que esa versión sea compatible con este proceso. Para Sophos Firewall en AWS o Azure se admite BYOL (Bring Your Own License); PAYG (Pay As You Go) no se admite para SD-WAN Orchestration. Por tanto, antes de incorporar un firewall en la nube se comprueban el modelo de despliegue y el de licencia, no solo la versión de SFOS.

Sophos Fusion exige el rol Admin o Super Admin para crear el grupo de firewalls requerido y acceder a su Policy. Cada grupo de conexiones necesita al menos dos firewalls que ya pertenezcan a un grupo de firewalls de Sophos Fusion. No se puede añadir un firewall registrado pero no asignado a un grupo.

Antes de crear el grupo, también se comprueba lo siguiente:

dirección IP pública o FQDN accesible para cada trayecto WAN
NAT delante de un firewall y el rol Initiator/Responder resultante
recursos locales únicos sin solapamientos
redes XFRM libres
enlaces WAN activos y gateways de respaldo previstos
servicios permitidos entre las sedes
configuraciones locales existentes de IPsec, enrutamiento, NAT y SD-WAN
acceso de administración independiente y una copia de seguridad actual de la configuración

Configurar una VPN IPsec de sitio a sitio en Sophos Firewall explica la estructura de una conexión individual basada en rutas. Sophos Fusion realiza muchos de estos pasos dentro de un grupo de conexiones, pero los requisitos subyacentes de enrutamiento, reglas y ruta de retorno siguen siendo los mismos.

Crear el grupo de conexiones en Sophos Fusion

Seleccionar firewalls y recursos

El proceso comienza en:

My Products > Firewall Management > SD-WAN Connection Groups > Create Connection Group

Se asigna al grupo un nombre inequívoco, por ejemplo HQ-Branches, y opcionalmente una descripción. A continuación se seleccionan al menos dos firewalls. Para cada uno se define qué dirección IP o rango de red estará disponible para las demás sedes como Shared resources. En el ejemplo solo FW-HQ comparte la red de servidores, lo que determina la distribución de roles hub-and-spoke.

Los recursos deben elegirse con el menor alcance posible. En lugar de compartir toda la red de la sede central, suele bastar con una red de servidores o aplicaciones. Del mismo modo, no conviene seleccionar Any por precaución en los servicios si solo se necesitan unas pocas aplicaciones.

Sophos Fusion puede crear reglas de firewall de forma opcional. También se tienen en cuenta los ajustes de usuarios autenticados y Security Heartbeat. Antes de guardar, se documenta si las reglas se generan automáticamente o se administran deliberadamente por separado. Así queda claro más adelante si una regla ausente es un error o una decisión de diseño.

Resolver conflictos de red y WAN

Sophos Fusion comprueba si existen conflictos en los recursos y las conexiones WAN seleccionados. Un conflicto no significa automáticamente que una red sea incorrecta. Indica que Sophos Fusion no puede generar una conexión inequívoca sin información adicional.

Según el resultado, se puede decidir, por ejemplo:

desactivar para esta conexión una subred solapada
asignar a la red una dirección NAT única
definir un objeto de red adicional
seleccionar el enlace WAN adecuado
definir un gateway de respaldo
sobrescribir manualmente la dirección detectada por Sophos Fusion

En el firewall que proporciona los recursos, el asistente solo permite activar o desactivar la red, no asignar NAT. Si se quiere seguir compartiendo la red solapada, primero debe resolverse el conflicto de direcciones en ese firewall o en el diseño de la red. Activarla sin más no resuelve el solapamiento. En el firewall que accede a los recursos, se puede utilizar la opción NAT para resolver el conflicto. Por tanto, antes de guardar se comprueba, para cada red solapada, qué firewall la proporciona, cuál accede a ella y si la medida elegida elimina realmente el conflicto. Si se excluye una red en lugar de resolver el conflicto, no estará disponible a través de este grupo de conexiones.

Cada decisión cambia la ruta de datos resultante. Por eso las direcciones NAT, las sobrescrituras WAN y las redes desactivadas se documentan en un plan de direccionamiento y enrutamiento, en lugar de configurarse solo hasta que el estado se vuelva verde.

Un comodín * en el campo Public IP or FQDN for selected WAN link solo está permitido cuando el firewall del gateway remoto actúa como Responder y ejecuta al menos SFOS 20.0. En un firewall que proporciona recursos con una dirección WAN dinámica y una sobrescritura mediante comodín, este firewall sigue siendo Initiator y utiliza el perfil IPsec Central_DefaultBranchOffice. El extremo remoto debe actuar como Responder y ejecutar SFOS 20.0 o posterior. Por tanto, compartir recursos no convierte por sí solo al firewall dinámico en Responder en este caso.

Antes de establecer *, se documentan para cada trayecto WAN el firewall local dinámico, su rol Initiator y el extremo remoto Responder accesible, incluida su versión de SFOS. Tras el despliegue, se comprueba en las conexiones IPsec generadas que los roles, el perfil y la asignación WAN coincidan con este plan, y se verifica el trayecto hacia los recursos con tráfico real de aplicaciones. El comodín no debe utilizarse para ocultar una situación WAN o NAT sin resolver. El Initiator, la accesibilidad pública y la identidad del peer deben seguir siendo inequívocos; los perfiles generados centralmente no se modifican de forma indiscriminada en la configuración local.

Guardar el grupo y supervisar las tareas

Después de guardar, Sophos Fusion crea las tareas necesarias para todos los firewalls participantes. Durante el proceso se mantiene abierta la sesión administrativa existente en al menos un firewall. En Sophos Fusion se comprueban el estado y los detalles del grupo de conexiones, así como:

My Products > Firewall Management > Tasks Queue

No se deben omitir sin más los estados Pending, Failed o Partial Success. Se documentan el firewall, Entity, el mensaje de error y la hora, y se comparan con la configuración local. Comprobar Sophos Fusion Firewall Tasks Queue explica en detalle Retry, Skip, Force Sync y la validación local.

Tras finalizar las tareas, también se comprueba el estado del túnel: GOOD significa que el túnel VPN está establecido; DOWN, que no está establecido o ha perdido la conexión. En cambio, UNKNOWN significa que no se ha recibido información de Heartbeat desde hace aproximadamente cinco minutos y que Sophos Fusion no puede determinar el estado del túnel. Esto no demuestra ni un fallo del túnel ni una validación correcta. Para autorizar la puesta en producción, los túneles esperados deben indicar GOOD y superar las siguientes comprobaciones locales.

Comprobar localmente la configuración generada automáticamente

Después de una tarea de Sophos Fusion correcta, se abre por separado cada firewall participante. Se comprueba lo siguiente:

En Site-to-site VPN > IPsec están activas las conexiones de Sophos Fusion esperadas.
En Network > Interfaces las interfaces XFRM tienen direcciones /30 únicas del grupo de direcciones previsto.
En Routing las rutas generadas apuntan a la interfaz XFRM esperada.
Los objetos de red, host y servicio con Central_ coinciden con los recursos compartidos.
Las reglas de firewall creadas automáticamente o por separado solo permiten los orígenes, destinos y servicios previstos.
NAT solo se aplica donde se haya elegido deliberadamente para resolver un conflicto.
Si hay varios trayectos WAN, el estado de gateway y SD-WAN coincide con la selección primaria y de respaldo prevista.

Si un grupo contiene Shared resources y Participating networks, el firewall crea dos rutas SD-WAN similares: una para los recursos compartidos y otra para las redes participantes. Es el comportamiento de despliegue esperado, no un duplicado que deba eliminarse localmente de forma precipitada.

Sophos Fusion administra los objetos generados. Los cambios locales manuales en objetos Central_ pueden sobrescribirse en una modificación posterior del grupo o provocar incoherencias. Por tanto, los cambios deben realizarse en el diseño del grupo de conexiones o en la Policy de Sophos Fusion correspondiente.

Validar con tráfico real

En la primera validación se realiza al menos una prueba real para cada trayecto de recursos compartidos. En el ejemplo, un cliente de 10.20.0.0/16 se conecta por HTTPS a un servidor expresamente permitido en 10.10.0.0/16; después se realiza una prueba desde 10.30.0.0/16.

En ambos lados se comprueba:

IKE y Child SA activas
Firewall Rule ID correcta
interfaces de entrada y salida en Packet Capture
direcciones de origen y destino esperadas después de una traducción NAT deliberada
ruta de ida y retorno
resultado de la aplicación, no solo un ping

Un túnel o estado de grupo verde es solo un resultado intermedio. Probar una regla de Sophos Firewall explica la validación completa con Log Viewer, Policy Test y Packet Capture.

Añadir perfiles SD-WAN y redundancia

Las siguientes versiones mínimas corresponden a funciones concretas de los perfiles y no sustituyen el requisito de SFOS 20.0 o posterior para el proceso de Orchestration descrito aquí.

Sophos Fusion admite perfiles SD-WAN para grupos de conexiones desde SFOS 19.0. La estrategia de enrutamiento está disponible desde SFOS 19.5. Sophos Fusion crea automáticamente el gateway del túnel VPN; como respaldo se selecciona un gateway que ya exista en el firewall. El perfil puede utilizar First available gateway o Load balancing; el balanceo ofrece Round-robin y varios tipos de persistencia de sesión. No sustituye una ruta correcta ni una conexión VPN individual funcional.

La dirección XFRM debe estar en una red /30. De lo contrario, Sophos Fusion muestra Migrate y, durante la migración, asigna todas las direcciones de túnel desde 10.252.0.0/15 y 10.254.0.0/16. La migración y cada cambio de perfil modifican la ruta de datos: conservar primero una copia de seguridad y acceso fuera de banda, cambiar una sola sede o trayecto en una ventana de mantenimiento, verificar las tareas de Sophos Fusion y la configuración local y solo entonces ampliar el despliegue.

Antes de activar un perfil se prueba cada trayecto WAN y de túnel por separado. Después se comprueba con tráfico real que las conexiones nuevas utilicen el trayecto previsto y cambien según lo previsto en caso de un fallo planificado. Los Health Checks utilizan Ping o TCP y un máximo de dos Probe Targets detrás del gateway. Si un Probe Target es una dirección IP pública, el firewall de destino necesita una regla de la zona VPN a la zona WAN. Si ningún gateway cumple el Custom SLA, el firewall utiliza la estrategia First available gateway. Por tanto, este comportamiento se comprueba mediante una prueba de failover planificada.

La lógica de enrutamiento local, los valores SLA y la validación del failover se explican en Configurar una ruta SD-WAN en Sophos Firewall. Sophos Fusion simplifica la distribución, pero no cambia el significado de gateway, Route Precedence, NAT ni el comportamiento de las sesiones.

Solucionar problemas por síntoma

No se puede seleccionar un firewall

Comprobar el registro en Sophos Fusion, la licencia válida o la autorización de Orchestration y la pertenencia a un grupo de firewalls de Sophos Fusion. Después, verificar si una tarea de grupo o sincronización pendiente bloquea el cambio.

Una tarea ha fallado o solo ha tenido éxito parcialmente

No se debe volver a crear el grupo de inmediato. Primero se conservan los detalles de la tarea y la configuración local parcial. Las causas habituales son conflictos de objetos o redes, firewalls inaccesibles, restricciones de licencia o una política de grupo que no pudo aplicarse por completo. Solo se repite la operación afectada después de corregir la causa.

El estado del túnel es UNKNOWN

Primero se comprueban la conexión con Sophos Fusion, Heartbeat y el estado de sincronización de los firewalls afectados, así como Tasks Queue. En paralelo, mediante el acceso de administración independiente, se comprueba el estado local del túnel en Site-to-site VPN > IPsec y se ejecuta la prueba de aplicación documentada. Si el túnel local y el tráfico de aplicaciones funcionan, lo que falta inicialmente es la confirmación central del estado; no se elimina ni se vuelve a crear el grupo solo por UNKNOWN. Si la conexión también falla localmente, se comprueban la accesibilidad WAN, IKE/Child SA y la ruta de datos. Tras restablecer la transmisión de Heartbeat, se vuelve a comprobar si Sophos Fusion indica GOOD. Si UNKNOWN persiste pese a que la conexión funciona correctamente, se conservan el estado, las horas y los detalles de las tareas para continuar el análisis del problema.

El túnel está activo, pero falta el tráfico de aplicaciones

Comparar Shared resources, la selección de servicios y la regla de firewall con el flujo real. A continuación comprobar la ruta, la interfaz XFRM, NAT, Route Precedence y la ruta de retorno. Un ping solo es significativo si ICMP está realmente permitido y el destino está previsto para ello.

Solo funciona un trayecto WAN o de respaldo

Comprobar la dirección pública o el FQDN, NAT delante del firewall, el rol del gateway, el enlace WAN y el gateway de respaldo. En un perfil SD-WAN, continuar con el destino SLA y el estado del gateway. Una dirección con comodín o un túnel verde no deben ocultar la falta de accesibilidad de extremo a extremo.

Un cambio del grupo de direcciones no aparece en el grupo de conexiones

Este comportamiento es normal en los grupos de conexiones existentes. Los nuevos grupos de IP solo se utilizan en grupos de conexiones creados posteriormente. No se debe eliminar y volver a crear un grupo de producción solo para cambiar el direccionamiento; primero se planifican el impacto, el tiempo de inactividad y la reversión.

Sophos Fusion aparece en verde, pero la aplicación sigue sin funcionar

El estado del grupo no se interpreta como monitorización de aplicaciones. Se comprueban simultáneamente los registros, Rule IDs, Packet Capture, la ruta y NAT en ambos firewalls. En HA o con tráfico distribuido, se tiene en cuenta el nodo que procesó el tráfico de prueba.

Realizar cambios y revertir de forma segura

Antes de realizar cambios importantes en el grupo, se documentan la configuración del grupo de conexiones, los firewalls miembros, Shared resources, la asignación WAN, el grupo de direcciones XFRM, las reglas generadas automáticamente y un flujo de prueba funcional. También se conserva una copia de seguridad actual del firewall.

Cuándo una actualización vuelve a generar objetos

Una ampliación añade, en principio, la configuración necesaria; los túneles, rutas y reglas de firewall existentes se mantienen mientras no se vean afectados sus criterios de creación. Por tanto, añadir una sucursal no implica automáticamente volver a crear todas las conexiones existentes. Sin embargo, si se cambian las condiciones de las reglas de firewall, reglas NAT o rutas SD-WAN administradas centralmente, Sophos Fusion elimina los objetos afectados y los vuelve a crear. Esto incluye cambios en:

redes de origen locales o permitidas;
Shared resources o redes de destino;
servicios y puertos;
condiciones de usuario o Security Heartbeat;
NAT para resolver subredes solapadas;
gateways de respaldo o la asignación de rutas SD-WAN a gateways.

Por ejemplo, si en el diseño existente HQ-Branches se cambia el acceso permitido de HTTPS a otro servicio, esto puede provocar que se vuelvan a generar las reglas de acceso y rutas afectadas; no se trata únicamente de cambiar el texto de la descripción. Por tanto, antes de guardar se comparan las redes de origen, destinos, servicios y trayectos afectados con el flujo de prueba anterior. Los cambios que regeneran objetos se planifican en una ventana de mantenimiento, teniendo en cuenta una posible interrupción; que un túnel no cambie no garantiza por sí solo que el acceso siga siendo adecuado.

En cada iteración se guarda un único cambio de Orchestration. Mientras Sophos Fusion crea, actualiza o elimina el grupo, no se realizan cambios paralelos en interfaces, WAN, LAN o redes de los firewalls. Tras finalizar las tareas, se vuelven a comprobar las reglas Central_ recién generadas, las asignaciones NAT y las rutas en los firewalls afectados, se identifica la Firewall Rule ID utilizada actualmente y se repiten tanto la prueba de aplicación anterior como la modificada. Si cambia la asignación de gateway, también se comprueba el trayecto de respaldo. Las correcciones o eliminaciones locales de objetos Central_ no son una vía de recuperación: el cambio deseado se realiza en el grupo de conexiones.

Revertir una ampliación o eliminar el grupo

Si falla una ampliación, no se elimina de forma automática todo el grupo. Primero se revierte en el asistente solo el recurso o firewall recién añadido, o el cambio de perfil. A continuación se espera a que finalicen las tareas de Sophos Fusion y se comprueba que los túneles, rutas, reglas y el flujo de prueba documentado anteriormente vuelvan a coincidir con el estado inicial. Solo ese resultado confirma la reversión; guardar el cambio no basta.

Si hay que eliminar por completo el grupo de conexiones, se hace durante una ventana de mantenimiento. Antes deben estar preparados trayectos alternativos entre sedes o túneles administrados manualmente. Tras la eliminación se comprueba en cada firewall que se hayan retirado los objetos Central_ asociados y que no queden reglas, rutas o dependencias NAT huérfanas.

Lista de comprobación para la puesta en producción

Todos los firewalls utilizan SFOS 20.0 o posterior, están administrados desde Sophos Fusion, tienen licencia y pertenecen a un grupo de firewalls; los firewalls de AWS/Azure utilizan BYOL.
Los recursos, servicios, trayectos WAN y redes XFRM están documentados y no se solapan.
Cada conflicto detectado se ha resuelto de forma deliberada.
Todas las tareas de Sophos Fusion han finalizado con un resultado documentado.
Los túneles esperados indican GOOD; cualquier UNKNOWN se ha aclarado y no se ha considerado una prueba de túnel satisfactoria.
Los túneles, interfaces XFRM, rutas, reglas y objetos Central_ se han comprobado localmente.
Una prueba bidireccional real de la aplicación funciona en cada trayecto entre sedes.
Los trayectos primario y de respaldo se han validado durante una ventana de mantenimiento.
La copia de seguridad, el acceso de administración y la vía de recuperación están documentados.

Preguntas frecuentes

¿Sustituye un grupo de conexiones los conocimientos locales de IPsec y enrutamiento?

No. Sophos Fusion automatiza la creación repetida, pero la ruta de datos sigue siendo IPsec basada en rutas con interfaces XFRM, rutas, reglas de firewall y, en algunos casos, NAT. Estas capas deben seguir entendiéndose para solucionar problemas y validar el funcionamiento.

¿Qué demuestra un estado verde en Sophos Fusion?

Según Sophos Fusion, verde significa que todos los firewalls del grupo de conexiones están activos. Naranja indica que al menos uno está inactivo y rojo que todos lo están. Esta vista de los túneles no demuestra que todos los recursos sean accesibles mediante todas las reglas y aplicaciones. Para ello se necesitan comprobaciones locales y conexiones de prueba reales.

¿Qué ocurre al anular el registro de un firewall?

Sophos Fusion elimina el grupo de conexiones asociado y los túneles que ha creado. Por tanto, no se debe anular y volver a registrar un firewall como medida rutinaria de solución de problemas. Este cambio debe realizarse en una ventana de mantenimiento, con una copia de seguridad y un trayecto de sustitución preparado.