¿Qué modo de Sophos RED encaja en la red de tu sucursal?
RED es un rol de sede remota, no un protocolo. Elige Standard/Unified, Standard/Split o Transparent/Split según quién posee la puerta de enlace de la sucursal y el DHCP.
Sophos RED es un rol de sede remota y no un protocolo VPN, por eso compararlo con IPsec o OpenVPN responde a la pregunta equivocada. El dispositivo extiende el control de un cortafuegos central hacia una sucursal, y el modo que elijas decide quién proporciona la puerta de enlace de la sucursal, quién reparte direcciones y qué tráfico cruza el túnel. Esas tres respuestas pesan más que los nombres de los modos. Escribirlas primero convierte una elección de producto en una decisión de diseño.
RED es un rol, no un protocolo
Un dispositivo RED une una sucursal a un Sophos Firewall central, y la configuración del cortafuegos define en qué se convierte la sucursal. El túnel es un detalle de implementación de esa unión, no un extremo de VPN de propósito general que puedas apuntar a cualquier par.
Ese planteamiento importa porque un RED no es intercambiable con un par IPsec arbitrario. Espera que el cortafuegos central lo gestione, y los modos admitidos describen cuánta parte de la sucursal asume. Tratarlo como un extremo de túnel corriente crea expectativas que el producto nunca prometió. Tratarlo como un rol produce las preguntas que de verdad deciden el diseño.
Las tres condiciones siguientes cambian la respuesta, y todas tratan de propiedad, no de cifrado.
Tres condiciones que eligen el modo
Pregunta quién posee la puerta de enlace de la sucursal, quién gestiona DHCP y DNS para los clientes de la sucursal y si la salida local a internet debe sobrevivir a una caída del túnel.
Standard/Unified responde a las tres igual: el cortafuegos central posee la LAN de la sucursal, incluidas las tareas de puerta de enlace y DHCP, y el tráfico cruza el túnel. Standard/Split mantiene la gestión central y envía por el túnel solo las redes configuradas. Transparent/Split deja que la red de sucursal existente se encargue de su propia puerta de enlace y sus direcciones, y redirige al túnel solo el tráfico seleccionado. Tres modos, tres propietarios distintos.
| Mode | Branch gateway and DHCP | Traffic through the tunnel |
|---|---|---|
| Standard/Unified | Central firewall owns both | All branch traffic |
| Standard/Split | Central firewall owns both | Only the configured networks |
| Transparent/Split | The existing branch router keeps both | Only the selected flows |
Lee primero la columna central, porque decide cuánta parte de la sucursal sigue funcionando cuando el túnel no está.
Quién posee la puerta de enlace de la sucursal y el DHCP
En la disposición unificada la sucursal no tiene una puerta de enlace independiente, lo que simplifica la configuración y concentra el fallo. Esa concentración está bien cuando la sucursal es pequeña y el cortafuegos central tiene alta disponibilidad.
En un despliegue transparente la sucursal conserva su enrutador y el RED se sitúa en línea para redirigir tráfico seleccionado. Eso preserva el control local y añade un dispositivo cuya posición en la ruta ahora importa para cada flujo redirigido. Documenta dónde está, porque un cambio posterior en el enrutador de la sucursal puede saltárselo sin avisar. Ninguna de las dos disposiciones gana en general; reparten la responsabilidad de forma distinta.
La propiedad de las direcciones es la parte que hay que escribir, porque dos servidores DHCP en un mismo segmento producen fallos intermitentes que se reportan como problemas de VPN.
Qué ocurre cuando cae el túnel
El funcionamiento en Split se lee a menudo como una promesa de que internet local sigue funcionando durante un fallo del túnel, y esa lectura no es segura. El comportamiento exacto depende del modo elegido, del firmware y del dispositivo, así que pertenece a los criterios de aceptación y no a una suposición.
Decide qué debe seguir haciendo la sucursal sin túnel: alcanzar impresoras locales, resolver nombres, cobrar pagos o nada en absoluto. Después prueba ese estado a propósito bloqueando el túnel y observando la sucursal. Una sucursal que pierde DNS en silencio es peor que una que falla ruidosamente, porque la llamada al soporte llega horas después. Escribe el resultado observado en el registro de diseño.
La dependencia central es la misma en todos los modos: alguien debe poseer la ruta de recuperación del propio dispositivo.
Escribe el contrato de sucursal antes de desplegar
Un contrato de sucursal cabe en una página: propietarios, fuentes de direcciones, prefijos tunelizados, política de salida y el comportamiento en caída que has aceptado.
Luego verifica el resultado desplegado y no el previsto. Comprueba la dirección del cliente de la sucursal, su puerta de enlace predeterminada, qué prefijos se resuelven por el túnel y qué sigue respondiendo cuando el túnel está bloqueado. Compatibilidad, accesibilidad y licenciamiento necesitan todos una comprobación contra la documentación actual del fabricante para el modelo exacto, porque un nombre de producto no garantiza un modo. Guarda esa página con el registro del dispositivo para que el siguiente ingeniero herede las decisiones y no el diagrama.
ip -br addr
ip route
traceroute -n 10.80.4.10
dig +short intranet.corp.exampleRepite ese bloque con el túnel bloqueado, y la diferencia entre las dos ejecuciones es el comportamiento en caída que realmente has comprado.