SDA Connectivity Service

Descripción general

El SDA Connectivity Service se basa en el SDA Glue, la aplicación para Gateways, disponible para hosts Linux y Windows. El servicio funciona con SoftEther VPN, que admite OpenVPN en clientes Windows, estableciendo un túnel TCP seguro entre una interfaz de red del Gateway y los servicios en la nube de SDA, como IDEaaS, Backup y VMs de Deployment. También combina los firewalls nativos del sistema operativo, iptables de Linux y Windows Filtering Platform (WFP), con una tabla NAT para conectar software específico de proveedores, como Siemens TIA Portal y Rockwell Studio 500, directamente con el dispositivo en la capa de control de fabricación.

Puntos clave

La gestión de activos industriales con SDA se apoya en una solución de conectividad industrial integral y segura que salva la distancia entre los entornos de fabricación y los servicios basados en la nube. Al aprovechar tecnologías probadas e implementar medidas de seguridad robustas, el servicio ofrece una conectividad de nivel empresarial diseñada específicamente para sistemas de automatización y control industrial.

Seguridad de nivel industrial: la integración con AWS IoT Core proporciona conexiones TLS seguras con políticas de control de acceso de granularidad fina. Esto sigue las mejores prácticas de seguridad de IoT industrial, permitiendo a los administradores restringir el acceso en función de las propiedades y el contexto del dispositivo.

Base VPN probada: el servicio utiliza SoftEther VPN, que proporciona cifrado AES de 256 bits y RSA de 4096 bits con un rendimiento de alta velocidad y un bajo consumo de memoria y CPU, garantizando que los datos en tránsito permanezcan protegidos frente a escuchas y accesos no autorizados, ideal para aplicaciones industriales donde la seguridad y el rendimiento son críticos.

Acceso a la red de confianza cero: el servicio elimina la necesidad de VPNs estáticas tradicionales al establecer las conexiones bajo demanda. Esta arquitectura punto a punto garantiza que los usuarios solo puedan acceder a los dispositivos específicamente autorizados y no a segmentos de red completos, reduciendo significativamente la superficie de ataque.

Diseño compatible con la fábrica: todas las conexiones son iniciadas hacia el exterior por el propio nodo — un Gateway o una Workstation — nunca aceptadas de forma entrante, por lo que no se requieren nunca reglas de firewall de entrada. Este diseño respeta las arquitecturas de seguridad industrial existentes al tiempo que proporciona capacidades de acceso remoto seguro.

Arquitectura

Los pares de una red virtual se denominan Nodos y son los componentes principales del Connectivity Service. Cada conexión se construye a partir de la interacción de una cadena de Nodos, cada uno con un rol específico.

Devices: activos industriales normalmente ubicados en la red segura de fabricación a los que se puede acceder mediante su dirección IP, p. ej. PLCs, HMIs y robots. Los Devices se declaran en la SDA Console para cada Tenant y el acceso de los usuarios se gestiona mediante control de acceso basado en roles. La conectividad requiere que cada Device esté vinculado con al menos un Gateway de red.

Gateways: hosts de red con acceso seguro a Internet y a los Devices gestionados en la SDA Console. Suelen ser IPCs, VMs, contenedores e incluso Raspberry Pis, ubicados en una zona de firewall que requiere reglas específicas para acceder a los recursos de la nube de SDA, como los Tenant Servers. Cada Gateway ejecuta el SDA Glue, que es un servicio del sistema operativo que escucha las solicitudes de conexión y proporciona datos de telemetría.

Workstations: un PC propiedad del cliente, utilizado para acceder a dispositivos a través de un Gateway en el sitio de destino. Una Workstation ejecuta el mismo software SDA Glue que un Gateway y se configura de forma idéntica a nivel de red; la única diferencia es el rol — una Workstation siempre inicia la conexión hacia el exterior en dirección a un Gateway y nunca reenvía tráfico hacia otros dispositivos.

