Para desplegar un Secure Twin mediante IP NAT, añada en la pasarela L3 una regla de destination-NAT que reescriba los flujos elegidos de la dirección real del par a su gemelo overlay, y luego enrute el rango overlay hacia el Access Gate. El activo sigue apuntando a la dirección real y nunca se entera de que fue redirigido. Las reglas NAT viven en su router: este método es best-effort.
Cuando no puedes cambiar el activo y este se alcanza por IP en lugar de por nombre, la redirección puede vivir por completo en la red. El router o el gateway L3 por el que el tráfico ya pasa reescribe el destino de los flujos que elijas hacia el overlay Secure Twin, empujándolos a través de Access Gate. El activo sigue hablando con la dirección real de su par; el gateway hace el resto.
¿Qué problema resuelve IP NAT?
El activo (un HMI en la VLAN OT) apunta a la dirección real de su par (192.168.2.20), exactamente como siempre. No puede, o no quiere, reconfigurarlo, y se accede a él por IP y no por nombre. El único punto que sí controla es la pasarela L3 que su tráfico ya atraviesa.
Así que hace que trabaje la pasarela: aplica destination-NAT a los flujos que elija, reescribe 192.168.2.20 a su gemelo overlay 100.64.2.20 y los reenvía al Access Gate. Nada cambia en el activo, la redirección es una sola regla en el router.
Este método solo funciona si los dos extremos están en subredes distintas, de modo que su tráfico atraviese realmente la pasarela. Dos equipos del mismo segmento hacen ARP entre sí y conmutan las tramas directamente: el router nunca ve esos paquetes y una regla DNAT en él no puede capturarlos jamás. Para ese caso use ARP NAT (L2), que intercepta en capa 2.
Como la redirección se sitúa en la frontera L3 entre una zona OT y una zona IT, es también el lugar natural para trazar un conducto IEC 62443 entre ambas y para producir la evidencia de control de acceso que piden el artículo 21 de NIS2 y NERC CIP-005.
¿Cómo funciona IP NAT?
Tres piezas trabajan juntas, todas en la pasarela y el Access Gate, ninguna en el activo:
- El rango overlay define una correspondencia 1:1 (un "binat") entre cada dirección underlay y su dirección overlay Secure Twin. En este laboratorio la subred de servidores
192.168.2.Xcorresponde a100.64.2.Xen el overlay. - Una regla de destination-NAT en la pasarela L3 reescribe el destino de los flujos seleccionados, de la dirección underlay a su gemelo overlay, de modo que el paquete queda dirigido al overlay.
- Una ruta al Access Gate lleva el rango overlay hasta la pasarela, que rebinata la dirección overlay al dispositivo real, aplica la política de enclave y devuelve la respuesta por la pasarela.
Como la reescritura ocurre en la pasarela, la dirección del activo, su gateway y su enrutamiento quedan exactamente como estaban: nunca se entera de que su tráfico fue redirigido.
Laboratorio de referencia
El ejemplo presenta un equipo OT que alcanza un servidor en otra subred, el caso para el que está pensado este método: los dos extremos están separados por un salto enrutado, y ese salto es justo lo que usted controla.
| Elemento | Dirección | Función |
|---|---|---|
| HMI | 192.168.1.10 | Equipo OT (origen), sin cambios |
| Historian | 192.168.2.20 underlay, 100.64.2.20 overlay | Servidor con el que habla el HMI, en otra subred |
| Router / pasarela L3 | 192.168.1.1 (OT), 192.168.2.1 (servidor) | Aplica destination-NAT hacia el overlay |
| Access Gate | interconexión 100.65.0.4/29, overlay servidor 100.64.2.0/24 | Identidades overlay, aplicación de políticas |
La correspondencia conserva los dos últimos octetos: 192.168.2.X en la subred de servidores corresponde a 100.64.2.X en el overlay, así que el historian (192.168.2.20) tiene el gemelo overlay 100.64.2.20.
Cómo desplegar un Secure Twin mediante IP NAT (L3), paso a paso
1. Definir el rango overlay
Cree en Access Gate una subred para la red de servidores y asígnele un overlay, para que cada servidor reciba una dirección Secure Twin. En este laboratorio el underlay 192.168.2.0/24 corresponde al overlay 100.64.2.0/24. Para definir rangos y el puerto Secure Twin en la interfaz, vea Twin IPs.
2. Aplicar destination-NAT en la pasarela L3
En el router, añada una regla DNAT que reescriba el destino de los flujos que quiere filtrar, de la dirección underlay a su gemelo overlay. Acótela al flujo concreto para no tocar el resto del tráfico.
# En la pasarela L3: DNAT del tráfico del HMI hacia el historian, redirigido a su gemelo overlay
iptables -t nat -A PREROUTING -s 192.168.1.10 -d 192.168.2.20 -j DNAT --to-destination 100.64.2.20
El DNAT ocurre antes de la decisión de enrutamiento, así que el paquete ya va dirigido a 100.64.2.20 cuando la pasarela elige su siguiente salto.
3. Enrutar el rango overlay hacia el Access Gate
Envíe el rango overlay al Access Gate, para que el paquete recién NATeado se reenvíe a la pasarela y no hacia la subred de servidores.
ip route add 100.64.2.0/24 via 100.65.0.4 # interconexión Access Gate
4. Verificar la ruta completa
El HMI alcanza el historian en su dirección real, sin cambios, y la pasarela redirige silenciosamente el flujo a través del Access Gate.
ping -c3 192.168.2.20 # desde el HMI (192.168.1.10)
El Access Gate rebinata 100.64.2.20 al historian real (192.168.2.20), aplica la política y devuelve la respuesta por la pasarela. Un TTL reducido en la respuesta confirma que el flujo atravesó la pasarela en lugar de enrutarse directamente.
Cómo es la ruta completa del tráfico
HMI (192.168.1.10) [apunta al servidor REAL 192.168.2.20, sin cambios]
-> Router / pasarela L3 (192.168.1.1) [DNAT 192.168.2.20 -> 100.64.2.20, ruta al Access Gate]
-> Access Gate (interconexión 100.65.0.4/29, aplicación de políticas) [binat 100.64.2.20 -> 192.168.2.20]
-> Historian (192.168.2.20)
-> y de vuelta, des-NATeado hacia el HMI
Desde el punto de vista del HMI, alcanzó el historian en la dirección de siempre. En realidad la pasarela L3 reescribió el destino hacia el overlay y la sesión pasó por el Access Gate, sin ningún cambio de dirección, gateway o enrutamiento en ninguno de los dos equipos.
Cuándo usarlo y cuándo no
La redirección vive por completo en la pasarela L3. El activo nunca se reconfigura y no interviene ninguna resolución de nombres: el router simplemente reescribe el destino de los flujos que elija.
Esto encaja cuando controla la pasarela L3 pero no los activos, el par se alcanza por IP, y hay un salto enrutado en la ruta. Tenga en cuenta que las reglas NAT son suyas: usted las construye, las mantiene y las documenta, y su soporte es best-effort o premium en lugar de estándar.
Use otra forma cuando puede tocar los activos. Twin DNS y Twin IPs migran un activo cada vez y están totalmente soportados; Source-Based Routing mueve una subred completa con una política de enrutamiento en lugar de una regla NAT, y también está totalmente soportado. Si no hay ningún salto L3 entre los dos equipos, este método no puede funcionar y ARP NAT (L2) lo hace en el conmutador. Vea Elegir su despliegue de Secure Twin.