¿Qué es el cruce de NAT para gateways SCADA remotos?
Un host de SCADA que espera sondear un gateway remoto necesita poder abrir una conexión hacia él, pero un gateway en un enlace celular por lo general se asienta detrás de un NAT de grado portadora sin dirección pública propia, así que no hay a dónde pueda aterrizar un sondeo entrante. El cruce de NAT es el conjunto de técnicas que rodean esto, dejando a un sistema central alcanzar un dispositivo que no puede alcanzarse de forma directa. Esta guía explica por qué el NAT de grado portadora bloquea las conexiones entrantes, y cómo los diseños iniciados hacia afuera y los túneles inversos resuelven el problema de la ausencia de IP pública para los gateways SCADA remotos en enlaces celulares.
Cruce de NAT en una línea: El cruce de NAT es cómo un sistema SCADA central se comunica con un gateway remoto que no tiene IP pública alcanzable porque se asienta detrás de un NAT de grado portadora. Como las conexiones entrantes hacia tal dispositivo fallan, las soluciones estándar hacen que el gateway inicie la conexión hacia afuera al host, o mantenga un túnel inverso que abrió él mismo, para que los datos puedan fluir en ambos sentidos por una ruta que el gateway estableció. Esto reemplaza el modelo tradicional del host sondeando hacia adentro.
Por qué el NAT de grado portadora bloquea los sondeos entrantes
En la mayoría de las conexiones de datos celulares el dispositivo no obtiene su propia dirección IP pública. En cambio, la portadora coloca a muchos suscriptores detrás de un NAT de grado portadora, o CGNAT, que comparte un pool de direcciones públicas entre muchos dispositivos y traduce sus direcciones privadas en el camino hacia afuera. Esto funciona bien para que el dispositivo alcance internet, porque el NAT recuerda cada conexión saliente y envía las respuestas de vuelta al dispositivo correcto. Pero desde afuera, el dispositivo no tiene dirección que nadie pueda marcar; simplemente no hay una IP pública que mapee a ese gateway específico para una conexión entrante no solicitada.
Esto rompe directamente el modelo tradicional de sondeo de SCADA. Clásicamente un maestro central abriría conexiones hacia afuera a cada unidad terminal remota, la sondearía por datos y leería la respuesta, lo que asume que el maestro puede alcanzar el dispositivo remoto en una dirección conocida. Detrás del CGNAT esa suposición falla: el intento de conexión del maestro no tiene a dónde ir, porque el NAT sólo reenvía tráfico que corresponde a una conexión que el dispositivo mismo inició. Un sondeo entrante a un gateway oculto por CGNAT no lo alcanza, así que un diseño que se apoya en que el host alcance hacia adentro simplemente no funcionará sobre tal enlace.
Vale la pena separar esto del tema general de atravesar cortafuegos. Un cortafuegos podría bloquear las conexiones entrantes por política, y hay formas de abrir o hacer túnel a través de él; el CGNAT es un obstáculo distinto, porque el problema no es una decisión de política de bloquear sino la ausencia de cualquier dirección que alcanzar en primer lugar. Aun sin ninguna regla de cortafuegos en el camino, un dispositivo detrás de CGNAT no tiene IP pública para que una conexión entrante apunte. Ese es el problema específico que el cruce de NAT para gateways SCADA celulares tiene que resolver.
Patrones iniciados hacia afuera y de túnel inverso
La solución limpia voltea la dirección de quién se conecta con quién. Como el CGNAT reenvía con gusto el tráfico para las conexiones que el dispositivo inició, se hace que el gateway inicie la conexión hacia afuera al sistema central en lugar de esperar a ser sondeado. Una vez que esa conexión saliente está abierta, es bidireccional: el gateway envía su telemetría por ella, y el sistema central envía comandos y solicitudes de vuelta por la misma conexión. Como el gateway la abrió, el NAT mantiene viva la ruta y reenvía las respuestas correctamente, así que el host puede efectivamente alcanzar el gateway aunque nunca hubiera podido marcarlo de forma directa.
Un túnel inverso es la misma idea hecha persistente y general. El gateway establece y mantiene un túnel hacia afuera a un punto conocido y alcanzable, y ese túnel entonces sirve como una ruta permanente por la cual el sistema central puede alcanzar el dispositivo en cualquier momento. Se llama inverso porque la conexión se establece en la dirección opuesta a la eventual solicitud de datos: el dispositivo que será alcanzado es el que abre el túnel, precisamente porque es el único lado que puede, dado que es el que está detrás del CGNAT. El punto al que el gateway se conecta hacia afuera debe él mismo ser alcanzable, y por eso típicamente vive en la nube o en un centro de datos con una dirección pública real.
También hay enfoques de perforación de agujeros, donde dos dispositivos detrás de NAT coordinan a través de un asistente para abrir conexiones salientes que embonan y se encuentran en medio, pero para el caso de SCADA el patrón por lo general es más simple, porque un lado, el sistema central, es alcanzable. El movimiento esencial en todos estos es el mismo: el dispositivo inalcanzable alcanza primero, y todo lo demás cabalga sobre la conexión que estableció. Diseñar el sistema en torno a que el gateway inicie el contacto, en lugar de ser contactado, es lo que hace posible una comunicación confiable sobre enlaces celulares CGNAT.
Diseño iniciado hacia afuera en SCADA de nube
El SCADA de nube embona con el modelo iniciado hacia afuera de forma natural, y esa es parte de por qué funciona tan suavemente sobre celular. La plataforma vive en un punto de nube alcanzable, y cada gateway remoto se conecta hacia afuera a ella y mantiene esa conexión arriba, enviando telemetría y recibiendo comandos por la ruta que abrió. Esto esquiva el problema del CGNAT por completo, porque nada necesita jamás alcanzar hacia adentro al gateway; la falta de IP pública del dispositivo es irrelevante cuando el dispositivo siempre es el que inicia el contacto. Una flota de gateways detrás de NAT de grado portadora se conecta a la plataforma sin que ninguno de ellos necesite ser individualmente direccionable desde afuera.
Este diseño también quita la carga operativa que las soluciones de alcance hacia adentro cargan. Las alternativas tradicionales al CGNAT, arreglar direcciones IP públicas o fijas para cada dispositivo, o abrir rutas entrantes, son costosas, delicadas y expanden la superficie de ataque, porque cualquier cosa alcanzable desde afuera es algo que puede sondearse y atacarse. Una arquitectura iniciada hacia afuera no necesita nada de eso: los gateways no exponen ninguna superficie entrante en absoluto, lo que es a la vez más simple de correr a través de muchos sitios e inherentemente más seguro, ya que no hay nada escuchando por conexiones no solicitadas que pueda explotarse.
Para un operador que corre muchos sitios remotos hacia una plataforma como Merobix, esto significa que la realidad de la ausencia de IP pública de la conectividad celular la maneja la arquitectura en lugar de combatirse. Los gateways en enlaces celulares CGNAT ordinarios alcanzan hacia afuera a la plataforma y se mantienen conectados, y el operador no tiene que adquirir un direccionamiento especial ni abrir rutas entrantes sólo para ver sus sitios. La combinación de conexiones iniciadas hacia afuera con controles de egreso estrictos, como restringir a dónde se le permite al gateway siquiera conectarse, da un modelo que es a la vez robusto contra el problema del CGNAT y difícil de atacar, que es justo lo que una flota de dispositivos de campo expuestos y difíciles de alcanzar necesita.
Preguntas frecuentes
¿Por qué un host de SCADA no puede sondear un gateway detrás de NAT de grado portadora?
Porque un dispositivo detrás de NAT de grado portadora no tiene una dirección IP pública que una conexión entrante pueda apuntar; comparte un pool de direcciones con muchos otros dispositivos y sólo es alcanzable para tráfico que corresponde a una conexión que él mismo inició. Un host que trata de sondear hacia adentro no tiene a dónde enviar su conexión, así que el modelo tradicional del maestro alcanzando cada dispositivo remoto falla sobre tal enlace. El dispositivo debe iniciar el contacto en su lugar.
¿Qué es un túnel inverso y cómo ayuda?
Un túnel inverso es una conexión que el gateway remoto abre hacia afuera a un punto alcanzable y mantiene viva, que luego sirve como una ruta permanente que el sistema central puede usar para alcanzar el dispositivo en cualquier momento. Se llama inverso porque el dispositivo que será alcanzado es el que establece la conexión, ya que es el único lado que puede cuando se asienta detrás de NAT de grado portadora. Los datos fluyen en ambos sentidos por la ruta que el gateway creó.
¿En qué se diferencia el cruce de NAT del cruce de cortafuegos?
El cruce de cortafuegos lidia con pasar una decisión de política de bloquear tráfico, mientras que el cruce de NAT para gateways celulares lidia con la ausencia de cualquier dirección pública que alcanzar en primer lugar. Un dispositivo detrás de NAT de grado portadora no tiene IP pública para que una conexión entrante apunte aun si ninguna regla de cortafuegos está bloqueando. El arreglo es arquitectónico: hacer que el dispositivo inicie la conexión hacia afuera, para que nunca necesite ser alcanzable desde afuera en absoluto.
Servicios de automatización
¿Necesita convertir esta información en un sistema que funcione?
Merobix integra SCADA, programa PLC Allen-Bradley y Siemens, y diseña y fabrica tableros de control industrial.
Las solicitudes de reunión se revisan antes de confirmarse.