Tenant Servers: hosts bastión que se ejecutan en un entorno seguro de la nube de SDA, dedicados a cada Tenant, que conectan la interfaz de red del Gateway con una VM de servicio de SDA o con otro Gateway. Estos servidores garantizan las políticas de filtrado necesarias para asegurar únicamente conexiones punto a punto, como por ejemplo desde IDEaaS hacia un PLC específico y no hacia otros dispositivos no deseados de la misma red que el Gateway. También autentican el acceso de los Gateways en base a una política de rotación de credenciales para cada conexión.

Service VMs: ejecutan las aplicaciones necesarias para los servicios de SDA, como IDEaaS, Backup y pipelines de Deployment. Estas VMs se apoyan en el Connectivity Service para acceder a los Devices en la capa de red, mediante su dirección IP, lo cual es esencial para las aplicaciones industriales.

Nube

En lugar de utilizar VPNs estáticas tradicionales, el SDA Connectivity Service establece conexiones con los activos industriales bajo solicitud, las cuales se reenvían a una cadena de Nodos que operan conjuntamente para proporcionar acceso de red punto a punto entre los servicios de SDA y los Devices.

Para la red de fabricación, todas las conexiones se inician desde el Gateway, sin requerir reglas de conexión entrante en la fábrica. Para lograrlo, los Nodos escuchan constantemente en un broker de mensajes IoT las solicitudes entrantes, que funciona con AWS IoT Core.

Esta arquitectura permite a los usuarios interactuar con los activos de la fábrica desde cualquier lugar con Internet, desde cualquier ordenador, dependiendo únicamente del navegador.

Red

El Gateway es un dispositivo de borde situado entre una capa de control de fabricación e Internet, que proporciona a los servicios de SDA un acceso controlado a los activos definidos en la Console. Por tanto, es muy importante consolidar una arquitectura que conecte de forma segura la nube de SDA con la infraestructura local. Recomendamos una de las dos configuraciones propuestas para el Gateway, tal como se describe a continuación.

Gateway en LAN

Este es el enfoque más habitual, en el que colocamos el Gateway junto a los PLCs que se incorporan a la plataforma SDA. Aquí, un firewall controla estrictamente las conexiones salientes desde el Gateway hacia Internet.

El Gateway tiene acceso a la subred en la que se encuentra, pero puede provisionarse un firewall en el router de la red como capa de control de acceso (ACL). También es habitual utilizar un dispositivo Gateway con dos interfaces de red: una apuntando a la DMZ y una privada en la capa de control. Esta arquitectura permite zonas IP repetidas, p. ej., ambas con la subred 10.0.0.0/24.

Gateway en DMZ

Este enfoque se utiliza mucho cuando el Gateway se ejecuta en una máquina virtual dedicada, en algún punto de la infraestructura de servidores. El equipo de IT proporcionará rutas especiales entre la VM y los PLCs de destino en la capa de control y probablemente existirán firewalls tanto en el acceso a Internet como al OT.

peligro

También puede existir una traducción de direcciones de red (NAT) al descender hacia los PLCs. Sin embargo, esto requiere atención: algunos software específicos de proveedores de PLC pueden no ser compatibles con direccionar el PLC mediante un alias de IP; podrían requerir el acceso a la IP configurada explícitamente en el proyecto.

En este caso, cada PLC de la unidad de fabricación debe tener una dirección IP única; de lo contrario, pueden producirse colisiones. Además, según la infraestructura de red, el acceso de capa 2 desde los Gateways al PLC puede no funcionar, lo cual es una funcionalidad próxima para la integración de redes industriales en tiempo real en los servicios de SDA.

Software

El SDA Glue es una aplicación que se ejecuta como un servicio del sistema operativo, garantizando la alta disponibilidad del Gateway con arranque y reinicio automatizados en caso de errores. Para establecer los túneles de red gestionando recursos de red como interfaces, rutas y reglas de firewall, requiere elevación como usuario del sistema.

Las actualizaciones automáticas están habilitadas por defecto. El servicio Glue leerá la última versión estable desde repository.eu1.sdacosole.io y aplicará la actualización cuando no haya conexiones activas. El mecanismo de actualización descarga el nuevo binario de la aplicación, lo sustituye por el antiguo y reinicia el servicio.

AWS IoT Core se conectará durante el inicio de sesión, utilizando el endpoint iot.eu1.sdaconsole.io. Una vez conectado, el servicio Glue escuchará constantemente las solicitudes de la nube de SDA y publicará datos de telemetría, como el estado de los Devices asociados con el Gateway. La autenticación de IoT está protegida por un ID corto y una contraseña de un solo uso que se puede obtener desde la SDA Console. La conexión a IoT también se asegura mediante una clave secreta en el binario de la aplicación. La conexión a IoT puede configurarse para establecerse mediante MQTT SSL o WebSocket Secure, ambos en el puerto 443.

Los mecanismos de red son diferentes para Linux y Windows. Por tanto, se describen por separado.

Linux

SDA Glue en Linux se basa en el SoftEther VPN Client, que es de código abierto (Apache License 2.0), instalado desde el mirror de SDA en repository.eu1.sdaconsole.io durante la instalación de Glue.

Para cada conexión, Glue utiliza el SoftEther Client para crear una interfaz de red NIC y conectarla al Tenant Server. También utilizará las herramientas IP de Linux para asignar una dirección IP a esa interfaz y crear las rutas necesarias entre la Service VM y el Device de destino.

Las reglas de firewall internas y la traducción NAT se crean en iptables, que no permite paquetes de red entrantes al Gateway, sino únicamente el reenvío de paquetes al Device de destino.

📚 Gestión de recursos de Linux en las conexiones

Para entender cómo el Gateway Linux conecta los servicios en la nube con los dispositivos de la fábrica, veamos un ejemplo concreto con direcciones IP específicas que ilustran el flujo completo.

Consideremos una red de fábrica donde un Device de destino (como un PLC) tiene la dirección IP local 10.0.0.5 y el Gateway se encuentra en la misma red con la IP 10.0.0.2. En la nube de SDA, una Service VM necesita conectarse a este Device y se le asignará la IP VPN 100.112.20.3, mientras que la interfaz VPN del Gateway recibirá 100.112.10.6.

Establecimiento del túnel

Cuando llega una solicitud de conexión, tanto el Gateway como la Service VM entran en acción. El Gateway crea una nueva interfaz de red virtual llamada vpn_iface y le asigna la dirección 100.112.10.6. Simultáneamente, la Service VM en la nube crea su propia interfaz VPN con la IP 100.112.20.3. Ambos extremos se conectan entonces al Tenant Server, estableciendo un túnel cifrado seguro entre ellos.

Factory Side:              Cloud Side:
Gateway                    Service VM
├─ Local: 10.0.0.2        ├─ VPN: 100.112.20.3
└─ VPN: 100.112.10.6      └─ Target: 10.0.0.5 (via Gateway)
Device
└─ Local: 10.0.0.5

En este punto, el túnel existe, pero los paquetes aún no saben a dónde ir. El Gateway necesita enseñar al sistema cómo enrutar el tráfico entre estos dos mundos.

Construcción de las rutas

El Gateway añade una regla de enrutamiento que crea la conexión entre la red VPN y la planta de producción:

ip route add 100.112.20.3 via 100.112.10.6 dev vpn_iface

Esta ruta indica al sistema una información crucial: cuando el Device en 10.0.0.5 envíe paquetes de respuesta, estos deben reenviarse a través de vpn_iface para llegar a la Service VM en 100.112.20.3. Sin esta ruta, el Gateway no sabría cómo devolver las respuestas del Device a la nube.

Pero el enrutamiento por sí solo no es suficiente. El firewall del Gateway seguiría bloqueando este tráfico por defecto. Para habilitar la conexión, el Gateway debe permitir explícitamente el reenvío bidireccional de paquetes entre la VM y el Device:

iptables -A GLUE_FORWARD -s 100.112.20.3 -d 10.0.0.5 -j ACCEPT
iptables -A GLUE_FORWARD -s 10.0.0.5 -d 100.112.20.3 -j ACCEPT

Estas reglas abren una vía controlada, permitiendo que los paquetes fluyan desde la Service VM hacia el Device y de vuelta, manteniendo al mismo tiempo la postura de seguridad del Gateway para todo el resto del tráfico. Además, tenga en cuenta que Glue utiliza sus propias cadenas en iptables, para no provocar conflictos con las demás reglas.

Traducción NAT

El Device de la fábrica espera comunicarse con direcciones IP locales — no tiene conocimiento de la red en la nube en 100.112.20.3 y no sabría cómo responder a paquetes procedentes de esa dirección. El Gateway resuelve esto enmascarando los paquetes de la Service VM:

iptables -t nat -A GLUE_POSTROUTING -s 100.112.20.3 -d 10.0.0.5 -j MASQUERADE

Con esta regla NAT en su lugar, cuando llega un paquete desde la Service VM con destino al Device, el Gateway reescribe su dirección de origen de 100.112.20.3 a 10.0.0.2. Desde la perspectiva del Device, parece estar comunicándose directamente con el propio Gateway — una dirección familiar y confiable de su red local. Cuando el Device envía su respuesta a 10.0.0.2, el Gateway realiza la traducción inversa, cambiando la dirección de destino de nuevo a 100.112.20.3 para que el paquete llegue a la Service VM a través del túnel VPN.

Mediante esta orquestación de túneles VPN, enrutamiento, reglas de firewall y traducción NAT, el Gateway crea una conexión punto a punto transparente. El Device nunca ve la infraestructura en la nube — simplemente se comunica con lo que parece ser el Gateway en su red local en 10.0.0.2. Mientras tanto, la Service VM obtiene acceso directo a nivel de red al Device mediante su dirección IP 10.0.0.5, permitiendo que aplicaciones industriales como TIA Portal o Studio 5000 funcionen como si se estuvieran ejecutando en la propia red local de la fábrica.

Windows

SDA Glue en Windows no admite el uso integrado del SoftEther VPN Client, por lo que utiliza el OpenVPN Community Open-Source Client (licencia GPL versión 2), instalado desde el mirror de SDA en repository.eu1.sdaconsole.io durante la instalación de Glue.

Para cada conexión, Glue utiliza el driver TAP de OpenVPN para crear una interfaz de red y conectarla al Tenant Server mediante autenticación basada en certificados. Utiliza la API nativa de Windows para asignar una IP a la interfaz y crear las rutas necesarias entre la Service VM y el Device de destino.

Glue también utiliza Windows Filtering Platform (WFP) para crear capas y reglas de firewall dedicadas. Sin embargo, depende de WinNAT o NetNat para declarar la traducción de direcciones entre la Service VM y el Device, que puede no estar habilitada por defecto.

Workstation vs. Gateway: las Workstations y los Gateways utilizan el mismo cliente de Windows y la misma configuración de conexión descrita anteriormente — el mismo driver TAP de OpenVPN, el mismo direccionamiento de interfaz basado en WinNAT. La única diferencia es la regla de firewall WFP asignada por conexión según la política del backend: la conexión de una Workstation siempre recibe una regla exclusivamente de salida limitada a la IP del dispositivo de destino específico a través de la interfaz de túnel de SDA, mientras que un Gateway puede recibir además una regla de reenvío para transferir el tráfico hacia los dispositivos situados detrás de él. Por tanto, una Workstation nunca abre rutas entrantes ni de reenvío en el host, y ninguna otra interfaz de red, ruta o conexión VPN existente en ese PC se ve afectada — todos los cambios se limitan a la interfaz virtual que SDA Glue crea para su propio túnel.

Resumen

El SDA Connectivity Service ofrece una solución madura, segura y escalable para los retos de la conectividad industrial. Al combinar tecnologías de código abierto probadas como SoftEther VPN con una infraestructura en la nube de nivel empresarial de AWS IoT Core, el servicio proporciona la fiabilidad y la seguridad que requieren las operaciones industriales, al tiempo que ofrece la flexibilidad y la facilidad de uso que esperan los equipos de ingeniería modernos.

La arquitectura del servicio respeta los principios de seguridad industrial al mismo tiempo que habilita las iniciativas de transformación digital que impulsan la eficiencia operativa, la colaboración remota y la toma de decisiones basada en datos. Para las organizaciones que buscan conectar de forma segura sus activos industriales con servicios en la nube sin comprometer la seguridad de la red ni la fiabilidad operativa, el SDA Connectivity Service proporciona una solución integral y lista para producción.